Tester les agents IA par résultat : vérifier l’état plutôt que de faire confiance aux réponses

Lorsqu’un agent IA répond « Terminé », cette phrase constitue une affirmation et non un reçu. Une évaluation qui ne prend en compte que le message final considérera à tort une réussite imaginaire comme valide. Ce guide montre comment tester les agents utilisant des outils en fonction de ce qui a réellement changé dans le monde : comment définir la finalisation, quels éléments examiner, comment gérer les temps d’attente et les cas où l’agent ne doit rien faire, ainsi que comment mesurer la fiabilité plutôt qu’un simple résultat chanceux.

Une réponse affirmative n’est pas une preuve

Prenons une demande simple adressée à un assistant de planification : déplacer une réunion au jeudi après-midi. L’assistant répond, poliment et sans hésiter, que la réunion a maintenant lieu à 15 heures. Or, en ouvrant le calendrier, on constate que l’événement se trouve exactement à sa place initiale.

Les variations sont tout aussi plausibles : l’événement a été déplacé à 15 heures dans une autre zone horaire, ou un événement entièrement nouveau est apparu tandis que l’original restait inchangé, laissant l’utilisateur face à deux options. Cet exemple est fictif, mais le problème de test est bien réel : si l’on évalue uniquement le texte produit par l’agent, les trois échecs ressemblent tous à un succès.

Le changement de perspective utile est le suivant : pour un agent, la réponse constitue un rapport sur son travail, et un rapport peut être erroné. Le système qui entoure le modèle, son cadre de fonctionnement, détermine s’il peut agir de manière fiable (nous abordons ce volet dans d’où provient réellement un comportement d’agent fiable). L’évaluation est l’étape qui confirme si ce système a bien rempli sa fonction.

Rédigez d’abord le contrat de validation

« Déplacer ma réunion » semble anodin tant que l’on n’essaie pas d’établir des critères d’acceptation pour cela.

Pour l’exemple donné, supposons que l’utilisateur ait identifié un seul événement, indiqué une date et une zone horaire, et autorisé une mise à jour. Le résultat souhaité n’est pas simplement qu’il existe une réunion à 15 heures ; il s’agit plutôt que cet même événement commence désormais à l’heure demandée, conserve sa durée et sa liste d’invités initiales, sans que aucun autre événement ne soit modifié. Si la demande est ambiguë ou si l’assistant n’a pas les autorisations nécessaires, le comportement correct est de demander des précisions plutôt que de deviner.

Ces règles s’appliquent à ce produit hypothétique. Un autre produit pourrait envoyer des notifications, exiger une approbation explicite ou traiter les participants différemment. Ce qui compte, c’est que le contrat soit écrit par écrit. Sans lui, un évaluateur loue un assistant pour son initiative tandis qu’un autre considère la même action comme une modification non autorisée, ce qui rend les scores peu fiables.

Chaque cas d’évaluation doit donc préciser :

• l’état initial de l’environnement ;
• la demande de l’utilisateur ;
• les actions que l’agent est autorisé à effectuer ;
• les conditions qui doivent être remplies par la suite ; et
• ce qui doit rester inchangé.

Cet dernier point est facile à oublier. Un bon test définit à la fois l’objectif et les limites qui l’entourent.

Trois points de vue sur une même exécution

Chaque exécution d’agent peut être examinée sous trois angles, et chacun révèle des échecs différents.

• Résultat affiché : le message que l’utilisateur a vu. Est-il précis et utile, ou bien cache-t-il un travail inachevé au lieu de l’indiquer ?
• Trajectoire : la séquence observable des appels d’outils, des résultats obtenus, des validations, des tentatives de réessai et des vérifications. L’agent a-t-il choisi l’événement approprié, resté dans le cadre de ses permissions et réagi de manière sensée en cas d’échec d’un outil ?
• Résultat final : l’état réel du calendrier une fois la tentative terminée.

Le guide d’Anthropic sur l’évaluation des agents fait la même distinction entre le transcript et l’état final de l’environnement, et il met en garde contre l’idée d’évaluer chaque solution valide selon une séquence fixe d’étapes. Ce équilibre mérite d’être adopté : observez le comportement de l’agent, mais n’insistez pas sur le parcours que vous préférez à moins que l’ordre des opérations ne fasse réellement partie des conditions prévues.

Concrètement, deux agents peuvent consulter le calendrier par des méthodes différentes et aboutir au même résultat correct ; tous deux devraient être jugés réussis. En revanche, omettre une approbation obligatoire constitue un échec, même si le calendrier finit par être correct. Le résultat détermine si la tâche a réussi, les limites déterminent si elle était autorisée, et le suivi explique la différence entre les deux.

Vérifier le monde par un canal indépendant

Pour vérifier le test de calendrier, lisez l’événement enregistré via une interface autorisée qui n’a aucun rapport avec la réponse de l’agent lui-même. Il est interdit à l’agent d’évaluer son propre travail.

Comparez les champs qui définissent réellement la correction avec l’état attendu :

• l’identifiant stable de l’événement ;
• les heures de début et de fin, ainsi que la zone horaire ;
• la liste des participants ;
• les événements voisins qui devraient rester inchangés.

Évitez de vous baser sur le titre de l’événement. Deux réunions peuvent partager un même nom, et une correspondance du titre confirmera à tort celle qui n’est pas la bonne.

Cette idée existe déjà avant les frameworks d’agents actuels. τ-bench évalue les conversations impliquant l’utilisation d’outils en comparant l’état final de la base de données avec un état cible annoté, tandis que WebArena mesure si les tâches sont effectivement achevées de manière fonctionnelle au sein d’environnements web réalistes. Ce sont tous deux des exemples de recherche visant à évaluer ce qui s’est produit plutôt que ce qui a été dit.

Savoir ce qu’un signal de succès promet réellement

Pour les systèmes asynchrones, décidez à l’avance combien de temps le vérificateur doit attendre et quel état est considéré comme finalisé. Si vous ne pouvez pas observer l’état du tout, enregistrez le résultat comme non vérifié. Ne l’assumez pas silencieusement comme un succès, et n’en supposez pas non plus le contraire. Cette troisième catégorie devient essentielle dès que les requêtes commencent à expirer.

Le moment le plus difficile : juste après une expiration

Une expiration ne vous indique rien sur le fait que la mise à jour ait bien été transmise. La requête a pu échouer avant d’atteindre le service de calendrier, ou elle a pu réussir mais seule la réponse s’est perdue en revenant.

1. Lire à nouveau l’événement cible.

Vérifier si le changement demandé est déjà en vigueur.

Ne pas réessayer que si les éléments de preuve et les spécifications de l’outil le permettent en toute sécurité.

Lorsque le service le supporte, utiliser un mécanisme d’idempotence afin qu’une demande répétée soit considérée comme la même opération et non comme une nouvelle.

Si le résultat reste inconnu, il peut être préférable de s’arrêter et d’expliquer l’incertitude à l’utilisateur. Une transmission claire vaut mieux qu’un succès artificiel. Ce même principe se retrouve dans la conception classique des backends ; consultez les clés d’idempotence pour les endpoints POST de Node.js pour en savoir plus sur le côté serveur.

Évaluez à la fois l’état et la formulation. « Je ne peux pas confirmer la mise à jour » est vrai même si le service applique ce changement un instant plus tard. « Rien n’a été modifié » est une affirmation infondée dans exactement la même situation. L’incertitude est un résultat légitime que l’agent doit gérer, et non un vide qu’il devrait combler par de la certitude.

Associez l’évaluateur à la question

Différentes questions méritent différents juges.

• Code déterministe pour des faits précis : identifiants, horodatages, ensemble des modifications autorisées, nombre d’événements dupliqués.
• Évaluateur basé sur un modèle avec une grille d’évaluation claire pour la qualité de la communication : l’assistant a-t-il distingué le travail achevé du travail en cours, et a-t-il décrit les étapes suivantes sans inventer de détails ?

Vérification humaine pour les cas ambigus, ainsi que pour vérifier périodiquement si les notes automatisées correspondent toujours aux attentes de l’équipe produit.

La documentation d’évaluation de LangSmith considère les règles de code, la vérification humaine et le jugement basé sur un modèle comme des options distinctes. Vous n’avez pas besoin de cette plateforme pour bénéficier du fait de les conserver séparées.

Un anti-modèle mérite une mention spéciale : transmettre à un second modèle la réponse affirmative de l’agent et lui demander si la tâche semble réussie. Le juge sera convaincu par cette même certitude qui vous a trompé. Au lieu de cela, fournissez au juge les preuves réellement requises par la question et permettez-lui de répondre « preuves insuffisantes ».

Il convient de séparer les défaillances critiques des scores de qualité. Une modification non autorisée du calendrier ne doit pas être atténuée par un ton agréable ou des formulations précises. Un tableau de scores compact est efficace : résultat correct, limites respectées, rapport honnête, réaction appropriée. Indiquez la latence et le coût à côté plutôt que de regrouper tout cela en un seul chiffre opaque.

Inclure les cas où la bonne réponse est de ne rien faire

Un ensemble de cas de base raisonnable pour l’assistant calendrier comprend :

• un report normal ;
• deux événements partageant le même titre ;
• une demande sans zone horaire indiquée ;
• un refus d’autorisation ;
• une expiration du délai de réponse par le service calendrier ;
• une mise à jour déjà appliquée avant que l’agent ne s’exécute ;
• une demande de rédiger une proposition de modification sans l’appliquer.

Ce dernier cas vous protège contre un biais subtil. Si chaque test récompense l’apport de changements externes, vous finissez par sélectionner un agent qui agit de manière trop hâtive.

Exécutez des tests qui modifient l’état dans des comptes de test isolés ou des environnements contrôlés, et réinitialisez les éléments préparatoires entre chaque tentative indépendante. Un résultat laissé par une exécution précédente ne doit en aucun cas faire croire que la prochaine exécution sera réussie.

Cette liste constitue un point de départ, mais ce n’est pas un échantillon statistiquement suffisant. Étendez-la en fonction de ce que vos utilisateurs demandent réellement, des vrais risques identifiés et des échecs qui se produisent dans la pratique. Supprimez les données personnelles des éléments préparatoires que vous comptez réutiliser, et restreignez l’accès aux traces contenant des données privées.

Mesurez la cohérence, pas la meilleure démonstration

Exécutez chaque cas plus d’une fois, et enregistrez chaque tentative, y compris les temps d’attente et celles où la vérification a échoué.

τ-bench a introduit une métrique d’essais répétés, pass^k, qui détermine si un agent réussit à toutes les k tentatives plutôt qu’à au moins une. Les scores de modèles publiés sont historiques et ne doivent pas être interprétés comme un classement des agents actuels, mais la leçon reste valable : « pouvoir réussir » et « réussir de manière fiable » sont des propriétés différentes, et une seule tentative réussie ne vous indique que la première.

Un tableau de bord de produit initial pourrait suivre :

• le taux de réussite valide ;
• le nombre d’actions non autorisées ;
• les affirmations de réussite non étayées ;
• les escalades appropriées ;
• la latence ;
• le coût par réussite valide.

Soyez précis quant au dénominateur. Comptez-vous les demandes des utilisateurs, les tentatives indépendantes ou les reprises individuelles ? Les mêmes données peuvent donner des taux très différents en fonction du choix retenu.

Lisez les chiffres ensemble. Un changement qui augmente le taux d’achèvement tout en augmentant également les actions non autorisées n’est pas une véritable victoire. De même, un agent qui évite tout risque en refusant toutes les tâches utiles n’est pas non plus idéal. Comparez les versions pour les mêmes dossiers avec les mêmes budgets, et indiquez le nombre de dossiers que vous avez traités ainsi que l’ampleur des variations des résultats entre les différentes exécutions. Un petit nombre d’essais est bien trop faible pour justifier une valeur précise de fiabilité en production.

Transformez chaque échec en test de régression

Lorsqu’un dossier échoue, déterminez d’abord ce qui ne va pas réellement : l’agent, l’outil, l’environnement ou le système d’évaluation. Un test défaillant n’est pas une preuve qu’un modèle est défectueux.

Il faut alors recréer un cas reproductible minimal et versionner tout ce qui peut l’influencer : la tâche, l’état attendu, le correcteur, la configuration du modèle, les instructions ainsi que les contrats des outils. Lorsque l’un de ces éléments change, il convient de relancer les cas concernés. Fixer l’état attendu est tout aussi important que fixer le modèle ; notre article sur la fixation des versions dans les suites d’évaluation pour les LLM aborde ce sujet plus en détail.

Les tests hors ligne et la surveillance en temps réel répondent à des questions différentes. Une évaluation ciblée avant publication vous indique si un changement peut être déployé en toute sécurité ; évaluer des interactions réelles vous permet de découvrir ce qui ne fonctionne pas dans le contexte réel. La documentation LangSmith décrit ces deux approches et recommande d’intégrer les pannes en production dans l’ensemble de tests.

Pour l’assistant de calendrier, un tel cycle pourrait commencer par des signalements d’utilisateurs concernant des événements dupliqués, ajouter un cas de réponse perdue au système, et s’assurer qu’une correction permettant la récupération fonctionne avant une diffusion plus large.

Points clés

• Considérez « Terminé » comme une affirmation à vérifier, jamais comme une preuve.
• Rédigez le contrat en fonction de chaque cas : état initial, demande, actions autorisées, état final requis et éléments qui ne doivent pas changer.
• Évaluez le résultat, appliquez les limites établies, et utilisez le suivi pour expliquer les différences.
• Vérifiez par une voie de lecture indépendante et autorisée, et conservez « non vérifié » comme résultat honnête.
• Testez explicitement les délais d’expiration, les doublons et les cas sans action ; c’est là que les agents fiables échouent.
• Éloignez les défaillances critiques des scores de qualité moyens, et mesurez la fiabilité des tentatives répétées.

Au lieu de croire aveuglément tout message indiquant un succès, demandez ce qui a changé, quelles contraintes ont été respectées et quels éléments prouvent la fiabilité du rapport.