Évaluer un agent IA : pourquoi les tests de prompt ne suffisent pas

Votre agent IA répond correctement à trois exemples dans une interface de démonstration. Vous changez légèrement la formulation, il choisit un mauvais outil. Vous lui donnez un document incomplet, il invente une réponse convaincante. Vous activez une vraie intégration, il exécute une action qu'il aurait dû vous demander de confirmer.

C'est le moment où l'on comprend qu'un agent ne se teste pas comme une simple fonction qui retourne une chaîne de caractères.

Un test de prompt vérifie une réponse sur un cas donné. Une évaluation d'agent doit aussi vérifier le chemin suivi pour produire cette réponse : les outils appelés, les données consultées, les décisions prises, les garde-fous déclenchés et le résultat réellement obtenu.

Les plateformes d'agents recommandent d'ailleurs de commencer par les traces pour comprendre un comportement, puis de passer à des jeux de données et des évaluations répétables lorsque l'on veut comparer des versions et détecter des régressions. ^1

Voici la méthode que j'utiliserais avant de confier à un agent un workflow métier réel.

Un agent peut donner la bonne réponse pour la mauvaise raison

Prenons un agent chargé de qualifier une demande entrante. On lui fournit un message client et on attend trois champs : une catégorie, une priorité et une prochaine action.

Sur dix exemples préparés à l'avance, les sorties semblent correctes. Mais plusieurs scénarios peuvent masquer un problème :

• l'agent a choisi la bonne catégorie, mais sans consulter la source qui faisait foi ;
• il a appelé un outil inutile, avec un coût ou un délai excessif ;
• il a utilisé une donnée périmée ;
• il a produit une priorité correcte par hasard ;
• il aurait pris une décision dangereuse sur une variante légèrement différente ;
• il a répondu avec un format valide, mais avec une action métier incohérente.

La qualité d'un agent ne se résume donc pas à la qualité de son texte final. Il faut évaluer au moins quatre dimensions :

1. Le résultat, est-il exact, utile et conforme au contrat attendu ?
2. La trajectoire, l'agent a-t-il suivi les bonnes étapes et appelé les bons outils ?
3. La sécurité, a-t-il refusé ou fait valider les actions à risque ?
4. L'exploitation, peut-on comprendre, mesurer et corriger son comportement ?

Cette distinction change complètement la manière d'écrire les tests.

Commencer par une définition observable du succès

Avant de sélectionner un modèle ou d'ajuster un prompt, écrivez ce que signifie "réussir" pour le workflow.

Pour un agent qui traite des tickets, la définition peut être :

• identifier la bonne catégorie lorsqu'elle est présente dans le référentiel ;
• demander une précision lorsqu'une information indispensable manque ;
• ne jamais modifier le ticket sans permission explicite ;
• utiliser le bon outil lorsque la demande concerne un compte client ;
• produire une sortie structurée qui respecte le schéma de l'application ;
• transférer à un humain les cas prévus par la politique métier.

Ces critères sont plus utiles qu'une consigne vague comme "répondre de manière pertinente". Ils peuvent être vérifiés séparément et reliés à une décision produit.

Pour chaque critère, précisez aussi le niveau d'échec acceptable. Une mauvaise tournure de phrase n'a pas le même impact qu'un remboursement déclenché sans validation. Les seuils doivent être proportionnels au risque, pas à la facilité de mesure.

Construire un jeu de cas à partir du réel

Un bon jeu d'évaluation ne contient pas uniquement des exemples propres, complets et bien formulés. Il doit représenter les situations que l'agent rencontrera réellement.

Commencez par collecter des cas anonymisés issus du support, des opérations ou des tests manuels. Ajoutez ensuite des variantes contrôlées :

• fautes de frappe et formulations indirectes ;
• informations contradictoires ;
• demandes incomplètes ;
• cas hors périmètre ;
• données anciennes ou indisponibles ;
• tentatives de contourner une règle ;
• contenu externe contenant des instructions à ignorer ;
• demandes nécessitant une validation humaine.

Ne mélangez pas tous les cas dans un seul score. Séparez les cas nominaux, les cas limites, les cas de sécurité et les cas de non-régression. Un agent peut progresser sur les réponses courantes tout en devenant moins fiable face aux demandes ambiguës.

Chaque cas doit contenir au minimum :

• l'entrée fournie à l'agent ;
• le résultat attendu ou les propriétés attendues ;
• les outils autorisés ;
• les outils qui ne doivent pas être appelés ;
• la décision d'escalade attendue ;
• la raison pour laquelle le cas existe.

Le dernier point est souvent oublié. Sans raison métier, un test devient rapidement un exemple historique que personne n'ose supprimer ni mettre à jour.

Évaluer la réponse finale, mais aussi la trajectoire

Une réponse finale peut être évaluée avec des règles déterministes lorsque le résultat est structuré : schéma JSON, identifiant, statut, montant, catégorie ou présence d'un champ obligatoire.

Pour le contenu textuel, une grille d'évaluation explicite est préférable à une impression globale. Vous pouvez vérifier par exemple :

• exactitude par rapport aux informations disponibles ;
• couverture des éléments indispensables ;
• absence d'affirmation non fondée ;
• respect du ton et du périmètre ;
• clarté de la prochaine étape ;
• respect de la langue et du format demandés.

Mais il faut également évaluer la trajectoire. Une trace utile permet de voir les appels de modèle, les appels d'outils, les garde-fous et les éventuels relais entre agents. Le trace grading consiste précisément à attribuer des critères structurés à cette exécution complète, plutôt qu'à regarder uniquement le texte final. ^2

Pour un agent de support, les questions deviennent alors :

• a-t-il consulté la bonne fiche avant de répondre ?
• a-t-il appelé l'outil de recherche avec les bons paramètres ?
• a-t-il tenté une action alors qu'une approbation était requise ?
• s'est-il arrêté lorsqu'une source était indisponible ?
• a-t-il transmis le contexte utile lors d'une escalade ?

Une trajectoire incorrecte qui produit une bonne réponse est un défaut latent. Elle peut se transformer en incident dès que le contexte change.

Combiner règles, tests et jugement humain

Il n'existe pas un évaluateur unique qui suffirait pour tous les agents.

Les règles déterministes sont adaptées aux contraintes qui ne doivent jamais varier : format, permission, présence d'un champ, outil interdit, limite de montant ou obligation d'escalade.

Un modèle évaluateur peut aider à juger une réponse ouverte, par exemple sa fidélité à un contexte, sa complétude ou sa clarté. Mais il faut lui fournir une grille précise, des exemples et des critères observables. Un score isolé donné par un autre modèle ne constitue pas une preuve de qualité.

La revue humaine reste nécessaire pour :

• créer et corriger les cas de référence ;
• vérifier que les critères représentent réellement le métier ;
• analyser les désaccords entre évaluateurs ;
• décider si un échec est bloquant ou acceptable ;
• valider les changements qui touchent à une action sensible.

L'objectif n'est pas d'automatiser tous les jugements. C'est de réserver le temps humain aux décisions qui nécessitent réellement du contexte.

Distinguer les erreurs de connaissance, de décision et d'exécution

Deux agents peuvent produire la même mauvaise réponse pour des raisons complètement différentes.

Un agent peut manquer d'information parce que la recherche documentaire a renvoyé le mauvais contenu. C'est un problème de données ou de retrieval.

Il peut avoir trouvé la bonne information, mais mal interprété la règle. C'est un problème de consigne, de modèle ou de conception du workflow.

Il peut avoir pris la bonne décision, mais l'appel d'outil a échoué ou a été mal paramétré. C'est un problème d'intégration ou de contrat applicatif.

Ces catégories doivent apparaître dans les résultats d'évaluation. Sinon, l'équipe risque de modifier le prompt pour corriger un bug d'API, ou de changer de modèle pour compenser une base documentaire mal indexée.

Pour chaque échec, consignez :

• l'étape où le comportement diverge ;
• la cause probable ;
• l'impact utilisateur ou métier ;
• la correction envisagée ;
• le cas de test qui empêchera la régression.

Une évaluation utile ne produit pas seulement une note. Elle produit une liste d'actions d'ingénierie.

Passer de la démo à une boucle d'évaluation continue

L'évaluation doit accompagner les changements du système : nouveau prompt, nouveau modèle, nouvelle source documentaire, nouvel outil, nouvelle règle métier ou nouvelle version du code.

Le cycle minimal est simple :

1. exécuter le jeu de cas sur la version actuelle ;
2. conserver les traces et les résultats ;
3. modifier un élément identifiable ;
4. relancer les mêmes cas ;
5. comparer les résultats par catégorie de risque ;
6. analyser les régressions avant de déployer.

Les cas doivent être versionnés avec le code ou dans un espace dont l'historique est fiable. Les scores doivent rester interprétables : un score global qui mélange sécurité, coût, latence et qualité peut cacher une dégradation importante sur un seul axe.

En production, ajoutez un échantillon de traces réelles, anonymisées selon vos obligations, afin de faire émerger des cas que votre jeu de tests ne prévoyait pas. Les observations de production deviennent alors de nouveaux cas de non-régression, après revue humaine.

L'observabilité est indispensable à cette boucle. Les conventions OpenTelemetry pour la GenAI structurent notamment les informations sur le modèle, les tokens, les durées et, lorsque cela est explicitement activé, le contenu des prompts, des sorties et des appels d'outils. La collecte du contenu doit être traitée avec prudence, car elle peut contenir des données sensibles. ^3

Un tableau de bord utile ne montre pas seulement un score

Pour piloter un agent, je préfère suivre quelques indicateurs reliés à des décisions :

• taux de réussite par type de cas ;
• taux d'escalade appropriée ;
• taux d'appel d'outil correct ;
• taux d'actions bloquées par un garde-fou ;
• erreurs de format ou de validation ;
• coût et durée par workflow ;
• régressions entre deux versions ;
• volume de corrections humaines après exécution.

Ces mesures ne doivent pas devenir un nouveau concours de KPI. Leur rôle est de rendre visible un risque et de déclencher une action : corriger le prompt, améliorer la donnée, revoir une permission, changer le workflow ou retirer une automatisation.

Un agent fiable n'est pas celui qui obtient le meilleur score sur un jeu de cas figé. C'est celui dont les limites sont connues, surveillées et régulièrement testées.

FAQ : évaluer un agent IA

Quelle est la différence entre tester un LLM et évaluer un agent ?

Tester un LLM consiste souvent à juger une réponse produite à partir d'une entrée. Évaluer un agent inclut cette réponse, mais aussi la trajectoire d'exécution : outils appelés, données consultées, décisions prises, validations et résultat métier.

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

Il n'existe pas de nombre universel. Le jeu doit couvrir les parcours fréquents, les cas limites et les risques propres au workflow. Commencez avec un ensemble assez petit pour être relu par des personnes du métier, puis enrichissez-le avec les erreurs observées.

Peut-on utiliser un autre LLM pour noter les réponses ?

Oui, pour certains critères ouverts, à condition d'utiliser une grille explicite, de contrôler les biais et de comparer régulièrement ses jugements à une revue humaine. Les contraintes critiques comme les permissions, le format ou l'appel d'un outil interdit doivent rester vérifiables par des règles déterministes.

Faut-il tester les appels d'outils même si la réponse finale est correcte ?

Oui. Un bon résultat obtenu par une mauvaise trajectoire peut être dû au hasard. Il révèle un comportement fragile qui risque d'échouer dès que la donnée, la formulation ou la disponibilité d'un outil change.

Quand un agent est-il prêt pour la production ?

Lorsqu'il existe une définition observable du succès, un jeu de cas représentatif, des contrôles sur les sorties et les outils, une observabilité suffisante, une procédure d'escalade et un moyen de couper ou de limiter l'automatisation. La décision dépend ensuite du risque du workflow, pas d'un score universel.

Ce que je recommande, en tant que CTO hands-on

Ne mettez pas un agent en production parce qu'il réussit une démonstration. Mettez-le en production lorsque vous savez expliquer ses succès, ses échecs, ses appels d'outils et ses limites.

La première étape n'est pas forcément de choisir un framework d'évaluation. C'est de cartographier le workflow, ses décisions et ses conséquences. Ensuite seulement, vous pouvez choisir les bons contrôles, les bons jeux de cas et le niveau d'automatisation acceptable.

C'est le type de démarche que je mène dans une mission de structuration d'un projet IA et automatisation : transformer une idée d'agent en système mesurable, testable et exploitable. Si le comportement actuel est difficile à expliquer, un audit technique permet de repartir des flux réels, des intégrations et des risques plutôt que du seul prompt.

Un agent n'est pas fiable parce qu'il paraît intelligent. Il est fiable lorsque son comportement peut être observé, évalué et corrigé.

Sources et références

• OpenAI, Evaluate agent workflows
• OpenAI, Trace grading
• OpenTelemetry, Inside the LLM Call: GenAI Observability with OpenTelemetry
• Google Cloud, From "Vibe Checks" to Continuous Evaluation