Contrôle humain d’une IA en assurance : passer du clic à une supervision effective

Dans beaucoup de parcours assistés par l’intelligence artificielle, la supervision tient dans un écran : une recommandation, deux informations résumées et un bouton « Valider ». L’organisation peut alors compter une intervention humaine dans le processus. Elle ne sait pourtant pas si cette intervention change réellement la décision.

Le sujet n’est pas de soupçonner systématiquement l’utilisateur de passivité. Il est de concevoir une situation dans laquelle son jugement a une chance raisonnable de s’exercer. Un gestionnaire qui reçoit une proposition très convaincante, traite une file en retard, ne voit pas la pièce source et doit justifier chaque désaccord supporte une architecture qui pousse à l’acquiescement. Ajouter une étape humaine à cette architecture déplace la responsabilité sans créer de maîtrise.

Pour un assureur, la question utile est donc observable : dans quelles conditions la personne détecte-t-elle une sortie inadéquate, et que peut-elle effectivement faire ensuite ? La réponse engage le produit, l’interface, les opérations, la formation, le contrôle interne et le management. Elle ne peut pas être laissée à une mention dans une procédure.

Pourquoi la validation formelle échoue

La supervision nominale décrit un rôle sur le papier : « le gestionnaire valide ». Le contrôle effectif décrit un mécanisme complet : l’utilisateur comprend le statut de la sortie, accède aux éléments nécessaires, dispose d’un temps cohérent avec la difficulté, peut s’écarter de la proposition et laisse une trace exploitable de son action.

Cette distinction évite trois erreurs fréquentes. La première consiste à confondre présence et attention : une personne peut être dans la boucle sans examiner le dossier. La deuxième confond autorisation et pouvoir : un manuel peut permettre le désaccord alors que l’interface, les objectifs de productivité ou la hiérarchie le découragent. La troisième confond explication et preuve : une justification générée par le même système ne constitue pas une source indépendante.

Le risque varie selon la tâche. Vérifier que le nom d’un assuré a été correctement extrait ne ressemble pas à apprécier une exclusion, modifier une prime ou orienter un dossier de fraude. Avant de dessiner l’écran, l’équipe doit décomposer le parcours en décisions élémentaires et qualifier pour chacune :

• la sortie produite par l’IA et son statut : fait extrait, score, résumé, recommandation ou action préparée ;
• le dommage plausible en cas d’erreur ou d’omission ;
• la réversibilité de l’action après validation ;
• les informations indépendantes nécessaires au jugement ;
• la compétence et l’habilitation requises ;
• le délai au-delà duquel le contrôle devient irréaliste ;
• la voie de recours pour le client et la voie d’escalade pour l’opérateur.

Cette analyse prolonge la grille des trois niveaux de contrôle d’une décision d’assurance. Elle descend d’un niveau : une fois le contrôle humain retenu, il faut prouver qu’il fonctionne dans le flux réel.

Les quatre capacités d’un contrôle effectif

1. Détecter : voir assez pour reconnaître un problème

La personne doit connaître la finalité et les limites du système, mais surtout voir les données utiles au cas présent. Une recommandation de souscription sans lien vers les pièces, une synthèse de sinistre sans signalement des documents illisibles ou une réponse client sans version de contrat prive le contrôleur de matière.

L’interface doit séparer les faits retrouvés, les calculs déterministes, les inférences et les éléments manquants. Elle doit aussi permettre l’ouverture de la source exacte. Le contrôle n’exige pas d’afficher chaque détail technique du modèle ; il exige de rendre visibles les éléments qui peuvent renverser la décision.

2. Contredire : former une opinion indépendante

Le choix ne doit pas être artificiellement asymétrique. Si valider prend un clic alors que contredire impose six champs, un commentaire libre et l’accord d’un supérieur, le produit organise une préférence. Une raison de désaccord peut être demandée pour apprendre, à condition qu’elle soit rapide, pertinente et qu’elle ne transforme pas chaque correction en faute présumée.

La contradiction suppose aussi un chemin cognitif indépendant. Montrer d’abord une recommandation ancre le jugement. Pour certains dossiers critiques, l’équipe peut tester une revue « aveugle » : l’opérateur examine d’abord les faits et formule une position, puis découvre la proposition de l’IA. Ce dispositif coûte plus cher ; il doit être réservé aux évaluations et aux décisions qui le justifient.

3. Corriger : agir sur le dossier, pas seulement rejeter

Un rejet sans suite renvoie souvent le cas dans une file opaque. Le contrôleur doit pouvoir corriger une donnée, demander une pièce, modifier une formulation, imposer une règle, reclasser le dossier ou l’orienter vers un spécialiste. La correction doit conserver la valeur antérieure, la source, l’auteur, le motif et la date.

La correction humaine n’est pas automatiquement une vérité terrain. Elle peut être incomplète ou erronée. Avant de la réutiliser pour évaluer ou entraîner un système, il faut définir une procédure de confirmation adaptée : second regard pour certains cas, contrôle par échantillon ou validation ultérieure par le résultat métier.

4. Interrompre : empêcher la poursuite d’un effet indésirable

Si l’utilisateur détecte un défaut systémique — mauvaise version de barème, pièces attribuées au mauvais dossier, réponses incohérentes après un changement de modèle — il doit pouvoir arrêter ou limiter le flux concerné. Cette capacité ne signifie pas que chacun coupe toute la plateforme. Elle suppose des périmètres d’arrêt : action, dossier, type de produit, version de modèle ou outil connecté, avec une reprise humaine prévue.

L’arrêt opérationnel et le mode dégradé méritent leur propre architecture ; ils sont détaillés dans le guide sur le traçage des systèmes génératifs et prolongés par le dossier consacré au mécanisme d’arrêt. Ici, le test minimal est simple : le contrôleur sait qui alerter, ce qui s’arrête et comment le client continue d’être servi.

Ce que les textes imposent — et ce qu’ils ne prouvent pas

Au 7 septembre 2026, l’article 14 du règlement européen sur l’intelligence artificielle prévoit, pour les systèmes d’IA à haut risque auxquels il s’applique, un contrôle effectif par des personnes physiques. Le texte vise notamment la compréhension des capacités et limites, la vigilance face au biais d’automatisation, l’interprétation correcte, la possibilité de ne pas utiliser ou de renverser la sortie, et la capacité d’interrompre le système en sécurité. La qualification dépend cependant du système, de sa finalité et du rôle de l’organisation ; l’article 14 ne doit pas être présenté comme une règle identique pour tout outil IA utilisé en assurance.

Depuis l’entrée en vigueur, le 27 juillet 2026, du règlement (UE) 2026/1744, les exigences de l’article 14 s’appliquent à compter du 2 décembre 2027 aux systèmes à haut risque relevant de l’article 6, paragraphe 2, et de l’annexe III, et du 2 août 2028 à ceux relevant de l’article 6, paragraphe 1, et de l’annexe I.

Le RGPD traite une autre question. Son article 22 encadre les décisions fondées exclusivement sur un traitement automatisé qui produisent un effet juridique ou affectent significativement une personne. Dans certains cas prévus par le texte, des garanties incluent le droit d’obtenir une intervention humaine, d’exprimer son point de vue et de contester la décision. Le texte officiel est accessible dans le chapitre consacré aux droits de la personne. Un contrôle au sens du règlement IA et une intervention au sens du RGPD sont donc liés, mais ne sont ni interchangeables ni une validation automatique de conformité.

L’avis de l’EIOPA du 6 août 2025 sur la gouvernance et la gestion des risques IA adopte une approche proportionnée fondée sur les risques et relie la gouvernance, l’équité, l’explicabilité, la gouvernance des données, les responsabilités et la tenue des dossiers. Son champ annoncé vise des systèmes qui ne sont ni interdits ni classés à haut risque par le règlement IA. Il complète donc l’analyse sectorielle ; il ne remplace pas la qualification juridique du cas d’usage.

Une recommandation de la CNIL publiée en mai 2026 sur l’octroi de crédit offre, dans un secteur voisin, une grille opérationnelle particulièrement utile : intelligibilité de la sortie, documentation des limites, accès aux données pertinentes, pouvoir et indépendance de l’agent, temps d’examen, formation, suivi des accords et désaccords. Cette recommandation sur l’évaluation de la solvabilité concerne le crédit, pas l’assurance. Elle doit être utilisée comme inspiration de test et non comme extension automatique de son champ juridique.

Le protocole de conception : partir de la décision, pas du bouton

Tableau — Huit étapes pour concevoir un contrôle humain effectif

Étape	Question de conception	Preuve attendue
1. Décomposer	Quelle décision élémentaire est réellement assistée ?	Carte du flux avec entrées, sortie, action et responsable
2. Qualifier	Que coûte une erreur et peut-elle être annulée ?	Classe de criticité et scénarios de dommage
3. Informer	Quels faits permettent de contredire la sortie ?	Sources ouvrables, version, incertitudes et manquants
4. Donner du temps	La charge et le délai permettent-ils un examen réel ?	Mesure en situation normale et en pic d’activité
5. Donner autorité	Que peut modifier ou arrêter la personne ?	Droits applicatifs, procédure d’escalade et protection managériale
6. Prévoir le repli	Le travail continue-t-il sans le système ?	Mode dégradé exercé et file de reprise
7. Instrumenter	Quelles traces distinguent accord, correction et passivité ?	Journal minimal, motifs structurés et protections d’accès
8. Réévaluer	Quels signaux déclenchent une nouvelle recette ?	Seuils internes, changement de version, incident ou réclamation

La hiérarchie doit être explicite avant le pilote. Un contrôleur ne peut exercer une autorité qu’on lui retire dans les objectifs. Si le délai moyen devient le seul indicateur valorisé, la correction d’un dossier complexe sera mécaniquement découragée. Le tableau de bord doit donc associer productivité, qualité de la décision, reprises, réclamations, escalades et résultats par segment pertinent.

La formation ne se limite pas à une démonstration de l’outil. Elle couvre les limites connues, les indices d’une sortie incertaine, les situations où l’IA doit être ignorée, la recherche dans les sources, la procédure de contestation et le repli. Elle doit aussi montrer des erreurs plausibles : une sortie grossière entraîne de la vigilance, une sortie fluide contenant une erreur subtile teste réellement le contrôle.

Tester l’usage et le désaccord

Un protocole en cinq familles de cas

1. Cas ordinaires correctement traités : vérifier que le contrôle n’ajoute pas de friction sans valeur et que les sources restent accessibles.
2. Erreurs manifestes : mauvaise donnée, pièce absente ou calcul incohérent. L’utilisateur doit les détecter rapidement.
3. Erreurs plausibles : bonne clause mais mauvaise version, synthèse fidèle sauf une exception omise, seuil appliqué au mauvais produit.
4. Cas ambigus : plusieurs interprétations raisonnables. Le test porte sur l’escalade et la justification, pas sur un accord artificiel avec une vérité unique.
5. Défaut systémique : plusieurs dossiers affectés par la même configuration. Le test porte sur la détection de série, l’arrêt du périmètre et la reprise.

Les participants doivent représenter les rôles et niveaux d’expérience réels. Un expert qui connaît les erreurs injectées n’est pas une mesure du contrôle quotidien. À l’inverse, observer uniquement des novices confond l’ergonomie du système et l’apprentissage du métier. Les résultats sont ventilés par type de dossier, niveau de criticité, charge et profil d’utilisateur, sans transformer de petits échantillons en conclusions générales.

Mesurer plusieurs choses à la fois

• détection : part des erreurs injectées repérées, par nature et gravité ;
• action correcte : part des anomalies suivies de la correction ou de l’escalade attendue ;
• temps utile : distribution des durées, en distinguant dossiers simples et difficiles ;
• désaccord : fréquence, motifs et qualité des écarts à la recommandation ;
• faux désaccord : corrections humaines qui dégradent le résultat, après confirmation indépendante ;
• abstention : capacité à reconnaître qu’aucune décision sûre n’est possible ;
• reprise : délai et qualité du traitement lorsque l’IA est indisponible ;
• équité opérationnelle : écarts de détection ou de reprise entre segments pertinents et licites.

Aucun taux universel ne transforme ces signaux en conformité. Les seuils doivent être décidés avant le test à partir du risque métier. Un désaccord nul est compatible avec trois histoires opposées : un système irréprochable sur l’échantillon, des utilisateurs totalement convaincus, ou une contradiction devenue impraticable. L’enquête qualitative et l’observation de l’écran permettent de les distinguer.

Deux scénarios assurance explicitement hypothétiques

Scénario hypothétique 1 — Une recommandation de souscription professionnelle

Une équipe imagine un copilote qui extrait les activités déclarées, rapproche les justificatifs et propose les questions manquantes. Le souscripteur reste décisionnaire. Pour rendre le contrôle effectif, l’écran montre chaque fait avec sa page source, isole les contradictions et masque toute recommandation d’acceptation tant que les pièces critiques ne sont pas examinées.

Le test injecte une attestation valable mais rattachée à une autre entité, une activité secondaire absente du résumé et une incohérence de chiffre d’affaires. La réussite ne se mesure pas au clic final. Elle exige que le souscripteur détecte les signaux, demande la pièce ou corrige le dossier et explique la décision sans reprendre mot pour mot la justification du modèle.

Ce scénario prolonge la réflexion sur la souscription augmentée sans remplacement du courtier et sur le copilote de courtage spécialisé : le rôle humain se renforce lorsque le système prépare les preuves, mais il s’affaiblit lorsque la synthèse devient le seul dossier effectivement consulté.

Scénario hypothétique 2 — Un brouillon de réponse après sinistre

Un assistant prépare un message expliquant les prochaines étapes. L’action semble faible car aucun paiement n’est déclenché. Elle peut pourtant créer une promesse, citer un délai erroné ou présenter une exclusion comme acquise. L’interface distingue donc les formulations issues d’un modèle, les données du dossier et les passages contractuels. Les montants et dates sont validés par des règles déterministes.

Le gestionnaire peut modifier librement le texte, ouvrir la police applicable et basculer en rédaction manuelle. Si plusieurs brouillons contiennent la même erreur, il suspend l’envoi automatique pour le produit concerné. Le contrôle porte ainsi sur le message individuel et sur la série, deux niveaux souvent confondus.

Piloter sans fabriquer un indicateur rassurant

Le tableau de bord doit être interprété en comité métier-risque-produit. Une hausse des désaccords peut signaler une dérive du modèle, une meilleure vigilance après formation ou un changement de portefeuille. Une baisse du temps de revue peut traduire une interface plus claire ou un examen plus superficiel. Aucun signal ne se lit seul.

Trois revues sont utiles. La revue opérationnelle examine chaque semaine les erreurs, escalades et irritants pendant un pilote. La revue de risque analyse périodiquement les tendances, les segments et les incidents. La revue de changement est déclenchée par une nouvelle version de modèle, de prompt, de source, de barème, d’interface ou de procédure. La fréquence exacte dépend de la criticité et du volume ; elle ne doit pas être copiée d’un autre cas d’usage.

Les traces doivent rester proportionnées. Enregistrer la décision, la version, les sources consultées, le type de correction et l’acteur peut être nécessaire. Copier sans limite tous les documents, les raisonnements ou les données personnelles crée un nouveau risque. La finalité, l’accès, la durée de conservation et l’effacement sont définis avant la collecte.

Un plan de mise en œuvre en douze semaines

1. Semaines 1 à 2 — cadrer : décomposer le parcours, qualifier les décisions, nommer les responsables et définir les dommages à éviter.
2. Semaines 3 à 4 — prototyper : construire l’écran avec sources, manquants, correction, escalade et mode manuel ; tester les asymétries de friction.
3. Semaines 5 à 6 — préparer la recette : constituer des cas ordinaires, ambigus et erronés, définir les seuils internes et protéger les données de test.
4. Semaines 7 à 8 — observer : mener des sessions d’usage, mesurer les actions et interroger les participants sans leur révéler à l’avance chaque erreur.
5. Semaines 9 à 10 — piloter en mode assisté : limiter le périmètre, maintenir un contrôle renforcé et comparer les résultats au processus de référence.
6. Semaines 11 à 12 — décider : corriger les bloqueurs, documenter le risque résiduel et choisir d’étendre, de maintenir, de réduire ou d’arrêter.

Douze semaines ne constituent pas une durée réglementaire ni une garantie de réussite. C’est un canevas de pilotage. Un flux étroit peut être testé plus vite ; une décision sensible, peu fréquente ou juridiquement complexe demandera davantage de temps et d’expertise.

Questions fréquentes

Faut-il imposer une justification à chaque validation ?

Pas nécessairement. Une justification systématique peut produire du texte routinier et détourner du contrôle. Réservez-la aux décisions critiques, aux désaccords, aux exceptions ou à un échantillon, puis vérifiez si elle améliore réellement la preuve.

Un faible taux de désaccord prouve-t-il que le système est bon ?

Non. Il doit être rapproché des erreurs injectées, des corrections confirmées, de la charge, de l’ergonomie et des entretiens. La qualité se juge sur la capacité à agir correctement lorsque la sortie est inadéquate.

Peut-on contrôler seulement un échantillon ?

Cela dépend de l’action, de sa réversibilité, de la capacité de détection automatique et du risque pour les personnes. L’échantillonnage peut compléter un contrôle intégré ; il ne suffit pas si une erreur individuelle irréversible doit être interceptée avant effet.

Qui doit posséder la décision finale ?

Le rôle doit être attribué explicitement selon le processus : métier, délégataire habilité, responsable de second niveau ou comité. « Un humain » n’est pas une responsabilité. L’organisation doit nommer l’acteur, son autorité, son suppléant et la voie d’escalade.

Pour un exemple appliqué aux messages et aux comptes rendus, l’analyse de Voxtral dans l’assurance propose une recette centrée sur les négations, les dates et les montants : la validation humaine doit retrouver le passage utile avant de donner une suite métier.

Sources et références

• Règlement (UE) 2024/1689 sur l’intelligence artificielle, notamment article 14 sur le contrôle humain ; texte officiel consulté le 7 septembre 2026.
• Règlement (UE) 2026/1744 modifiant le calendrier d’application du règlement IA, entré en vigueur le 27 juillet 2026.
• EIOPA, Opinion on Artificial Intelligence governance and risk management, 6 août 2025.
• CNIL, RGPD — chapitre III, dont l’article 22, texte officiel et présentation des droits.
• CNIL, recommandation concernant l’évaluation de la solvabilité dans le cadre de l’octroi de crédit, mai 2026 ; utilisée ici comme grille méthodologique d’un secteur voisin.