Quand l'IA agit : la trajectoire devient l'objet de la mesure

Imaginez un agent chargé de traiter les demandes de remboursement des clients. Une réclamation arrive. L'agent lit le message, retrouve la commande dans l'outil de gestion, vérifie les conditions de retour, calcule le montant, déclenche le virement, puis rédige la réponse au client.

Six étapes, trois outils, plusieurs décisions, et pas une seule intervention humaine. Cet agent nous servira de fil conducteur pour une question : comment évaluer la qualité de l'action d'un agent IA ?

Pour évaluer la pertinence d'un agent, il faut évaluer sa trajectoire

Les deux premiers volets de notre série défendaient une même ligne : toute sortie d'IA est une hypothèse tant qu'elle n'a pas été mesurée. Et la mesure s'organise en boucle : construire, mesurer, améliorer, généraliser.

Sur un assistant RAG, l'exercice était exigeant mais praticable. La raison est simple : l'objet à juger était facile à isoler. Une question, une réponse. Avec notre agent de remboursement, cet objet disparaît. Juger la réponse envoyée au client ne suffit pas : elle peut être parfaite alors que le virement est parti deux fois. Ce qu'il faut évaluer, c'est la trajectoire, la suite complète des étapes parcourues. Et la difficulté, c'est que cette trajectoire n'est jamais deux fois la même.

Ce volet est plus prospectif que les deux précédents : le sujet bouge vite et les pratiques ne sont pas stabilisées. La direction, elle, se dessine déjà nettement.

L'anatomie d'un agent

Si le vocabulaire de l'agentique vous est familier, sautez cette section.

Un agent est un modèle de langage auquel on a ajouté trois choses.

• Une mémoire, pour garder le fil de ce qu'il a déjà fait et appris au cours de la tâche.
• Un orchestrateur : la partie qui découpe une demande en étapes et décide de la suite à donner.
• Des outils qu'il peut appeler lui-même : une base de commandes, un service de paiement, un moteur de recherche, une messagerie. Chaque « appel d'outil » est une action de l'agent sur son environnement.

L'agent interroge donc des systèmes, prend des décisions, et modifie l'état du monde autour de lui.

Restent deux termes.

• Un sous-agent est un agent spécialisé auquel l'agent principal délègue une portion du travail. Un agent réel est souvent une petite équipe d'agents. Notre agent de remboursement, lui, travaille seul.
• La trace (ou tracing) est l'enregistrement horodaté de chaque étape, chaque appel d'outil et chaque décision prise pendant l'exécution. C'est le journal de bord de la trajectoire.

Un agent, c'est le même modèle de langage entouré d'un dispositif qui lui permet d'agir. La trace en est le journal de bord.

Cinq raisons rendent un agent plus difficile à évaluer qu'un RAG

Première raison : une erreur au début fausse tout ce qui suit

Avec un agent, chaque étape produit un résultat servant de base à l'étape suivante. Si une étape produit un résultat incorrect, toutes les suivantes partent d'une donnée fausse, même si les IA font correctement leur travail.

Reprenons notre agent de remboursement. À l'étape 2, il cherche la commande du client dans l'outil de gestion. Ce client a passé deux commandes à quelques jours d'intervalle, et l'agent sélectionne la mauvaise. À partir de là :

• l'étape 3 vérifie les conditions de retour de cette commande ;
• l'étape 4 calcule le montant de cette commande ;
• l'étape 5 émet le virement pour ce montant.

Ces trois étapes ont fait exactement ce qu'on leur demandait. Mais le remboursement émis ne correspond pas à la réclamation.

Pour l'évaluation, le problème est le suivant.

• Ce qu'on observe, c'est un mauvais montant à l'étape 5.
• La cause réelle est à l'étape 2.

Si on ne regarde que l'endroit où l'erreur devient visible, on va chercher à corriger le calcul du montant, alors que ce calcul est juste.

Deuxième raison : personne ne voit les étapes intermédiaires

Avec un assistant RAG, chaque réponse est lue par un utilisateur. Si elle est fausse, il a au moins une chance de s'en rendre compte, parce qu'il la voit.

Avec un agent, ce n'est plus vrai. Notre agent reçoit la réclamation, enchaîne ses six étapes, et envoie un message de confirmation au client.

• L'équipe qui exploite l'agent voit la réclamation en entrée et le virement en sortie.
• Elle ne voit pas les cinq étapes qui les séparent.

Reprenons l'erreur précédente : l'agent sélectionne la mauvaise commande à l'étape 2. Rien ne le signale à ce moment-là, puisque personne ne regarde l'étape 2. Le message final, lui, est bien rédigé et ne laisse rien paraître.

Les erreurs se produisent donc dans des étapes que personne n'observe. Et le seul élément que quelqu'un observe, le résultat final, ne permet pas de les repérer.

Troisième raison : l'agent ne fait jamais deux fois la même chose

Un modèle de langage ne donne pas toujours la même réponse à la même question. Un agent enchaîne des dizaines d'appels à ce modèle, et hérite de cette variabilité à chaque étape.

Concrètement, si on envoie deux fois la même réclamation à notre agent, voici ce qui peut se passer.

• La première fois, il interroge l'outil de gestion avec le numéro de commande figurant dans le message, obtient la bonne commande du premier coup, puis enchaîne.
• La seconde fois, il interroge l'outil avec le nom du client et la date d'achat, obtient deux commandes, et lance donc une troisième requête pour trancher entre les deux.

Le résultat final peut être identique dans les deux cas. Le chemin pour y arriver ne l'est pas.

Pour l'évaluation, cela change tout.

En test logiciel classique, si un test passe, le comportement est validé, parce que le programme refera la même chose la prochaine fois.

Ici, non. Un test qui passe prouve seulement que ce chemin-là a fonctionné une fois. Le chemin suivant sera différent, et rien ne dit qu'il fonctionnera aussi.

Quatrième raison : les risques d'échec se multiplient d'étape en étape

Les trois raisons précédentes portaient sur la nature des erreurs. Celle-ci porte sur leur nombre, par un effet purement arithmétique.

Supposons que notre agent réussisse chaque étape dans 90 % des cas. Pris séparément, 90 % semble un bon score.

Sauf qu'un remboursement n'est correct que si toutes les étapes réussissent. Si une seule échoue, le résultat est faux. Les risques d'échec ne se compensent pas, ils s'ajoutent les uns aux autres.

Pour le voir, prenons 100 réclamations et suivons-les étape par étape.

• L'étape 1 en traite correctement 90 et en abîme 10. Il reste donc 90 dossiers sains.
• L'étape 2 s'applique à ces 90 dossiers seulement, et non aux 100 du départ : les 10 déjà faussés le restent. Elle en réussit 90 %, soit 81.
• L'étape 3 applique de nouveau 90 % à ces 81, ce qui donne 73.
• Et ainsi de suite.

À chaque étape, on perd 10 % de ce qu'il reste, et non 10 % du total de départ. La base sur laquelle on calcule rétrécit à chaque fois.

Au bout de 8 étapes, un agent fiable à 90 % n'aura traité correctement que 43 réclamations sur 100.

Cinquième raison : quand ça casse, on ne sait pas quelle pièce a cassé

Notre agent de remboursement n'est pas un seul programme. C'est un assemblage de pièces, celles décrites plus haut dans l'anatomie d'un agent :

• le modèle de langage, qui comprend la réclamation, en extrait la référence de commande et rédige le message au client ;
• l'orchestrateur, qui décide de l'ordre des étapes ;
• les trois outils qu'il interroge : la gestion des commandes, le référentiel des conditions de retour, et le service de paiement, qui calcule le montant remboursable et émet le virement.

Imaginons que l'on mesure le taux de remboursements corrects chaque semaine, et qu'il passe de 95 % à 80 %. On sait qu'une de ces pièces s'est dégradée. Mais le chiffre ne dit pas laquelle. Cela peut être :

• l'outil de gestion des commandes, qui renvoie de mauvais résultats depuis une mise à jour ;
• l'orchestrateur, qui a commencé à sauter la vérification des conditions de retour ;
• le modèle de langage, dont le fournisseur a livré une nouvelle version qui extrait moins bien la référence de commande du message client.

Ce sont trois problèmes différents, avec trois corrections différentes, et un score global ne permet pas de les distinguer.

Un agent doit être évalué à trois niveaux : est-ce que ça marche, pourquoi, et où ça casse

Les cinq raisons précédentes mènent à une même conclusion : un score unique ne suffit pas. Il dit si l'agent a réussi, mais ni pourquoi ni où il a échoué.

L'évaluation d'un agent se conduit donc à trois niveaux, qui répondent chacun à une question différente :

• le niveau end-to-end répond à « est-ce que ça marche ? » ;
• le niveau trajectoire répond à « pourquoi ça marche, ou pas ? » ;
• le niveau composant répond à « où exactement ça casse ? ».

Niveau 1, end-to-end : la tâche a-t-elle réussi ?

End-to-end signifie « de bout en bout ». Dans notre exemple le remboursement est-il arrivé ? Avec le bon montant ? Dans un délai raisonnable ?

On ne s'intéresse pas au chemin, seulement au résultat.

Quatre mesures :

• le taux de réussite (task success rate) : sur 100 réclamations, combien sont correctement traitées ;
• la qualité du résultat : le message envoyé au client est-il juste et compréhensible ;
• le coût : ce que chaque réclamation a coûté en appels au modèle ;
• la latence : le temps écoulé entre la réclamation et le virement.

Le coût et la latence comptaient peu pour un RAG.

Un RAG fait un appel au modèle par question. Un agent en fait des dizaines par tâche :

• un pour comprendre la réclamation ;
• un pour décider de l'étape suivante ;
• un après chaque réponse d'outil ;
• et ainsi de suite.

Ce niveau est indispensable, c'est lui qui mesure le service effectivement rendu. Mais il ne sert à rien pour corriger. Il apprend à l'équipe que des remboursements sont faux, il ne lui dit pas pourquoi.

Niveau 2, trajectoire : le chemin était-il le bon ?

Ici on ouvre le parcours et on regarde comment l'agent s'y est pris. A-t-il appelé les bons outils ? Dans le bon ordre ?

Trois métriques répondent à ces questions :

• La tool correctness (justesse des appels d'outils) vérifie que chaque appel d'outil était le bon, avec les bons paramètres. Dans notre exemple : l'outil de gestion des commandes a-t-il été appelé avec la bonne référence ? C'est ce contrôle qui attrape l'erreur de l'étape 2.
• La trajectory precision (précision de la trajectoire) vérifie que l'agent n'a pas fait d'étapes superflues. A-t-il interrogé trois fois le même outil alors qu'une fois suffisait ?
• Le trajectory recall (couverture de la trajectoire) vérifie qu'il n'a pas sauté d'étape nécessaire. A-t-il bien vérifié les conditions de retour avant d'émettre le virement ?

Ce niveau explique le score du niveau 1.

Niveau 3, composant : quelle pièce a cassé ?

Le dernier niveau descend jusqu'à la pièce fautive : cet outil, cette décision de l'orchestrateur, ce passage de raisonnement du modèle.

Il repose entièrement sur la trace, définie au début de l'article : l'enregistrement horodaté de chaque étape, chaque appel d'outil et chaque décision.

Ce niveau n'existe que si la trace existe. Sans elle, un agent est une boîte noire, et le diagnostic se fait à l'aveugle.

Avec la trace, on rejoue le parcours pas à pas. On voit la requête envoyée à l'outil de gestion à l'étape 2, les deux commandes qu'il a renvoyées, et le choix de la mauvaise.

Le piège : imposer son chemin à un agent

Une fois admis qu'il faut juger la trajectoire, une question se pose. Comment noter un parcours quand il n'existe pas un seul bon chemin, mais plusieurs ?

Le réflexe naturel : une trajectoire de référence

Le réflexe hérité du test logiciel est d'écrire une trajectoire de référence : la séquence exacte d'étapes que l'agent est censé suivre. Ensuite, on compare. L'agent a suivi cette séquence, c'est un succès. Il s'en est écarté, c'est un échec.

Ce réflexe se comprend. C'est le prolongement direct de la ground truth de l'article précédent, où chaque question avait sa réponse de référence. Ici, chaque réclamation aurait son parcours de référence.

Et pourtant, c'est presque toujours une mauvaise idée.

Sur la même réclamation, l'agent a parfois besoin d'un appel à l'outil de gestion, parfois de trois, parce que sa première recherche a renvoyé deux commandes et qu'il a dû trancher. Les deux parcours aboutissent à la bonne commande.

Avec une trajectoire de référence à un seul appel, le second parcours est compté comme un échec. On pénalise l'agent pour avoir levé une ambiguïté, c'est-à-dire pour avoir bien fait son travail.

Plus l'agent a de latitude, plus les parcours légitimes sont nombreux, et plus la trajectoire de référence en rejette à tort.

Si le bon chemin est vraiment unique, si on peut l'écrire à l'avance étape par étape, alors la question n'est plus celle de l'évaluation. C'est un processus à coder en logiciel classique, déterministe, testable comme n'importe quel programme.

Imposer le chemin revient à noter la conformité plutôt que le travail. Et si le chemin peut s'écrire à l'avance, un agent n'est pas nécessaire pour le suivre.

L'approche qui s'impose : décrire le scénario attendu

L'approche qui se généralise prend le problème dans l'autre sens. Au lieu de dire à l'agent par où passer, on décrit le scénario, c'est-à-dire deux choses :

• l'état final attendu : pour notre réclamation, la bonne commande remboursée du bon montant, et un message envoyé au client ;
• les règles à ne jamais enfreindre en chemin, quel que soit le parcours.

La question posée à l'évaluation change alors. Elle passe de « as-tu suivi cette séquence ? » à « as-tu atteint ce résultat sans enfreindre aucune règle ? ».

Un appel ou trois à l'outil de gestion, peu importe, tant que la bonne commande est remboursée et qu'aucune règle n'a été violée.

Ces règles portent un nom : les invariants. Un invariant est une propriété qui doit rester vraie à chaque instant de l'exécution, du début à la fin, quel que soit le chemin emprunté.

Pour notre agent de remboursement, trois invariants viennent immédiatement :

• ne jamais rembourser deux fois la même commande ;
• ne jamais rembourser plus que le montant payé ;
• ne jamais écrire de données personnelles du client dans un journal technique.

L'agent peut inventer mille façons de traiter une réclamation. Aucune des mille n'a le droit de franchir ces trois lignes.

Évaluer un agent, c'est vérifier qu'il atteint le but et qu'il respecte ses invariants, sans se soucier de l'itinéraire.

Concrètement, trois techniques de jugement se partagent le travail

Reste à savoir comment vérifier le résultat, la trajectoire, les composants et le respect des invariants. Aucune technique ne couvre tout, alors on en combine trois, chacune sur le terrain où elle est la meilleure.

Technique 1 : les vérifications déterministes, pour tout ce qui se tranche par oui ou non

Une grande partie de ce qu'on veut vérifier est factuel et binaire.

• Le virement a-t-il été émis une seule fois ?
• Le montant est-il égal au montant payé ?
• L'outil de paiement a-t-il reçu la bonne référence de commande ?

À chaque question, la réponse est oui ou non, et deux personnes qui la vérifient trouveront la même chose.

Pour ces questions, on écrit des assertions : des lignes de code qui affirment une condition et échouent si elle n'est pas remplie. C'est exactement ce que font les tests logiciels classiques depuis toujours.

Les trois invariants de notre agent se traduisent directement en trois assertions.

Ces vérifications sont rapides, donnent toujours le même verdict, et ne laissent aucune place à l'interprétation.

Notre recommandation : confier aux assertions la plus grande part possible du travail, et ne laisser aux deux techniques suivantes que ce qui leur échappe.

Technique 2 : le LLM-as-judge (modèle juge), quand il n'y a pas de réponse binaire

Certaines choses ne se tranchent pas par oui ou non. La stratégie de l'agent était-elle raisonnable ? Le détour qu'il a fait était-il justifié ? Le message au client est-il clair et bien argumenté ? Ici, il faut un jugement.

Le principe est celui du LLM-as-judge vu dans l'article précédent : on demande à un second modèle de langage, distinct de celui qui a fait le travail, de noter ce travail en suivant une grille écrite.

Une différence importante par rapport au RAG : on ne lui soumet plus une réponse de quelques lignes, mais la trace complète d'une exécution, qui peut compter des dizaines d'étapes.

Quand ce juge est lui-même un agent, capable d'aller consulter les données ou de rejouer une étape pour se forger un avis, on parle d'agent-as-judge.

Par exemple, pour vérifier que la bonne commande a été remboursée, le juge peut lui-même interroger l'outil de gestion et comparer.

Ces juges ne sont pas des produits sur étagère. Ce sont des dispositifs d'évaluation que l'équipe construit et calibre elle-même, avec ses propres grilles et ses propres cas.

Les exigences de prudence mentionnées dans l'article précédent s'appliquent ici avec encore plus de force, parce que les traces à juger sont longues, et qu'un juge se perd plus facilement dans quarante étapes que dans quatre lignes. Deux réflexes à garder :

• calibrer le juge sur des cas dont on connaît déjà le verdict, pour vérifier qu'il note comme on le ferait ;
• faire relire par un humain tous les cas où le juge hésite ou surprend.

Technique 3 : la simulation et le rejeu, pour dompter le non-déterminisme

Une exécution réussie ne prouve rien, puisque la suivante pourrait être différente.

La réponse est donc de changer d'unité de mesure. On ne regarde plus une exécution, mais plusieurs.

Concrètement, on simule les interactions :

• on construit des réclamations de test ;
• on les envoie à l'agent des dizaines ou des centaines de fois ;
• on regarde comment se répartissent les résultats.

On lit une distribution, c'est-à-dire une répartition des issues possibles, et non un verdict unique.

La conclusion change alors de forme. Elle passe de « l'agent a réussi le test » à « sur 100 exécutions de ce scénario, l'agent réussit 87 fois, et voici les trois façons dont il échoue les 13 autres fois ».

C'est un changement de culture pour les équipes de test, habituées à un test qui passe ou qui casse.

Quand un défaut apparaît, la trace permet de rejouer la trajectoire depuis l'étape fautive. On reproduit le problème à volonté, on corrige, et on relance la simulation pour vérifier que les 13 échecs ont bien disparu, sans en créer d'autres.

Embarquer ces contrôles en production : les quality gates

Le premier article posait un principe : savoir quoi mesurer sert deux fois.

• Une fois avant la mise en production, pour décider si on peut livrer.
• Une fois pendant que le système tourne, pour surveiller qu'il reste dans les clous.

Avec un agent, ce second usage devient une condition, parce qu'un test réussi ne prouve presque rien.

Le mécanisme : des points de contrôle dans l'exécution elle-même

Le mécanisme consiste à placer les contrôles directement dans le déroulement de l'agent, sous forme de quality gates, littéralement « portes de qualité ». Une gate est un point de passage où l'agent, avant de poursuivre, vérifie qu'il est toujours dans les clous.

La différence avec le test tient à la question posée. En test, la question était « peut-on livrer cette version ? ». En production, elle devient « peut-on continuer cette exécution ? ».

On retrouve dans ces gates la même distinction :

• les gates déterministes posent une question binaire, comme une assertion : l'invariant est-il sur le point d'être violé ? Le montant dépasse-t-il le seuil autorisé ? Cette commande a-t-elle déjà été remboursée ?
• les gates non déterministes s'appuient sur un jugement de modèle : le score de confiance de cette étape est-il anormalement bas ? Cette trajectoire ressemble-t-elle à celles qui échouent d'habitude ?

Dans les deux cas, quand la gate se déclenche, l'effet est le même : l'agent s'interrompt, demande une validation, ou passe la main à une personne. C'est ce qu'on appelle le human-in-the-loop, « l'humain dans la boucle ».

Pour notre agent de remboursement, cela donne par exemple : au-dessus d'un certain montant, l'agent prépare le virement mais ne l'émet pas. Il s'arrête et attend qu'une personne de l'équipe valide. Il traite seul les petits litiges, et escalade les gros.

Deux bénéfices : la gate arrête l'erreur, et indique où l'agent échoue

Le premier bénéfice se voit tout de suite. On n'attend plus de découvrir l'erreur après coup, une fois le virement parti. On l'intercepte pendant l'exécution, avant qu'elle ait des conséquences.

Le second compte autant.

Chaque déclenchement de gate est une information : à quelle étape, sur quel type de réclamation, pour quelle raison. En agrégeant ces déclenchements semaine après semaine, on obtient en continu la carte de ce qui coince réellement en production.

Au bout des trois volets : même boucle, nouvelle unité de mesure

Au terme de cette série, la démarche est restée la même : construire, mesurer, améliorer, généraliser. Ce qui s'est déplacé, c'est l'objet que l'on mesure.

Que la démarche s'applique sur un assistant documentaire ou un agent autonome, on retrouve les mêmes principes : des cas représentatifs, des critères explicites, une mesure rejouée à chaque évolution, et le double usage, valider avant de livrer puis surveiller après.

Sur un agent, le banc d'essai prend la forme d'une simulation continue plutôt que d'un jeu de questions. Mais sa fonction ne change pas. C'est lui qui sépare une démonstration impressionnante d'un système sur lequel une entreprise peut réellement s'appuyer.

Les quality gates ont aussi un coût.

• Chaque gate ajoute du temps et des appels au modèle à chaque exécution.
• Chaque passage à un humain ajoute une attente et du travail pour l'équipe. Sur des milliers de réclamations, cela pèse.

D'où une question à se poser avant de construire l'agent. S'il faut tant de gates, un processus classique, en code déterministe, ferait-il aussi bien pour moins cher ?

La réponse n'est pas toujours en faveur de l'agent. L'évaluation sert aussi à cela : mesurer ce que l'autonomie rapporte, une fois son coût de contrôle compté.

Plus un système gagne en autonomie, plus l'écart se creuse entre ce qu'il paraît faire et ce qu'on a prouvé qu'il fait.

Combler cet écart devient une condition pour lui confier des actions.

Antoine Habert en montre une mise en œuvre outillée dans Tester à l'ère agentique, où chaque règle de comportement d'un agent devient un test exécutable.

Notre conseil : ouvrir ce chantier maintenant, pendant que vos agents sont encore des pilotes.