Ce qu’il faut retenir
- Un jeu d’évaluation IA pour l’assurance représente une décision et son coût d’erreur, pas seulement un stock de dossiers. Chaque cas doit préciser l’entrée disponible, la sortie attendue, les preuves, les tolérances et le traitement d’une ambiguïté.
- La représentativité a plusieurs axes. Fréquence, gravité, produit, canal, complexité, qualité documentaire et populations exposées doivent être couverts sans prétendre reproduire le portefeuille avec un seul échantillon.
- Les cas fréquents et les cas sentinelles remplissent deux fonctions différentes. Les premiers estiment l’usage courant ; les seconds vérifient des dangers rares, des bords et la capacité d’abstention. Leurs résultats ne se mélangent pas dans une moyenne.
- L’annotation est un protocole métier versionné. Les critères, la preuve attendue, les désaccords entre experts, les arbitrages et les changements de doctrine sont conservés avec chaque version.
- La fuite entre entraînement et test invalide la conclusion. Il faut séparer les dossiers par entité ou événement lorsque des cas liés existent, protéger un lot final et contrôler la contamination des corpus et prompts.
- Le jeu vit après la mise en production. Incidents, abstentions, corrections humaines, nouvelles versions de contrat et changements de modèle l’enrichissent ; ils ne remplacent pas une revue de couverture planifiée.
Demander « combien de dossiers faut-il pour tester notre IA ? » commence par la mauvaise variable. Cent cas interchangeables peuvent laisser invisibles une exclusion rare, une police remplacée par un avenant, un document illisible ou un écart de performance sur une population. À l’inverse, un jeu plus petit mais structuré peut déjà révéler qu’une sortie n’est pas vérifiable, qu’une classe est mal définie ou que le système devrait s’abstenir.
Le nombre devient pertinent seulement après avoir défini ce que l’évaluation doit autoriser : sélectionner un passage, extraire un montant, prioriser un dossier, préparer un message ou proposer une décision. Pour chaque action, l’équipe doit connaître le coût d’une erreur, la diversité des cas et l’incertitude qu’elle accepte. Le jeu d’évaluation est donc un produit métier gouverné : il possède un propriétaire, une spécification, des versions, des droits d’accès, des tests de qualité et un cycle de mise à jour.
Définir l’objet exact de l’évaluation
Le noyau du NIST AI Risk Management Framework associe la mesure aux risques cartographiés et demande que les jeux de test, métriques, outils et conditions soient documentés. Il recommande des évaluations dans des conditions proches du déploiement et une surveillance en fonctionnement. Ce cadre volontaire ne fixe pas un volume universel : il demande d’abord de relier la mesure au but du système.
Commencez par rédiger une fiche d’unité d’évaluation :
Tableau — Spécification d’un cas avant sélection des dossiers
| Élément | Question à trancher | Exemple assurance |
|---|---|---|
| Population | Sur quels dossiers la conclusion sera-t-elle utilisée ? | Contrats habitation individuels actifs, hors contentieux |
| Instant | Quelles informations sont disponibles au moment de la tâche ? | Police et avenants reçus avant la question |
| Action | Quelle sortie élémentaire évalue-t-on ? | Retrouver le passage qui traite une garantie |
| Preuve | Qu’est-ce qui rend la réponse vérifiable ? | Document, version, page et extrait exact |
| Tolérance | Quelles variantes restent acceptables ? | Deux formulations équivalentes pointant le même passage |
| Abstention | Quand l’absence de réponse est-elle correcte ? | Police applicable non identifiable ou preuve absente |
| Impact | Que provoquerait l’erreur si la sortie était suivie ? | Mauvaise information au gestionnaire ou au client |
Cette fiche empêche de confondre trois objets : la capacité du modèle, la performance d’un composant et la qualité du système de bout en bout. Un modèle peut extraire correctement un passage si on lui fournit la bonne page, alors que le système échoue à retrouver cette page. Il peut produire un JSON valide, mais appliquer la mauvaise version de contrat. L’évaluation doit donc isoler les composants lorsque le diagnostic l’exige, puis tester leur chaîne complète.
Pour un système multimodal, cette discipline est détaillée dans la méthode d’évaluation du texte, de l’image et du document sans mélanger les preuves. Pour un RAG contractuel, les huit tests avant production fournissent des cas spécifiques aux versions, renvois, exclusions, tableaux et silences documentaires.
Construire une matrice d’échantillonnage, pas un tiroir de « beaux cas »
Un tirage purement aléatoire décrit surtout ce qui est fréquent. Un choix effectué par l’équipe projet surreprésente souvent les dossiers propres et connus. La matrice d’échantillonnage combine plusieurs axes afin de rendre visibles les zones où l’erreur coûte cher ou passe inaperçue.
Tableau — Matrice de couverture à adapter au cas d’usage
| Axe | Strates possibles | Risque révélé |
|---|---|---|
| Fréquence | Courant, occasionnel, rare | Un score dominé par les cas faciles |
| Gravité | Faible, significative, critique selon une grille métier | Une erreur rare masquée par la moyenne |
| Produit et version | Gamme, génération contractuelle, avenant, option | Application d’une règle à la mauvaise police |
| Canal | Formulaire, e-mail, scan, photo, téléphone retranscrit | Qualité variable des entrées |
| Complexité | Une pièce, multi-pièces, contradiction, historique long | Perte de relation entre documents |
| Population | Langue, accessibilité, zone ou segment légalement et métier pertinent | Performance différenciée et effet injuste |
| Décision attendue | Réponse, refus motivé, abstention, escalade | Système poussé à répondre à tout prix |
Deux lots complètent cette matrice. Le lot de fréquence est tiré selon une méthode documentée dans le flux cible et sert à estimer la qualité sur l’usage courant. Le lot sentinelle réunit les cas rares, adversariaux, extrêmes ou réglementairement sensibles. Il sert à vérifier des comportements bloquants. Un cas sentinelle ajouté volontairement ne doit pas être pondéré comme s’il reflétait sa fréquence dans le portefeuille.
Le nombre de cas dépend ensuite de la précision recherchée, de la variabilité entre cas, du taux d’événement et des analyses par sous-groupes. Le rapport NIST AI 800-3, publié en février 2026, distingue la performance sur un benchmark fixe de la performance généralisée à une population de questions similaires. Il montre aussi que des méthodes courantes peuvent produire des estimations d’incertitude invalides lorsque leurs hypothèses ne sont pas explicitées. La conséquence pratique n’est pas d’imposer son modèle statistique à chaque projet, mais de déclarer quelle grandeur on estime, sur quelle population, avec quelles hypothèses et quelle incertitude.
Règle de décision. Ne demandez pas au data scientist de « donner le bon nombre ». Demandez-lui quel échantillon permet de décider, avec l’incertitude acceptable, sur la population et les erreurs décrites par le métier. Les cas critiques peuvent relever d’un critère bloquant individuel plutôt que d’un intervalle autour d’une moyenne.
Éviter fuite, contamination et surapprentissage du test
La fuite apparaît lorsque l’évaluation utilise une information qui ne serait pas disponible au moment réel : issue du sinistre, décision finale, note créée après traitement ou champ calculé par le système cible. La contamination apparaît lorsque le même contenu, ou un contenu suffisamment proche, a servi à construire le modèle, le prompt, le corpus ou les exemples. Dans les deux cas, le score surestime ce que le système saura faire sur un nouveau dossier.
Une séparation aléatoire ligne par ligne ne suffit pas lorsque plusieurs lignes appartiennent au même assuré, contrat, sinistre, document ou événement. Des fragments du même dossier peuvent se retrouver des deux côtés. Définissez donc une unité de séparation adaptée : dossier complet, entité, famille documentaire, période ou génération de produit. Le choix dépend du type de généralisation que l’on veut mesurer.
Conservez au minimum quatre espaces :
- Construction. Cas accessibles à l’équipe pour concevoir consignes, règles et intégration.
- Validation. Cas utilisés pour choisir une configuration et comprendre les erreurs.
- Recette protégée. Lot dont les réponses ne servent pas aux itérations ordinaires et qui autorise la décision de version.
- Surveillance. Échantillons postérieurs au déploiement, incidents et corrections, séparés dans le temps.
Le programme AI Technology Evaluation du NIST illustre l’intérêt d’un environnement de test séquestré : les données de test non accessibles réduisent le risque de contamination et soutiennent une évaluation objective. Une entreprise n’a pas besoin de reproduire cette infrastructure nationale, mais elle peut appliquer le principe : droits restreints, réponses chiffrées ou séparées, journal des consultations et responsable indépendant de la libération du lot.
Pour un LLM tiers, il est rarement possible de démontrer l’absence totale de contamination avec des contenus publics. On doit alors limiter la portée de la conclusion, privilégier des cas internes récents et autorisés, créer des variantes réellement nouvelles sans changer le phénomène testé, et surveiller les résultats sur des flux ultérieurs. Une excellente performance sur un benchmark connu reste un signal, pas une recette assurance.
Organiser une annotation défendable
Une vérité de référence utile n’est pas toujours une réponse unique. Une clause peut être ambiguë, une photographie insuffisante, ou deux experts appliquer différemment une consigne. Effacer ces désaccords produit une fausse certitude. Le protocole doit les capturer et distinguer ce qui relève d’une erreur d’annotation, d’une doctrine à préciser ou d’une pluralité de réponses acceptables.
Écrire le guide avant d’annoter en volume
Le guide définit l’unité, les catégories, les preuves admissibles, la gestion de l’absence, les exemples limites et le motif d’escalade. Il interdit aux annotateurs d’utiliser une information postérieure à l’instant évalué. Une phase pilote sur un petit lot sert à identifier les catégories incomprises ; elle ne sert pas encore à publier un score.
Doubler les cas qui commandent la décision
Les cas à fort impact et un échantillon des cas courants sont annotés indépendamment par plusieurs experts. Mesurez le désaccord brut et, si une statistique d’accord est retenue, documentez ses hypothèses et sa sensibilité à la prévalence des catégories. Surtout, lisez les raisons : un accord faible peut révéler un libellé flou ; un accord élevé peut seulement montrer une classe dominante.
Conserver l’arbitrage sans réécrire l’histoire
Un arbitre métier tranche avec la règle ou la doctrine applicable. La valeur initiale, les deux annotations, le motif du désaccord et la décision finale restent versionnés. Lorsque la doctrine change, créez une nouvelle version du label ; ne remplacez pas silencieusement l’ancienne référence. Cette conservation permet de distinguer une amélioration technique d’un changement de définition métier.
Mesurer la qualité, le risque et l’abstention
Le tableau de bord doit refléter la structure de l’erreur. Une classification déséquilibrée ne se résume pas à l’accuracy. Une extraction demande une mesure champ par champ et sur les valeurs critiques. Une réponse contractuelle exige à la fois récupération de la bonne preuve, fidélité à cette preuve et qualité de l’abstention.
Tableau — Familles de mesures pour un système IA d’assurance
| Famille | Mesures possibles | Lecture métier |
|---|---|---|
| Exactitude de tâche | Précision et rappel par classe, exactitude par champ, conformité structurée | Le système réalise-t-il l’action élémentaire attendue ? |
| Preuve | Source correcte, version correcte, passage localisable, affirmation soutenue | Le gestionnaire peut-il vérifier sans refaire toute la recherche ? |
| Abstention | Refus appropriés, réponses indues, couverture utile | Le système connaît-il ses limites opérationnelles ? |
| Impact | Erreurs pondérées par gravité, faux négatifs critiques, coût de reprise | Quel dommage aurait produit l’erreur ? |
| Segments | Résultats et incertitude par produit, canal, complexité et population pertinente | La moyenne masque-t-elle une zone faible ? |
| Opération | Latence, disponibilité, coût par résultat correct, temps de contrôle | Le service reste-t-il exploitable au volume attendu ? |
| Robustesse | Variations, entrées dégradées, contradiction, attaque et changement de version | Comment l’erreur apparaît-elle hors du cas nominal ? |
Le profil NIST AI 600-1 consacré à l’IA générative recense des risques comme la confabulation, la protection des données, les biais, l’intégrité de l’information et la sécurité. Il recommande des évaluations adaptées au contexte plutôt qu’une confiance dans une seule métrique. Dans un système assurance, ces risques doivent être traduits en scénarios observables : citation inexistante, mélange de deux assurés, conseil hors périmètre, fuite d’une donnée dans la trace ou exécution d’une instruction contenue dans une pièce.
Le red teaming ne remplace pas le jeu représentatif. Il explore intentionnellement les faiblesses et enrichit le lot sentinelle. Inversement, un excellent résultat sur le flux fréquent ne prouve pas la résistance à une attaque. Les deux lectures doivent rester séparées puis réunies dans la décision de risque.
Fixer des seuils qui commandent une décision
Les seuils sont écrits avant l’évaluation finale et portent sur plusieurs niveaux :
- Bloqueurs absolus. Exemples à adapter : accès à un dossier non autorisé, action hors périmètre, mélange d’identité, preuve fabriquée sur un cas critique.
- Seuils par segment. Une moyenne acceptable ne compense pas une dégradation importante sur une langue, un produit ou un type de pièce essentiel.
- Plancher d’abstention. Le système doit refuser correctement les cas sans preuve et les router vers une personne ou un traitement défini.
- Budget opérationnel. Temps de vérification, latence, coût et taux de reprise ne doivent pas annuler la valeur attendue.
- Stabilité. Une nouvelle version ne passe que si elle respecte les mêmes bloqueurs et si les différences sont comprises.
Il n’existe pas de valeur universelle à insérer ici. Un seuil dépend du risque, du volume, du contrôle humain, de la réversibilité et de la réglementation applicable. La documentation doit dire qui l’a fixé, sur quelle base, quand il sera revu et quelle action automatique suit son dépassement.
Scénario hypothétique : évaluer un assistant contractuel
Cette illustration est volontairement hypothétique et ne rapporte aucun résultat réel. Un courtier veut évaluer un assistant qui retrouve les passages utiles d’un contrat professionnel et prépare une réponse interne. L’assistant ne répond pas directement au client.
L’unité est une question accompagnée du jeu de documents disponible à la date de la demande. La référence contient la police applicable, les avenants ordonnés, le ou les passages utiles et, si nécessaire, la conclusion « information insuffisante ». La matrice répartit les cas par produit, génération contractuelle, présence d’avenant, type de garantie, renvoi, tableau, qualité du scan et langue. Les questions courantes sont échantillonnées dans le flux ; les contradictions et absences de réponse forment un lot sentinelle.
Deux juristes ou gestionnaires expérimentés annotent les cas critiques. Un arbitrage conserve les raisons du désaccord. Les documents d’un même contrat ne sont jamais répartis entre construction et recette protégée. Les métriques séparent : récupération du bon document, localisation du passage, fidélité de la synthèse, abstention, temps de vérification et erreur pondérée par impact.
Si le système cite correctement mais applique parfois un avenant périmé, le score de rédaction n’a aucune valeur décisionnelle. L’équipe corrige d’abord la sélection de version et rejoue le lot protégé selon la procédure prévue. Si le système s’abstient trop souvent sur un produit rare, le comité peut autoriser un périmètre limité aux produits couverts au lieu d’abaisser globalement le seuil.
Faire du jeu d’évaluation un produit métier
L’opinion de l’EIOPA du 6 août 2025 souligne, pour son périmètre, une gouvernance proportionnée au risque, des responsabilités claires, une gouvernance des données, une documentation ordonnée, une supervision humaine et une robustesse adaptées. Le jeu d’évaluation contribue à ces objectifs seulement s’il est détenu par le métier et relié aux changements du système.
Donnez-lui une fiche de version comprenant : finalité, population, période de données, base d’accès, méthode de sélection, matrice de couverture, guide d’annotation, qualité des labels, séparation des lots, métriques, seuils, résultats, limites et approbateurs. Un registre des transformations indique les corrections de données et les variantes créées. Les accès sont révisés et la durée de conservation est justifiée.
Après déploiement, chaque incident confirmé devient candidat au test de non-régression. Chaque correction humaine n’est pas automatiquement une nouvelle vérité : elle suit le contrôle d’annotation. Les changements de produit, de canal, de modèle, de prompt, d’outil ou de source déclenchent une analyse d’impact. Enfin, un lot entièrement nouveau est constitué périodiquement pour éviter qu’une équipe optimise indéfiniment le système sur les mêmes questions.
La bonne question de comité n’est donc plus « quel est le score de l’IA ? », mais : quelles décisions ce jeu nous autorise-t-il, sur quels dossiers, avec quelles incertitudes et quels mécanismes d’arrêt ?
Sources et références
Références consultées le 7 septembre 2026. Les cadres NIST sont volontaires et non sectoriels ; les recommandations de cet article les traduisent en méthode assurance sans leur attribuer de seuils qu’ils ne fixent pas.
- NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023.
- NIST AI Resource Center — AI RMF Core, notamment la fonction Measure.
- NIST — Expanding the AI Evaluation Toolbox with Statistical Models, NIST AI 800-3, février 2026.
- NIST — Generative Artificial Intelligence Profile, NIST AI 600-1, 2024.
- NIST — Artificial Intelligence Technology Evaluation, présentation du testbed séquestré.
- EIOPA — Opinion on Artificial Intelligence governance and risk management, 6 août 2025.
Construire une recette qui autorise vraiment une décision
Vous devez transformer des dossiers, règles et risques métier en jeu d’évaluation versionné ? Jacques Joly Blary peut vous aider à cadrer la matrice, l’annotation, les seuils et le dispositif de non-régression avant le choix d’un modèle ou le passage en production.
