La bonne réponse par le mauvais chemin : évaluer la trajectoire d'un agent IA

---

title: "La bonne réponse par le mauvais chemin : évaluer la trajectoire d'un agent IA" seoTitle: "Évaluer la trajectoire d'un agent IA" description: "Un agent peut rendre la bonne réponse en interrogeant le mauvais système et en brûlant dix appels d'outils. Ce qu'un décideur doit noter dans le chemin, et pas seulement dans la sortie." seoDescription: "Un agent IA peut donner la bonne réponse par le mauvais chemin : coût par trajectoire, non-déterminisme et réussite par accident." date: "2026-10-09" author: "Équipe Raicode" tags: ["IA", "automatisation", "architecture", "qualité"] category: "IA & Automatisation" keywords: ["évaluer un agent IA", "trajectoire agent IA", "appels d'outils LLM", "coût par trajectoire", "non-déterminisme LLM", "recette agent IA", "auditer un agent livré", "évaluation agent sans plateforme", "agent IA prestataire"]

La recette s'est bien passée. Le prestataire a déroulé trente demandes devant vous, l'agent a rendu vingt-huit réponses justes, et le tableau de résultats qui accompagne la livraison affiche 93 % de réussite. Six semaines plus tard, la facture d'API est quatre fois supérieure à l'estimation, un commercial a reçu une réponse construite sur les tarifs de l'année dernière, et personne ne sait dire pourquoi : la réponse était bonne en recette, elle l'est encore la plupart du temps, et pourtant quelque chose ne va pas.

Ce qui n'allait pas était visible dès le premier jour, mais pas à l'endroit où vous regardiez. Sur l'une des demandes de la recette, l'agent avait donné la bonne réponse après onze appels d'outils, dont sept inutiles, et en interrogeant l'export CSV d'un ancien ERP plutôt que la base de facturation. La sortie était juste. Le chemin était faux. Et c'est le chemin qui se reproduit en production, pas la sortie.

Cet article s'adresse à qui doit juger un agent livré par quelqu'un d'autre : un CTO qui prend la recette, un chef de produit qui arbitre une mise en ligne, un founder qui a sous-traité une brique IA et doit décider s'il l'accepte. Pas à l'ingénieur qui instrumente son propre agent — c'est un autre métier, et un autre article.

Pourquoi un taux de réussite entrée-sortie ne suffit pas

Le réflexe naturel, quand on évalue un agent, est de constituer un jeu de cas avec une réponse attendue et de compter les succès. C'est déjà beaucoup mieux que la démo, et c'est le point de départ que nous avons détaillé dans notre méthode de construction d'un jeu d'évaluation. Mais cette mesure a un angle mort structurel : elle compare deux points, l'entrée et la sortie, et ignore tout ce qui s'est passé entre les deux.

Or entre les deux, un agent fait des choses. Il choisit un outil, construit des arguments, lit un résultat, décide de recommencer, interroge un deuxième système, écrit parfois dans une base. Cette séquence — les appels d'outils, leurs paramètres, leurs retours, et les décisions prises entre chacun — c'est ce qu'on appelle la trajectoire. Un agent se définit par le fait qu'il la construit lui-même, au moment de l'exécution. Si vous aviez écrit la séquence à l'avance, vous auriez un enchaînement déterministe qui appelle un LLM, pas un agent, et vous n'auriez pas ce problème.

Trois classes de défauts vivent entièrement dans la trajectoire et sont invisibles depuis la sortie :

• les chemins coûteux, qui donnent la bonne réponse mais multiplient la facture ;
• les chemins dangereux, qui passent par le mauvais système, ou qui écrivent quelque part sans que ce soit prévu ;
• les chemins fragiles, qui réussissent pour une raison qui ne tiendra pas la semaine prochaine.

Aucune de ces trois ne fait baisser le taux de réussite de la recette. Les trois arrivent en production.

Ce qu'il faut exiger à la livraison

Vous ne pouvez pas noter une trajectoire que vous ne voyez pas. Avant toute discussion de barème, la question à poser au prestataire est très concrète : pour chacun des cas de recette, fournissez l'enregistrement complet de ce que l'agent a fait. Pas les logs applicatifs, pas une capture d'écran de la conversation : la liste ordonnée des appels d'outils, avec pour chacun le nom de l'outil, les arguments envoyés, le retour reçu (ou l'erreur), le nombre de tokens consommés et la durée.

Si cette demande provoque un silence gêné, vous venez d'apprendre quelque chose d'important sur la livraison, et le sujet n'est plus l'évaluation mais la reprise. Un agent dont on ne peut pas rejouer les décisions ne s'exploite pas : il se subit. C'est précisément le point de départ d'une reprise de projet IA, où la première semaine consiste souvent à rendre lisible ce que le code fait réellement avant d'avoir le droit d'en juger la qualité.

Deux précisions sur le périmètre, pour ne pas confondre deux moments distincts. Ce dont il est question ici, c'est de l'enregistrement des cas de recette, obtenu une fois, avant la décision d'accepter. La question de l'instrumentation permanente, des seuils qui déclenchent une alerte et du retour arrière quand l'agent se dégrade est un autre chantier, qui commence le jour de la mise en ligne et que nous avons traité dans l'article sur l'exploitation d'un agent en production. Ici, on cherche seulement à savoir si l'on signe.

Trois défauts que seule la trajectoire révèle

Le coût ne se mesure pas par requête, mais par trajectoire

L'estimation budgétaire d'un agent est presque toujours construite à partir d'un appel modèle moyen : tant de tokens en entrée, tant en sortie, multiplié par le volume mensuel. Cette arithmétique est fausse d'un facteur qui se situe couramment entre 3 et 10, parce qu'une demande utilisateur ne déclenche pas un appel modèle, mais une trajectoire entière.

Prenons un cas réel de support technique. La trajectoire courte : l'agent reformule la demande, interroge la base de connaissance, rédige. Trois appels modèle, environ 4 000 tokens cumulés. La trajectoire longue, sur la même catégorie de demande : l'agent interroge la base, ne trouve pas, reformule sa requête, interroge à nouveau, élargit, récupère huit documents dont six hors sujet qu'il renvoie intégralement au modèle au tour suivant, puis vérifie une information dans un second système. Onze appels, 38 000 tokens, parce que chaque tour réinjecte tout l'historique précédent — la fenêtre de contexte grossit à chaque pas, et c'est elle qu'on paie.

À 12 000 demandes par mois, la différence entre un parc de trajectoires courtes et un parc de trajectoires longues se chiffre en centaines d'euros par mois sur un petit produit, en milliers dès qu'on monte en volume. Et la moyenne ment : ce qu'il faut regarder, c'est la médiane et le 90e centile du nombre d'appels d'outils par demande. Un agent à 3 appels de médiane et 14 au 90e centile n'a pas un problème de coût moyen, il a une catégorie de demandes qui part en boucle, et vous la trouverez en triant vos cas de recette par nombre d'appels décroissant. C'est le même raisonnement que celui qui s'applique quand une facture d'API LLM explose en production, à ceci près qu'ici vous pouvez encore le constater avant de signer.

Le non-déterminisme : le même cas, dix fois

Une trajectoire n'est pas reproductible. Deux exécutions de la même demande, avec le même prompt et le même modèle, peuvent emprunter des chemins différents — et c'est le défaut le plus systématiquement ignoré en recette, parce qu'une recette se déroule une fois.

Le test tient en une ligne : rejouez dix fois chacun de vos cinq cas les plus sensibles, et comparez les trajectoires. Sur les agents que nous auditons, il n'est pas rare d'obtenir cinq ou six trajectoires distinctes pour dix exécutions du même cas, et une ou deux réponses fausses là où la recette en avait validé une bonne. Le taux de réussite que vous a présenté le prestataire est donc un tirage, pas une mesure.

Toute variance n'a pas la même gravité, et c'est là que la lecture du chemin devient utile. Il faut séparer :

• la variance de surface : l'agent appelle les deux mêmes outils dans un ordre différent, le résultat est identique. Sans conséquence, hormis sur la durée.
• la variance décisionnelle : l'agent choisit un autre outil, ou s'arrête après deux appels au lieu de quatre. Là, le résultat dépend du tirage, et un cas « validé » peut échouer en clientèle sans que rien n'ait changé dans le système.

Une variance décisionnelle sur un cas sensible n'est pas un défaut de qualité à améliorer plus tard : c'est un signal que le périmètre donné à l'agent est trop large pour la tâche, et qu'une partie de la décision doit être sortie du modèle et remise dans du code.

L'agent qui réussit par accident

Le cas le plus désagréable est celui où la bonne réponse ne vient pas d'où l'on croit. L'agent interroge un index documentaire, la récupération ne rend rien d'utile — ou l'outil renvoie une erreur que personne ne lit — et le modèle rédige quand même une réponse exacte, parce que l'information se trouvait dans le prompt système, dans un exemple, ou tout simplement dans ce qu'il a appris à l'entraînement. Le cas passe au vert. L'évaluation enregistre un succès. Et le jour où la question porte sur votre tarif de novembre, qui n'existe nulle part ailleurs que dans votre base, la même mécanique produit une réponse également assurée, et fausse.

Il existe un test simple, et il se fait en une demi-journée : cassez l'outil exprès. Videz l'index, coupez l'accès à la base, faites renvoyer une liste vide à la fonction de recherche, puis rejouez vos cas.

• La réponse reste bonne : le résultat ne venait pas de vos données. Le cas ne prouve rien sur la qualité de la récupération, et il faut le réécrire autour d'une information que le modèle ne peut pas connaître.
• La réponse devient une invention présentée avec le même aplomb : l'agent n'a aucune gestion de l'échec de ses outils. C'est un défaut bloquant, et il se corrige côté code, pas côté prompt.
• L'agent dit qu'il n'a pas l'information : c'est le comportement attendu, et c'est rare à la première recette.

Ce test recoupe en partie le diagnostic d'une récupération documentaire qui répond à côté, mais il s'en distingue par son objet : on ne cherche pas à améliorer la pertinence, on cherche à savoir si les bonnes réponses de la recette reposent réellement sur le système qu'on a payé.

Noter un chemin sans acheter de plateforme

Les outils d'évaluation d'agents du marché savent faire tout cela, et bien davantage. Pour une décision de recette, ils ne sont pas nécessaires : vingt-cinq cas, les enregistrements de trajectoires, un tableur et deux jours suffisent à produire un verdict défendable.

Quatre notes par trajectoire, chacune lisible par quelqu'un qui n'écrit pas de code :

| Note | Question | Barème | | --- | --- | --- | | Atteinte | La réponse finale est-elle juste et exploitable ? | oui / non | | Justesse du chemin | Chaque appel d'outil était-il nécessaire, et le bon système a-t-il été interrogé ? | 0 appel inutile / 1 à 2 / plus de 2 | | Coût | Nombre d'appels d'outils et tokens cumulés | valeur brute, comparée à la médiane | | Effets de bord | L'agent a-t-il écrit, envoyé ou déclenché quelque chose hors du périmètre prévu ? | aucun / à vérifier / oui |

La quatrième ligne est celle qu'on oublie, et la seule qui puisse coûter un client : un agent qui envoie un e-mail, modifie une fiche ou crée un ticket au milieu d'une trajectoire fait une chose irréversible sur une décision non déterministe. Si la colonne « effets de bord » n'est pas vide sur vos cas de recette, le sujet passe avant tous les autres.

La notation du chemin demande un jugement humain sur la première passe. C'est volontaire : vous cherchez moins un score qu'une liste de chemins anormaux à montrer au prestataire. Vingt-cinq cas se notent en une journée à deux, et c'est à cette occasion qu'on découvre les deux ou trois schémas qui expliquent la majorité des dérives.

Ce qu'on fait du résultat

Un rapport de trajectoires ne sert que s'il débouche sur l'une de trois décisions, et il vaut mieux les avoir écrites dans le contrat de recette avant de lancer l'évaluation.

Accepter, quand les trajectoires anormales sont rares, sans effet de bord, et que la dispersion du coût reste contenue. Les critères chiffrés qui tiennent en recette sont peu nombreux : un 90e centile d'appels d'outils qui ne dépasse pas le double de la médiane, zéro effet de bord non prévu, et une stabilité décisionnelle sur les cas sensibles rejoués dix fois.

Corriger avant mise en ligne, quand le défaut est un chemin et pas une intelligence. La plupart des trajectoires longues se règlent en réduisant le périmètre : moins d'outils exposés, des descriptions d'outils plus strictes, un plafond d'itérations, et le déplacement d'une décision du modèle vers du code ordinaire. Ce sont des corrections de quelques jours, pas une réécriture.

Refuser, quand l'agent réussit par accident sur une part significative des cas, ou qu'il écrit dans vos systèmes sur des décisions non reproductibles. Ce n'est pas une question de maturité du modèle : c'est une architecture qui ne deviendra pas sûre en attendant.

Par où commencer

Si vous avez un agent en attente de recette, la semaine se découpe sans difficulté. Un jour pour obtenir et lire les enregistrements de trajectoires — et, s'il n'y en a pas, pour traiter ce manque comme le premier constat du rapport. Un jour pour constituer vingt-cinq cas dont cinq sensibles, et les rejouer dix fois chacun. Une demi-journée pour le test de l'outil cassé. Un jour pour noter les quatre colonnes et trier par nombre d'appels décroissant. Une demi-journée pour écrire les trois ou quatre schémas anormaux et la décision qui en découle.

Au bout de cette semaine, vous ne saurez pas si l'agent est bon. Vous saurez s'il est bon pour une raison qui tiendra, ce qui est la seule question qui se pose avant de le mettre devant des clients.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.