Récapitulatif du webinaire : comment l’un des plus grands assureurs d’Europe a mis des agents IA en production

Les clients des assurances appellent rarement lorsque tout va bien. Ils appellent après un accident, pour déclarer un sinistre ou en pleine crise. Cette conversation conditionne tout ce qui suit et constitue souvent la seule véritable interaction d’un client avec son assureur.

Admiral gère chaque année des millions de ces conversations au Royaume-Uni, en Italie, en France et en Espagne. L’entreprise utilise désormais des agents IA pour les gérer tout en restant conforme aux réglementations. 

Lors de ce webinaire, l’équipe d’Admiral a expliqué son approche : choisir un premier cas d’usage, associer les équipes juridiques et conformité dès le premier jour, puis passer d’un prototype opérationnel à des modifications déployées en production en quelques heures plutôt qu’en plusieurs semaines.

À retenir

• Commencez par un cas ciblé, mais concret. Le premier cas d’usage d’Admiral en production, les devis de règlement de son activité de crédit au Royaume-Uni, était suffisamment circonscrit pour être déployé dans un délai réaliste, tout en mobilisant la téléphonie et les intégrations back-end. De quoi valider l’architecture sans chercher à tout résoudre d’un coup.
• Relevez les exigences avant de passer à l’échelle, ne les abaissez pas. Admiral a conçu sa solution pour la production dès le premier jour, revu son rythme de gouvernance pour suivre l’évolution technologique et associé les équipes juridiques et conformité dès le premier jour dans le cadre d’un pilote clairement défini.
• La réglementation est un socle, pas l’ensemble de la conception. Admiral ajoute ses propres règles internes aux exigences réglementaires, recourt à une logique déterministe pour tout ce qui doit être démontrable et oriente les clients vulnérables ou en détresse vers des agents humains.
• Le véritable travail commence en production. Chaque modification d’un agent est soumise à une suite complète de tests de simulation et son déploiement passe de 1 % à 100 % du trafic, un cycle désormais réduit de plusieurs semaines à quelques heures.

Commencer par un cas ciblé, mais pas trop

Le premier cas d’usage d’Admiral en production concernait les devis de règlement de son activité de crédit au Royaume-Uni : un point de départ volontairement maîtrisé, plutôt que le problème le plus complexe de la liste. Kampa a décrit cette approche comme le choix d’un pays et d’une ligne d’activité pour expérimenter avant d’élargir le périmètre.

Selon Neely, c’est ce qui distingue les déploiements qui atteignent la production de ceux qui stagnent : le cas d’usage doit être suffisamment ciblé pour être résolu dans un délai réaliste, mais assez complexe pour réellement solliciter les systèmes qui l’entourent. Les devis de règlement ont fonctionné car la conversation offre un nombre limité de parcours, tout en mobilisant la téléphonie et les intégrations back-end. Ils ont ainsi permis de valider l’architecture sans tenter de tout résoudre à la fois.

Plusieurs éléments ont compté dans ce choix :

• Un périmètre défini, une complexité réelle. Le cas d’usage doit présenter assez de variations pour tester la téléphonie et l’intégration back-end, et non se limiter à un parcours idéal scénarisé.
• Une mise en production rapide. Plus un développement reste longtemps en cours, plus il faut attendre avant que de véritables conversations ne génèrent les retours qui améliorent réellement l’agent. Neely appelle cela « les 20 derniers pour cent », la partie qui n’apparaît qu’une fois que de vrais clients parlent au système.
• Volume et impact réunis. Admiral a commencé par des interactions simples et fréquentes, pour lesquelles des temps d’attente plus courts et une résolution plus rapide amélioreraient visiblement l’expérience client.

Relever les exigences avant de passer à l’échelle, pas les abaisser

La direction d’Admiral a clairement indiqué que les agents IA devaient relever les exigences de conformité et de test, non les abaisser. Kampa l’a formulé sans détour : les critères de validation doivent être plus stricts qu’auparavant, car le risque qu’un agent s’écarte du script ou enfreigne une règle diffère par nature de celui d’un agent humain exerçant son jugement.

Cette exigence s’est traduite très tôt par trois engagements de l’équipe :

• Concevoir pour la production, pas pour une preuve de concept. Kampa a demandé à ses équipes de concevoir dès le premier jour avec l’objectif d’une mise en production, plutôt que de mener une petite expérimentation qui ne passerait jamais à l’échelle.
• Une gouvernance au rythme de la technologie. Kampa a souligné qu’un processus de gouvernance prenant six mois pour approuver une initiative risque de valider une technologie déjà obsolète au moment de son déploiement. Admiral a revu le rythme de ses évaluations pour l’adapter à l’évolution rapide des modèles et des outils sous-jacents.
• Les équipes juridiques et conformité dès le premier jour. Lorsqu’on leur a demandé quand les équipes juridiques et conformité avaient rejoint le projet, Kampa et Clark ont toutes deux répondu immédiatement : dès le premier jour, dans le cadre d’un pilote clairement défini, avec un nombre d’appels fixé, plutôt qu’une demande de validation sans limites précises.

Laisser la réglementation définir le socle, pas l’ensemble de la conception

Clark a précisé que les exigences réglementaires, telles que l’obligation d’informer un client qu’il parle à une IA ou, dans certaines juridictions, de proposer un transfert vers un humain, varient entre le Royaume-Uni, l’Italie, la France et l’Espagne. Admiral a conçu ses agents pour gérer ces différences sans permettre à un appelant de recourir au « transfert » pour abandonner une conversation qui peut être résolue.

Certaines conversations sont entièrement écartées du périmètre de l’agent : Admiral oriente les clients vulnérables ou en détresse vers des agents humains, l’IA étant entraînée à détecter les signaux déclenchant ce transfert.

Kampa a présenté cette approche globale comme une superposition de niveaux : « La réglementation n’est qu’un socle », auquel s’ajoutent les règles internes et les standards culturels d’Admiral, parfois plus exigeants que la réglementation.

Cette superposition a également déterminé les cas où Admiral utilise une logique déterministe ou non déterministe. Clark a expliqué que le raisonnement non déterministe convient bien à la compréhension de l’intention de l’appelant ou à la détection de la détresse, tandis que tout élément que l’entreprise doit pouvoir démontrer, toute déclaration réglementaire obligatoire ou tout parcours que le client doit suivre doit fonctionner de manière déterministe, sans aucune tolérance pour l’improvisation de l’agent.

Neely a expliqué comment la structure des workflows d’ElevenLabs rend cela possible en pratique : les agents sont conçus comme un ensemble de sous-agents spécialisés, avec des contrôles déterministes, tels que l’authentification, qui activent ou restreignent des fonctionnalités selon qu’une condition est remplie, plutôt que de laisser le modèle déduire ce qu’il est autorisé à faire.

Co-construire avec les personnes qui maîtrisent le processus

Au lieu d’un transfert traditionnel entre les exigences métier et la réalisation technique, Admiral et ElevenLabs ont organisé des ateliers sur site réunissant dans une même salle les personnes qui connaissaient le cas d’usage, l’équipe d’ingénierie et l’équipe de téléphonie. Selon Neely, le premier atelier a produit en quatre ou cinq heures une v0 fonctionnelle de l’agent, connectée au back-end et à la téléphonie, que Kampa et Clark ont ensuite pu présenter en interne pour obtenir l’autorisation de poursuivre le développement.

Clark a indiqué que cette proximité est restée importante au-delà du premier prototype : les responsables métier sont désormais suffisamment proches de la technologie pour effectuer eux-mêmes certaines modifications, car l’atelier a présenté la plateforme comme un moyen de transposer un processus métier existant, plutôt que d’introduire un nouveau processus inconnu. Kampa a élargi ce constat à la conduite du changement, en associant tôt les dirigeants, les managers intermédiaires et les équipes de terrain afin que la technologie s’intègre au fonctionnement réel de l’entreprise, au lieu de rester un projet parallèle.

Le véritable travail commence en production

Une fois en ligne, Admiral traite chaque modification d’agent, importante ou mineure, de la même façon : comme une branche soumise à une suite complète de tests de simulation avant d’atteindre les clients. Clark a décrit un déploiement démarrant à 1 % du trafic, avec un suivi en temps réel des indicateurs de satisfaction et de résolution, puis une extension à 100 % lorsque les résultats se maintiennent. Ce cycle est passé de plusieurs semaines à quelques heures.

Deux enseignements se dégagent de ce processus d’itération :

• Localiser la langue, pas seulement les mots. Admiral a d’abord rédigé tous les prompts et workflows en anglais, puis a constaté que les performances en France, en Espagne et en Italie ne correspondaient pas à celles du Royaume-Uni. Réécrire les prompts directement dans la langue de chaque marché, plutôt que de les traduire depuis l’anglais, a permis d’obtenir des réponses conformes aux attentes et à la culture locales des clients.
• Les tests de simulation doivent être pris au sérieux, pas considérés comme une formalité. Neely a souligné qu’il paraît facile d’écrire un prompt qui réussit une poignée de tests simulés, mais que le travail le plus difficile et le plus important consiste à construire des suites de tests qui mettent réellement l’agent à l’épreuve et à définir clairement les critères de réussite dès le départ. Admiral soumet désormais chaque modification à des centaines, voire des milliers, de conversations simulées avant son déploiement.

Concernant les résultats, Kampa a mis en avant le temps de traitement comme indicateur clé : les conversations pilotées par l’IA atteignent souvent la même résolution plus rapidement que celles menées par des humains, notamment parce qu’il n’y a aucun silence pendant le chargement d’un système. Elle a également constaté une progression graduelle du CSAT et des taux de résolution, marché après marché, grâce à des cycles répétés de tests et d’ajustements, plutôt qu’à une avancée unique.

Ce qu’il faut retenir pour vous lancer

Le conseil de Neely aux équipes qui débutent : choisissez un cas d’usage bien défini, mettez-le rapidement en production et laissez les conversations réelles avec les clients, plutôt que davantage de tests avant le lancement, révéler les cas limites. Clark a ajouté qu’une fois les intégrations aux deux extrémités, la téléphonie et les systèmes internes, validées, l’extension à d’autres cas d’usage s’accélère progressivement, car l’équipe sait déjà quelles évaluations et quels indicateurs comptent.

La conclusion de Kampa porte plus loin : l’ambition dépasse l’automatisation des conversations et vise à utiliser la même couche d’IA pour assister directement les agents humains, grâce à des transcriptions en direct, des suggestions de prochaine action et des simulations de formation.

Comme l’a résumé notre hôte, le fil conducteur de cette conversation est que réglementation et IA ne s’opposent pas. Concevoir dès le premier jour en tenant compte de l’auditabilité, de la cohérence et du transfert vers un humain a rendu les agents d’Admiral plus rigoureux, non moins.

Regarder la session complète

Regardez la session complète ici, y compris la démonstration en direct et les questions-réponses avec le public.