Évaluer un agent IA : construire et faire vivre son jeu de tests

Pourquoi le jeu de tests passe avant le reste

Un agent IA ne se juge pas à la démonstration. En démonstration, on pose les questions que l'on sait qu'il réussit. En production, les utilisateurs posent les leurs : mal formulées, incomplètes, hors sujet, parfois piégeuses. Entre les deux, il faut un instrument de mesure. C'est le jeu d'évaluation : une liste de cas réels, avec pour chacun la réponse attendue et la façon de juger si l'agent l'a donnée.

Sans ce jeu, toute décision se prend à l'impression. On modifie une consigne parce qu'une réponse a déplu, et on ne sait pas ce que cette modification a cassé ailleurs. On change de modèle sur la foi d'un classement public. On ouvre l'agent à tous parce que « ça a l'air de marcher ». L'impression voit les réussites spectaculaires, elle ne voit pas les régressions discrètes.

Anthropic le résume dans sa documentation sur le choix d'un modèle : avoir un bon jeu d'évaluation est l'étape la plus importante. Nous irions plus loin : c'est le premier livrable sérieux d'un projet d'agent, avant même la première version de l'agent. Il fixe ce que « fonctionner » veut dire, et il sert pendant toute la vie du système. Il figure d'ailleurs parmi les prérequis de mise en production d'un POC métier.

Partir de cas réels

Un jeu d'évaluation inventé en réunion ressemble à ce que l'équipe projet imagine. Un jeu tiré de l'activité réelle ressemble à ce que l'agent rencontrera. La différence est considérable.

Les meilleures sources de cas sont celles qui existent déjà :

• l'historique des tickets ou des demandes adressées au service concerné ;
• les courriels reçus sur une boîte de contact ;
• les questions que les collaborateurs posent aux experts internes, notées pendant quelques jours d'observation ;
• les documents réellement traités : bons de commande, factures, contrats, comptes rendus, avec leurs défauts de format.

La documentation de Claude insiste sur ce point : un jeu d'évaluation doit refléter la répartition réelle des tâches. Si la moitié de vos demandes portent sur le suivi de commande, la moitié du jeu doit en parler. Un jeu qui surreprésente les cas intéressants donne une image flatteuse et fausse.

Les cas réels contiennent des données personnelles ou sensibles. Ils se traitent comme tels : extraction limitée à ce qui est utile, pseudonymisation quand c'est possible, stockage au même niveau de protection que la source. Un jeu d'évaluation ne circule pas par courriel comme un simple fichier de travail.

C'est ici que le modèle forward deployed prend son sens : l'ingénieur qui s'installe chez vous voit passer les vraies demandes, sait lesquelles reviennent et lesquelles posent problème, et construit le jeu à partir de ce qu'il observe.

Des réponses attendues validées par le métier

Un cas sans réponse attendue ne sert à rien. Et la réponse attendue ne peut pas venir de l'équipe technique : seul le métier sait ce qui est juste. Un ingénieur peut juger qu'une réponse est claire et bien formée. Il ne peut pas juger qu'elle applique la bonne règle de remboursement ou la bonne clause du contrat cadre.

Concrètement, chaque cas du jeu comporte :

• L'entrée. La question ou le document, tel qu'il arrive réellement.
• La réponse attendue. Formulée par un expert du métier, ou au minimum les éléments qu'elle doit contenir et ceux qu'elle ne doit surtout pas contenir.
• La source. Le document ou la règle qui justifie la réponse, quand l'agent répond depuis une base documentaire.
• Le comportement attendu. Répondre, demander une précision, refuser, ou transmettre à une personne.
• Le niveau de gravité d'une erreur. Une imprécision de formulation n'a pas le poids d'une information fausse donnée à un client.

La validation par le métier prend du temps, et c'est un temps bien investi. Elle révèle souvent des désaccords internes : deux experts qui ne donnent pas la même réponse au même cas. Mieux vaut les découvrir avant la mise en service qu'après une réclamation. Organiser cette collaboration entre métier et technique fait partie du rôle de product management IA.

Couvrir les cas difficiles et les cas hors périmètre

Un jeu composé uniquement de cas simples mesure la facilité. Il faut y ajouter volontairement ce qui fait trébucher un agent. La documentation de Claude cite plusieurs familles de cas limites à inclure : entrées sans rapport avec la tâche, entrées trop longues, demandes ambiguës, demandes malveillantes. Nous les déclinons ainsi :

Les cas difficiles

• des questions ambiguës, où la bonne réponse est de demander une précision ;
• des documents mal scannés, incomplets, dans un format inhabituel ;
• des cas où deux règles semblent s'appliquer ;
• des formulations familières, avec fautes, abréviations ou jargon interne ;
• des demandes qui combinent plusieurs sujets dans un même message.

Les cas hors périmètre

Ce sont les plus importants et les plus oubliés. Un agent de support sur les garanties recevra des questions sur la facturation, la politique, la météo. Pour chacune, le comportement attendu est clair : ne pas inventer, dire que ce n'est pas son rôle, orienter vers le bon interlocuteur.

Une famille mérite une attention particulière : les demandes qui poussent l'agent à produire une donnée qui engage l'entreprise. Un prix, une date de livraison, une disponibilité, une remise. Le jeu doit vérifier que l'agent ne les invente jamais et qu'il s'appuie sur le système qui les calcule. C'est le principe exposé dans notre article sur pourquoi un agent IA ne doit jamais annoncer un prix.

Ajoutez enfin quelques tentatives de détournement : consignes cachées dans un document, demande de révéler ses instructions, sollicitation d'un contenu interdit. L'agent doit les traiter comme des données, jamais comme des ordres.

Définir les critères de réussite

« Bonne réponse » n'est pas un critère. La documentation de Claude recommande des critères spécifiques, mesurables, atteignables et en rapport avec l'usage, et rappelle que la plupart des applications doivent être évaluées sur plusieurs dimensions à la fois. Parmi celles qu'elle cite : l'exactitude sur la tâche, la cohérence entre des questions proches, la pertinence, le ton, la protection des données personnelles, le temps de réponse et le coût.

Pour chaque dimension retenue, il faut décider comment on la note.

La vérification automatique

Quand la réponse attendue est précise (une catégorie, un montant extrait d'une facture, une décision oui ou non), un programme compare la réponse de l'agent à la réponse attendue. C'est rapide, gratuit à rejouer, et sans ambiguïté. Il faut structurer autant de cas que possible pour permettre ce type de vérification.

La notation par un modèle

Quand la réponse est rédigée librement, un autre modèle peut la juger à partir d'une grille : la réponse contient-elle les éléments attendus, respecte-t-elle le ton, contient-elle une information interdite ? La documentation de Claude recommande d'utiliser un modèle différent de celui qui génère les réponses. Ce juge doit lui-même être vérifié, en comparant ses notes à celles d'un humain sur un échantillon.

La relecture humaine

Elle reste la référence, et elle coûte cher. On la réserve aux cas sensibles, aux critères subtils, et à la vérification des deux méthodes précédentes. La même documentation note qu'un grand nombre de cas notés automatiquement apporte en général plus d'information qu'un petit nombre de cas notés à la main. Les deux se complètent.

Fixez enfin un seuil par critère, avant de mesurer. Décider du seuil après avoir vu le résultat revient à valider ce que l'on a obtenu.

Rejouer le jeu à chaque changement

Un agent change souvent : consignes retouchées, documents ajoutés, découpage modifié, outil branché, modèle remplacé. Chacun de ces changements peut améliorer un point et en dégrader un autre. La règle est simple : aucun changement ne part en production sans que le jeu complet ait été rejoué et comparé à la version précédente.

Quelques pratiques rendent ce rejeu utile :

• Automatiser le lancement. Si rejouer le jeu demande une demi-journée de manipulation, personne ne le fera. Il doit se lancer en une commande.
• Comparer cas par cas. Le score global peut rester stable alors que des cas importants ont basculé. Regardez la liste des cas qui passent de réussi à échoué.
• Garder l'historique. Conserver les résultats de chaque version permet de comprendre quand une dégradation est apparue.
• Mettre de côté une partie du jeu. Si l'on retouche les consignes en regardant toujours les mêmes cas, on finit par optimiser pour eux. La documentation de Claude recommande de garder des cas de test à part, que l'on ne consulte pas pendant les réglages.

Pour un agent qui répond depuis des documents, rejouez aussi la mesure de la recherche seule : le bon passage est-il retrouvé ? Anthropic utilise ce type de mesure dans ses travaux sur la recherche contextuelle, et elle permet de savoir si une régression vient de la recherche ou de la rédaction de la réponse.

Le changement de modèle est le cas le plus visible. Notre article sur ce que change Claude Opus 5.5 montre comment le jeu d'évaluation sert à décider d'une bascule.

Le suivi en production

Le jeu d'évaluation mesure l'agent sur des cas connus. La production lui soumet des cas nouveaux. Il faut donc un second dispositif, qui observe ce qui se passe réellement.

• Les signaux directs. Pouces levés ou baissés, demandes de transfert vers un humain, reformulations successives de la même question, conversations abandonnées.
• Les signaux techniques. Temps de réponse, erreurs, coût par conversation, taux de réponses « je ne sais pas ».
• Les signaux métier. Réclamations, corrections faites par les équipes après coup, tickets rouverts.

Chaque signal négatif est un candidat pour le jeu d'évaluation. Une question mal traitée en production, une fois corrigée et validée par le métier, rejoint le jeu. Ainsi, le jeu grandit avec l'usage, et une erreur corrigée ne revient pas sans être détectée.

Le suivi doit respecter les mêmes règles que le reste du système : journaux protégés, durée de conservation définie, accès limité. C'est un des principes de notre mémo IA responsable.

La relecture humaine d'échantillons

Les indicateurs automatiques ne voient pas tout. Une réponse peut être polie, rapide, bien notée par l'utilisateur, et fausse. Le seul moyen de le savoir est qu'un expert relise.

La pratique que nous mettons en place : à intervalle régulier, un expert du métier relit un échantillon de conversations tirées au hasard, plus un échantillon ciblé sur les conversations signalées. Il note chaque réponse selon la même grille que le jeu d'évaluation. Cela produit trois choses :

• une mesure de la qualité réelle, indépendante des indicateurs automatiques ;
• de nouveaux cas pour le jeu d'évaluation ;
• une vérification du juge automatique, s'il y en a un, en comparant ses notes à celles de l'expert.

Le rythme dépend du volume et du risque. Un agent qui répond à des clients sur des sujets sensibles demande une relecture plus fréquente qu'un assistant interne de recherche documentaire. Ce qui compte, c'est que la relecture soit planifiée, attribuée à une personne nommée, et que ses conclusions débouchent sur des actions.

Faire vivre le jeu dans la durée

Un jeu d'évaluation vieillit comme un corpus documentaire. Les règles changent, les produits évoluent, une procédure est remplacée. Une réponse attendue devenue fausse fait échouer un agent qui a raison, ou valider un agent qui a tort.

• Un propriétaire. Le jeu appartient au métier, avec un appui technique. Quelqu'un est responsable de sa justesse.
• Une revue à chaque changement de règle. Quand une procédure change, les cas concernés sont mis à jour en même temps.
• Un versionnage. Le jeu évolue par versions datées, pour que les comparaisons dans le temps restent lisibles.
• Un équilibre surveillé. À mesure que l'on ajoute des cas issus d'incidents, la répartition peut dériver vers les cas difficiles. Vérifiez de temps en temps qu'elle reflète encore l'usage réel.

Les erreurs fréquentes

• Construire le jeu après l'agent. On teste alors ce que l'agent sait faire, pas ce qu'on attend de lui.
• Laisser la technique écrire les réponses attendues. Le jeu mesure alors la conformité à l'idée qu'un ingénieur se fait du métier.
• Oublier le hors périmètre. L'agent brille sur son sujet et invente dès qu'on en sort.
• Ne regarder que le score global. Les régressions graves se cachent derrière une moyenne stable.
• Arrêter à la mise en service. Sans suivi ni relecture, la qualité dérive sans que personne ne le voie.

Notre article sur le déploiement d'un agent IA en entreprise replace ces étapes dans le déroulé complet, et notre page sur la conception d'un agent IA présente notre façon de travailler. Si vous avez un agent en projet ou déjà en service et voulez savoir comment le mesurer, notre diagnostic IA permet de poser les cas, les critères et le dispositif de suivi.

Sources

• Documentation Claude, Define success criteria and build evaluations
• Documentation Claude, Choosing the right model
• Anthropic, Introducing Contextual Retrieval

Questions fréquentes

Combien de cas faut-il pour commencer ?

Il n'existe pas de nombre universel. Le jeu doit couvrir les principales familles de demandes dans leurs proportions réelles, plus les cas difficiles et hors périmètre. Mieux vaut démarrer avec un jeu modeste mais représentatif, puis l'enrichir à partir de la production.

Qui doit consacrer du temps au jeu d'évaluation chez nous ?

Un ou plusieurs experts du métier, pour fournir les cas et valider les réponses attendues. L'équipe technique structure le jeu, automatise le rejeu et analyse les résultats. Sans le temps des experts, le jeu ne mesure rien d'utile.

Peut-on faire noter les réponses entièrement par une IA ?

En partie. Un modèle juge bien les critères qu'on lui décrit précisément, et il permet de noter beaucoup de cas à faible coût. Il doit toutefois être contrôlé par des relectures humaines régulières, et les cas sensibles restent relus par un expert.

Le jeu d'évaluation remplace-t-il la recette utilisateur ?

Non, il la prépare. Le jeu vérifie que l'agent répond juste sur des cas connus. La recette avec les utilisateurs vérifie qu'il s'insère dans leur travail, que l'interface convient et que les passages de relais fonctionnent.

Que faire si l'agent n'atteint pas le seuil fixé ?

Regarder d'abord quels cas échouent et pourquoi : recherche, consignes, données, modèle. Parfois la réponse est de réduire le périmètre de l'agent aux familles de demandes où il est fiable, et de transmettre le reste à une personne.