Comment évaluer une application IA avant de la mettre en production ?

« J’ai testé dix questions et ça marche » n’est pas une recette

Un bon système d’évaluation ne cherche pas à démontrer que l’application fonctionne. Il cherche à découvrir où elle ne fonctionne pas encore suffisamment bien.

Une application classique produit généralement un résultat déterministe : une même entrée conduit, dans les mêmes conditions, au même comportement attendu. Un système génératif introduit de la variabilité. Un agent ajoute encore une dimension : il choisit ses outils et peut suivre plusieurs chemins différents pour accomplir une même tâche, sans qu’aucun ne soit « le » chemin correct au sens où un test unitaire l’entend.

Le principe d’une évaluation, lui, reste simple : on soumet une entrée à l’application, puis on applique une logique de notation à ce qu’elle produit pour décider si le résultat est acceptable. Toute la difficulté du sujet tient dans cette logique de notation, et dans le choix des entrées auxquelles on la soumet.

Dans « Demystifying evals for AI agents », publié le 9 janvier 2026, l’équipe ingénierie d’Anthropic formule le paradoxe de départ : les capacités qui rendent les agents utiles, l’autonomie, l’appel d’outils, l’adaptation et le fonctionnement multi-tours, sont exactement celles qui les rendent difficiles à évaluer. La conséquence pratique est qu’on ne peut plus se contenter d’inspecter une sortie. Il faut décider à l’avance ce que l’on mesure, sur quels cas on le mesure, et qui attribue la note.

Commencer par définir ce que « bon » signifie

Avant de choisir un outil ou un framework d’évaluation, il faut trancher une question métier : qu’est-ce qu’une réponse réussie dans ce cas d’usage ? Anthropic propose un test simple pour savoir si le critère est assez précis : deux experts du domaine, jugeant indépendamment la même réponse, doivent aboutir au même verdict. Tant que ce n’est pas le cas, le critère n’en est pas un, c’est une intention.

Pour un chatbot de support, l’exactitude factuelle est le premier réflexe, et elle ne suffit jamais seule. Une réponse peut être exacte et inexploitable parce qu’elle ignore la procédure applicable, par exemple en annonçant un remboursement là où le contrat impose un avoir. Elle peut aussi être irréprochable dans sa forme et inventée dans son contenu, ce qui reste le mode de défaillance le plus coûteux pour une marque. Une deuxième famille de critères porte moins sur la réponse que sur la lecture de la demande : le système a-t-il compris le motif réel du contact, souvent différent de la question littéralement posée ? Une troisième porte sur ce qu’il fait quand il ne devrait pas répondre, car transférer à un humain au bon moment vaut mieux qu’une réponse plausible sur un dossier sensible. Reste le ton, qu’on range volontiers dans le cosmétique alors qu’il constitue la partie la plus visible du service rendu.

Pour un agent, ces critères changent de nature, parce que le système n’écrit pas seulement : il agit. Le résultat final correct demeure le critère terminal, mais il ne dit rien de la manière dont il a été obtenu. Trois questions s’ajoutent en amont : l’agent a-t-il choisi le bon outil, l’a-t-il appelé avec des paramètres corrects, et s’est-il tenu à l’écart des actions qu’il n’a pas le droit d’exécuter ? La quatrième est économique : le nombre d’étapes consommées détermine directement le coût et le temps de réponse de chaque exécution. Un agent qui réussit en trente appels d’outils réussit sur le papier et échoue en production.

Construire un jeu d’évaluation représentatif

Des critères sans cas sur lesquels les appliquer ne mesurent rien. Ce jeu de référence, que l’on appelle souvent golden dataset, est le véritable actif du dispositif : il détermine ce que l’équipe verra et, surtout, ce qu’elle ne verra pas.

Les cas nominaux, les scénarios courants, ne mesurent qu’une chose : que le système fonctionne quand tout va bien. Ils restent nécessaires pour détecter les régressions grossières, mais un jeu composé uniquement de ceux-là produit un score flatteur et sans information.

Les cas limites, formulations ambiguës, informations manquantes, demandes mal posées, mesurent le comportement du système quand l’entrée est imparfaite. Ils révèlent surtout s’il sait réclamer une précision plutôt que de combler un vide par une hypothèse.

Les cas non passants, ceux que le système doit refuser ou transférer, évaluent une compétence d’une autre nature : savoir ne pas répondre. C’est la catégorie la plus souvent oubliée, parce qu’elle oblige à écrire des tests dont le succès est une absence d’action. Anthropic insiste sur ce point : il faut tester à la fois les situations où un comportement doit se produire et celles où il ne doit pas, faute de quoi l’optimisation dérive vers un système qui répond toujours.

Les cas adversariaux pertinents, tentatives de contournement des consignes ou instructions hostiles glissées dans un document que le système va lire, mesurent la robustesse des règles. Ils prolongent, côté qualité, ce que les contrôles de sécurité d’un agent connecté au SI traitent côté architecture. L’adjectif « pertinents » compte : l’objectif n’est pas de rejouer un exercice générique, mais de couvrir les attaques réalistes compte tenu de ce que ce système précis a le droit de faire.

Les cas métier rares mais critiques, enfin, sont ceux dont la fréquence ne justifie aucune attention et dont l’impact la justifie entièrement : une résiliation, une réclamation encadrée par la réglementation, un client en litige. Statistiquement invisibles, opérationnellement décisifs.

Ce jeu n’a pas besoin d’être exhaustif pour être utile. Anthropic recommande de partir de vingt à cinquante tâches simples, tirées d’échecs réellement observés, plutôt que d’attendre un corpus parfait. Chaque cas gagne à être accompagné d’une solution de référence, une sortie connue qui passe tous les contrôles : c’est elle qui prouve que la tâche est solvable et que la notation est correctement configurée. Sans elle, un test qui échoue ne permet pas de distinguer un défaut du système d’un défaut du test.

Mesurer plusieurs dimensions

Une application IA ne se résume pas à un score unique. Chaque dimension répond à une question différente, et un système peut être excellent sur l’une et disqualifié sur l’autre.

L’ancrage mérite d’être suivi séparément de l’exactitude : il distingue une réponse juste d’une réponse juste par hasard, et c’est cette distinction qui prédit le comportement du système sur les questions qu’il n’a jamais vues.

Les deux dernières lignes sont tout aussi importantes. Le meilleur modèle en qualité brute n’est pas automatiquement le meilleur choix si le gain obtenu ne justifie pas son coût ou sa latence : c’est exactement l’arbitrage décrit dans notre méthode de sélection d’un LLM.

Évaluer également la trajectoire des agents

Pour un chatbot simple, évaluer la réponse finale peut suffire. Pour un agent, c’est insuffisant, parce que deux exécutions qui aboutissent au même résultat n’ont pas la même valeur. L’une a pu appeler un outil qu’elle n’était pas autorisée à appeler, ce qui constitue un incident de sécurité même lorsque la réponse est bonne. Une autre a pu exposer une donnée en la faisant transiter par un service qui n’avait pas à la voir. Une troisième a atteint le bon résultat au prix de dix appels inutiles, et cela se paie en coût et en latence à chaque exécution. Une quatrième a échoué trois fois avant de réussir, signe d’une instabilité qui finira par se manifester le jour où la quatrième tentative échouera aussi. La réponse finale, seule, ne distingue aucune de ces quatre exécutions d’une exécution propre.

Évaluer la trajectoire ne signifie pas pour autant figer la séquence d’appels attendue. Anthropic met en garde contre ce réflexe : vérifier que l’agent a suivi exactement les étapes prévues produit des tests fragiles, car les agents empruntent régulièrement des chemins valides que le concepteur de l’évaluation n’avait pas anticipés. Ce qu’il faut contrôler, ce sont les invariants : aucun outil interdit appelé, des paramètres corrects, un état final conforme, et un nombre d’étapes qui reste dans une enveloppe acceptable.

Cela suppose de disposer de la trace complète de l’exécution, sorties intermédiaires et appels d’outils compris, ce que seule une observabilité capable de reconstruire les trajectoires rend possible.

Qui attribue la note ? Le juge LLM et ses limites

Définir des critères et rassembler des cas ne suffit pas encore : il reste à décider comment la note est attribuée. Deux familles de correcteurs coexistent, et les dispositifs sérieux utilisent les deux.

La notation programmatique compare la sortie à une attente vérifiable par du code : présence d’une valeur, conformité d’un format, état d’une base après exécution. Elle est rapide, peu coûteuse, objective, reproductible et facile à déboguer. Sa limite est mécanique : elle sanctionne des variations parfaitement valides qui ne correspondent pas au motif attendu, et elle ne sait rien dire d’un critère subjectif comme le ton ou la pertinence d’une reformulation.

C’est là qu’intervient le juge LLM, le LLM-as-judge : un modèle chargé de noter la sortie d’un autre modèle selon une grille rédigée en langage naturel. Il traite les critères que le code ne sait pas exprimer et il passe à l’échelle, là où une relecture humaine coûte cher et arrive tard. En contrepartie, il est lui-même non déterministe, et rien ne garantit a priori que son jugement rejoigne celui d’un expert du domaine.

Trois précautions le rendent exploitable. La première est la calibration : comparer ses notes à celles d’experts humains sur un échantillon et vérifier que l’écart reste faible, avant de lui accorder la moindre confiance. La deuxième est la granularité : mieux vaut une grille structurée, avec un juge isolé par dimension évaluée, qu’un juge unique chargé de tout apprécier d’un seul tenant. La troisième est la porte de sortie : autoriser explicitement le juge à répondre qu’il ne sait pas, plutôt que de le contraindre à trancher avec des informations insuffisantes, réduit nettement le risque qu’il fabrique une justification.

Le principe à retenir est que le dispositif d’évaluation est lui-même un système à évaluer. Le cadre de gestion des risques liés à l’IA du NIST le formalise : parmi les résultats attendus de sa fonction Measure, l’une des quatre qui structurent sa démarche de gouvernance du risque IA, figure l’évaluation et la documentation de l’efficacité des métriques et des processus d’évaluation employés. Concrètement, cela commence par un geste peu spectaculaire sur lequel Anthropic insiste : lire les traces et les notes d’un grand nombre d’exécutions. Un échec doit paraître juste, c’est-à-dire qu’on doit comprendre ce que le système a raté et pourquoi. Quand les scores cessent de progresser, c’est la seule façon de savoir si le problème vient de l’application ou de son évaluation.

Transformer les incidents en nouveaux tests

Un dispositif d’évaluation ne devrait jamais être figé. Chaque incident de production intéressant est un cas de test que personne n’avait imaginé, et il coûte toujours moins cher de l’ajouter à la suite que de le redécouvrir. Le cycle devient :

incident → compréhension → nouveau cas de test → correction → test de non-régression

Avec le temps, deux usages se séparent. Les évaluations de capacité répondent à la question « que sait faire ce système ? » et servent à explorer ses limites ; leur taux de réussite n’a aucune raison d’atteindre cent pour cent, et un score parfait y signale plutôt un jeu de tests trop facile. Les évaluations de non-régression répondent à « fait-il toujours ce qu’il faisait ? » et doivent, elles, passer quasi intégralement : tout échec y est un signal, pas une statistique. Confondre les deux dans un score unique fait disparaître l’information utile. C’est cette séparation, entretenue incident après incident, qui transforme progressivement une collection de tests en patrimoine qualité.

L’évaluation continue après la mise en production

La recette initiale n’est qu’un point de départ, car le comportement d’une application IA dépend de pièces mobiles dont aucune n’est stable. Le modèle sous-jacent est mis à jour ou remplacé. Le prompt système évolue au fil des corrections. Une procédure métier change et rend fausses des réponses jusque-là correctes. La base documentaire est réindexée, et ce que le modèle voit réellement de l’entreprise change avec elle. Un outil est ajouté à l’agent, ce qui élargit l’espace des trajectoires possibles. Une API tierce modifie son format de réponse. Aucune de ces modifications ne se présente comme une régression, et chacune peut en produire une.

Il faut donc pouvoir rejouer les scénarios importants et comparer les résultats d’une version à l’autre, ce qui suppose une suite automatisée et branchée sur l’intégration continue. Anthropic décrit la combinaison qui fonctionne : des évaluations automatisées déclenchées à chaque changement d’agent ou de modèle comme première ligne de défense, une surveillance de la production pour détecter les dérives et les défaillances non anticipées, puis une relecture humaine périodique pour recalibrer l’ensemble.

Cette continuité n’est pas une préférence d’ingénieur. Le cadre de gestion des risques liés à l’IA publié par le NIST en janvier 2023 pose que les activités de test, d’évaluation, de vérification et de validation, regroupées sous l’acronyme TEVV, sont menées tout au long du cycle de vie du système et non lors d’une phase de recette. Le document détaille ce qu’elles recouvrent en exploitation : surveillance continue, tests périodiques, recalibrage des modèles par des experts du domaine, suivi des incidents signalés et détection des comportements émergents. La description correspond exactement à ce qu’un dispositif d’évaluation doit rester une fois l’application en production.

À retenir

Un bon système d’évaluation ne cherche pas à démontrer que l’application fonctionne. Il cherche à découvrir où elle ne fonctionne pas encore suffisamment bien. C’est une différence de posture, et c’est elle qui sépare un POC réussi d’un système réellement industrialisé. La question à poser avant une mise en production n’est donc pas « est-ce que ça marche ? », mais « qu’avons-nous testé qui aurait pu nous faire dire non ? ».