Un agent IA démontré en réunion a l'air de fonctionner. Le lendemain, un client pose la question un peu différemment, l'agent se trompe d'outil, et personne ne sait si c'est un cas isolé ou le quotidien. Sans mesure, chaque correction est un pari : on répare un cas et on en casse un autre sans le voir.
La réponse tient en un mot, que les équipes d'IA appellent des evals : un jeu de tests qui note ce que fait l'agent. Cet article explique comment en construire un petit, utile et honnête, avant de passer en production. Les définitions et les recommandations de méthode viennent du guide publié par l'équipe d'ingénierie d'Anthropic en janvier 2026 (cité en fin d'article) ; les adaptations à une PME sont notre analyse.
Pourquoi un agent ne se teste pas comme un logiciel classique
Un logiciel traditionnel donne la même sortie pour la même entrée : un test unitaire suffit. Un agent, lui, enchaîne plusieurs étapes, appelle des outils, modifie des données et s'adapte à ce qu'il rencontre. Ses réponses varient d'une exécution à l'autre.
Anthropic le résume ainsi : une évaluation consiste à donner une entrée à une IA, puis à appliquer une logique de notation à sa sortie. Sans cela, explique l'équipe, on tombe dans une boucle réactive : les problèmes ne se découvrent qu'en production, et en corriger un en crée d'autres.
Le vocabulaire à connaître
Le guide d'Anthropic fixe quelques termes qui évitent de longues discussions :
| Terme | Sens |
|---|---|
| Tâche (cas de test) | Un test unique, avec une entrée et des critères de réussite définis |
| Essai | Une tentative sur une tâche. On en lance plusieurs, car les sorties varient |
| Correcteur | La logique qui note un aspect de la performance. Une tâche peut en avoir plusieurs |
| Transcription | Le journal complet d'un essai : réponses, appels d'outils, résultats intermédiaires |
| Résultat | L'état final dans l'environnement, pas ce que l'agent affirme avoir fait |
La distinction entre transcription et résultat est la plus utile en pratique. Si votre agent dit « j'ai créé le rendez-vous », ce qui compte est de savoir si le rendez-vous existe dans votre agenda. C'est l'exemple que donne le guide, avec une réservation dans une base de données.
Étape 1 : partir de cas réels, pas de cas rêvés
Le guide recommande de commencer par 20 à 50 tâches simples tirées d'échecs réels, et précise que c'est un excellent départ, parce que les premiers changements ont souvent des effets assez marqués pour être détectés avec peu de cas.
Pour une PME, les sources sont déjà là :
- les vérifications manuelles que vous faites aujourd'hui avant de livrer une réponse ;
- les demandes réelles de clients ou de collègues, avec les erreurs déjà signalées ;
- les cas limites que les utilisateurs métier vous décrivent (« quand le client a deux adresses »).
N'attendez pas d'en avoir des centaines. L'équipe d'Anthropic insiste : il faut commencer tôt et ne pas attendre la suite parfaite.
Étape 2 : écrire des tâches sans ambiguïté
Une tâche est bien écrite quand deux experts du métier, à qui l'on montre la sortie, arrivent au même verdict. Le guide ajoute une exigence : chaque tâche doit avoir une solution de référence connue, qui passe tous les correcteurs. Si vous ne savez pas à quoi ressemble une bonne réponse, l'agent ne peut pas le deviner pour vous.
Équilibrez aussi le jeu : testez les cas où l'agent doit agir et ceux où il ne doit pas le faire. Un agent testé uniquement sur « envoie la relance » apprendra à tout relancer.
Étape 3 : choisir comment noter
Le guide distingue trois familles de correcteurs, avec des forces opposées :
| Famille | Forces | Limites |
|---|---|---|
| Code | Rapide, peu coûteux, objectif, reproductible | Fragile face aux variantes valides, peu nuancé |
| Modèle | Souple, capte la nuance, adapté aux textes libres | Non déterministe, plus coûteux, à calibrer |
| Humain | Qualité de référence, jugement d'expert | Coûteux, lent |
La règle pratique : préférer un correcteur déterministe dès que le résultat s'y prête (le dossier est-il dans le bon statut ? le montant est-il exact ?), recourir à un modèle pour les textes libres, et faire relire un échantillon par une personne pour vérifier que la note du modèle correspond à son avis.
Le guide ajoute deux conseils : noter ce que l'agent a produit plutôt que le chemin exact suivi, car un agent trouve souvent des approches valides que vous n'aviez pas prévues, et prévoir un crédit partiel quand la tâche comporte plusieurs étapes.
Étape 4 : répéter les essais, et lire le bon indicateur
Comme les sorties varient, un seul essai ne prouve rien. Le guide présente deux mesures :
- pass@k : la probabilité d'obtenir au moins une bonne réponse en k essais. Utile quand un seul succès suffit ;
- pass^k : la probabilité que les k essais réussissent tous. À privilégier quand la régularité est essentielle, par exemple pour un agent en contact avec des clients.
L'exemple chiffré du guide montre l'écart : avec 75 % de réussite par essai, réussir trois essais sur trois ne se produit qu'environ 42 % du temps (0,75 au cube). Un agent « bon trois fois sur quatre » est donc loin d'être fiable pour un usage où chaque erreur compte.
Étape 5 : lire les transcriptions
Un score ne dit pas pourquoi l'agent échoue. Le guide recommande de lire les transcriptions pour distinguer une vraie erreur de l'agent d'un défaut du correcteur : un test trop strict qui refuse une réponse correcte fausse autant la mesure qu'un agent défaillant. C'est souvent là que l'on trouve les améliorations les plus rentables : une consigne ambiguë, un outil mal décrit, une donnée manquante.
Deux jeux, deux rôles
Le guide distingue deux types d'évaluations :
- les évaluations de capacité mesurent ce que l'agent sait bien faire. Elles démarrent avec un taux de réussite bas : c'est une pente à gravir ;
- les évaluations de non-régression vérifient qu'il réussit toujours ce qu'il réussissait. Elles doivent rester proches de 100 % pour signaler tout recul.
Une tâche maîtrisée passe de la première catégorie à la seconde. Surveillez enfin la saturation : un jeu qui affiche 100 % ne détecte plus que les régressions et ne dit plus rien sur les progrès. Il faut alors y ajouter des cas plus difficiles.
Un plan en une semaine pour une PME
Voici une trame réaliste, à adapter à votre cas. Elle prolonge le cadrage d'un premier projet d'agent IA et le calcul du coût par tâche réussie, qui supposent justement de savoir ce qu'est une réussite.
- Jour 1 : lister les 30 cas réels à tester et le critère de réussite de chacun, validé par la personne du métier.
- Jour 2 : fixer pour chaque cas la réponse ou l'état final attendu.
- Jour 3 : choisir les correcteurs, déterministes d'abord.
- Jour 4 : lancer plusieurs essais par cas, partir d'un environnement propre à chaque essai.
- Jour 5 : lire les transcriptions des échecs, corriger, relancer, et décider si la mise en production est raisonnable.
Dans les cas où l'agent peut engager de l'argent ou modifier des données sensibles, ce jeu de tests ne remplace pas la validation humaine avant dépense : il vous dit à quelle fréquence cette validation devra intervenir.
Questions fréquentes
Combien de cas faut-il pour commencer ?
Le guide d'Anthropic recommande de démarrer avec 20 à 50 tâches simples tirées d'échecs réels. Quelques dizaines de cas bien choisis valent mieux qu'un grand jeu jamais terminé.
Peut-on faire noter un agent par un autre modèle d'IA ?
Oui, pour les réponses en texte libre. Le guide précise toutefois que ce type de correcteur est non déterministe et doit être calibré avec un jugement humain. Préférez un contrôle déterministe dès que le résultat peut se vérifier par une règle.
Quelle différence entre pass@k et pass^k ?
Le premier mesure la chance d'obtenir au moins un succès en k essais, le second la chance de réussir tous les essais. Pour un agent qui répond à des clients, le second est le plus proche de ce que vous vivrez.
Faut-il refaire les tests après chaque modification ?
Oui, au moins pour le jeu de non-régression. Changer de modèle, de consigne ou d'outil peut améliorer un cas et en dégrader un autre ; seule la mesure permet de le voir.
Sources
Pour aller plus loin
Vous avez un agent en préparation, ou un prototype dont vous ne savez pas mesurer la fiabilité ? Décrivez-nous le processus : nous définissons avec vous les cas à tester, le critère de réussite et la mesure avant toute mise en production. Notre approche part toujours d'un cas précis, et nos offres détaillent les formats d'accompagnement.