Évaluer un agent IA : la méthode des evals

Vous avez branché un agent IA, les premières sorties semblent correctes, et la question arrive vite : fonctionne-t-il vraiment, ou avez-vous simplement eu de la chance sur trois essais ? Tester un agent au feeling ne dit rien de fiable. La méthode des evals répond à cette question en transformant une impression en mesure : un jeu de cas, des critères de qualité explicites, et une boucle de test que vous relancez à chaque changement. Voici comment la construire concrètement.

Pourquoi un agent IA ne se teste pas comme un logiciel classique

Un logiciel traditionnel est déterministe : la même entrée produit toujours la même sortie. Vous écrivez un test, il passe ou il échoue, et le verdict est binaire. Un agent IA repose sur un modèle de langage probabiliste : la même requête peut donner des formulations différentes d'une exécution à l'autre, et une réponse peut être "presque bonne" sans être strictement exacte.

Cette nature change la façon de tester. On ne cherche plus une égalité parfaite, mais une qualité mesurée sur un ensemble de cas. Trois conséquences pratiques :

Un seul essai réussi ne prouve rien. Il faut un échantillon de cas pour estimer un comportement.
Le verdict est rarement binaire. On mesure un taux de réussite, une cohérence, un respect de règles, plutôt qu'un simple "ça marche".
Le comportement peut dériver sans qu'aucune ligne de votre code ne change : une nouvelle version du modèle, un prompt retouché, une base documentaire mise à jour suffisent.

C'est exactement le rôle des evals : donner une mesure répétable là où l'intuition est trompeuse. Cet article décrit le protocole de mesure. Si vous voulez d'abord comprendre d'où viennent les erreurs des agents et les garde-fous qui les limitent, lisez notre article sur la fiabilité des agents IA, qui pose le problème ; le présent texte se concentre sur la façon de le mesurer.

Construire un jeu d'evals : le golden dataset

Le cœur de la méthode est un jeu de cas de référence, souvent appelé golden dataset. C'est une collection d'entrées associées à la sortie attendue, ou au moins aux critères qui définissent une bonne sortie. C'est l'actif le plus précieux de votre démarche d'évaluation, et il vaut mieux le construire avec soin que vite.

Quoi mettre dans ce jeu

Un bon jeu de cas couvre trois familles de situations :

Le cas nominal. La situation standard, la plus fréquente, celle pour laquelle vous avez conçu l'agent en premier lieu.
Les variantes courantes. Les formulations, formats ou contextes différents que l'agent rencontrera régulièrement en production.
Les cas limites et les pièges. Les entrées ambiguës, incomplètes, hors périmètre, ou celles sur lesquelles vous avez déjà vu l'agent se tromper. Ces cas sont les plus instructifs : ce sont eux qui révèlent les régressions.

Une règle simple : chaque fois qu'un agent échoue en production, ajoutez ce cas à votre jeu d'evals avec la bonne réponse. Votre jeu grandit ainsi par apprentissage des erreurs réelles, et chaque correction est verrouillée contre une réapparition.

D'où viennent les cas

Trois sources se combinent bien : vos données historiques réelles, anonymisées, qui reflètent les situations authentiques ; des cas que vous construisez à la main pour couvrir des situations rares mais importantes ; et les remontées du terrain, c'est-à-dire les échecs observés une fois l'agent déployé. Privilégiez toujours le réel sur l'imaginé. Un jeu de cas inventés par ressemblance avec ce que vous croyez être l'usage produit une mesure tout aussi imaginaire.

Définir des métriques de qualité utiles

Un jeu de cas ne sert à rien sans critères pour juger les réponses. La difficulté n'est pas de mesurer, c'est de décider ce qui compte. Voici les familles de métriques les plus utiles en pratique.

Exactitude factuelle. La réponse est-elle juste ? Pour des sorties structurées (une catégorie, un score, un champ extrait), la comparaison à la référence est directe. Pour du texte libre, vous jugez la présence des bons faits et l'absence d'inventions.
Complétude. L'agent a-t-il traité l'ensemble de la demande, ou laissé de côté une partie de la tâche ?
Respect des règles métier. L'agent suit-il vos contraintes : ton, format, mentions obligatoires, interdictions ? Une règle métier non respectée peut invalider une réponse pourtant exacte.
Pertinence et absence de hors-sujet. L'agent reste-t-il dans son périmètre, ou ajoute-t-il du contenu non demandé ?
Robustesse aux cas limites. Sur les entrées ambiguës ou hors champ, l'agent refuse-t-il proprement ou improvise-t-il une réponse hasardeuse ?

Pour chaque métrique, fixez un seuil d'acceptation avant de lancer le test, pas après. Décider du seuil une fois les résultats sous les yeux revient à se noter soi-même : la tentation d'ajuster la barre à ce que l'agent atteint est trop forte.

Trois manières de noter une réponse

Selon le type de sortie, on note différemment :

Vérification programmatique. Quand la sortie est structurée et la référence connue, une règle automatique tranche : la catégorie attendue est-elle là, le champ extrait est-il correct, le format est-il valide. C'est la méthode la plus fiable et la moins coûteuse ; privilégiez-la dès que la sortie s'y prête.
Notation par un modèle évaluateur. Pour du texte libre, on peut demander à un second modèle de juger une réponse selon une grille explicite. C'est utile à grande échelle, mais à manier avec prudence : un juge IA a ses propres biais, et il faut périodiquement vérifier ses verdicts contre un jugement humain.
Revue humaine. Sur un échantillon, le jugement d'un expert métier reste la référence. Coûteux, donc à réserver aux cas où la qualité est critique et aux contrôles de calibration des deux autres méthodes.

La boucle de test : du premier jeu au filet de sécurité

Un eval prend toute sa valeur quand il devient une boucle, pas un événement ponctuel. La séquence à mettre en place :

Établir une mesure de départ. Faites tourner le jeu de cas sur la version actuelle de l'agent et notez les scores. C'est votre point de référence, celui auquel vous comparerez tout changement futur.
Itérer sur l'agent. Vous ajustez un prompt, changez de modèle, enrichissez la base documentaire. Chaque modification vise à améliorer un score précis.
Relancer le jeu complet. Après chaque changement, relancez tous les cas, pas seulement ceux que vous pensiez avoir améliorés. C'est ainsi que l'on détecte une régression : une retouche qui corrige un cas mais en casse trois autres.
Comparer et décider. Le score global a-t-il progressé sans régression sur les cas critiques ? Si oui, vous gardez la version. Sinon, vous revenez en arrière.

Ce cycle transforme l'optimisation d'un agent, souvent vécue comme un bricolage à l'aveugle, en une démarche pilotée par la mesure. Vous ne vous demandez plus si votre dernière modification de prompt a aidé : vous le savez.

Un point d'attention fréquent : ne sur-optimisez pas sur votre jeu de cas. Si vous ajustez l'agent jusqu'à ce qu'il réussisse parfaitement vos vingt cas, vous risquez de le rendre bon sur ces vingt cas précis et fragile partout ailleurs. Gardez une partie des cas de côté, qui ne sert jamais à l'optimisation et uniquement à la validation finale.

Evals avant le lancement, monitoring après

Les evals décident si une version est prête à partir. Une fois l'agent en production, le travail change de nature : vous observez son comportement sur le trafic réel, qui contient toujours des situations qu'aucun jeu de cas n'avait prévues. C'est le rôle du suivi continu, que nous détaillons dans notre article sur le monitoring et l'observabilité des agents IA.

Les deux se nourrissent l'un l'autre. Le monitoring fait remonter des échecs réels que vous n'aviez pas anticipés ; ces échecs deviennent de nouveaux cas dans votre jeu d'evals ; le jeu enrichi valide la correction et empêche la régression. C'est cette circulation, et non chaque brique prise isolément, qui rend un agent durablement fiable. Les evals s'intègrent d'ailleurs comme une étape obligatoire de toute mise en service sérieuse, comme le rappelle notre checklist pour déployer un agent IA en production.

Par où commencer cette semaine

Inutile d'attendre un outillage complet pour démarrer. La première version d'un dispositif d'evals tient dans un tableur et une heure de travail :

Listez dix à quinze entrées réelles que votre agent traite, avec pour chacune la réponse que vous considérez comme bonne.
Pour chaque cas, écrivez le ou les critères qui font qu'une réponse est acceptable. C'est l'étape qui demande de la rigueur métier, et c'est la plus importante.
Faites tourner ces cas sur votre agent actuel, notez à la main, et vous tenez votre mesure de départ.
La prochaine fois que vous modifiez le prompt ou changez de modèle, refaites passer les mêmes cas et comparez.

À partir de là, vous automatiserez l'exécution et vous élargirez le jeu au fil des échecs réels. Mais la bascule décisive se produit dès le premier passage : vous arrêtez de juger votre agent à l'intuition, et vous commencez à le mesurer.

Questions fréquentes

Qu'est-ce qu'un eval pour un agent IA ?

Un eval est un test automatisé qui mesure si un agent IA produit le bon résultat sur un ensemble de cas représentatifs. Concrètement, vous lui soumettez des entrées dont vous connaissez la sortie attendue, puis vous comparez ce qu'il produit à cette référence. C'est l'équivalent des tests unitaires en développement logiciel, appliqué à une brique non déterministe.

Combien de cas faut-il dans un jeu d'evals ?

Il n'existe pas de chiffre universel. Un premier jeu utile peut tenir en vingt à cinquante cas bien choisis, qui couvrent le cas nominal, les variantes courantes et les cas limites. L'important n'est pas le volume mais la représentativité : chaque cas doit correspondre à une situation que l'agent rencontrera vraiment, et inclure des exemples sur lesquels vous l'avez déjà vu échouer.

Quelle différence entre evals et monitoring d'un agent IA ?

Les evals mesurent la qualité avant déploiement, sur un jeu de cas figé et reproductible, pour décider si une version est prête. Le monitoring observe l'agent une fois en production, sur le trafic réel, pour détecter les dérives. Les deux sont complémentaires : les evals valident, le monitoring surveille. L'un ne remplace pas l'autre.

Peut-on évaluer un agent IA sans compétences techniques ?

La partie la plus exigeante de l'évaluation n'est pas technique, elle est métier : définir ce qu'est une bonne réponse et construire les cas de référence. Cette étape relève de l'expertise opérationnelle, pas du code. L'automatisation de l'exécution des tests demande ensuite un appui technique, mais elle vient après le travail de définition, qui est le vrai cœur du sujet.

À quelle fréquence relancer ses evals ?

Relancez votre jeu d'evals à chaque changement susceptible d'affecter le comportement de l'agent : nouvelle version du modèle, modification du prompt, mise à jour de la base documentaire, ajout d'un outil. C'est précisément à ces moments qu'une régression silencieuse peut s'introduire. Un eval qui ne tourne qu'une fois ne sert à rien : sa valeur vient de sa répétition.