Migration de modèle IA en assurance : démontrer l’équivalence avant la bascule

Pour remplacer un modèle d’intelligence artificielle en assurance sans provoquer de régression silencieuse, il faut traiter la bascule comme un changement de système à risque : définir l’équivalence métier, mesurer le candidat sur des cas représentatifs, l’observer sans effet en production, limiter son exposition réelle, puis conserver une voie de retour testée. Le nouveau modèle n’a pas besoin de reproduire chaque mot de l’ancien. Il doit respecter le même contrat de sortie et ne pas dégrader les décisions au-delà de seuils fixés à l’avance.

Cette méthode vaut pour le remplacement d’un grand modèle de langage, d’un modèle de classification, d’un composant d’extraction documentaire ou d’un assemblage de modèles. Elle ne dit pas qu’un système donné est automatiquement « à haut risque » au sens du règlement européen sur l’IA. La qualification réglementaire dépend du rôle, de l’usage et du contexte. En revanche, les principes de gestion continue des risques, de traçabilité, de supervision et de robustesse fournissent un excellent niveau d’exigence pour une migration maîtrisée.

Pourquoi un score global ne démontre pas l’équivalence

Deux modèles peuvent obtenir le même taux de réussite moyen tout en commettant des erreurs radicalement différentes. Le premier peut échouer sur des dossiers simples et peu sensibles ; le second sur des exclusions, des montants, des bénéficiaires ou des pièces dont l’absence change la décision. La moyenne efface cette distribution. Elle ne dit ni qui supporte l’erreur, ni si celle-ci peut être détectée, ni si le système sait s’abstenir.

Le problème devient plus net avec un système génératif. Une réponse peut être correcte sur le fond mais perdre une référence de preuve. Une extraction peut contenir la bonne valeur mais l’associer au mauvais document. Une recommandation peut être plausible tout en utilisant une règle qui n’était pas applicable à la date du contrat. Une migration apparemment réussie sur la similarité textuelle peut donc dégrader la fiabilité métier.

Analyse. L’équivalence utile n’est pas l’identité des sorties. C’est le maintien d’un ensemble de propriétés vérifiables : exactitude sur les champs critiques, complétude minimale, provenance, format exploitable, respect des limites, abstention en cas d’incertitude et comportement attendu face aux erreurs d’entrée. Ce sont ces propriétés qu’il faut transformer en tests.

Cette logique prolonge celle d’un jeu d’évaluation IA construit autour des vrais risques de l’assurance. La migration ne commence pas par « quel modèle est meilleur ? », mais par « quelles décisions ne doivent pas régresser, et comment le démontrer ? »

Étape 1 — Cartographier le changement réel

Le modèle n’est qu’une pièce du système. Une bascule peut aussi modifier le tokenizer, la fenêtre de contexte, le comportement des sorties structurées, les règles de filtrage, les outils appelés, le calcul d’embeddings, les limites de débit, la latence, le fournisseur ou la localisation des traitements. Si plusieurs éléments changent en même temps, l’attribution d’un écart devient difficile.

Le dossier doit donc décrire une unité de changement précise :

• version du modèle actuel et version candidate, avec dates et identifiants disponibles ;
• paramètres d’inférence, prompts système, schémas de sortie et outils autorisés ;
• sources de données, règles de préparation, versions d’index et filtres de recherche ;
• cas d’usage touchés et décisions aval qui consomment la sortie ;
• personnes concernées, équipes utilisatrices et mécanismes de recours ou de correction ;
• éléments inchangés, afin de limiter les causes possibles d’une régression.

Recommandation. Lorsque c’est techniquement possible, migrer une variable à la fois. Si le remplacement du modèle impose une adaptation de prompt, conserver une variante qui isole d’abord le modèle, puis mesurer séparément l’effet du nouveau prompt. Cette discipline évite d’attribuer au modèle une amélioration créée par les instructions — ou de masquer une régression par une réécriture opportune.

Étape 2 — Écrire le contrat de sortie avant de comparer

Un contrat de sortie transforme une réponse attendue en propriétés testables. Il ne se limite pas à un schéma JSON. Il précise ce que chaque champ signifie, les valeurs autorisées, les preuves requises, les tolérances et les comportements de défaillance.

Pour une extraction de dossier de sinistre, ce contrat peut inclure :

• un identifiant stable pour chaque pièce et chaque fait extrait ;
• la valeur, son unité, sa date et sa source documentaire ;
• une distinction entre valeur lue, valeur calculée et valeur déduite ;
• un statut explicite lorsque l’information est absente, ambiguë ou illisible ;
• l’interdiction de compléter silencieusement un champ critique ;
• les codes d’erreur et la conduite attendue lorsque le schéma ne peut pas être produit.

Pour une aide à la décision, le contrat doit en plus séparer le fait, la règle, le raisonnement et la recommandation. Une réponse qui arrive à une conclusion acceptable à partir d’un fait inventé reste une défaillance. De même, une bonne conclusion sans preuve ne peut pas être auditée ni corrigée proprement.

Fait sourcé. Le cœur du NIST AI RMF demande notamment de documenter les risques et impacts, d’organiser la surveillance et de prévoir la désactivation ou le remplacement des systèmes dont les résultats deviennent incompatibles avec l’usage prévu. Ce cadre est volontaire ; il est néanmoins directement utile pour structurer un contrat de migration et ses responsabilités.

Étape 3 — Geler un corpus de référence sans le figer pour toujours

Le corpus de migration doit être gelé pendant la comparaison : mêmes entrées, mêmes versions documentaires, mêmes réponses de référence et mêmes règles d’évaluation. Sinon, le candidat peut sembler meilleur parce qu’il a reçu des cas différents ou une vérité terrain corrigée après coup.

« Gelé » ne signifie pas immuable. Après la décision, de nouveaux cas difficiles doivent enrichir le corpus. Mais chaque campagne doit conserver un identifiant, une empreinte et une date. Cela permet de reproduire la preuve qui a fondé le go/no-go.

La composition du corpus compte davantage que sa taille brute. Il faut représenter :

• les volumes ordinaires, pour mesurer le fonctionnement quotidien ;
• les cas rares mais graves, même s’ils pèsent peu dans la moyenne ;
• les entrées dégradées : scans incomplets, doublons, pages tournées, tableaux, signatures, versions contradictoires ;
• les variations temporelles : anciens contrats, nouveaux modèles de documents, règles applicables à des dates différentes ;
• les populations, produits, canaux et équipes susceptibles de subir des écarts différents ;
• les cas où la bonne sortie est une abstention, une demande de pièce ou une escalade humaine.

Il faut aussi séparer le corpus de réglage du corpus de décision. Si l’équipe modifie le prompt jusqu’à réussir les cas qui serviront au go/no-go, elle transforme la recette en exercice d’entraînement. La contamination est particulièrement facile lorsque les erreurs sont discutées dans un fil partagé puis réinjectées dans les instructions.

La matrice de non-régression par risque

Une matrice efficace relie chaque famille de sortie à son impact, sa métrique, son seuil, sa méthode de revue et sa règle de blocage. Les valeurs ci-dessous sont des exemples de structure, pas des seuils universels.

Famille de test	Risque observé	Mesure utile	Règle de décision à définir
Champs critiques	Montant, date, assuré ou garantie incorrects	Exactitude par champ et coût pondéré des erreurs	Aucune régression tolérée sur les erreurs critiques ; seuil explicite pour les autres
Preuve et provenance	Réponse juste mais non vérifiable, ou source erronée	Taux de citations valides et fidélité de l’extrait	Blocage si une conclusion sensible ne peut pas être reliée à sa pièce
Abstention	Confiance injustifiée sur un cas ambigu	Rappel des cas devant être escaladés, faux sentiment de certitude	Le candidat doit détecter les cas graves, même au prix de davantage de revue
Équité et sous-groupes	Dégradation concentrée sur un produit, un canal ou une population	Écarts de performance et de coût d’erreur par segment pertinent	Aucun segment critique masqué par l’agrégat
Robustesse documentaire	Échec sur format inattendu ou document dégradé	Performance par type de perturbation et taux de rejet sûr	Pas d’action aval si l’intégrité de l’entrée n’est pas établie
Exploitation	Latence, coût ou indisponibilité incompatibles avec le processus	Percentiles de latence, taux d’échec, consommation et reprise	Budget d’exploitation respecté sous charge réaliste, repli disponible

Pour chaque ligne, la décision doit être pondérée par la gravité, pas seulement par la fréquence. Une erreur rare qui déclenche un refus injustifié ou une action irréversible peut suffire à bloquer la bascule. À l’inverse, une variation stylistique sans effet sur le contrat peut être acceptée.

Recommandation. Publier la règle de calcul avant de lancer la campagne : population, exclusions, poids, intervalles d’incertitude, méthode de revue et autorité de décision. Une équipe ne doit pas pouvoir changer la métrique après avoir vu que le candidat échoue.

Étape 4 — Analyser les écarts, pas seulement les agrégats

Une comparaison utile produit trois listes : les améliorations, les régressions et les changements non classés. Chaque régression reçoit un niveau de gravité, une cause probable et une décision : corriger, contenir, accepter explicitement ou bloquer.

Les analyses différentielles sont précieuses. Elles montrent les cas que l’ancien modèle réussissait et que le candidat échoue, même si le candidat progresse globalement. Ce sous-ensemble révèle souvent un changement de comportement : tendance à compléter une donnée manquante, difficulté avec les tableaux, format structuré plus fragile, refus excessifs ou interprétation différente d’une instruction.

Le regard humain reste nécessaire, mais il doit être organisé. Une revue en aveugle limite le biais en faveur du nouveau modèle. Les évaluateurs doivent disposer d’un guide d’annotation et pouvoir marquer un cas « indéterminé ». Lorsque deux personnes divergent sur un cas critique, l’arbitrage et sa justification appartiennent au dossier de preuve.

Étape 5 — Le mode silencieux répond à une autre question

Les tests hors ligne montrent ce que le candidat fait sur un corpus connu. Ils ne couvrent pas toutes les particularités de la production : documents nouveaux, séquences d’appels, indisponibilités, évolution de la charge ou interactions avec des outils. Le mode silencieux exécute le candidat sur le trafic réel sans laisser sa sortie agir sur le métier.

Le système actuel conserve l’autorité. La sortie candidate est journalisée, comparée et évaluée avec un décalage maîtrisé. Pour respecter la finalité et la minimisation, il ne faut pas dupliquer les données « au cas où » : le périmètre, l’accès, la durée de conservation et la sécurité du flux silencieux doivent être définis.

Le mode silencieux sert à détecter :

• des formats absents du corpus ;
• des appels d’outils ou des sorties invalides qui n’apparaissent qu’en séquence ;
• des régressions concentrées sur une période, un canal ou un portefeuille ;
• des variations de coût et de latence sous charge réelle ;
• des cas d’abstention nouveaux, à intégrer au jeu d’évaluation.

Il ne prouve pas l’absence de risque. Il réduit l’inconnu avant d’exposer une sortie à un utilisateur ou à une action.

Étape 6 — Un canary borné avec des seuils d’arrêt

Lorsque les preuves hors ligne et silencieuses sont satisfaisantes, le canary donne au candidat une exposition réelle limitée. La limite doit porter sur plus qu’un pourcentage aléatoire. On peut borner le canary à un produit, une équipe formée, une classe de documents, des décisions réversibles ou un niveau de montant. Les cas les plus sensibles restent sur le système de référence.

Le canary doit avoir un propriétaire opérationnel, une durée, un tableau de bord et des seuils d’arrêt automatiques ou immédiatement exécutables. Les mesures couvrent la qualité, les incidents, les escalades, les corrections humaines, la latence et les échecs techniques. Une hausse des validations humaines n’est pas nécessairement mauvaise si elle reflète une meilleure abstention ; il faut donc interpréter les indicateurs ensemble.

Scénario pédagogique fictif. Un candidat extrait correctement davantage de montants, mais multiplie les associations à la mauvaise pièce lorsque plusieurs devis sont joints. La moyenne d’exactitude progresse. Le mode silencieux révèle pourtant que l’erreur se concentre sur des dossiers de réparation complexes. La décision raisonnable n’est ni « le modèle est meilleur » ni « il est mauvais » : elle consiste à bloquer ce sous-flux, corriger la règle d’appariement et rejouer la recette avant une nouvelle exposition.

La règle go/no-go

Une règle de décision lisible peut tenir en cinq portes cumulatives :

1. Contrat. Tous les champs, états d’abstention, preuves et erreurs sont définis ; les consommateurs aval acceptent le format.
2. Risque. Aucun bloqueur critique n’est ouvert et chaque seuil pondéré par le risque est respecté sur le corpus gelé.
3. Production observée. Le mode silencieux n’a pas révélé de classe d’entrée non maîtrisée ; les écarts importants sont expliqués.
4. Exploitation. La surveillance, les responsabilités, la gestion d’incident et la capacité de retour arrière ont été testées.
5. Décision. Le responsable métier et le responsable du risque acceptent les risques résiduels documentés, pour un périmètre et une date déterminés.

Le « no-go » n’est pas un échec du projet. Il peut signifier : revenir au réglage, réduire le périmètre, conserver l’ancien modèle pour une classe critique, demander une pièce supplémentaire ou reporter la bascule. Le NIST AI RMF cite explicitement la désactivation, la reprise et la gestion du changement parmi les résultats attendus d’une gestion du risque opérationnelle.

Tester le retour arrière avant d’en avoir besoin

Un bouton de configuration n’est pas encore un plan de retour arrière. Il faut vérifier que l’ancienne version reste disponible, que ses dépendances et index sont compatibles, que les files en cours peuvent être reprises et que les résultats déjà produits ne seront pas dupliqués. Les actions irréversibles exigent une précaution supplémentaire.

Le test doit répondre à des questions concrètes : combien de temps faut-il pour revenir ? Que deviennent les demandes en vol ? Comment identifier les dossiers traités par chaque version ? Faut-il recalculer certaines sorties ? Qui a l’autorité d’activer le repli, y compris hors heures ouvrées ? Comment informer les équipes utilisatrices ?

La discipline d’idempotence des agents IA est ici déterminante : rejouer une opération ne doit pas créer une deuxième relance, un second paiement ou une nouvelle écriture métier. La migration doit préserver les clés d’idempotence et les identifiants de traitement.

Le dossier de preuve minimal

Le dossier ne doit pas être un rapport décoratif produit après la bascule. C’est l’instrument qui permet aux décideurs de comprendre ce qu’ils acceptent. Il doit être assez compact pour être lu et assez précis pour être reproduit.

• Fiche de changement : objectif, périmètre, versions, composants modifiés, date et responsables.
• Contrat de sortie : schémas, invariants, règles d’abstention, preuves et erreurs.
• Corpus : identifiant, empreinte, méthode d’échantillonnage, couvertures et limites.
• Résultats : métriques globales et segmentées, intervalles, régressions différentielles, revue humaine.
• Écarts : liste des anomalies, gravité, cause, correction, acceptation ou blocage.
• Production : résultats du mode silencieux et du canary, incidents, charge, coût et latence.
• Décision : go/no-go, risques résiduels, signataires, périmètre autorisé et date de réexamen.
• Repli : déclencheurs, procédure, test réalisé, temps observé et responsables.

Fait sourcé. Le règlement européen sur l’IA décrit, pour les systèmes relevant de ses exigences correspondantes, une gestion des risques continue sur le cycle de vie et des essais fondés sur des métriques et seuils définis à l’avance. L’avis de l’EIOPA du 6 août 2025 retient pour l’assurance une approche proportionnée fondée sur le risque. Ces textes n’imposent pas un même protocole chiffré à toute migration ; ils confortent l’idée qu’une bascule doit être gouvernée, justifiée et suivie.

Les six raccourcis qui fragilisent la bascule

1. Comparer seulement coût et latence. Ce sont des contraintes d’exploitation, pas une preuve de qualité décisionnelle.
2. Utiliser un seul score moyen. Il masque les segments et erreurs rares à fort impact.
3. Retoucher le corpus après chaque échec. La preuve devient non reproductible et risque d’être optimisée a posteriori.
4. Confondre validation humaine et filet de sécurité. Sans temps, compétence, contexte et pouvoir de contradiction, la validation peut devenir automatique.
5. Passer directement du test au plein trafic. Les inconnues de production ne sont alors découvertes qu’après exposition.
6. Prévoir le rollback sur le papier. Une dépendance expirée, un index incompatible ou une action non idempotente peut rendre le repli inutilisable au moment critique.

Un plan de migration en quatre temps

Temps 1 — Cadrer. Nommer un propriétaire métier et un propriétaire technique, inventorier les décisions touchées, qualifier les exigences applicables, écrire le contrat de sortie et classer les erreurs par coût. La sortie attendue est une règle de go/no-go approuvée avant les résultats.

Temps 2 — Mesurer. Geler le corpus, lancer l’ancien et le candidat, examiner les différences en aveugle, segmenter les résultats et corriger les bloqueurs. Chaque changement du candidat crée une nouvelle version de campagne.

Temps 3 — Observer et exposer. Déployer le candidat en mode silencieux, enrichir la recette avec les cas nouveaux, puis ouvrir un canary borné. Activer la surveillance et tester le retour arrière pendant que l’impact est encore faible.

Temps 4 — Décider et surveiller. Signer les risques résiduels, étendre progressivement le périmètre, conserver une période de surveillance renforcée et programmer une revue. Une bascule réussie n’achève pas la gestion du risque : elle change simplement sa phase.

La question qui doit clore la revue

La mauvaise question est : « le nouveau modèle est-il globalement meilleur ? » La bonne est : « avons-nous des preuves suffisantes qu’il respecte le contrat de décision sur notre périmètre, que ses écarts les plus graves sont maîtrisés et que nous savons revenir en arrière ? »

Cette formulation évite deux excès : bloquer toute évolution au nom d’une identité impossible, ou accepter une bascule sur la foi d’un benchmark flatteur. Elle place la décision là où elle doit être : dans une combinaison de preuves techniques, de compréhension métier et de responsabilité explicite.

Questions fréquentes

Faut-il obtenir exactement les mêmes réponses avec l’ancien et le nouveau modèle ?

Non. Une identité mot à mot serait souvent inutile et parfois impossible. L’objectif est de conserver les propriétés qui comptent pour le processus : champs critiques exacts, format exploitable, preuve reliée à la bonne source, abstention sur les cas ambigus et absence de nouvelle erreur grave. Une formulation différente est acceptable si le contrat reste respecté.

Combien de cas faut-il dans le corpus de migration ?

Il n’existe pas de nombre universel. Le corpus doit couvrir les décisions, les formats et les erreurs qui déterminent le risque. Une grande collection de cas faciles ne compense pas l’absence d’un scénario rare à forte conséquence. Il faut documenter la couverture, l’incertitude statistique et les limites plutôt que promettre qu’un volume arbitraire prouve l’équivalence.

Peut-on conserver deux modèles en production après la migration ?

Oui, si le routage est explicite, testé et observable. Un ancien modèle peut rester autoritaire sur un sous-flux critique pendant que le candidat traite les autres cas. Cette coexistence ajoute toutefois des versions, des coûts et des chemins d’incident : elle doit être gouvernée comme une architecture durable, pas comme une transition oubliée.

Sources et références

• Règlement (UE) 2024/1689 sur l’intelligence artificielle — EUR-Lex.
• Artificial Intelligence Risk Management Framework 1.0 — NIST.
• Generative Artificial Intelligence Profile, NIST AI 600-1.
• Opinion on Artificial Intelligence governance and risk management — EIOPA, 6 août 2025.
• Développer la confiance dans l’IA par une approche par les risques cyber — ANSSI et partenaires.

Vous préparez une migration de modèle sur un processus d’assurance ? Commencez par le contrat de sortie et la matrice de non-régression : ce sont eux qui transforment une comparaison de modèles en décision défendable. Pour cadrer le protocole avec vos équipes métier, risque et technique, échangeons sur votre cas d’usage.