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. 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.
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.
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. C’est exactement la logique d’un test de non-régression, transposée à la qualité floue d’un agent.
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.
L’accompagnement Agenticiel pour é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. Agenticiel accompagne les équipes qui veulent mesurer réellement leurs agents : construction du jeu de référence, définition des critères, calibration du modèle-juge, et automatisation de l’eval à chaque modification.
Ce travail est mené par une équipe de développeurs offshore francophones, basée à Madagascar. La sous-traitance de développement vous apporte l’expertise nécessaire pour bâtir une mesure fiable, sans détourner votre équipe de son travail. Vous parlez directement à ceux qui construisent vos evals, dans votre langue.
Notre approche consiste à faire de l’évaluation une habitude plutôt qu’un luxe : on construit un jeu de cas représentatif, on mesure chaque modification, et on ne laisse jamais un agent évoluer sans savoir s’il progresse ou s’il régresse.