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

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

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

Dans ce webinaire, l’équipe d’Admiral nous a expliqué sa démarche : choisir un premier cas d’usage, réunir les équipes juridiques et de conformité dès le premier jour, puis passer d’un prototype fonctionnel à des modifications mises en production en quelques heures plutôt qu’en plusieurs semaines.

Points clés

• Commencez par un périmètre restreint, mais concret. Le premier cas d’usage d’Admiral en production, les devis de règlement dans 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 des intégrations back-end. De quoi valider l’architecture sans chercher à tout résoudre d’un coup.
• Rehaussez les exigences avant de passer à l’échelle, ne les abaissez pas. Admiral a conçu son système pour la production dès le premier jour, revu le rythme de sa gouvernance pour suivre celui de la technologie et associé les équipes juridiques et de conformité dès le premier jour dans le cadre d’un pilote clairement défini.
• La réglementation est le socle, pas l’ensemble de la conception. Admiral ajoute ses propres règles internes aux exigences réglementaires, utilise une logique déterministe pour tout ce qui doit être démontrable et oriente les clients vulnérables ou en détresse vers des conseillers humains.
• C’est en production que le vrai travail commence. Chaque modification d’agent est soumise à une suite complète de tests de simulation, puis déployée de 1 % à 100 % du trafic, un cycle passé de plusieurs semaines à quelques heures.

Commencer par un périmètre restreint, sans être trop limité

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

Selon Neely, c’est ce qui distingue les déploiements qui atteignent la production de ceux qui s’enlisent : le cas d’usage doit être suffisamment restreint pour être résolu dans un délai réaliste, mais assez complexe pour réellement mobiliser les systèmes qui l’entourent. Les devis de règlement convenaient car la conversation suit un nombre limité de scénarios tout en impliquant la téléphonie et des intégrations back-end. Cela a permis de valider l’architecture sans chercher à tout résoudre d’un coup.

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

• Périmètre défini, complexité réelle. Le cas d’usage doit présenter suffisamment de variations pour tester la téléphonie et l’intégration back-end, et ne pas se limiter à un scénario idéal prédéfini.
• Mise en production rapide. Plus un développement reste longtemps en cours, plus il faut attendre avant que de vraies conversations 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 que lorsque de vrais clients échangent avec le système.
• Volume et impact réunis. Admiral a commencé par des interactions simples et fréquentes, pour lesquelles des délais d’attente réduits et une résolution plus rapide amélioreraient visiblement l’expérience client.

Rehausser les exigences avant de passer à l’échelle

La direction d’Admiral a clairement indiqué que les agents IA devaient relever les exigences en matière de conformité et de tests, non les abaisser. Kampa l’a formulé sans détour : la norme de validation doit être plus stricte qu’auparavant, car le risque qu’un agent s’écarte du script ou enfreigne une règle est d’une nature différente de celui lié au jugement d’un conseiller humain.

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

• Concevoir pour la production, pas pour une preuve de concept. Kampa a demandé à ses équipes de concevoir dès le premier jour en vue de la 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 repensé le rythme de ses revues pour suivre l’évolution des modèles et outils sous-jacents.
• Équipes juridiques et conformité dès le premier jour. Interrogés sur le moment où les équipes juridiques et de conformité ont rejoint le projet, Kampa et Clark ont répondu immédiatement : dès le premier jour, avec un pilote clairement défini, portant sur un nombre précis d’appels, plutôt qu’une demande d’approbation sans limites.

Laisser la réglementation fixer le socle, pas toute la conception

Clark a précisé que les exigences réglementaires, comme le fait d’informer un client qu’il échange avec une IA ou de proposer un transfert vers un humain dans certaines juridictions, 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 laisser un appelant « escalader » une conversation pourtant susceptible d’être résolue.

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

Kampa a présenté l’approche globale comme une superposition de couches : « La réglementation n’est que le 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é où Admiral utilisait une logique déterministe ou non déterministe. Clark a expliqué que le raisonnement non déterministe convient bien pour comprendre l’intention d’un appelant ou détecter sa détresse, tandis que tout élément que l’entreprise doit pouvoir prouver, toute déclaration réglementaire obligatoire ou tout parcours que le client doit suivre doit s’exécuter de façon déterministe, sans aucune tolérance à l’improvisation de l’agent.

Neely a expliqué comment la structure des workflows d’ElevenLabs soutient concrètement cette approche : 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 ou non, 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

Plutôt qu’un transfert traditionnel entre les exigences métier et le travail d’ingénierie, Admiral et ElevenLabs ont organisé des ateliers sur site réunissant dans une même pièce 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 version 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 afin d’obtenir l’autorisation de poursuivre le développement.

Selon Clark, cette proximité a compté 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 traité la plateforme comme un moyen de transposer un processus métier existant plutôt que d’introduire un nouveau processus inconnu. Kampa a fait le lien avec la conduite du changement au sens large, en associant très tôt dirigeants, managers intermédiaires et équipes de première ligne, afin que la technologie fasse partie intégrante du fonctionnement de l’entreprise, et non d’un projet annexe.

C’est en production que le vrai travail commence

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

Deux enseignements ressortent 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, avant de constater 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, et non traités comme une formalité. Neely a indiqué qu’il semble facile d’écrire un prompt qui réussit quelques tests simulés, mais que le travail le plus difficile et le plus important consiste à concevoir des suites de tests qui mettent réellement l’agent à l’épreuve et à définir dès le départ des critères de réussite clairs. Admiral exécute désormais des centaines, voire des milliers de conversations simulées pour chaque modification avant son déploiement.

Concernant les résultats, Kampa a mis en avant le temps de traitement : les conversations pilotées par l’IA atteignent souvent la même résolution plus rapidement que celles gérées par des humains, notamment parce qu’il n’y a aucun silence pendant le chargement d’un système. Elle a également observé une hausse progressive du CSAT et des taux de résolution, marché par marché, au fil de cycles répétés de tests et d’ajustements, plutôt qu’en une seule avancée.

Ce qu’il faut retenir pour vous lancer

Le conseil de Neely aux équipes qui se lancent : choisissez un cas d’usage bien défini, mettez-le rapidement en production et laissez les vraies conversations 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, le déploiement vers 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 se projette plus loin : l’ambition ne se limite pas à automatiser les conversations, mais vise aussi à utiliser la même couche d’IA pour soutenir directement les conseillers humains, grâce à des transcriptions en direct, des suggestions de prochaine action et des simulations de formation.

Comme l’a résumé notre animateur, le fil conducteur de cette conversation est que réglementation et IA ne sont pas en opposition. 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, pas 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.