Pourquoi les assureurs ne devraient pas commencer par créer un chatbot

Ce qu’il faut retenir

• Un chatbot est une interface : il ne remplace ni le cadrage du processus, ni la qualité des données, ni les règles de contrôle.
• Les premiers gains se trouvent souvent dans la qualification des demandes, l’analyse documentaire, la complétude des dossiers et l’assistance aux gestionnaires.
• Le premier cas d’usage doit être choisi selon sa valeur opérationnelle, sa mesurabilité, sa faisabilité et le coût métier d’une erreur.
• Une mise en production durable exige des sources versionnées, des preuves visibles, une supervision conçue et des indicateurs suivis dans le temps.
• Le chatbot devient pertinent lorsqu’il s’appuie sur ces fondations et s’intègre à un parcours métier clairement délimité.

Lorsqu’un comité de direction décide « d’accélérer sur l’intelligence artificielle », le chatbot arrive presque toujours en tête de liste. Il se voit, se démontre facilement et donne en quelques minutes l’impression d’un changement profond. Pourtant, dans l’assurance, commencer par une interface conversationnelle revient souvent à poser une belle porte d’entrée devant un bâtiment dont les pièces, les circulations et les règles d’accès ne sont pas encore organisées.

Le problème n’est pas que le chatbot soit inutile. Bien conçu, relié aux bonnes sources et placé au bon endroit dans un processus, il peut améliorer la recherche d’information, l’assistance aux gestionnaires ou l’orientation d’un assuré. Le problème est d’en faire le point de départ, alors que la valeur se trouve généralement plus en amont : comprendre une demande, retrouver un contrat, classer des pièces, vérifier la complétude d’un dossier, rapprocher des données, détecter une incohérence, préparer une décision et tracer les contrôles.

Ce guide propose une méthode concrète pour choisir un premier projet IA dans une compagnie, une mutuelle, une institution de prévoyance, un courtier ou une délégation de gestion. Il explique pourquoi le réflexe chatbot produit tant de pilotes décevants, quels cas d’usage privilégier, comment mesurer la valeur et à quelles conditions une interface conversationnelle devient réellement pertinente.

1. L’illusion du chatbot comme stratégie IA

Une démonstration séduisante n’est pas un processus opérationnel

Une démonstration de chatbot suit souvent un scénario idéal : une question claire, un document propre, une réponse courte et un utilisateur coopératif. L’environnement réel est différent. Un assuré peut mélanger plusieurs demandes, citer un ancien numéro de contrat, joindre une photo floue, employer un vocabulaire non technique ou omettre l’information qui permettrait de trancher. Un gestionnaire, lui, a besoin de savoir quelle version d’un avenant s’applique, d’où vient chaque donnée, quelles actions sont autorisées et qui devra valider la suite.

La fluidité de la conversation masque alors quatre difficultés. Premièrement, le système doit identifier le bon contexte. Deuxièmement, il doit accéder à des sources fiables et à jour. Troisièmement, il doit distinguer ce qu’il sait, ce qu’il déduit et ce qu’il ignore. Quatrièmement, il doit transformer une réponse en action métier sans contourner les habilitations, les contrôles ou la traçabilité. La génération de texte n’est que la partie visible de cet ensemble.

Un prototype peut donc sembler convaincant tout en étant très éloigné d’un service exploitable. Répondre correctement à dix questions préparées ne prouve ni la robustesse sur les cas rares, ni la bonne gestion des versions, ni la capacité à résister à une instruction malveillante, ni la conformité du traitement de données. La vraie question n’est pas « le modèle sait-il répondre ? », mais « le système complet améliore-t-il un résultat métier mesurable avec un niveau de risque acceptable ? ».

Le chatbot concentre les attentes sur la forme

Parce qu’il est immédiatement visible, le chatbot attire les commentaires sur le ton, le logo, l’animation, le temps de réponse ou la formulation. Ces éléments comptent, mais ils détournent parfois l’attention de sujets plus déterminants : la couverture documentaire, la qualité des métadonnées, la définition du contrat en vigueur, les règles d’escalade, le taux de faux positifs ou le coût d’une erreur.

Il peut aussi créer une promesse implicite très large. Une zone de texte libre invite l’utilisateur à tout demander. Or un premier système est rarement capable de traiter « tout le service client » ou « tous les contrats ». Il faut limiter son périmètre, ce qui produit une tension entre l’apparence généraliste de l’interface et la spécialisation réelle de la solution. Une interface structurée — choix d’une opération, dépôt d’une pièce, confirmation d’un contrat — rend parfois mieux le service parce qu’elle réduit l’ambiguïté.

Le coût caché d’une réponse plausible

Les modèles de langage sont optimisés pour produire une suite de mots cohérente. Cette capacité est précieuse pour synthétiser, reformuler ou préparer un brouillon. Elle devient dangereuse quand la vraisemblance est confondue avec la vérité contractuelle. Une réponse peut être claire, polie et juridiquement fausse ; citer une garantie qui appartient à une autre version ; oublier une exclusion ; ou affirmer qu’une pièce n’est pas nécessaire alors que la règle dépend d’un attribut absent.

Dans l’assurance, une bonne réponse doit souvent être accompagnée d’une preuve : clause, page, version, date d’effet, donnée du dossier, règle interne ou événement horodaté. La conception doit donc partir de la preuve et du contrôle, puis décider de la meilleure manière de restituer le résultat. Commencer par le chatbot inverse cet ordre.

Principe directeur : ne demandez pas d’abord « que pourrait dire notre assistant ? ». Demandez « quelle décision, quelle action ou quel délai voulons-nous améliorer, et quelles preuves permettent de le faire sans perdre la maîtrise ? ».

2. Pourquoi l’assurance rend le sujet plus exigeant

Un même mot peut recouvrir plusieurs réalités contractuelles

Des termes comme franchise, bénéficiaire, conducteur, sinistre, résiliation ou incapacité semblent familiers. Leur sens opérationnel dépend pourtant du produit, de la police, des conditions particulières, des avenants et de la date considérée. Une réponse générique trouvée dans une base documentaire peut être exacte en théorie et inapplicable au dossier consulté.

Le système doit savoir quel document fait foi, si un avenant remplace une clause, si une garantie était active au jour du fait générateur et si l’utilisateur est habilité à accéder au contrat. Cela implique une modélisation temporelle et documentaire. Un simple moteur de recherche vectorielle sur un dossier partagé ne suffit pas à garantir cette cohérence.

Les flux combinent texte libre, documents et données structurées

Une demande d’assurance arrive rarement sous la forme d’un enregistrement complet. Elle peut être constituée d’un e-mail, de pièces jointes, d’un formulaire, d’images, d’un historique d’échanges et de données déjà présentes dans le logiciel métier. Pour comprendre la situation, il faut classer les pièces, extraire certains champs, rapprocher les identités et repérer les contradictions.

Supposons qu’un courtier reçoive une demande d’attestation. Le texte « pouvez-vous m’envoyer l’attestation à jour ? » est simple. Le traitement réel peut nécessiter d’identifier l’entreprise, de retrouver le contrat actif, de vérifier le paiement, de choisir le bon millésime, de contrôler la portée géographique et de produire ou récupérer le document. Le texte de la réponse représente une fraction du travail.

Les décisions ont des conséquences asymétriques

Une erreur n’a pas le même coût selon le cas d’usage. Mal classer une demande interne peut provoquer quelques minutes de délai. Indiquer à tort qu’un risque est garanti, exposer des données de santé ou influencer une tarification peut avoir des conséquences commerciales, réglementaires et humaines importantes. Une stratégie IA mature adapte donc les contrôles, les tests et l’autonomie au niveau de risque.

Cette asymétrie invite à commencer par des tâches préparatoires : extraction avec preuve, recherche sourcée, détection d’éléments manquants, proposition de classement ou génération d’un brouillon soumis à validation. Elles apportent une valeur concrète tout en laissant la décision finale à une personne habilitée.

La confiance dépend de la capacité à expliquer et corriger

Un gestionnaire adopte un outil quand il peut vérifier rapidement son résultat, corriger une erreur et comprendre ce qui a conduit à la proposition. Une longue réponse sans source augmente parfois le temps de travail : il faut alors tout relire dans les documents d’origine. À l’inverse, une synthèse courte qui affiche les passages sources, les champs incertains et les contrôles déclenchés accélère réellement la décision.

La supervision humaine ne doit pas être un slogan. Elle doit être conçue : qui revoit quoi, selon quel seuil, avec quelles informations, dans quel délai, et comment la correction alimente-t-elle le suivi de qualité ? Un bouton « valider » n’est pas une supervision si l’utilisateur ne dispose pas des éléments permettant de juger.

3. Où se trouve réellement la valeur : avant, pendant et après la conversation

Avant : rendre l’information exploitable

Avant de répondre, il faut généralement préparer le contexte. Cela comprend la classification des documents, l’extraction des données utiles, la résolution des doublons, l’identification de la version applicable, la détection des pièces manquantes et le rattachement au bon dossier. Ces tâches sont peu spectaculaires, mais elles conditionnent tout ce qui suit.

Un projet qui réduit de plusieurs minutes la préparation de milliers de dossiers peut créer davantage de valeur qu’un chatbot public peu utilisé. Surtout, il produit des composants réutilisables : taxonomie documentaire, service d’extraction, référentiel de règles, index de recherche, mécanisme de citation et journal d’audit.

Pendant : assister la décision, pas seulement rédiger

Au moment du traitement, l’IA peut présenter une synthèse structurée, comparer les déclarations aux justificatifs, signaler une incohérence ou proposer la prochaine action. Le résultat doit être adapté au rôle. Un souscripteur veut comprendre le risque et les points à approfondir ; un gestionnaire veut connaître l’état du contrat et l’opération possible ; un conseiller veut une réponse claire et sourcée ; un responsable veut suivre les délais, les erreurs et les exceptions.

L’interface peut être conversationnelle, mais elle peut aussi prendre la forme d’une checklist, d’un panneau latéral, d’une timeline, d’un formulaire prérempli ou d’une file d’anomalies. Le bon format est celui qui réduit la charge cognitive et sécurise l’action.

Après : exécuter, tracer et apprendre

Une réponse sans suite opérationnelle oblige l’utilisateur à copier-coller, retrouver le dossier et refaire une partie du travail. La valeur augmente lorsque le système peut créer une tâche, préparer un courrier, mettre à jour un champ, demander une pièce ou affecter une demande — dans les limites prévues et avec la validation appropriée.

Chaque action doit laisser une trace : sources consultées, version du système, règles déclenchées, proposition, validation, correction et résultat. Ces traces servent à l’audit, mais aussi à l’amélioration. Elles permettent de savoir dans quels cas le système aide réellement, où les utilisateurs le corrigent et quelles évolutions ont dégradé la qualité.

La bonne unité de valeur est le résultat métier

Le nombre de conversations ou de messages générés n’est pas un indicateur suffisant. Il faut mesurer des résultats tels que le délai avant première action, le taux de dossiers complets, le nombre de réaffectations, le temps de recherche documentaire, la proportion de réponses sourcées, le taux de correction ou les échéances manquées.

Cette discipline évite le « théâtre de l’IA » : beaucoup d’activité visible, peu d’amélioration démontrée. Elle facilite aussi l’arbitrage budgétaire, car le projet peut être comparé à d’autres leviers d’optimisation du processus.

4. Six exemples métier détaillés : ce qu’il vaut mieux construire avant un chatbot

Exemple 1 — Qualification des e-mails entrants

Une boîte de gestion reçoit des demandes d’attestation, des déclarations de sinistre, des pièces, des relances, des résiliations, des réclamations et des messages de partenaires. Le premier enjeu n’est pas de converser avec l’expéditeur : il est d’identifier le client, le contrat ou le sinistre, de comprendre l’intention, de détecter l’urgence et d’envoyer la demande dans la bonne file.

Un système utile analyse le nouveau message sans confondre la signature ou l’historique cité, lit les pièces jointes, propose un rattachement et explique les indices utilisés. Les demandes bien reconnues peuvent être routées automatiquement ; les rapprochements ambigus restent en revue. Ensuite seulement, un brouillon de réponse peut être préparé.

Exemple concret : un message intitulé « dossier Dupont » contient un constat amiable et une phrase demandant si le véhicule de remplacement est couvert. Le système doit détecter deux intentions — déclaration et question de garantie —, retrouver le contrat automobile, créer le bon circuit sinistre et fournir au gestionnaire les clauses pertinentes. Un chatbot qui répond uniquement à la question risque d’oublier l’ouverture du dossier.

Pour voir comment ce cas d’usage peut être conçu, mesuré et déployé, consultez l’étude de cas consacrée à la qualification des e-mails entrants en assurance.

Exemple 2 — Analyse des dossiers de souscription

Un dossier professionnel peut contenir un questionnaire, un extrait d’immatriculation, des bilans, un relevé de sinistralité, des attestations, des contrats antérieurs et des échanges libres. Le souscripteur consacre une part importante de son temps à vérifier que les informations sont présentes et cohérentes avant d’exercer son expertise.

L’IA peut classer les documents, extraire les champs avec leur source, comparer l’activité déclarée aux justificatifs, relever une divergence de chiffre d’affaires, signaler une période sans antécédent ou préparer une synthèse. Elle ne doit pas masquer l’incertitude : un champ mal lu est présenté comme tel et orienté vers une validation.

Exemple concret : le formulaire mentionne une activité de conseil, tandis qu’une facture et le site de l’entreprise suggèrent aussi une prestation de mise en œuvre. Le système ne doit pas conclure seul à une fausse déclaration. Il doit faire apparaître l’écart, citer les éléments et proposer une question de clarification au souscripteur.

Ce fonctionnement est détaillé dans l’étude de cas sur l’analyse automatique des dossiers de souscription.

Exemple 3 — Contrôle des pièces et relance intelligente

Les relances documentaires génériques créent de la friction : elles réclament parfois une pièce déjà reçue, n’expliquent pas pourquoi un document est inexploitable ou multiplient les allers-retours. Une IA bien cadrée peut construire une checklist conditionnelle, reconnaître les pièces malgré des noms de fichiers variables, vérifier quelques critères objectifs et préparer une demande consolidée.

Exemple concret : un relevé d’information automobile est présent, mais il ne couvre pas toute la période exigée. Le bon résultat n’est ni « document reçu » ni « document manquant ». Il faut indiquer la période couverte, la période à justifier, la règle qui déclenche la demande et le type de document acceptable. Le gestionnaire peut alors envoyer une relance précise.

Exemple 4 — Recherche et synthèse contractuelles sourcées

Une question de garantie exige souvent de rapprocher conditions générales, conditions particulières, avenants, définitions et dates d’effet. Un moteur de recherche augmenté peut retrouver les passages pertinents, mais la restitution doit conserver la hiérarchie et la version des documents.

Exemple concret : un assuré demande si le vol d’un ordinateur dans un véhicule est couvert. La réponse dépend du contrat, du lieu, des circonstances, de l’effraction, du plafond, de la franchise et parfois des horaires. Le système doit présenter les clauses concernées et les faits encore inconnus. Il peut préparer une réponse conditionnelle, pas transformer une information incomplète en certitude.

Exemple 5 — Préparation des opérations de gestion

Résiliation, changement d’adresse, ajout d’un véhicule, demande d’attestation ou modification d’un bénéficiaire suivent des procédures et des règles différentes. Un assistant interne peut reconnaître l’opération, réunir les informations, indiquer les pièces nécessaires et préremplir l’action. La validation et l’exécution restent gouvernées par les habilitations.

Exemple concret : une entreprise demande de retirer un établissement de son contrat. Avant de préparer l’avenant, le système vérifie l’identité du demandeur, la date souhaitée, l’existence d’un sinistre en cours, les conséquences sur les garanties et les documents nécessaires. Il prépare ensuite une tâche structurée. Une simple réponse « votre demande est prise en compte » ne réalise aucun de ces contrôles.

Exemple 6 — Détection des anomalies et des écarts

De nombreux processus produisent des écarts détectables : montant incohérent entre deux pièces, date d’effet antérieure à une validation, doublon de paiement, document rattaché au mauvais assuré, garantie citée hors période ou tâche close sans événement attendu. Une IA peut aider à prioriser ces anomalies, à condition que les règles déterministes et les modèles statistiques soient clairement distingués.

Exemple concret : une attestation est prête à être envoyée alors que l’appel de cotisation est toujours impayé et que la procédure impose une retenue. Le système doit bloquer ou alerter selon la règle explicite. Il n’est pas nécessaire d’utiliser un modèle génératif pour cette décision ; celui-ci peut en revanche expliquer le blocage au gestionnaire et préparer le message approprié.

5. L’architecture utile avant l’interface

Une solution robuste sépare les responsabilités. Cette séparation évite qu’un modèle de langage devienne à la fois moteur de recherche, base de données, moteur de règles et système d’exécution. Le modèle intervient là où ses capacités sont pertinentes : compréhension de texte, extraction tolérante, synthèse, reformulation ou proposition. Les données de référence, les règles critiques et les actions restent portées par des composants contrôlables.

1. Les systèmes de référence

Contrats, clients, sinistres, paiements, documents et tâches doivent conserver un système maître. L’IA ne doit pas créer une vérité parallèle difficile à réconcilier. Lorsqu’une donnée est reprise dans une synthèse, son origine et sa date doivent pouvoir être retrouvées.

2. Une couche d’accès gouvernée

Les connecteurs vers le logiciel métier, la GED, le CRM, la messagerie ou les référentiels appliquent les habilitations et normalisent les formats. Les droits ne peuvent pas être contrôlés uniquement dans le chatbot : ils doivent s’appliquer à chaque requête vers chaque source. Cela limite le risque qu’un utilisateur obtienne indirectement une information qu’il ne pourrait pas consulter dans l’outil d’origine.

3. La préparation documentaire

OCR, classification, découpage, extraction, métadonnées, détection des versions et indexation constituent un chantier à part entière. Une mauvaise préparation contamine toute la chaîne. Un document scanné sans texte, une page manquante ou un avenant mal daté ne seront pas réparés par un prompt plus élégant.

4. La recherche avec contexte et preuve

Une architecture de type RAG — génération augmentée par recherche — peut aider à répondre à partir d’un corpus. Elle doit toutefois filtrer par client, produit, version, date et habilitation avant de rechercher la proximité sémantique. Les passages retenus sont présentés avec leur référence. Un score de similarité n’est pas une preuve que la clause s’applique.

5. Les règles métier explicites

Les règles stables et critiques gagnent à être représentées hors du prompt : seuils, pièces obligatoires, validations, opérations interdites, délais ou conditions d’escalade. Elles sont versionnées, testées et rattachées à un propriétaire. Le modèle peut expliquer leur résultat, mais ne doit pas les réinventer à chaque requête.

6. L’orchestration des étapes

Un traitement peut comporter plusieurs étapes : identifier le dossier, lire les pièces, appliquer des contrôles, demander une validation et exécuter une action. L’orchestrateur gère l’état, les reprises, les délais, les erreurs et les confirmations. Il empêche qu’une conversation interrompue laisse une opération dans un état incohérent.

7. Les garde-fous et la supervision

Les garde-fous couvrent la validation des entrées, la limitation du périmètre, la détection des données sensibles, les sorties structurées, les seuils de confiance, les revues humaines et les confirmations avant action. Ils doivent être adaptés au cas d’usage : une réponse documentaire interne et une décision de tarification n’appellent pas le même niveau de contrôle.

8. L’observabilité et l’évaluation continue

Le système journalise les temps de traitement, erreurs techniques, sources utilisées, sorties, corrections humaines et résultats métier. Un jeu d’évaluation représentatif est rejoué à chaque évolution importante. Sans cette discipline, une mise à jour de modèle ou de corpus peut dégrader silencieusement un cas rare mais critique.

6. Risques, conformité et gouvernance : les traiter dès le cadrage

La conformité n’est pas une étape ajoutée juste avant la mise en production. Elle influence le choix du cas d’usage, les données accessibles, le niveau d’autonomie, les informations affichées et les preuves à conserver. L’objectif n’est pas de ralentir le projet, mais d’éviter qu’un prototype prometteur doive être entièrement reconstruit lorsqu’il rencontre les exigences du réel.

Données personnelles : maîtriser la finalité et la minimisation

Une zone de texte libre permet à l’utilisateur de transmettre des informations que l’organisation n’avait pas prévu de collecter : données de santé, détails financiers, identité d’un tiers ou récit d’un sinistre. La CNIL rappelle dans ses recommandations sur les chatbots l’importance d’anticiper ces données, d’informer les personnes et de prévoir des mécanismes de minimisation et de purge adaptés.

Le cadrage doit préciser quelles données sont nécessaires, pour quelle finalité, pendant combien de temps, dans quelles zones géographiques elles circulent et quels sous-traitants interviennent. Il faut aussi distinguer les journaux nécessaires à la sécurité ou à l’audit des conversations conservées par défaut « au cas où ». L’utilité future hypothétique ne remplace pas une finalité définie.

Les fiches pratiques IA de la CNIL constituent un point de départ utile pour analyser les traitements de données personnelles lors du développement et de l’utilisation d’un système d’IA. Selon le contexte, le délégué à la protection des données doit être associé et une analyse d’impact peut être nécessaire.

AI Act : raisonner par usage et par risque

Le règlement européen sur l’intelligence artificielle, règlement (UE) 2024/1689, adopte une approche fondée sur les risques. Il ne faut donc pas classer « le chatbot » en bloc. La finalité du système, les personnes concernées, l’influence sur la décision et le secteur d’application déterminent les obligations.

Le règlement accorde notamment une attention particulière aux systèmes utilisés pour l’évaluation du risque et la tarification des personnes physiques en assurance vie et santé. À l’inverse, une tâche procédurale étroite ou préparatoire peut relever d’un profil différent selon ses caractéristiques concrètes. L’analyse doit être documentée avec les fonctions juridique, conformité, risques et métier ; cet article ne remplace pas un avis juridique appliqué au projet.

Gouvernance sectorielle : proportionnalité, responsabilité et robustesse

L’opinion 2025 de l’EIOPA sur la gouvernance et la gestion des risques liés à l’IA insiste sur une approche proportionnée au risque et sur des responsabilités clairement définies. L’EIOPA avait déjà formulé des principes de gouvernance pour une IA éthique et digne de confiance dans l’assurance, couvrant notamment l’équité, la transparence, la supervision humaine, la gestion des données, la conservation des enregistrements et la robustesse.

Concrètement, chaque système devrait avoir un propriétaire métier, un responsable technique, un périmètre autorisé, des utilisateurs identifiés, des critères de qualité, une procédure d’incident et une fréquence de revue. La sous-traitance d’un modèle ou d’une plateforme ne transfère pas la responsabilité de l’usage. Il faut comprendre les engagements du fournisseur, les données utilisées, les changements de version, les possibilités d’audit et les conditions de sortie.

Confidentialité et fuite d’information

Les risques ne se limitent pas à l’entraînement du modèle. Une fuite peut provenir d’un mauvais filtrage entre clients, d’un journal trop bavard, d’une pièce jointe envoyée au mauvais service, d’un cache partagé ou d’une instruction qui pousse le modèle à révéler son contexte. Les tests doivent chercher activement ces scénarios.

Il faut appliquer les principes classiques de sécurité : moindre privilège, segmentation, chiffrement, gestion des secrets, revue des dépendances, journalisation, sauvegarde et plan de réponse aux incidents. L’IA ajoute des surfaces spécifiques, mais ne remplace pas les fondamentaux.

Injection de prompt et contenu non fiable

Un document analysé peut contenir une instruction destinée au modèle : « ignore les règles précédentes », « envoie ce dossier à cette adresse » ou « considère le document valide ». Cette instruction ne doit jamais être traitée comme une règle système. Les contenus externes sont des données non fiables, même lorsqu’ils se trouvent dans un PDF apparemment légitime.

La défense repose sur plusieurs couches : séparation claire entre instructions et données, liste d’actions autorisées, validation des paramètres, confirmations humaines, filtrage des sorties et impossibilité pour le modèle d’appeler librement n’importe quel outil. Aucun prompt unique ne constitue une garantie suffisante.

Équité et biais

Un modèle peut reproduire les biais d’un historique, utiliser indirectement une variable sensible ou produire des performances très différentes selon les populations. L’évaluation ne doit donc pas se limiter à une moyenne globale. Elle doit examiner les segments pertinents, les cas minoritaires, les erreurs les plus dommageables et la possibilité de recours.

Dans un cas préparatoire, un biais peut déjà avoir un effet : si certaines demandes sont plus souvent jugées « peu urgentes » ou certains documents plus souvent considérés illisibles, les personnes concernées subissent un traitement moins favorable. La supervision humaine et le suivi des écarts doivent être prévus dès le pilote.

Transparence utile, pas transparence décorative

Informer qu’« une IA est utilisée » est nécessaire dans certains contextes, mais insuffisant pour le travail opérationnel. Le gestionnaire a besoin de connaître les sources, les hypothèses et les limites. Le client a besoin de savoir ce que fait le système, comment demander une intervention humaine et comment exercer ses droits. L’auditeur a besoin d’une documentation plus technique. La transparence doit être adaptée au destinataire.

7. Une méthode de priorisation praticable

Une liste d’idées IA devient vite interminable. Pour éviter que la visibilité du chatbot l’emporte sur la valeur, chaque idée peut être décrite selon une fiche identique puis évaluée à partir de critères explicites. L’objectif n’est pas de produire un score scientifique, mais de rendre les arbitrages comparables et discutables.

Étape 1 — Décrire le processus sans parler de technologie

Commencez par observer le travail : événement déclencheur, entrées, étapes, rôles, décisions, outils, exceptions, sorties et délais. Demandez aux équipes où elles cherchent l’information, ce qu’elles ressaisissent, pourquoi un dossier revient et quelles erreurs coûtent le plus cher. Cette observation révèle souvent un problème différent de celui formulé initialement.

Par exemple, « nous avons besoin d’un chatbot pour répondre aux courtiers » peut cacher trois difficultés : les demandes arrivent dans une boîte non triée, les informations contractuelles sont dispersées et les réponses doivent être validées par une petite équipe experte. Le premier chantier pertinent peut alors être le routage, puis la recherche sourcée, puis la préparation de brouillons.

Étape 2 — Définir un résultat observable

Une formulation utile ressemble à : « réduire le délai médian entre la réception d’un e-mail et son affectation correcte », « augmenter la part de dossiers complets après la première relance » ou « réduire le temps nécessaire pour retrouver les clauses qui justifient une réponse ». Une formulation trop vague — « améliorer l’expérience » ou « utiliser l’IA générative » — ne permet pas d’évaluer le pilote.

Étape 3 — Mesurer le volume et la friction

Recueillez un ordre de grandeur du volume, du temps moyen, de la variabilité et des reprises. Il est inutile de chercher une précision artificielle : quelques semaines d’observation et un échantillon de dossiers peuvent suffire pour décider si le sujet mérite une exploration. Il faut compter le temps total, y compris la recherche, les changements d’outil, les relances et les corrections.

Étape 4 — Évaluer la faisabilité informationnelle

Les données nécessaires existent-elles ? Sont-elles accessibles, lisibles, reliées au bon dossier et suffisamment représentatives ? Les règles peuvent-elles être expliquées ? Dispose-t-on de dossiers déjà traités permettant de construire un jeu d’évaluation ? Une idée à forte valeur mais sans vérité terrain peut nécessiter un chantier préalable de données.

Étape 5 — Évaluer le risque d’erreur

Pour chaque sortie, demandez ce qui arrive si elle est fausse, incomplète, tardive ou envoyée à la mauvaise personne. La conséquence détermine le niveau d’autonomie. Un système peut être excellent pour proposer un classement et rester inadéquat pour déclencher seul une décision.

Étape 6 — Définir la réversibilité

Un bon premier cas d’usage permet de revenir facilement au traitement habituel, de corriger une proposition et de contenir l’impact d’une erreur. Le mode silencieux, dans lequel le système produit un résultat comparé au travail humain sans influencer l’opération, est particulièrement utile au début.

Grille de notation recommandée

Critère	Questions à poser	Signal favorable
Valeur	Quel délai, coût, risque ou irritant est réduit ?	Résultat métier chiffrable et reconnu par les équipes
Volume	Le traitement revient-il assez souvent ?	Flux régulier, avec un coût cumulé significatif
Faisabilité	Les entrées et la vérité terrain sont-elles disponibles ?	Données accessibles et échantillon représentatif
Standardisation	Existe-t-il un noyau commun malgré les exceptions ?	Étapes et sorties attendues clairement décrites
Risque	Quel est l’impact d’une erreur ?	Impact contenu ou validation humaine efficace
Adoption	Les utilisateurs participeront-ils aux tests ?	Propriétaire métier et équipe pilote disponibles
Intégration	Peut-on agir dans le flux existant ?	API, exports ou mécanismes d’intégration maîtrisés
Réutilisation	Les composants serviront-ils à d’autres sujets ?	Documents, règles ou connecteurs mutualisables

Un cas à valeur élevée, faisabilité moyenne et risque faible peut être préférable à un chatbot très visible, techniquement facile à démontrer mais difficile à intégrer et à mesurer. La grille doit aussi faire apparaître les dépendances : parfois, le projet prioritaire est la structuration documentaire qui rendra possibles plusieurs usages.

Les signaux d’un mauvais premier cas d’usage

• Le périmètre est formulé comme « répondre à toutes les questions ».
• Personne ne sait définir une réponse correcte sur les cas complexes.
• Les sources se contredisent et aucune règle de priorité n’est établie.
• Le projet dépend d’une intégration profonde non disponible pendant le pilote.
• Une erreur peut produire un engagement important sans possibilité de revue.
• Le succès est mesuré par le nombre de conversations plutôt que par un résultat métier.
• Les utilisateurs opérationnels ne sont pas disponibles pour annoter et tester.
• La seule justification est que des concurrents affichent un assistant.

8. Une feuille de route en quatre étapes : de l’audit à la mise en production

Phase 1 — Audit ciblé et choix du flux

L’audit ne consiste pas à dresser une liste générique de cas d’usage. Il observe quelques flux, mesure leur réalité et identifie les dépendances. Les entretiens sont complétés par des exemples de dossiers, des volumes, des temps et des exceptions. Le livrable utile contient une cartographie concise, une sélection argumentée et les conditions de réussite.

À ce stade, il faut associer le métier, l’IT, la sécurité, la conformité et la protection des données. Leur rôle n’est pas d’approuver une solution déjà choisie, mais de contribuer à définir un périmètre viable. Les décisions importantes — finalité, données, hébergement, autonomie, supervision — sont consignées.

Phase 2 — Cadrage et protocole d’évaluation

Le cadrage décrit les entrées, sorties, sources, règles, utilisateurs, actions autorisées et cas d’escalade. Il définit surtout comment la qualité sera évaluée. Pour une extraction documentaire, on mesure les champs séparément selon leur criticité. Pour un routage, on regarde la précision par catégorie et le rappel sur les urgences. Pour une recherche contractuelle, on mesure la pertinence des sources et la fidélité de la réponse.

Le jeu d’évaluation doit contenir des cas simples, des exceptions, des documents dégradés, des informations contradictoires et des situations où le système doit refuser ou demander une clarification. Les dossiers sont anonymisés ou traités selon un cadre défini. La vérité attendue est validée par des personnes compétentes.

Phase 3 — Prototype sur données représentatives

Le prototype teste les hypothèses les plus risquées, pas seulement l’interface. S’il faut retrouver la bonne version d’un contrat, cette capacité doit être éprouvée. Si les pièces sont souvent photographiées, le corpus doit en contenir. Si l’enjeu est le rattachement à un dossier, le prototype doit travailler avec des homonymes et des références incomplètes.

Les résultats sont comparés au protocole défini. Une démonstration qualitative complète l’évaluation, mais ne la remplace pas. Les erreurs sont regroupées par cause : document illisible, métadonnée absente, recherche incorrecte, règle mal définie, hallucination, intégration ou incompréhension de l’intention. Cette taxonomie oriente les corrections.

Phase 4 — Pilote opérationnel et industrialisation

Le pilote commence avec une équipe et un périmètre limités. Le système peut fonctionner en double lecture : il propose, le gestionnaire décide, et les écarts sont enregistrés. Les seuils d’automatisation augmentent uniquement lorsque les résultats le justifient. Les cas non couverts restent clairement identifiés.

L’industrialisation traite la disponibilité, la sécurité, la performance, la gestion des versions, le support, la documentation, la formation et le suivi des fournisseurs. Une procédure prévoit la désactivation ou le retour à un mode manuel. Le tableau de bord combine mesures techniques, qualité des sorties, adoption et résultat métier.

Exemple de trajectoire sur douze semaines

1. Semaines 1 et 2 : observation du flux, sélection d’un périmètre et collecte d’un échantillon.
2. Semaines 3 et 4 : règles métier, vérité terrain, risques, architecture et critères d’acceptation.
3. Semaines 5 à 7 : prototype technique, évaluation hors production et analyse des erreurs.
4. Semaines 8 et 9 : intégration limitée, interface de revue et journalisation.
5. Semaines 10 à 12 : pilote avec utilisateurs, mesure des gains, décision de poursuivre, corriger ou arrêter.

Ce calendrier est indicatif. Un flux sensible ou une intégration complexe nécessite davantage de temps. L’important est de maintenir des points de décision : ne pas transformer automatiquement un prototype encourageant en programme long sans preuve de valeur.

9. Comment évaluer la qualité sans se laisser tromper par une moyenne

Mesurer par composant

Un système peut échouer parce qu’il a choisi le mauvais dossier, extrait une mauvaise date, retrouvé une clause non applicable ou mal formulé la synthèse. Un score final unique ne permet pas de savoir quoi corriger. Il faut mesurer séparément le rattachement, la classification, l’extraction, la recherche, l’application des règles, la génération et l’exécution.

Mesurer par criticité

Une erreur sur la civilité et une erreur sur la date d’effet ne se valent pas. Les champs, catégories et réponses sont pondérés selon leurs conséquences. Pour certains éléments critiques, le taux d’erreur acceptable peut être proche de zéro et imposer une validation systématique.

Observer les refus et les demandes de clarification

Un système fiable ne répond pas toujours. Il sait signaler une information absente, un conflit de sources ou un cas hors périmètre. Le taux de refus ne doit pas être optimisé vers zéro : un refus pertinent vaut mieux qu’une réponse confiante et fausse. On mesure donc la qualité des escalades et la capacité à poser la question qui débloque réellement le dossier.

Tester les changements

Un modèle, un prompt, un corpus ou une règle peuvent évoluer. Chaque changement significatif déclenche une réévaluation sur un jeu stable, complété au fil des incidents. On compare les performances globales et les cas critiques. Une amélioration moyenne ne justifie pas une régression sur les réclamations ou les données sensibles.

Relier qualité technique et résultat métier

Un classifieur très précis peut n’apporter aucun gain si les utilisateurs doivent ouvrir un autre outil ou si la file de destination est déjà saturée. Inversement, une assistance imparfaite mais bien présentée peut réduire fortement le temps de recherche. L’évaluation doit donc relier la qualité du modèle au délai, au taux de reprise, à la satisfaction des équipes et aux conséquences pour le client.

10. Quand le chatbot devient le bon choix

Après cette critique, il serait excessif de conclure qu’il ne faut jamais construire de chatbot. L’interface conversationnelle est pertinente lorsque le besoin lui-même est exploratoire ou linguistique, que les sources sont maîtrisées et que les limites sont explicites.

Cas pertinent 1 — Assistant interne de recherche

Un gestionnaire peut poser une question avec ses mots, puis recevoir une réponse courte accompagnée des clauses et documents sources. L’assistant est utile si le corpus est bien versionné, les droits sont respectés et le système demande le contexte manquant. Il accélère la lecture sans prétendre remplacer l’analyse.

Cas pertinent 2 — Guide procédural

Un conseiller peut demander comment traiter une opération rare. L’assistant retrouve la procédure en vigueur, affiche les étapes et crée éventuellement une checklist. Les règles restent dans un référentiel versionné ; la conversation facilite l’accès.

Cas pertinent 3 — Collecte adaptative d’informations

Une conversation peut guider un utilisateur lorsqu’un formulaire rigide serait trop long ou complexe. Elle doit toutefois produire des données structurées, confirmer les informations critiques et expliquer pourquoi certaines questions sont posées. Les données sensibles non nécessaires sont découragées ou filtrées.

Cas pertinent 4 — Brouillon contextualisé

Une fois le dossier identifié et les règles appliquées, l’assistant peut rédiger une réponse adaptée au destinataire. Le gestionnaire voit les sources, les éléments à confirmer et les formulations sensibles. La génération intervient à la fin d’un processus fiable, et non à la place de celui-ci.

Les conditions minimales

• Un périmètre annoncé et compris par les utilisateurs.
• Des sources identifiées, versionnées et filtrées par droits.
• Des réponses reliées aux preuves utiles.
• Une gestion explicite de l’incertitude et du hors-périmètre.
• Une intervention humaine accessible pour les situations sensibles.
• Des actions limitées, validées et journalisées.
• Un protocole de test qui inclut erreurs, abus et cas rares.
• Des indicateurs métier au-delà du nombre de conversations.

Dans cette configuration, le chatbot n’est plus « le projet IA ». Il devient une interface parmi d’autres au-dessus d’une capacité métier maîtrisée. Cette distinction change la trajectoire : les composants construits restent utiles même si l’interface évolue.

11. Trois scénarios comparés

Scénario A — Le chatbot vitrine

L’organisation indexe une sélection de FAQ, ajoute une interface publique et mesure les conversations. Le lancement est rapide. Après quelques semaines, les questions réellement posées débordent le corpus, les réponses génériques frustrent les utilisateurs et les conseillers doivent reprendre les échanges. Le chatbot ne connaît ni le contrat ni l’état du dossier. Son taux de réponse paraît correct, mais il ne réduit pas les appels ni les délais.

Leçon : la visibilité et la rapidité de lancement ne compensent pas l’absence de contexte et d’intégration.

Scénario B — L’assistance invisible

L’organisation commence par qualifier les e-mails, rattacher les dossiers et préparer des synthèses. Pendant le pilote, les gestionnaires corrigent les propositions. Les causes d’erreur sont suivies et la taxonomie est ajustée. Le délai d’affectation diminue, les urgences sont mieux repérées et les données préparées deviennent réutilisables.

Quelques mois plus tard, un assistant interne permet de questionner les dossiers déjà structurés. La conversation fonctionne mieux parce que les fondations existent.

Leçon : un premier cas d’usage discret peut construire la capacité qui rendra ensuite le chatbot pertinent.

Scénario C — Le parcours hybride

L’utilisateur choisit d’abord une opération : attestation, modification, sinistre ou question contractuelle. Le parcours collecte les informations structurées indispensables. Une conversation intervient seulement lorsque la demande nécessite une précision ou une explication. Le système prépare l’action, puis demande une confirmation ou transfère au gestionnaire selon le risque.

Leçon : la meilleure expérience n’est pas toujours entièrement conversationnelle. Combiner boutons, formulaires, documents et langage naturel réduit l’ambiguïté.

12. Checklist de cadrage avant d’autoriser un chatbot

Sur le besoin

• Quel problème précis l’interface conversationnelle résout-elle mieux qu’une recherche, une checklist ou un formulaire ?
• Quel résultat métier doit changer, et quelle est sa valeur actuelle ?
• Qui utilisera le système, à quel moment et dans quel outil ?
• Quelles demandes sont explicitement hors périmètre ?

Sur les sources

• Quels systèmes font foi pour les clients, contrats, documents et opérations ?
• Comment identifier la version applicable et sa date d’effet ?
• Les documents sont-ils lisibles, classés et dotés de métadonnées suffisantes ?
• Comment traiter une contradiction entre deux sources ?

Sur la décision

• Le système informe-t-il, recommande-t-il, prépare-t-il ou exécute-t-il ?
• Quelles décisions doivent toujours rester humaines ?
• Quelles informations permettent au valideur de contrôler rapidement ?
• Comment l’utilisateur conteste-t-il ou corrige-t-il le résultat ?

Sur les données et la conformité

• Quelle finalité justifie chaque catégorie de données ?
• Des données sensibles peuvent-elles être saisies librement ?
• Quelle durée de conservation s’applique aux requêtes et aux journaux ?
• Quels fournisseurs traitent les données et sous quelles garanties ?
• Quelles obligations du RGPD, de l’AI Act et du cadre sectoriel doivent être documentées ?

Sur la sécurité

• Les habilitations sont-elles appliquées à chaque source et chaque action ?
• Comment les contenus externes et les injections de prompt sont-ils traités ?
• Quelles actions sont techniquement impossibles sans confirmation ?
• Comment détecter, contenir et déclarer un incident ?

Sur l’évaluation

• Existe-t-il un corpus représentatif avec une vérité validée ?
• Les cas rares et critiques sont-ils suffisamment représentés ?
• Quels seuils conditionnent le passage du prototype au pilote ?
• Comment les régressions seront-elles détectées après une mise à jour ?

13. Questions fréquentes

Un chatbot n’est-il pas le moyen le plus rapide de montrer des résultats ?

Il est souvent le moyen le plus rapide de montrer une interface. Ce n’est pas nécessairement le moyen le plus rapide de produire un résultat métier durable. Une démonstration peut être réalisée en quelques jours, tandis que la gestion des sources, des droits, des versions et des exceptions demande davantage de travail. Un pilote bien choisi peut rester visible : montrez le temps gagné, la qualité des dossiers ou les erreurs évitées, pas seulement une conversation.

Peut-on commencer avec une FAQ ?

Oui, si les questions sont stables, les réponses non personnalisées, le corpus maîtrisé et le risque faible. Il faut annoncer clairement les limites et proposer une orientation humaine. Mais une FAQ conversationnelle ne doit pas être présentée comme la preuve qu’un assistant pourra ensuite traiter des contrats individuels : les exigences sont très différentes.

Faut-il entraîner son propre modèle ?

Rarement pour un premier projet. La valeur vient souvent de l’orchestration, des sources, des règles et de l’évaluation. Des modèles existants peuvent être utilisés avec recherche, sorties structurées et garde-fous. Un ajustement ou un modèle spécialisé peut devenir pertinent lorsque le volume, la stabilité de la tâche, les exigences de performance ou les contraintes d’hébergement le justifient.

Le RAG empêche-t-il les hallucinations ?

Non. La recherche augmentée fournit du contexte, mais le système peut retrouver un passage non applicable, ignorer une source importante ou tirer une conclusion excessive. Il faut évaluer séparément la recherche et la fidélité de la réponse, afficher les preuves, gérer les versions et permettre au système de signaler qu’il ne dispose pas d’assez d’information.

Comment choisir entre automatisation et assistance ?

Regardez la conséquence d’une erreur, la réversibilité, la stabilité des règles et la possibilité d’une revue efficace. Commencez souvent par une proposition soumise à validation. L’automatisation peut ensuite concerner les cas bien définis et fortement maîtrisés. Il n’est pas nécessaire d’automatiser 100 % du flux pour obtenir un gain important.

Comment calculer le retour sur investissement ?

Estimez le volume, le temps complet par traitement, le coût des reprises, les délais et les erreurs évitables. Comparez ensuite les gains observés aux coûts de construction, d’intégration, d’exploitation, de contrôle et de changement. Ajoutez les bénéfices qualitatifs importants — meilleure traçabilité, satisfaction des équipes, réduction d’un risque — sans les transformer artificiellement en euros si l’hypothèse est fragile.

Comment éviter qu’un pilote reste bloqué au stade de démonstration ?

Incluez dès le cadrage l’intégration, le propriétaire, le budget d’exploitation, les critères de passage et la procédure de support. Testez tôt l’accès aux systèmes réels et les contraintes de sécurité. Décidez à l’avance ce qui conduira à industrialiser, corriger ou arrêter. Un arrêt argumenté est préférable à un pilote permanent sans valeur mesurée.

14. Conclusion : construire la capacité avant la conversation

Le chatbot est une interface, pas une stratégie. Dans l’assurance, la valeur durable vient de la capacité à comprendre un flux, accéder aux bonnes sources, préserver les versions, appliquer des règles explicites, produire une preuve, organiser la supervision et agir dans le système d’information. Une conversation peut ensuite rendre cette capacité plus accessible.

Le meilleur premier projet est souvent moins spectaculaire : qualifier des demandes, préparer un dossier, vérifier des pièces, rechercher des clauses ou détecter des anomalies. Il est aussi plus facile à mesurer, à limiter et à améliorer. Il produit des fondations réutilisables pour les projets suivants.

La question à poser au prochain comité IA n’est donc pas « quel chatbot pouvons-nous lancer ? », mais « quel résultat métier voulons-nous améliorer, quelles preuves faut-il réunir et quel niveau d’autonomie pouvons-nous maîtriser ? ». Si la réponse mène ensuite à une interface conversationnelle, celle-ci aura enfin une raison d’être.