Most engineering teams still evaluate AI agents the same way they grade math homework. They look at the final output. If

La plupart des équipes d'ingénierie évaluent encore les agents IA de la même manière qu'elles corrigent un devoir de mathématiques. Elles regardent le résultat final. Si la réponse est correcte, elles donnent le feu vert à la mise en production et passent à autre chose. C'est un raccourci dangereux. Une réponse correcte peut masquer un système profondément défaillant.

La véritable histoire réside dans le chemin emprunté par l'agent pour y parvenir. Ce chemin s'appelle la trajectoire de l'agent. Elle inclut chaque appel d'outil, chaque décision de routage, chaque pause où l'agent s'arrête pour reconsidérer sa position. Vous pouvez l'imaginer comme les miettes de pain laissées par l'agent. Et si vous n'inspectez que la destination, vous passez à côté de tous les signaux d'alerte éparpillés en chemin.

Le problème des trajectoires désordonnées

Un agent peut arriver à la bonne réponse tout en se comportant comme un conducteur ivre. Il dévie vers les mauvais outils, fait demi-tour vers le routeur et s'enferme dans un cycle de raisonnements redondants avant de finir par tomber sur quelque chose de correct. L'utilisateur voit un résultat propre. En coulisses, le système gaspille des ressources et accumule des risques.

À quoi ressemble concrètement ce désordre en pratique ?

Premièrement, il y a l'appel d'outil redondant. L'agent interroge votre base de données client, obtient le résultat, l'oublie cinq secondes plus tard, et interroge à nouveau le même enregistrement avec des paramètres identiques. Ce n'est pas un problème de données. C'est un problème de trajectoire. L'agent n'a pas réussi à conserver l'état, il répète donc le travail.

Ensuite, il y a le schéma du « mauvais outil en premier ». Un agent de codage pourrait tenter de chercher sur le web une définition de fonction qui existe déjà dans le dépôt local. Ou un agent de support pourrait solliciter l'API de facturation alors que la question de l'utilisateur nécessite clairement l'outil de paramètres du compte. Chaque mauvais choix consomme des tokens, ajoute de la latence et augmente le risque de saturer les limites de contexte avant même que le travail réel ne commence.

Les boucles de routage sont un autre signal d'alarme. Le nœud de décision ne parvient pas à se décider. Il envoie la tâche à la branche A, change d'avis, la retire, l'envoie à la branche B, puis la redirige vers un nœud de repli (fallback) générique sans raison. Chaque boucle ajoute un saut réseau et une couche de confusion supplémentaire au futur journal de débogage.

Enfin, il y a l'analyse répétée. L'agent continue de redériver la même conclusion à chaque étape au lieu de la considérer comme acquise. C'est comme un menuisier qui mesurerait la planche dix fois avant chaque coupe. La première mesure était correcte. Les neuf suivantes sont des mouvements inutiles.

Ces étapes supplémentaires ont des conséquences réelles. La latence s'accumule. Dans une interface de chat synchrone, trois secondes de plus semblent une éternité. À grande échelle, ces secondes se traduisent par des milliers de dollars de calcul. Le risque d'échec augmente également. Chaque saut inutile est une chance de plus pour qu'une API externe expire (timeout), qu'une fenêtre de contexte déborde ou qu'une condition de concurrence (race condition) apparaisse. Et quand quelque chose casse, bonne chance pour déboguer une trace qui ressemble à des spaghettis. Vous passerez des heures à reconstruire pourquoi l'agent a effectué la septième étape, pour finalement réaliser que cette septième étape n'aurait jamais dû exister.

Ce que signifie réellement la convergence

Si la trajectoire est le chemin, la convergence est la mesure de son efficacité. La convergence vous indique à quel point l'agent suit le chemin le plus court et viable entre la requête de l'utilisateur et la résolution correcte.

Ce n'est pas la même chose que la précision (accuracy). La précision est un instrument grossier. Elle demande si l'état final est correct. La convergence demande si le voyage était cohérent. Un agent doté d'une précision élevée mais d'une faible convergence est un risque déguisé en succès. Un agent avec une convergence élevée et une précision moyenne est généralement plus facile à corriger, car son raisonnement est propre et ses erreurs sont localisées.

Vous pouvez calculer un score de convergence approximatif en comparant les étapes réellement effectuées par l'agent au chemin le plus court que vous avez défini pour cette classe de tâches. Si une requête de remboursement standard devrait nécessiter exactement trois appels d'outils et que l'agent en a utilisé neuf, votre ratio de convergence en pâtit. Vous pouvez affiner cela en pondérant différents types de gaspillage. Un seul appel d'outil erroné peut coûter plus cher qu'un seul appel redondant, selon la latence et le prix de l'outil. Une boucle de routage qui n'apporte aucune valeur pourrait être la plus lourdement sanctionnée, car elle signale un problème architectural