Évaluer un agent IA sur son propre travail

Des cas tirés du processus

L’évaluation d’un agent IA part du travail qu’une personne fait déjà. Un exemple inventé vous dit si l’agent sait traiter l’exemple. Il ne vous dit pas s’il peut tenir le poste.

Les cas viennent de trois endroits. Les vérifications qu’une personne fait déjà à la main avant de faire confiance au résultat. Les dossiers qui ont mal tourné : escalades, corrections, réclamations, tickets. Et les dossiers ordinaires d’une journée normale, car un ensemble fait uniquement de cas difficiles cache la façon dont le système se comporte sur les cas simples.

La note d’ingénierie d’Anthropic du 9 janvier 2026, Demystifying evals for AI agents (en anglais), fait une remarque à retenir tôt. Écrire les cas oblige l’équipe à dire ce que réussir veut dire. Deux ingénieurs qui lisent la même spécification seront souvent en désaccord sur la façon de traiter un cas limite, et un cas écrit tranche avant que le système ne le fasse à leur place.

L’ensemble doit couvrir les deux sens. Incluez des cas où l’agent doit agir et des cas où il ne doit pas. Anthropic décrit la construction des évaluations de la recherche web dans Claude.ai avec les deux types : des questions qui demandent une recherche et des questions auxquelles le modèle doit répondre avec ce qu’il sait déjà. Un ensemble qui ne teste qu’un sens apprend au système à en faire trop.

Dans le processus de factures qui sert d’exemple à ces guides, un premier ensemble contiendrait des rapprochements sans difficulté, un montant qui diffère du bon de commande, une facture en double, une facture sans numéro de commande, un fournisseur dont les coordonnées bancaires ont changé, et une facture dont le texte contient des instructions adressées au système. Certains de ces cas doivent passer. Certains doivent être signalés. Certains doivent aller à une personne.

Écrivez l’ensemble avant la mise en service, et relancez-le à chaque modification du système. La méthode autour de tout cela se trouve dans Construire un agent IA qui tient.

Ce que contient chaque cas

Chaque cas a trois parties : l’entrée que reçoit le processus, le résultat qu’une personne peut noter, et la vérification qui le note.

Notez le résultat, pas le récit qu’en fait l’agent. L’exemple d’Anthropic est une réservation de vol. L’agent annonce que le vol est réservé, mais le résultat, c’est l’existence d’une réservation dans la base de données. Pour le processus de factures, le résultat est le statut de la facture dans le système financier, pas le résumé que l’agent écrit à la fin.

Notez ce que l’agent a produit, pas le chemin exact qu’il a suivi. Anthropic avertit qu’exiger un ordre fixe d’appels d’outils rend les cas fragiles, car un agent capable trouve souvent une voie valide que personne n’avait prévue. Ne vérifiez le chemin que là où le chemin est lui-même l’enjeu, comme « l’identité a été vérifiée avant le remboursement ».

Accordez un crédit partiel quand le travail a plusieurs parties. Un agent qui identifie le problème et vérifie le client mais n’arrive pas à traiter le remboursement a fait mieux qu’un agent qui échoue dès le départ, et le score doit le montrer.

Un cas est prêt quand il passe trois tests.

• Deux personnes qui connaissent le processus, en le notant chacune de leur côté, arrivent au même verdict. Sinon, le cas est ambigu et son score n’est que du bruit.
• Tout ce que la vérification recherche figure dans le cas. Un agent ne doit pas échouer parce que la vérification attendait un détail que personne n’a écrit.
• Il existe une réponse de référence qui passe la vérification. Cela prouve que le cas peut être résolu et que la vérification fonctionne. Anthropic ajoute que si un modèle puissant échoue sur un cas à de nombreuses reprises, c’est en général le cas ou la vérification qui est cassé, pas le modèle.

Écrit, un cas de facture peut tenir en quelques lignes :

• cas : duplicate-invoice-03
• entrée : invoices/acme-4471-resent.pdf
• statut attendu : signalé, motif doublon, paiement non mis en file
• contrôle : l’état dans le système financier

Au moins 50 cas

L’ensemble d’évaluation compte au moins 50 cas tirés du processus. Ce chiffre est notre seuil. La note d’Anthropic suggère que 20 à 50 cas tirés d’échecs réels constituent un bon départ, parce que les premiers changements ont souvent des effets assez grands pour qu’un petit ensemble les détecte. Nous plaçons notre minimum en haut de cette fourchette pour que chaque type d’échec connu apparaisse plus d’une fois et qu’aucun cas isolé ne porte à lui seul toute une catégorie.

L’arithmétique compte aussi. Avec 50 cas, chacun vaut deux points. Un changement qui déplace le score d’un ou deux cas reste dans le bruit. Ne livrez pas et ne revenez pas en arrière sur cette base sans avoir lu ce qui a changé.

Lancez chaque cas plusieurs fois. Le même agent sur le même cas peut réussir à une exécution et échouer à la suivante, si bien qu’une seule exécution mesure la chance autant que la compétence. Anthropic distingue deux mesures. L’une demande si l’agent réussit au moins une fois sur plusieurs tentatives. L’autre demande s’il réussit à chaque fois. La seconde chute vite : un agent qui réussit 75 % du temps sur un cas ne passera trois exécutions d’affilée qu’environ 42 % du temps. Pour un processus qui met des paiements en file, « à chaque fois » est le chiffre honnête.

La façon dont nous menons un processus mesuré jusqu’en production se trouve sur la page agents IA.

Relancer le même ensemble

Le premier score sert de référence. Le guide d’OpenAI du 15 janvier 2026, A practical guide to building agents (en anglais), donne l’ordre sans détour : mettre en place les évaluations d’abord, atteindre la précision visée avec le modèle le plus capable, puis seulement remplacer par des modèles plus petits là où ils tiennent encore la cible.

Chaque changement ultérieur, qu’il s’agisse d’un nouveau prompt, d’un nouvel outil ou d’un nouveau modèle, est soumis aux mêmes cas. Un ensemble écrit après le changement ne peut pas vous dire si le système fait encore le travail que vous avez mesuré.

Cela ne veut pas dire que l’ensemble ne grandit jamais. Anthropic distingue deux types d’ensemble. Un ensemble de capacité contient les cas sur lesquels l’agent peine encore et donne à l’équipe une pente à gravir. Un ensemble de non-régression contient les cas qu’il réussit déjà et doit rester proche de 100 %. Une baisse à cet endroit signifie que quelque chose a cassé. À mesure que les cas de capacité sont résolus, ils passent dans l’ensemble de non-régression. Les nouveaux échecs observés en production deviennent de nouveaux cas. Quand l’ensemble grandit, notez aussi l’ancienne version sur les nouveaux cas, pour que la comparaison reste juste.

Trois habitudes gardent les scores honnêtes.

• Partir d’un environnement propre à chaque exécution. Des fichiers ou un état restés d’une exécution peuvent fuir dans la suivante. Anthropic rapporte qu’un modèle a obtenu un avantage indu dans certaines évaluations internes en lisant l’historique laissé par des essais précédents.
• Lire les exécutions, pas seulement le score. Anthropic ne prend pas un score pour argent comptant tant que quelqu’un n’a pas lu des transcriptions. Un échec doit paraître juste : on doit voir clairement ce que l’agent a raté. Leur exemple est un benchmark public où un modèle a d’abord obtenu 42 %. Une fois corrigés des bugs de notation, dont une vérification qui rejetait un nombre correct simplement arrondi autrement, le même modèle est monté à 95 %. Une vérification cassée peut faire paraître cassé un système qui fonctionne, et l’inverse est vrai aussi.
• Se méfier d’un score parfait. Un ensemble où tout passe détecte encore les régressions mais ne dit plus rien des progrès. Quand cela arrive, ajoutez des cas plus difficiles.

Un ensemble entretenu rapporte aussi d’une façon que les équipes prévoient rarement. Quand un nouveau modèle sort, une équipe qui a un ensemble peut le mesurer en quelques jours. Une équipe qui n’en a pas passe des semaines à tester à la main.

Un second appel a besoin d’un écart écrit

La note d’Anthropic du 19 décembre 2024, Building effective agents (en anglais), décrit une boucle dans laquelle un second appel examine un brouillon et l’écart entre ce brouillon et un critère. Sans le critère, le second appel n’a rien à juger. La même règle s’applique quand c’est un modèle qui note l’évaluation.

Utilisez d’abord la vérification fiable la moins chère. Les vérifications en code sont rapides, reproductibles et faciles à déboguer : un champ est présent, un statut est positionné, un montant correspond. Ne confiez à un modèle que ce que le code ne sait pas noter, par exemple la clarté et la politesse d’un message à un fournisseur. Gardez les personnes pour l’étalonnage et pour les cas où le jugement est précisément l’enjeu.

Quand un modèle note, la note de janvier 2026 donne quatre règles à adopter.

• Rédiger une grille structurée en dimensions séparées, pas un simple « est-ce bien ? ».
• Noter chaque dimension par un appel distinct plutôt qu’un seul appel pour tout.
• Laisser au modèle qui note une porte de sortie, comme répondre « inconnu » quand les éléments manquent, au lieu de le forcer à deviner.
• Comparer ses notes à celles d’une personne sur un échantillon, et continuer à le faire. Un correcteur automatique qui s’écarte du jugement humain s’en écarte sans bruit.

La note qu’une personne peut vérifier reste celle sur laquelle l’ensemble est bâti. Les personnes les plus proches du processus sont les mieux placées pour écrire des cas, donc la personne responsable du processus doit pouvoir en ajouter un sans attendre un ingénieur. Les évaluations ne sont pas le seul signal. La surveillance en production, les retours des utilisateurs et une lecture régulière d’exécutions réelles attrapent ce qu’un ensemble fixe manque. Mais l’ensemble est le seul que vous pouvez lancer avant que quoi que ce soit n’atteigne un utilisateur.

Voyez ensuite comment les cas s’insèrent dans la construction, dans Construire un agent IA qui tient.