Réponse courte : pour évaluer une sortie textuelle d'IA générative, ne demandez pas seulement si elle « semble bonne ». Construisez un paquet d'évaluation rejouable : un registre de cas, une référence annotée, une grille avec des exemples de notation et un rapport qui sépare qualité, gravité, désaccord humain, variabilité et temps de correction. L'unité mesurée est le texte utile à une tâche précise, avec ses sources et ses contraintes, pas le modèle pris isolément.
Ce guide ne décrit pas le calendrier d'un pilote ni une décision générale de déploiement. Il montre comment fabriquer l'instrument qui permettra de mesurer une synthèse, un brouillon ou une réponse textuelle fondée sur des documents. Pour une classification, une extraction structurée, du code, une image ou une action automatisée, il faut d'autres références et d'autres tests.
Le paquet d'évaluation tient dans quatre fichiers versionnés
Une conversation réussie dans une démonstration n'est pas une preuve. Le profil NIST AI 600-1 pour l'IA générative recommande de mesurer les performances dans des conditions proches du déploiement, de documenter les mesures et de ne pas extrapoler à partir d'évaluations étroites, non systématiques ou anecdotiques.
Le paquet minimal matérialise cette discipline :
cases.csvinventorie les situations testées, leur famille, leur référence et les résultats interdits.annotation-guide.mddéfinit chaque critère, chaque niveau de note et la règle de traitement des désaccords.runs.csvconserve les sorties, les sources récupérées, les versions, les durées et les notes brutes.evaluation-report.mdprésente les résultats par critère et famille de cas, les défauts, la variabilité, l'effort humain et les limites.
Ces noms sont indicatifs. L'important est de pouvoir relier chaque conclusion à un cas, une sortie, une référence et une version. Un tableau de bord sans données brutes ne permet ni enquête ni régression.
Construire un registre de cas réellement copiable
Chaque ligne du registre doit permettre à une personne qui n'a pas conçu le système de comprendre ce qui est évalué. Le modèle suivant peut être copié dans un tableur ou un fichier CSV.
| Champ | Contenu attendu | Exemple pédagogique |
|---|---|---|
case_id |
Identifiant stable, sans donnée personnelle | ACHAT-CONFLIT-004 |
family |
Cas courant, source manquante, contradiction, hors périmètre ou cas de résistance | sources_contradictoires |
input |
Question et documents autorisés, ou pointeur vers un jeu privé | Comparer la durée de garantie indiquée dans trois fiches |
required_facts |
Faits qui doivent apparaître | Valeur, unité, produit et date de chaque fiche |
forbidden_outcomes |
Affirmations ou actions qui invalident la sortie | Choisir une valeur sans signaler la contradiction |
source_refs |
Références exactes utilisées pour annoter | Fiche A p. 2 ; fiche B p. 6 ; fiche C datée |
severity |
Gravité maximale d'un résultat interdit | majeure |
annotation_status |
À annoter, doublement annoté, arbitré ou gelé | gelé |
set |
Mise au point, calibration, évaluation ou régression | evaluation |
Ajoutez des colonnes propres au métier si elles changent la lecture : langue, type de document, niveau de confidentialité, groupe d'utilisateurs ou version de règle. Ne placez pas une information sensible dans le registre uniquement pour rendre le cas réaliste ; utilisez des données fictives, synthétiques, anonymisées ou dûment autorisées.
Séparer représentativité et recherche de défaillances
Un seul jeu répond mal à deux questions différentes. Le jeu opérationnel reproduit autant que possible les proportions du travail réel : il estime la qualité habituelle. Le jeu de résistance surreprésente les contradictions, documents incomplets, demandes hors périmètre et formulations manipulatrices : il cherche où le système casse.
| Famille | Preuve recherchée | Résultat attendu |
|---|---|---|
| Courante | Exactitude et effort sur le flux majoritaire | Réponse complète avec la revue prévue |
| Source manquante | Capacité à reconnaître une preuve insuffisante | Question, réserve ou abstention explicite |
| Sources contradictoires | Détection du conflit et traçabilité | Deux valeurs citées, sans arbitrage inventé |
| Hors périmètre | Respect de la tâche et des documents autorisés | Refus limité ou escalade |
| Test de résistance | Comportement face à une instruction cachée ou trompeuse | Instruction ignorée et incident journalisé |
Présentez les résultats des deux jeux séparément. Une forte proportion de cas difficiles dans le jeu de résistance ne représente pas leur fréquence en production. À l'inverse, un échantillon opérationnel peut contenir trop peu de cas rares pour éprouver un garde-fou.
Le rapport pilote ARIA 0.1, NIST AI 700-2, publié le 13 novembre 2025, distingue trois niveaux de test : test du modèle, équipe rouge et test terrain. Il décrit l'annotation de dialogues, les questionnaires de testeurs et les arbres de mesure. Une PME n'a pas à reproduire ce programme, mais elle peut conserver sa séparation utile entre capacité annoncée, comportement sous contrainte et usage réel.
Décrire une sortie acceptable sans imposer une phrase unique
Pour une sortie textuelle, une « réponse parfaite » rédigée mot à mot devient vite un mauvais étalon. Deux textes peuvent être corrects sans partager la même formulation. La référence doit plutôt énumérer :
- les faits obligatoires et leur source ;
- les contradictions ou inconnues à signaler ;
- les affirmations interdites ;
- la forme attendue : longueur, structure, langue, citations ;
- l'action autorisée après lecture ;
- la gravité de chaque écart important.
Le profil NIST AI 600-1 rappelle que les jeux de test peuvent eux-mêmes contenir des erreurs d'étiquetage. Faites donc relire la référence par une personne compétente et conservez la date, l'auteur de l'annotation et le motif de chaque modification. Un changement de référence crée une nouvelle version du jeu ; il ne doit pas réécrire silencieusement les résultats passés.
Ancrer cinq critères avec des exemples observables
La grille suivante convient à une synthèse fondée sur des documents. Chaque niveau décrit un résultat observable ; il ne demande pas à l'évaluateur d'interpréter une notion vague comme « intelligence » ou « qualité globale ».
| Critère | 0 — échec | 1 — partiel | 2 — conforme |
|---|---|---|---|
| Exactitude | Fait, calcul ou attribution faux | Imprécision sans changement de conclusion | Faits et calculs conformes aux références |
| Couverture | Question principale ou contrainte décisive omise | Un élément secondaire manque | Tous les éléments obligatoires sont traités |
| Traçabilité | Source absente, fabriquée ou sans rapport | Source pertinente mais attribution imprécise | Chaque affirmation décisive renvoie à la bonne source |
| Respect des règles | Document, instruction ou résultat interdit | Écart formel corrigeable | Périmètre, format et restrictions respectés |
| Utilité | La sortie conduit à une mauvaise action ou exige une réécriture | Une correction locale reste nécessaire | La tâche peut être poursuivie avec la revue prévue |
Notez la gravité dans un champ distinct. Un score de 0 sur la forme n'a pas la même conséquence qu'une citation inventée qui change une décision. Une erreur critique peut suffire à invalider une campagne même si les autres notes sont élevées.
Le NIST définit la « confabulation » comme un contenu faux ou erroné présenté avec assurance, y compris une logique ou une citation fabriquée. Une sortie fluide n'est donc pas une preuve de validité. Le même profil recommande de vérifier les sources et citations avant déploiement puis pendant la surveillance.
Mesurer le désaccord entre évaluateurs avant de noter l'IA
Deux personnes annotent indépendamment un lot de calibration avec le même guide. Pour chaque critère, calculez d'abord un indicateur simple :
taux d'accord = décisions identiques / décisions comparées
Ne transformez pas ce taux en seuil universel. Utilisez-le pour localiser l'ambiguïté. Si les évaluateurs s'accordent sur l'exactitude mais divergent souvent sur l'utilité, ajoutez des exemples d'utilité 0, 1 et 2 ou séparez deux situations métier. Conservez aussi une matrice des désaccords : confondre régulièrement 0 et 2 est plus préoccupant que discuter entre 1 et 2.
Le fichier de calibration doit enregistrer :
- la note de chaque évaluateur avant discussion ;
- le critère concerné et l'écart observé ;
- la décision arbitrée et son motif ;
- la modification éventuelle du guide ;
- la version à partir de laquelle le jeu peut être gelé.
Si le guide change, rejouez la calibration. Arbitrer les lignes sans conserver les notes initiales ferait disparaître la preuve que l'instrument était ambigu.
Mesurer la variabilité sans compter les répétitions comme de nouveaux cas
Une même entrée peut produire plusieurs sorties. Sélectionnez donc des cas importants et répétez-les avec la même version, à des moments séparés si l'architecture le justifie. Comparez les faits, les citations, l'abstention et la note par critère.
Trois répétitions d'un cas ne constituent pas trois situations indépendantes. Le rapport doit présenter deux mesures distinctes :
- couverture des cas : nombre de situations différentes évaluées ;
- stabilité : dispersion des résultats lorsque la même situation est rejouée.
Une moyenne correcte peut masquer un comportement instable : deux réponses exactes et une affirmation fabriquée restent un risque à comprendre. Ajoutez toute défaillance nouvelle au jeu de régression, avec une référence qui permettra de vérifier qu'elle ne revient pas.
Exemple fictif : la mesure révèle d'abord un guide ambigu
L'exemple suivant est entièrement pédagogique. Il ne décrit ni un client, ni un test, ni un résultat de Forge Labs.
Une équipe évalue un système qui synthétise trois fiches techniques publiques pour préparer une réunion d'achat. Avant l'exécution, elle écrit trois limites propres à cet exemple : aucune valeur décisive sans source, aucune contradiction masquée et au moins 36 cas sur 40 notés 2 en exactitude. Ces nombres illustrent une décision locale ; ils ne constituent pas une norme.
Deux évaluateurs commencent par dix cas de calibration sur cinq critères, soit 50 décisions comparables. Ils donnent la même note sur 42 décisions : 42 / 50 = 84 %. La matrice montre que cinq des huit désaccords portent sur la traçabilité. Le guide disait « source précise » sans distinguer le document de la page. L'équipe ajoute des exemples, conserve les notes initiales, puis rejoue la calibration. Elle ne mesure pas encore le système : elle corrige d'abord son instrument.
Sur le jeu d'évaluation fictif de 40 cas, le rapport ne publie pas seulement un total. Il présente cette lecture :
| Preuve fictive | Résultat | Conclusion limitée |
|---|---|---|
| Exactitude notée 2 | 37 cas sur 40 | La limite locale de 36 est franchie |
| Affirmation décisive sans source | 1 cas | La condition de zéro cas n'est pas respectée |
| Contradiction masquée | 0 cas | Aucun échec trouvé dans ce jeu |
| Temps médian de correction | Valeur à mesurer, non inventée ici | Impossible de conclure sur l'effort humain |
Le système ne satisfait pas les critères du paquet d'évaluation, malgré 37 cas exacts sur 40 : une affirmation décisive sans source viole une limite écrite. Le rapport doit conserver le cas, la sortie, la cause supposée et le test de régression. Zéro contradiction masquée observée ne prouve pas qu'aucune ne surviendra ; cette conclusion reste bornée aux 40 cas et à la version testée.
Écrire un rapport que l'on peut contredire et rejouer
Le programme NIST consacré aux tests, à l'évaluation, à la validation et à la vérification souligne que le contexte est déterminant et que chaque caractéristique — exactitude, robustesse, biais, interprétabilité ou transparence — demande son propre portefeuille de mesures.
Un rapport exploitable contient au minimum :
- l'usage textuel, les exclusions et les versions testées ;
- le nombre de cas différents par famille et le nombre de répétitions ;
- les résultats par critère, famille et gravité ;
- l'accord initial entre évaluateurs et les arbitrages ;
- les défauts nouveaux, sorties concernées et causes encore hypothétiques ;
- l'effort de lecture, vérification, correction et rejet ;
- les limites franchies ou non, sans modifier leur valeur après le test ;
- les cas ajoutés au paquet de régression.
Après une mise à jour, rejouez d'abord les cas de régression, puis un jeu indépendant. Le profil NIST AI 600-1 recommande d'évaluer les performances en situation réelle, de documenter les décisions remplacées par un opérateur et de suivre erreurs, quasi-incidents et impacts négatifs.
Le centre de métrologie de l'IA du NIST relie des méthodes et métriques aux caractéristiques de confiance et aux étapes du cycle de vie. Le NIST précise que l'inclusion d'une ressource ne vaut ni approbation, ni validation, ni garantie d'adéquation. L'instrument retenu reste à justifier pour la tâche.
La frontière de cette preuve
Ce paquet évalue une sortie textuelle, dans un contexte et avec une version donnés. Il ne prouve pas qu'une IA peut prendre une décision, agir sans contrôle ou conserver sa qualité après un changement de sources, d'instructions, d'outils ou de fournisseur.
Pour replacer cette mesure dans une démarche plus large, consultez les conditions permettant à une PME d'aborder l'IA sans disperser son effort et l'analyse des causes qui expliquent pourquoi des projets IA échouent.
La question finale devient vérifiable : quels textes, sur quels cas, selon quelle référence, avec quel désaccord humain, quelle variabilité et quel coût de correction ont respecté les limites écrites ? Si le rapport ne permet pas de retrouver cette réponse ligne par ligne, l'évaluation n'est pas encore un instrument de décision.