Mode silencieux : tester un agent IA en assurance avant de lui permettre d’agir

Autoriser un agent IA à agir dans un processus d’assurance ne devrait jamais être la première expérience faite sur des flux réels. Entre la démonstration et l’autonomie existe une étape plus exigeante : laisser le système produire ses propositions dans les conditions d’exploitation, tout en empêchant ces propositions d’altérer le dossier, la relation client ou la comptabilité. Cette exécution parallèle est souvent appelée mode silencieux, shadow mode ou observation à blanc.

La valeur ne vient pas du silence en lui-même. Elle vient du protocole de comparaison. Un agent qui tourne pendant trois semaines et accumule des sorties non relues ne fournit aucune preuve. À l’inverse, un dispositif qui relie chaque proposition à la décision réelle, au coût d’une erreur, aux versions et aux segments peut répondre à une question de direction : sur quel périmètre précis ce système mérite-t-il un pouvoir supplémentaire, et sous quelles conditions de retrait ?

Ce que le mode silencieux doit réellement prouver

Le NIST AI Risk Management Framework 1.0 recommande d’inscrire la mesure dans le contexte d’usage et tout au long du cycle de vie. Son noyau précise que les systèmes doivent être testés avant déploiement et régulièrement en fonctionnement, avec des processus de test, évaluation, vérification et validation documentés. Le cadre est volontaire et transversal : il ne prescrit pas une recette propre à l’assurance. Il soutient néanmoins une idée centrale du mode silencieux : la performance doit être mesurée dans des conditions proches de celles du déploiement, pas seulement sur un benchmark de laboratoire.

Pour un assureur, une mutuelle ou un courtier, cette preuve comporte quatre dimensions distinctes :

1. La capacité. L’agent sait-il accomplir la tâche bornée : classer, extraire, rapprocher, proposer une réponse ou préparer une action ?
2. La maîtrise. S’abstient-il lorsque les pièces, les droits ou la règle manquent ? Produit-il une justification vérifiable ?
3. La valeur opérationnelle. Sa proposition réduit-elle réellement le temps actif ou le stock, contrôles et reprises inclus ?
4. La stabilité. Les résultats restent-ils acceptables par produit, canal, complexité et population, puis après un changement de modèle, de corpus ou de règle ?

Ces dimensions empêchent un raccourci courant : considérer l’accord avec l’opérateur comme une vérité absolue. La décision humaine peut être correcte, discutable ou elle-même erronée. Le désaccord est donc un objet d’enquête, pas automatiquement une faute de l’agent. Sur les cas critiques ou ambigus, un arbitre métier indépendant doit relire l’entrée, les deux propositions et la règle applicable sans être influencé par le score global.

Écrire le contrat contrefactuel avant la première exécution

Le protocole compare ce qui s’est passé à ce qui se serait passé si la proposition de l’agent avait été suivie. Pour rendre cette comparaison crédible, le dossier d’observation doit être défini avant les résultats. Il ne faut pas ajouter après coup une catégorie qui embellit la performance ou retirer les cas difficiles parce qu’ils « ne correspondent pas au pilote ».

Tableau — Contenu minimal d’un enregistrement de mode silencieux

Bloc	Éléments à conserver	Question de contrôle
Contexte	Identifiant pseudonymisé, produit, canal, étape, horodatage, complexité et segment pertinent	Peut-on expliquer sur quels cas le résultat vaut ?
Entrée autorisée	Références des pièces et champs effectivement visibles, avec leur version	L’agent a-t-il reçu plus d’information que l’opérateur réel ?
Système	Modèle, instructions, règles, outils, corpus, paramètres et versions	Peut-on reproduire la proposition ?
Proposition	Action proposée, données extraites, preuve, niveau de confiance exploitable et motif d’abstention	La sortie est-elle vérifiable sans relire tout le dossier ?
Référence	Action réellement effectuée, corrections, issue ultérieure et avis d’arbitrage si nécessaire	À quoi compare-t-on l’agent ?
Impact	Gravité potentielle, réversibilité, client affecté, temps de contrôle et coût de reprise	Deux désaccords de nature différente sont-ils pondérés différemment ?

La référence ne doit pas fuir dans la génération. L’agent produit d’abord sa proposition ; la décision réelle est jointe ensuite pour l’évaluation. Sinon, l’expérience mesure sa capacité à répéter une réponse connue. Pour la même raison, les personnes qui annotent les désaccords gagnent à ne pas savoir quel système ou quelle version est évalué lorsqu’une revue en aveugle est possible.

Le profil NIST du cadre AI RMF consacré à l’IA générative met notamment l’accent sur l’évaluation empirique, la traçabilité des contenus et l’analyse des risques propres au contexte. Il ne transforme pas un journal exhaustif en objectif : les traces doivent rester proportionnées, sécurisées et limitées. Dans l’assurance, recopier chaque dossier complet dans une plateforme d’observabilité créerait un second gisement de données sensibles.

Déployer le protocole en huit étapes

1. Borner une action, une population et un coût d’erreur

« Tester un agent sinistres » est trop large. Le premier périmètre peut être : proposer la catégorie et la priorité d’une déclaration automobile reçue par e-mail, sans modifier le dossier. Décrivez les exclusions : langues non couvertes, dossiers corporels, suspicion de fraude, urgence, litige ou pièces illisibles. Associez à chaque type d’erreur sa conséquence : délai, orientation vers une mauvaise équipe, demande inutile, perte d’information ou atteinte au client.

Ce cadrage prolonge les garde-fous exposés dans les dix pièges du passage d’une démo IA à la production en assurance : le système testé doit correspondre à une étape réelle et à une responsabilité nommée.

2. Mesurer le processus actuel

Avant l’agent, mesurez le volume, le délai d’attente, le temps actif, le taux de reprise, les désaccords entre opérateurs et la distribution des cas. Sans cette base, un score du système ne dit pas si le service s’améliore. La baseline doit aussi montrer où l’humain consulte des données auxquelles l’agent n’aura pas accès : connaissance tacite, appel téléphonique, écran externe ou règle locale.

3. Constituer une cohorte représentative et des sentinelles

Le flux courant fournit les cas fréquents, mais il peut ne contenir aucun événement rare pendant la fenêtre d’essai. Ajoutez donc une cohorte sentinelle séparée : doublons, pièces contradictoires, mauvaise version de contrat, demande hors périmètre, identifiant ambigu, contenu hostile, valeurs extrêmes. Ces cas ne doivent pas être mélangés au taux de fréquence réel ; ils servent à éprouver des risques spécifiques.

4. Isoler techniquement l’agent

Utilisez des identités de service en lecture seule, une liste d’outils autorisés et un stockage distinct des propositions. Les appels sortants sont désactivés sauf nécessité testée. Les secrets ne figurent ni dans les prompts ni dans les traces. Les entrées provenant d’e-mails ou de documents restent des données non fiables : elles ne peuvent pas modifier les instructions ni ouvrir un privilège.

5. Geler et identifier chaque version

Chaque proposition doit être reliée au modèle, au prompt, au corpus, aux règles et au code d’orchestration. Si un fournisseur change silencieusement un composant, ouvrez une nouvelle période d’observation. Mélanger deux versions dans une seule moyenne empêche de savoir laquelle a produit l’amélioration ou l’incident.

6. Organiser la revue des désaccords

Échantillonnez les accords, mais relisez tous les désaccords critiques et toutes les abstentions jugées anormales. La taxonomie de revue doit distinguer au minimum : référence humaine erronée, agent erroné, cas ambigu, règle insuffisante, donnée absente, intégration fautive et situation hors périmètre. Cette taxonomie transforme l’évaluation en liste de corrections attribuables.

7. Rejouer les corrections en non-régression

Tout incident compris devient un test permanent. Corriger une instruction sans rejouer les anciens cas peut déplacer l’erreur vers un autre segment. Les tests adversariaux complètent les flux observés ; la méthode est détaillée dans le guide de red teaming IA appliqué à l’assurance.

8. Faire signer une décision explicite

À la date prévue, le propriétaire métier, les risques, la conformité, la sécurité, la donnée et l’exploitation examinent les seuils fixés. La décision n’est pas seulement « go/no go ». Elle indique le périmètre autorisé, le niveau de contrôle humain, les actions interdites, les alertes, la durée avant revue et le mécanisme de retour au silence.

Lire les résultats sans se laisser tromper par la moyenne

Un tableau de bord utile sépare qualité, risque, opération et dérive. Le noyau du NIST AI RMF demande notamment de documenter les jeux de test, les métriques et les outils, de mesurer dans des conditions proches du déploiement et d’impliquer des évaluateurs qui ne sont pas uniquement les développeurs de première ligne. Ce principe justifie une lecture par segments et une revue indépendante, pas un score unique choisi par l’équipe qui construit l’agent.

Tableau — Grille de métriques à adapter au coût d’erreur du processus

Mesure	Calcul ou lecture	Signal de décision
Erreur critique	Nombre et nature des propositions qui auraient produit un effet grave	Peut être bloquante sans attendre une significativité statistique
Accord utile	Accord avec la référence après arbitrage des cas ambigus	À segmenter ; ne suffit jamais seul
Abstention appropriée	Cas hors périmètre ou insuffisamment prouvés correctement refusés	Une abstention bien routée protège le service
Fausse assurance	Sorties affirmatives alors qu’une preuve obligatoire manque	Seuil très faible, souvent bloquant
Écart par segment	Différence de qualité et d’impact par produit, canal, langue ou complexité	Peut imposer un périmètre plus étroit
Temps de contrôle	Temps humain pour vérifier, corriger et documenter une proposition	À comparer au temps actif de référence
Coût par dossier correct	Infrastructure, appels, revue, reprises et exploitation divisés par les dossiers acceptables	Plus fidèle que le coût par appel
Stabilité	Évolution après chaque changement et dans le temps	Déclenche une nouvelle observation ou un retour arrière

Les seuils ne sont pas universels. Pour une suggestion d’étiquette sans effet client, une reprise fréquente peut rester acceptable au début. Pour une proposition de refus, de résiliation ou de paiement, le coût d’erreur et le cadre applicable imposent une autre exigence. La grille des trois niveaux de contrôle d’une décision d’assurance aide à relier chaque action à son impact et à sa réversibilité.

Scénario hypothétique : prioriser des déclarations de sinistre

Le cas suivant est une illustration pédagogique, pas un retour d’expérience ni une performance observée. Une mutuelle souhaite aider son équipe à orienter les déclarations reçues dans une boîte partagée. L’agent doit proposer une catégorie, une priorité et les pièces à examiner. Il n’envoie rien et ne modifie aucune fiche.

La cohorte courante comprend les messages arrivant pendant une période définie. Les dossiers corporels, les menaces contentieuses et les situations de vulnérabilité sont balisés pour une revue prioritaire. Une cohorte sentinelle ajoute des pièces en double, un numéro de contrat absent, une déclaration multilingue, un PDF illisible et une instruction malveillante cachée dans un document. L’agent ne voit que les contenus disponibles au moment où l’opérateur prend sa décision.

Chaque soir, un échantillon d’accords et tous les désaccords à impact élevé sont relus. Une proposition « urgence faible » sur un cas corporel constitue un incident critique potentiel ; une différence entre deux catégories internes équivalentes est une erreur de taxonomie moins grave. Une demande de pièce déjà reçue est mesurée séparément, car elle créerait une friction client. L’équipe évalue enfin le temps nécessaire pour contrôler la preuve et corriger la proposition.

Le comité peut conclure que l’agent ne doit pas prioriser, mais qu’il peut préremplir une liste de pièces avec validation humaine. Ce résultat n’est pas un échec du protocole : il identifie le niveau d’autonomie compatible avec les preuves. Si une version ultérieure du modèle modifie le comportement, le système revient automatiquement au mode silencieux jusqu’au passage des tests de non-régression.

Décider du passage, du maintien ou de l’arrêt

Avant l’expérience, formalisez trois portes :

• Passage. Tous les seuils bloquants sont respectés sur une couverture jugée suffisante, les écarts sont compris, l’exploitation sait surveiller et l’action ouverte reste bornée et réversible.
• Maintien en silence. La preuve est insuffisante, un segment manque ou une correction doit être confirmée. Le maintien est assorti d’une hypothèse, d’un responsable et d’une date ; il ne devient pas un POC permanent.
• Arrêt ou recadrage. Une erreur critique demeure, le coût de contrôle annule la valeur, l’accès aux données n’est pas maîtrisé ou le système résout mal le problème. Les enseignements et les cas de test sont conservés.

L’opinion de l’EIOPA du 6 août 2025 sur la gouvernance et la gestion du risque IA s’adresse aux autorités nationales de contrôle et formule des attentes de haut niveau pour les systèmes hors pratiques interdites ou haut risque couverts par son périmètre. Elle insiste sur une approche proportionnée, les responsabilités, la gouvernance des données, la documentation, l’équité, l’explicabilité, la supervision humaine et la robustesse. Le mode silencieux n’est pas une conformité « clé en main » ; il peut fournir certaines preuves utiles à ces dimensions.

Si le système intervient dans une décision concernant une personne, l’analyse juridique porte sur le parcours concret. Le RGPD, notamment son article 22 pour certaines décisions fondées exclusivement sur un traitement automatisé, et le règlement européen sur l’intelligence artificielle peuvent être pertinents selon la finalité, le rôle de l’organisation et la qualification du système. Une phase silencieuse n’autorise pas à différer cette qualification.

Ce que le mode silencieux ne prouve pas

• Il ne prouve pas l’absence de risque. Il évite certaines actions, mais traite encore des données et exécute du code.
• Il ne prouve pas la généralisation. Une période sans événement rare ne démontre pas que l’agent saura le traiter.
• Il ne reproduit pas totalement l’usage réel. Les opérateurs changent parfois leur comportement lorsqu’une recommandation devient visible ; l’automatisation peut aussi modifier les volumes et les délais.
• Il ne valide pas une supervision humaine future. Le contrôleur doit disposer du temps, des informations, de la compétence et de l’autorité pour contredire l’agent.
• Il ne dispense pas d’un mode dégradé. Panne du fournisseur, indisponibilité du corpus ou dérive doivent laisser le processus fonctionner sans l’agent.

Une fois une assistance ouverte, les traces doivent relier la proposition, la correction humaine et l’action finale sans recopier inutilement le dossier. Le guide sur l’observabilité des systèmes génératifs en assurance détaille cet équilibre entre capacité de diagnostic et minimisation.

Sources et références

Références consultées le 7 septembre 2026. Elles fournissent un cadre de gestion du risque et des textes applicables ; l’analyse d’un système précis doit être menée avec les fonctions juridiques, conformité, risques, sécurité et métier concernées.

• NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023.
• NIST AI Resource Center — AI RMF Core, fonctions Govern, Map, Measure et Manage.
• NIST — Generative Artificial Intelligence Profile, NIST AI 600-1, 2024.
• EIOPA — Opinion on Artificial Intelligence governance and risk management, 6 août 2025.
• EUR-Lex — Règlement (UE) 2016/679, RGPD.
• EUR-Lex — Règlement (UE) 2024/1689 sur l’intelligence artificielle.