Un agent qui fonctionne en démonstration ne dit rien de sa fiabilité en production. Entre un prototype qui répond bien à quelques questions choisies et un agent qui traite des centaines de demandes réelles, l’écart se situe presque toujours là où personne ne regarde : l’évaluation. C’est la partie que les équipes sautent en premier, faute de temps et faute d’outillage.
Le marché des outils d’évaluation s’est structuré en quelques familles distinctes. Il y a les bibliothèques de métriques, qu’on installe dans son propre code. Il y a les plateformes d’observabilité qui ajoutent des évaluations à leurs traces. Il y a les frameworks de test en ligne de commande, pensés pour tourner dans une chaîne d’intégration. Chacune répond à un besoin différent, et les confondre mène à des choix coûteux.
Ce comparatif classe ces outils par famille, avec ce que chacune apporte et où elle s’arrête. Le bon outil dépend de vos contraintes de données, de votre maturité et de votre budget : vous repartez avec une grille de décision applicable à votre contexte.
Évaluer un agent : de quoi parle-t-on
Évaluer un agent suppose trois éléments, quel que soit l’outil. Un jeu de scénarios représentatifs de votre usage réel : des questions, des tâches, des cas limites, avec la réponse attendue. Une mesure : exactitude, respect des sources, format de sortie, coût en jetons, latence. Une exécution répétable : la même version de l’agent, sur le même jeu, pour comparer deux variantes. Si ces notions sont nouvelles pour vous, commencez par les evals expliquées avant de choisir un outil.
Il faut distinguer deux moments. L’évaluation hors ligne s’exécute avant le déploiement, sur un jeu figé, et sert à décider si une modification peut partir en production. L’évaluation en ligne observe le trafic réel et détecte ce que le jeu de test n’avait pas prévu. Les outils se répartissent différemment sur ces deux terrains, et beaucoup ne couvrent bien que l’un des deux.
Une trace, enfin, n’est pas une évaluation. La trace raconte ce que l’agent a fait : appels d’outils, requêtes envoyées, latence, erreurs. L’évaluation juge si c’était bien. Sans jeu de test ni critère explicite, le plus complet des tableaux de bord ne vous dira pas si votre agent progresse.
Les bibliothèques de métriques
Cette famille regroupe des bibliothèques, essentiellement Python, qu’on intègre dans son propre code. Ragas s’est imposée sur les mesures de systèmes RAG : fidélité aux sources, pertinence du contexte récupéré, qualité de la réponse produite. DeepEval propose une approche proche des tests unitaires, avec des assertions sur la sortie du modèle. OpenAI Evals fournit un cadre générique pour décrire des tâches et les noter.
Leur force est le coût : elles sont ouvertes, s’installent en quelques minutes et s’insèrent naturellement dans une chaîne d’intégration. Leur faiblesse est tout le reste : stockage, comparaison entre exécutions, relecture humaine et historique restent à votre charge. Ce sont d’excellents moteurs de calcul, pas des plateformes.
Les plateformes d’observabilité avec évaluation
Un second groupe part des traces et ajoute l’évaluation par-dessus. LangSmith, Langfuse, Arize Phoenix et W&B Weave suivent la même logique : instrumenter l’agent pour capturer chaque étape, regrouper les exécutions, puis noter les réponses avec des juges automatiques, souvent un modèle de langage, ou avec des relecteurs humains.
L’intégration au framework compte aussi : LangSmith est le compagnon naturel de LangChain et LangGraph, Langfuse se branche sur la plupart des frameworks, de LlamaIndex à l’OpenAI Agents SDK. Les différences portent ensuite sur trois points. Le mode d’hébergement d’abord : Langfuse et Arize Phoenix sont open source et s’installent sur votre infrastructure, d’autres s’utilisent avant tout en service hébergé, ce qui change tout pour des données sensibles. Le format des traces ensuite : les outils qui s’appuient sur OpenTelemetry évitent l’enfermement, les formats propriétaires le créent. La profondeur d’analyse enfin : certaines se concentrent sur la visualisation, d’autres sur la gestion de jeux de test et la comparaison fine de versions.
Ces plateformes coûtent plus cher que les bibliothèques, mais elles rendent visibles des régressions et des dérives que les scores seuls ne montrent pas.
Les frameworks de test en ligne de commande
Une troisième famille vise la simplicité : un fichier de configuration, une commande, un rapport. Promptfoo en est l’exemple le plus courant. Vous décrivez les cas de test et les critères d’évaluation dans un fichier, vous lancez la commande, et vous obtenez un verdict lisible, directement exploitable dans GitHub Actions ou GitLab CI. Il permet aussi de comparer plusieurs modèles (GPT, Claude, Mistral) sur le même jeu de cas. La même approche se prête aux tests d’injection de prompt et de contournement de consignes, un sujet qu’on traite à part dans notre article sur la sécurisation des prompts.
Ce sont les outils les plus rapides à mettre en route, et souvent les premiers qu’une équipe devrait adopter. Leur limite apparaît quand l’agent se complexifie : suivre une trace longue, avec plusieurs appels d’outils et des reprises après erreur, demande une infrastructure que ces frameworks ne fournissent pas. Ils excellent sur l’évaluation hors ligne d’un comportement isolé.
Les critères qui départagent
Le premier critère est la localisation des données. Si vos scénarios contiennent des informations clients ou des extraits de contrats, l’hébergement devient décisif : une solution auto-hébergée évite d’envoyer vos exemples à un tiers. C’est souvent ce point seul qui tranche entre deux outils équivalents, et c’est la même logique que pour l’agent lui-même : voyez nos principes d’IA souveraine (hébergement UE, open source, RGPD).
Le deuxième est le format des traces. Un outil qui parle OpenTelemetry vous laisse la liberté de changer de fournisseur sans réinstrumenter votre code. Un format propriétaire vous attache à la plateforme et à son coût de sortie.
Le troisième est la gestion des jeux de test. Un outil sérieux versionne les scénarios, permet de les annoter à la main et affiche la différence entre deux exécutions, cas par cas. Sans cette fonction, vous saurez qu’un score a baissé, mais pas quelle question a régressé.
Le quatrième est le coût réel, qui dépasse l’abonnement : stockage des traces et jetons consommés par les juges automatiques. Un juge qui note chaque réponse peut doubler la facture d’un agent à fort volume.
Le cinquième est l’intégration à la chaîne d’intégration continue. Un outil sans interface en ligne de commande finit par être lancé à la main, donc jamais.
Les pièges à éviter
Le premier piège est de choisir la plateforme avant d’écrire le jeu de test. L’outil le plus riche ne sert à rien si les scénarios ne représentent pas votre usage réel. Commencez par vingt cas concrets, choisis avec les personnes qui connaissent le métier.
Le deuxième est de se reposer sur un score global unique. Un taux de réussite agrégé masque les catégories en difficulté : un agent peut progresser en moyenne et régresser précisément sur les cas qui comptent. Regardez les résultats par type de demande.
Le troisième est de ne mesurer qu’en ligne, une fois l’agent en production. Attendre le trafic réel pour découvrir une régression revient à faire payer l’erreur à vos utilisateurs. L’évaluation hors ligne, exécutée à chaque changement, reste la barrière la moins chère.
Le bon point de départ tient en une phrase : un jeu de test représentatif, l’outil le plus simple qui couvre vos contraintes, et une exécution automatique à chaque modification.
Passer à l’action : mettre en place vos évaluations
Sur nos projets, on procède dans l’ordre inverse de ce que suggèrent les démonstrations d’outils : d’abord une vingtaine de scénarios tirés de votre usage réel, ensuite l’outil le plus simple qui respecte vos contraintes de données, enfin l’exécution automatique à chaque modification. Le détail de ce dispositif (evals, CI/CD, garde-fous) est décrit dans notre méthode, et c’est un bon point de départ si vous voulez évaluer l’agent que vous avez déjà.
