L’agent a-t-il vraiment terminé ? Vérifier le résultat sans se fier à sa réponse finale

L’action n’est pas le résultat

Un agent peut répondre « c’est fait » sans que l’objectif soit atteint. Il peut aussi appeler un outil, recevoir une réponse indiquant que la demande a été acceptée et, malgré cela, laisser le travail en attente ou inachevé. Ce sont des affirmations différentes, qui exigent des preuves différentes.

Il est utile de distinguer trois états. Premièrement, l’agent a tenté une action : par exemple, il a envoyé une instruction pour modifier un enregistrement. Deuxièmement, le système qui a reçu la demande l’a acceptée ou y a répondu. Troisièmement, l’état final demandé par la personne existe et respecte les conditions convenues. À lui seul, seul ce troisième état démontre que l’objectif a été atteint.

Cette distinction compte, car une réponse positive peut ne concerner qu’une étape du processus. « Demande reçue » ne signifie pas nécessairement « modification enregistrée » ; « test exécuté » ne signifie pas que toutes les exigences du changement sont satisfaites ; et « réservation demandée » n’équivaut pas à une réservation confirmée. La réponse de l’agent peut résumer ce qui s’est passé, mais elle ne devrait pas devenir l’unique preuve de ce qui s’est réellement passé.

L’évaluation des agents vise notamment à vérifier si des systèmes capables d’agir peuvent accomplir un travail de façon fiable. Cet article se concentre sur une question plus restreinte : quelles preuves permettent d’accepter une tâche précise comme étant terminée ? Les recommandations et les exemples qui suivent constituent une méthode pratique ; ils ne prétendent pas qu’il existe un signal universel valable pour tous les agents et tous les outils.

Étape 1 : transformer la demande en un état final observable

Avant d’exécuter une tâche, reformulez la demande en décrivant l’état dans lequel le système ou le monde devrait se trouver une fois le travail terminé. « Mets à jour l’enregistrement » est ambigu : cette formulation ne précise ni le champ à modifier, ni la valeur attendue, ni les autres données qui doivent rester intactes. « Fais la modification du code » ne précise pas davantage le comportement attendu ni les conditions qui doivent continuer à être respectées.

Une formulation utile identifie l’objet concerné, l’état souhaité, les conditions à préserver et les limites pertinentes. Il n’est pas nécessaire de transformer chaque demande en une longue spécification. Il faut toutefois lever les ambiguïtés qui modifieraient la décision de déclarer la tâche terminée.

Le résultat observable doit pouvoir être décrit sans s’appuyer sur l’intention de l’agent. Au lieu de « l’agent s’est occupé de la réservation », précisez ce qui devrait exister pour pouvoir affirmer que la réservation est confirmée. Au lieu de « l’agent a corrigé le code », définissez le comportement attendu qui doit fonctionner et les vérifications pertinentes pour ce changement.

Délimitez également ce qui ne fait pas partie de la tâche. Si la demande consiste à mettre à jour un champ, ne supposez pas que l’agent devait aussi modifier d’autres champs, avertir des tiers ou examiner tout l’historique. Cette limite permet d’éviter deux erreurs opposées : accepter une tâche partielle comme achevée et élargir la mission sans autorisation.

Étape 2 : convenir des critères d’acceptation avant d’agir

Les critères d’acceptation précisent ce qu’il faudrait observer pour considérer la demande comme satisfaite. Il est préférable de les définir avant l’exécution : après coup, il est plus facile de confondre une sortie commode avec une preuve appropriée, ou d’abaisser le niveau d’exigence pour justifier un résultat partiel.

Un critère utile est précis et vérifiable. « L’enregistrement est correct » laisse trop de place à l’interprétation. « Le champ d’état affiche la valeur convenue pour l’enregistrement identifié » désigne un état et un objet. Si la préservation d’autres champs importe aussi, il faut l’ajouter comme critère distinct.

Une seule observation ne permet pas toujours de vérifier toutes les exigences. Un changement peut devoir faire apparaître une valeur tout en laissant un autre attribut intact. Une réservation peut nécessiter à la fois une confirmation et des détails exacts. Un test de code peut couvrir un comportement important sans démontrer à lui seul que toutes les exigences de la demande sont implémentées. La liste doit refléter les conditions réelles de la demande, pas seulement celles qu’il est le plus facile de mesurer.

Pour les demandes ouvertes à plusieurs interprétations, il peut d’abord être nécessaire de demander une précision. Si plusieurs interprétations sont raisonnables et que la différence influe sur le résultat acceptable, l’agent ne devrait pas en choisir une silencieusement puis agir comme si elle avait toujours été la seule possible. Les critères convenus déterminent aussi à quel moment une tâche n’est que partiellement achevée et quelles informations doivent être communiquées.

Étape 3 : choisir des preuves adaptées à l’affirmation

Les preuves doivent répondre à une question précise : qu’est-ce qui permet d’affirmer que l’état final souhaité existe ? La sortie d’un outil peut convenir pour savoir qu’une demande est parvenue à un composant donné, sans pour autant démontrer que le résultat a été enregistré ou qu’il satisfait toutes les exigences. N’attribuez pas à un signal une portée supérieure à sa signification réelle.

Dans la mesure du possible, vérifiez l’état au moyen d’une lecture pertinente du système concerné ou d’un contrôle qui évalue directement le résultat. Pour certaines tâches, la preuve peut être un test automatisé ; pour d’autres, une confirmation visible dans la source qui gère cet état. « Indépendante » ne signifie pas toujours « provenant d’un autre fournisseur » : cela signifie que l’affirmation de l’agent qui dit avoir terminé n’est pas utilisée comme unique preuve.

L’indépendance comporte elle aussi différents degrés. Demander une nouvelle fois à l’agent s’il a terminé peut simplement répéter son affirmation, sans la vérifier. Consulter une vue de l’enregistrement peut fournir une observation de l’état, mais il faut savoir ce que représente cette vue et si elle correspond au bon objet. Une source distincte peut permettre une meilleure comparaison, à condition qu’elle mesure bien le résultat demandé.

La preuve doit être liée au critère pertinent et au bon objet. La réussite d’un test de code ne valide pas automatiquement les exigences qu’il ne couvre pas. Une réponse de confirmation de réservation n’est utile que si elle concerne la réservation demandée et si ses détails concordent avec ce qui a été convenu. Si ce lien ne peut pas être établi, signalez l’incertitude au lieu de combler les lacunes par des suppositions.

Étape 4 : distinguer l’exécution de la vérification

Le composant qui réalise une action et celui qui en vérifie le résultat remplissent des fonctions différentes. Dans un flux simple, un même agent peut appeler un outil puis consulter le système concerné. Même dans ce cas, la seconde opération doit apporter une observation de l’état, et non simplement répéter que la première a réussi.

Dans les systèmes à plus fort impact, il peut être préférable que la vérification emprunte une voie différente de l’exécution ou qu’elle soit examinée par une personne. Cette séparation réduit le risque qu’une seule réponse soit considérée à la fois comme l’action et comme sa preuve. Ce n’est pas une règle absolue : le degré de séparation approprié dépend du risque, de l’ambiguïté de la tâche et de la qualité des signaux disponibles.

L’automatisation peut suffire lorsque les critères sont clairs, que la vérification couvre le résultat pertinent et que les conséquences d’une erreur éventuelle sont limitées. Une revue humaine prend davantage d’importance lorsque les instructions se prêtent à plusieurs interprétations, que les conséquences sont significatives, que les preuves ne sont pas concluantes ou qu’un jugement contextuel nécessaire n’est pas représenté par un test automatisé.

Demander une revue humaine ne rend pas automatiquement une conclusion correcte. La personne doit pouvoir consulter la demande, les critères convenus et les preuves observées. Une approbation dépourvue de ces éléments risque de devenir un autre « oui » sans fondement. La revue doit résoudre une question précise ; elle ne doit pas être une formalité sans lien avec le résultat.

Trois exemples détaillés

Les exemples qui suivent illustrent la méthode au moyen de critères hypothétiques. Ils ne décrivent aucun outil ou produit en particulier, et les signaux disponibles varient selon le système. Dans chaque cas, il est essentiel de ne pas transformer une réponse d’acceptation en preuve d’achèvement sans vérifier ce que signifie cette réponse.

Pour la mise à jour d’un enregistrement, la demande peut consister à changer un champ précis. L’action émise démontre une tentative ; une réponse d’acceptation peut indiquer que le système a reçu la demande. Pour déclarer le travail terminé, il faut observer le bon enregistrement et vérifier la valeur convenue. Si d’autres données doivent également rester intactes, elles doivent faire partie de la vérification. Si le système indique seulement que la modification est en attente, le résultat ne satisfait pas encore un critère exigeant que la valeur apparaisse déjà dans l’enregistrement.

Pour une modification de code, la tâche n’est pas définie par la seule existence d’un correctif ou d’une réponse positive. Avant de l’exécuter, précisez le comportement attendu et les conditions qui font partie de la demande. Ensuite, utilisez des contrôles pertinents pour ce comportement et examinez les critères qu’ils ne couvrent pas. Le fait qu’un test se termine sans erreur apporte des preuves sur ce que ce test a exécuté ; cela ne démontre pas automatiquement que toutes les exigences fonctionnelles ou de qualité de la demande sont satisfaites.

Pour une réservation, il est essentiel de distinguer la demande de la confirmation. L’agent peut envoyer une demande et recevoir une réponse qui ne précise pas si la réservation a été confirmée. Les preuves doivent permettre d’identifier la réservation concernée et de comparer les détails avec ceux qui ont été convenus. S’il n’y a qu’une demande en attente, ou si les données nécessaires ne peuvent pas être confirmées, le message final doit le préciser au lieu de présenter la réservation comme effectuée.

Résultats partiels, contradictoires ou impossibles à vérifier

Si seuls certains critères sont satisfaits, décrivez le résultat comme partiel. Ne transformez pas « l’action a été acceptée » en « la tâche est terminée » dans le but de fournir une conclusion plus convaincante. Évitez aussi l’excès inverse : si des preuves valides confirment certaines exigences, indiquez lesquelles au lieu de présenter l’ensemble du travail comme inconnu.

Si deux signaux se contredisent, suspendez votre conclusion jusqu’à ce que vous ayez clarifié ce que chacun mesure et à quel état il correspond. Une réponse positive peut indiquer que la demande a été reçue, tandis qu’une autre observation montre que l’état final n’a pas encore changé. Il ne s’agit pas nécessairement d’une véritable contradiction : les deux signaux peuvent concerner des étapes différentes. Mais tant que cette différence n’est pas clarifiée, ils ne justifient pas une affirmation complète de réussite.

S’il n’existe aucun moyen adapté d’observer le résultat, la conclusion correcte est qu’il n’a pas pu être vérifié — et non que l’agent a nécessairement échoué ou réussi. Communiquez l’action tentée, la réponse observée et le critère qui reste à vérifier. L’absence de preuve concernant l’état final ne permet pas, à elle seule, de déterminer quel est cet état.

La description du résultat doit rester proportionnée aux preuves. « Demande envoyée » ne signifie pas « demande acceptée » ; « modification observée dans le champ » ne signifie pas « toutes les exigences vérifiées » ; et « tests sélectionnés exécutés » ne signifie pas « aucun problème ne subsiste ». Un message précis permet à la personne qui reçoit le résultat de décider si elle doit attendre, examiner la situation ou accepter la tâche.

Liste de contrôle pour concevoir un flux

L’évaluation des agents peut chercher à déterminer si un système qui exécute des actions accomplit un travail de façon fiable, et les tests peuvent aider à interpréter des exécutions précises. Toutefois, un score, un état d’exécution ou une réponse d’outil ne remplace pas la définition du résultat qui compte pour une tâche particulière. L’équipe doit traduire la demande en critères observables et relier chaque conclusion aux preuves qui l’étayent.

Avant d’accepter une tâche ou de la présenter comme terminée, parcourez cette liste. Si vous ne pouvez pas répondre à une question, cela ne signifie pas toujours que la tâche a échoué ; cela indique néanmoins qu’il convient de limiter la portée de l’affirmation, d’obtenir les preuves manquantes ou de demander une revue adaptée à l’impact.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.