Comment évaluer un agent IA : les evals expliquées

Un agent IA a une particularité déroutante pour un développeur habitué aux logiciels classiques : on ne peut pas dire s’il fonctionne en le regardant faire une fois. Le même prompt, exécuté deux fois, peut donner deux résultats différents, et un changement de modèle ou de consigne peut améliorer un cas tout en en dégradant un autre sans que rien ne le signale. Pour savoir si un agent est bon, il faut le mesurer, et c’est exactement ce que font les evals.

Le terme d’eval, contraction d’évaluation, désigne l’ensemble des méthodes qui consistent à confronter les sorties d’un agent à des résultats attendus, sur un jeu de cas représentatif, et à en tirer un score. C’est l’équivalent, pour un agent IA, de la suite de tests d’un logiciel classique, avec une différence majeure : on n’y vérifie pas une égalité exacte mais une qualité, ce qui rend la mesure plus délicate.

Cet article explique ce que sont réellement les evals, comment construire un jeu de cas de référence sans y passer des semaines, et comment brancher cette mesure dans le cycle de développement pour que chaque modification soit validée avant d’atteindre la production.

Pourquoi les tests classiques ne suffisent pas

Un test classique vérifie que pour une entrée donnée, la sortie est exactement celle attendue. Cette logique échoue avec un agent IA pour deux raisons. La première est la variabilité : le même modèle ne reproduit pas deux fois exactement la même phrase, et une comparaison stricte échouerait en permanence. La seconde est la nature ouverte des sorties : pour une question donnée, plusieurs réponses peuvent être correctes, et l’égalité exacte est un critère trop pauvre pour les départager.

Il faut donc accepter une forme de jugement approximatif, et c’est là que la rigueur devient cruciale. On ne vérifie pas que la sortie est identique à un modèle, mais qu’elle satisfait des critères : la réponse contient-elle les bons faits, respecte-t-elle la consigne, refuse-t-elle correctement ce qui est hors périmètre, cite-t-elle les bonnes sources. Ces critères se déclinent en cases à cocher ou en notes, et c’est l’ensemble qui forme un score.

Cette approche a une conséquence pratique : une eval ne vaut que ce que valent ses critères. Des critères flous produisent des scores sans signification. Des critères précis, même simples, produisent une mesure sur laquelle on peut s’appuyer pour décider si un changement est une amélioration ou une régression. La qualité de l’eval est donc un investissement en amont, pas une formalité en aval.

Construire un jeu de cas de référence

Le cœur d’une eval est le jeu de cas de référence : un ensemble d’exemples représentatifs, chacun associé à une réponse attendue ou à des critères de réussite. Ce jeu doit ressembler au trafic réel de l’agent, dans ses proportions comme dans ses difficultés. Un jeu composé uniquement de cas faciles donne un score flatteur et faux ; un jeu composé uniquement de cas exotiques donne un score décourageant et tout aussi faux.

La construction commence par la vraie matière : les conversations, tickets, requêtes que l’agent reçoit réellement. On en extrait un échantillon, on le nettoie, on l’annote, et on le fige comme référence. Si l’agent est déjà tracé dans Langfuse ou LangSmith, ces outils permettent de constituer ce jeu directement à partir des traces de production. C’est un travail manuel, mais il n’a pas besoin d’être gigantesque pour être utile : quelques dizaines de cas bien choisis, couvrant les scénarios principaux et les échecs connus, suffisent à détecter la plupart des régressions. Pour un assistant documentaire, la démarche a ses particularités, détaillées dans construire un jeu de test représentatif pour un RAG.

Le jeu de cas doit inclure délibérément les cas difficiles et les cas d’échec. Ce sont eux qui révèlent les régressions, car c’est sur eux qu’un changement de modèle ou de prompt se paie le plus. Un agent qui ne s’évalue que sur ses succès historiques est un agent dont on ne voit jamais la dégradation arriver.

Noter les réponses : le jugement humain et le modèle-juge

Une fois le jeu de cas posé, il faut noter les réponses. Deux approches coexistent, et la bonne pratique consiste à les combiner. La première est le jugement humain : une personne relit les réponses et applique les critères. C’est la référence la plus fiable, mais elle coûte du temps et ne se répète pas à chaque modification. On la réserve donc aux décisions importantes et à la validation du jeu de cas.

La seconde est le modèle-juge : un second modèle de langage reçoit la réponse de l’agent, les critères, et rend une note ou un verdict. Cette approche est rapide et se branche dans un pipeline automatisé, ce qui permet d’exécuter l’eval à chaque modification. Elle a toutefois un défaut : le juge a ses propres biais, et il peut noter avec générosité ou sévérité selon les cas. On ne peut donc pas lui faire une confiance aveugle.

La bonne pratique consiste à calibrer le juge : on compare ses notes à celles d’un humain sur un sous-ensemble de cas, et on ajuste les critères jusqu’à ce que l’écart soit acceptable. Une fois calibré, le juge devient un instrument fiable et répétable, et c’est lui qui rend l’eval exécutable à grande échelle. Plusieurs outils du marché outillent ce travail : Promptfoo pour décrire cas et critères dans un fichier de configuration, DeepEval pour les écrire comme des tests Python, Ragas pour les métriques propres au RAG (fidélité aux sources, pertinence du contexte). On les compare dans notre comparatif des outils d’évaluation d’agents.

Brancher l’eval dans le cycle de développement

Une eval ne sert à rien si elle n’est exécutée que de temps en temps, à la main. Sa vraie valeur apparaît quand elle devient une étape automatique du cycle : à chaque changement de prompt, de modèle ou d’outils, on relance le jeu de cas et on compare le score à la référence. Une baisse significative bloque le changement, une hausse le valide. Un job GitHub Actions ou GitLab CI suffit à déclencher cette exécution sur chaque pull request. C’est exactement la logique d’un test de non-régression, transposée à la qualité floue d’un agent, et le point de départ d’une vraie chaîne CI/CD pour agents IA.

Cette intégration change la façon de travailler. On ne déploie plus un prompt modifié sur un espoir, on le déploie sur un score. On ne change plus de modèle parce que le nouveau est plus récent, on le change parce que l’eval le valide sur le cas réel. Et quand une régression apparaît, on sait précisément quel cas la provoque, ce qui transforme le débogage d’une quête aveugle en une recherche ciblée.

Il faut aussi faire grandir le jeu de cas avec l’usage. Chaque erreur constatée en production, chaque cas que l’agent a mal traité, doit rejoindre le jeu de référence. C’est ainsi que l’eval s’améliore en continu et que l’agent, au lieu de se dégrader silencieusement, se renforce à chaque itération.

Construire ces jeux de référence demande souvent un travail d’annotation : ces projets IA concrets montrent ce que le data labeling apporte.

En pratique : évaluer vos agents

Mettre en place des evals demande un jeu de cas solide, des critères précis et une intégration dans le cycle de développement. Le plus dur n’est pas technique : c’est d’accepter de passer quelques jours à annoter de vrais cas avant d’écrire la moindre ligne d’automatisation.

Chez Agenticiel, chaque agent part en production avec son jeu de référence. Construction des cas à partir de votre trafic réel, critères définis avec vos équipes métier, calibration du modèle-juge sur un échantillon noté à la main, puis exécution automatique à chaque changement de prompt ou de modèle : c’est la première brique de notre méthode, et c’est elle qui permet de changer de modèle sur un score plutôt que sur une intuition.

Si vous avez déjà un agent en production sans aucune mesure, commencez petit : trente cas réels, trois critères, une exécution avant chaque déploiement. Vous saurez très vite si votre dernière modification était une amélioration.