L’exactitude d’une IA commence par un dossier de test

Le mot « exactitude » vient d’entrer dans une bataille politique américaine. Le 7 juillet 2026, la Federal Trade Commission a publié un projet de position sur les systèmes d’intelligence artificielle. Son point de départ est simple : une entreprise peut tromper ses clients si elle présente un système comme orienté vers les objectifs de l’utilisateur tout en dirigeant secrètement ses réponses vers d’autres objectifs. La consultation s’est close le 31 juillet.

La proposition vise notamment les réponses déformées par des préférences idéologiques non déclarées. Elle rappelle aussi quelque chose de plus ordinaire : lorsqu’un fournisseur promet une performance, il doit pouvoir étayer cette promesse. Un avertissement enfoui dans les conditions générales ne corrige pas nécessairement l’impression créée par le produit et son marketing.

Cette exigence de loyauté est saine. Elle laisse pourtant entière la question la plus difficile : comment reconnaître une réponse exacte ? Une IA ne possède pas un cadran universel dont l’aiguille indiquerait la vérité. Elle résume, classe, extrait, prédit, recommande ou agit. Chacun de ces verbes appelle une référence différente, un type d’erreur différent et un seuil différent.

Sans dossier de test, l’exactitude reste un adjectif. Elle peut servir une promesse commerciale, une règle ou une querelle, mais elle ne permet ni d’accepter une livraison, ni de détecter une régression, ni de savoir quand retirer le système.

Un score sans question ne mesure rien

Demander « quel est le taux d’exactitude de votre IA ? » ressemble à une question technique. C’est en réalité une question incomplète. Il manque au moins le travail demandé, la population de cas, la réponse de référence, la manière de noter et les conditions d’utilisation.

Un modèle peut retrouver correctement le numéro de TVA dans 99 % de factures propres et échouer sur des scans inclinés. Il peut classer 92 % des tickets dans la bonne file tout en envoyant presque tous les incidents de sécurité vers le support ordinaire. Il peut produire un résumé fidèle d’un contrat court et perdre une exception située dans une annexe. Les trois systèmes peuvent afficher un beau score moyen et rester impropres au travail qui leur est confié.

Le NIST définit l’exactitude comme la proximité entre un résultat et une valeur vraie ou acceptée comme telle. Son cadre ajoute immédiatement les conditions qui donnent un sens à cette proximité : jeux de test réalistes, représentatifs de l’usage prévu, méthode documentée, résultats ventilés et validité au-delà des conditions d’entraînement. Il demande aussi de considérer l’association entre humain et IA, pas seulement la sortie isolée du modèle.

Cette précision change l’achat. Le fournisseur ne doit pas seulement livrer un pourcentage. Il doit indiquer la question à laquelle ce pourcentage répond.

FTC, projet de position sur l’exactitude des systèmes d’IA et NIST, risques et caractéristiques d’une IA digne de confiance, vérifiés le 4 août 2026.

La vérité du métier précède la réponse du modèle

Pour une extraction de données, la référence peut être un champ relu par deux personnes. Pour un classement, elle peut être la file réellement choisie par une équipe expérimentée. Pour un résumé, il n’existe souvent pas une phrase unique attendue. Il faut alors définir ce qui doit absolument apparaître, ce qui ne doit pas être inventé et ce qui peut varier sans rendre la réponse fausse.

Le mot « vérité » cache donc plusieurs objets.

Tâche	Référence utile	Erreur à isoler	Décision de sécurité
Extraire un montant	Montant validé dans le document source	Chiffre inventé, signe perdu, devise confondue	Bloquer l’écriture si la source n’est pas retrouvée
Classer un ticket	Catégorie confirmée après traitement	Incident critique rangé comme demande ordinaire	Faire remonter les cas sensibles ou ambigus
Résumer un contrat	Liste d’obligations et d’exceptions relue	Clause omise ou ajout absent du texte	Afficher les passages d’appui et garder la revue humaine
Rédiger une réponse	Faits du dossier et règles éditoriales	Affirmation non sourcée, destinataire ou ton erroné	Produire un brouillon sans envoi automatique

Une moyenne commune à ces quatre tâches ne serait pas seulement peu informative. Elle pourrait masquer précisément l’erreur que l’organisation cherchait à éviter. Le dossier de test doit donc partir du travail, pas du modèle. Il décrit d’abord ce qui compte lorsque personne ne parle encore de pourcentage.

Cette étape révèle aussi les désaccords humains. Deux spécialistes peuvent classer différemment un même ticket ou résumer autrement la même note. Ce n’est pas une raison pour abandonner la mesure. C’est une raison pour conserver l’accord, le désaccord et la règle d’arbitrage. Une réponse de référence fabriquée à la hâte n’est pas plus vraie parce qu’elle se trouve dans une colonne appelée golden answer.

Les erreurs n’ont pas toutes le même prix

Un score global additionne volontiers les réussites et divise par le nombre de cas. Cette opération suppose que chaque cas pèse autant. Le métier sait que ce n’est presque jamais vrai.

Dans un tri de factures, un faux positif peut autoriser un document qui ne devait pas passer. Un faux négatif peut envoyer une facture correcte en revue manuelle. Les deux sont des erreurs, mais la première peut déclencher un paiement indu tandis que la seconde coûte quelques minutes. Dans un filtre de sécurité, le rapport peut s’inverser. Dans une recherche documentaire, ne rien trouver et inventer une référence ne doivent surtout pas partager la même case « réponse incorrecte ».

La mesure utile sépare au minimum :

1. les réponses correctes et complètes ;
2. les réponses partielles mais récupérables ;
3. les faux positifs ;
4. les faux négatifs ;
5. les inventions sans appui ;
6. les abstentions justifiées ;
7. les échecs techniques ou délais dépassés.

Puis elle attribue un traitement à chaque catégorie. Certaines autorisent une correction automatique. D’autres imposent une revue. Quelques-unes arrêtent la mise en production, même si la moyenne reste élevée.

Cette pondération n’est pas une déformation cachée de l’exactitude. Elle est la déclaration honnête de l’objectif. Le NIST rappelle d’ailleurs que validité, fiabilité, sécurité, interprétabilité, vie privée et équité peuvent entrer en tension. Le jugement humain doit choisir les métriques et les seuils adaptés au contexte. Prétendre qu’un seul chiffre supprime ces arbitrages les rend simplement invisibles.

Le benchmark et le dossier réel ne sont pas la même population

Les benchmarks publics sont utiles. Ils rendent une comparaison possible, donnent un langage commun et accélèrent la détection de régressions. Ils deviennent trompeurs quand leur score est présenté comme une aptitude générale.

Dans son rapport AI 800-3 publié en février 2026, le NIST distingue l’exactitude sur un benchmark fixé de l’exactitude généralisée sur l’ensemble plus large des questions comparables à ce benchmark. Les chercheurs ont évalué 22 modèles accessibles par API sur trois benchmarks et montrent que les deux objets ne se calculent pas nécessairement de la même manière. Une moyenne peut cacher les hypothèses de l’évaluation et mal représenter son incertitude.

Cette distinction est encore plus importante dans une entreprise. Le corpus public ne contient ni ses abréviations, ni ses modèles de documents, ni ses exceptions contractuelles, ni la qualité réelle de ses scans. Il ne connaît pas les cas qui arrivent le lundi après une migration, ceux qui mélangent deux langues ou ceux qu’un client remplit dans le mauvais champ.

Un modèle mieux classé peut donc être moins adapté. Ce constat ne rend pas les benchmarks inutiles. Il limite leur fonction : présélectionner, explorer une capacité et documenter une hypothèse. Le test d’acceptation commence lorsque les dossiers représentatifs du travail réel entrent dans la pièce.

NIST AI 800-3, Expanding the AI Evaluation Toolbox with Statistical Models, distinction entre exactitude de benchmark et exactitude généralisée vérifiée le 4 août 2026.

Une réponse exacte peut être une abstention

Les démonstrations récompensent la réponse. La production doit parfois récompenser le refus.

Un document manque. Deux sources se contredisent. La date de référence n’est pas connue. Le modèle ne dispose pas du barème applicable. Dans ces situations, une phrase prudente qui nomme l’information absente est plus exacte qu’une réponse fluide. Pourtant, un test qui exige toujours une sortie complète peut la pénaliser.

Il faut donc écrire les règles d’abstention avant d’évaluer. Quand le système doit-il dire « je ne sais pas » ? Quand peut-il proposer une hypothèse clairement étiquetée ? Quand doit-il citer un passage ? Quand la décision revient-elle obligatoirement à une personne ?

L’abstention doit elle aussi être testée. Trop rare, elle laisse passer les inventions. Trop fréquente, elle transforme l’outil en détour coûteux. Le bon seuil dépend encore du prix des deux erreurs. Il n’existe pas dans le modèle seul.

La bibliothèque de scénarios proposée par le NIST suit cette logique. Elle part de situations sectorielles réalistes et testables, avec données, méthodes, risques et bénéfices associés. Un scénario n’est pas un long prompt décoratif. C’est une unité que l’on peut rejouer, annoter et relier à une conséquence.

NIST, bibliothèque de scénarios pour des évaluations et métriques répétables, vérifiée le 4 août 2026.

La version fait partie du résultat

Un test d’IA n’est pas achevé quand le score est calculé. Il faut pouvoir le refaire.

Le dossier doit conserver le fournisseur, le nom du modèle, la version ou l’identifiant disponible, la date, les paramètres, le prompt système, les outils accessibles, la base documentaire, les filtres, le schéma de sortie et le code d’évaluation. Pour un service distant qui change sans numéro public, la date et un lot de réponses témoins deviennent indispensables.

Il faut aussi garder les cas qui ont échoué. Les remplacer par des exemples plus propres améliore le tableau sans améliorer le système. À l’inverse, ajouter chaque incident au corpus permet au test de suivre le travail réel. Le dossier devient alors une mémoire des erreurs coûteuses, pas une photographie choisie pour le comité de pilotage.

Après une mise à jour, trois résultats sont possibles : amélioration, stabilité ou régression. Une meilleure moyenne n’exclut pas la régression. Dix réponses ordinaires peuvent progresser pendant qu’un seul cas critique se dégrade. Le rapport doit afficher les deux.

Cette exigence rejoint l’article 15 du règlement européen sur l’IA pour les systèmes à haut risque. Le texte demande un niveau approprié d’exactitude, de robustesse et de cybersécurité durant le cycle de vie. Il prévoit que les niveaux et métriques d’exactitude soient déclarés dans la notice. Il n’impose pas un pourcentage magique ; il impose que la mesure existe, soit pertinente et reste lisible.

Commission européenne, article 15 du règlement sur l’IA, texte et métriques d’exactitude vérifiés le 4 août 2026.

Le petit dossier de test qui vaut mieux qu’une grande promesse

Une PME n’a pas besoin d’un laboratoire complet pour commencer. Elle a besoin d’un corpus assez petit pour être relu et assez contrarié pour révéler les erreurs importantes.

Trente à cinquante cas peuvent suffire pour une première décision bornée, à condition de ne pas choisir trente cas faciles. On peut répartir le lot entre situations ordinaires, limites, documents incomplets, contradictions, anciennes versions, formats dégradés et cas où l’abstention est attendue. Les cas sensibles doivent être synthétiques ou correctement protégés ; le dossier de test ne justifie pas de copier des données personnelles dans un service non approuvé.

Chaque ligne contient au minimum :

• un identifiant stable et la source du cas ;
• l’entrée exacte donnée au système ;
• le résultat attendu ou les critères acceptables ;
• les éléments interdits, comme une invention ou une action ;
• la gravité d’un faux positif et d’un faux négatif ;
• la réponse obtenue, les preuves citées et le temps de traitement ;
• le verdict humain et son motif ;
• la version testée et la date.

Le seuil de passage vient ensuite. Il peut exiger, par exemple, zéro invention de montant, cent pour cent de citations retrouvables pour les décisions sensibles et une limite de faux négatifs sur les cas ordinaires. Ces nombres ne prétendent pas mesurer toute l’intelligence. Ils décrivent les conditions d’acceptation d’un travail précis.

Le fournisseur peut contester un cas, proposer une autre métrique ou expliquer une limite. C’est même souhaitable. La discussion devient productive parce qu’elle porte sur une entrée, une sortie et une conséquence observables. Elle ne porte plus sur la confiance abstraite dans une marque ou sur une démonstration choisie par celui qui vend.

Ce qu’il faut laisser reposer

L’exactitude d’une IA ne se protège pas en déclarant qu’elle doit dire vrai. Elle se protège en rendant falsifiable la promesse faite à l’utilisateur.

La proposition de la FTC pose une bonne question de loyauté : le système poursuit-il secrètement un objectif différent de celui qui a été annoncé ? Le dossier de test ajoute la question opérationnelle : comment le savons-nous, sur quels cas, avec quelle version et que faisons-nous quand la réponse change ?

Un modèle peut être exact sur un benchmark et faux dans un dossier. Il peut être exact en moyenne et dangereux sur l’exception. Il peut produire une phrase vraie à partir d’une source périmée. Il peut enfin s’améliorer sur la forme tout en perdant la capacité de s’abstenir.

Le cadran n’est utile que si l’on connaît l’unité, la plage et l’instrument. Pour l’IA, cette plaque signalétique s’appelle un dossier de test. Sans elle, l’aiguille bouge, mais personne ne sait encore ce qu’elle mesure.