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, indique ce que chacune apporte concrètement et où elle s’arrête. Il ne désigne pas de gagnant, parce qu’il n’y en a pas : le bon outil dépend de vos contraintes de données, de votre maturité et de votre budget. Ce que vous pouvez en réutiliser, c’est 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.
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.
Les différences portent sur trois points. Le mode d’hébergement d’abord : certaines plateformes s’installent sur votre infrastructure, d’autres restent un service hébergé uniquement, 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 une chaîne d’intégration. La même approche se prête aux tests d’injection de prompt et de contournement de consignes.
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.
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 honnête, l’outil le plus simple qui couvre vos contraintes, et une exécution automatique à chaque modification.
L’accompagnement Agenticiel pour mettre en place vos évaluations
Choisir un outil d’évaluation et le faire tenir dans le temps touche à la fois à l’architecture, aux données et aux habitudes d’équipe. La plupart des PME n’ont pas de profil dédié à ces questions, et l’évaluation finit reléguée derrière les fonctionnalités visibles, jusqu’au premier incident en production.
Agenticiel accompagne les PME sur ces sujets avec une équipe de développeurs offshore francophones, basée à Madagascar. La sous-traitance de développement prend ici tout son sens : construire et maintenir un jeu de test, instrumenter les traces, brancher les évaluations dans la chaîne d’intégration sont des tâches régulières et bien cadrées, que l’offshore francophone absorbe sans friction de langue ni de fuseau horaire.
Notre approche consiste à commencer par un jeu de scénarios issu de votre usage réel, à installer l’outil le plus simple qui respecte vos contraintes de données, puis à faire tourner les évaluations à chaque modification avant d’élargir le dispositif.