Mon agent a appelé la même API en échec 5 fois — le bug n'était pas dans le code

Un bug en production. Mon agent répétait le même appel API cinq fois de suite. Par réflexe, j’ai ouvert le code. La logique de retry était correcte. Le flux des fonctions, normal. Aucune erreur dans les logs.

Le code n’avait rien à dire. Ce n’est qu’en ouvrant la trace que la cause est devenue visible.

Le code d’un agent est une coquille vide

Ouvrez le code source de n’importe quel agent : vous trouverez une spécification de modèle, une liste d’outils, et un prompt système. C’est à peu près tout. Quel outil appeler et quand, quelle séquence de raisonnement suivre — rien de tout ça ne se trouve dans le code.

Les équipes qui font tourner des agents sous LangGraph disent toutes la même chose : « On ne peut pas juger la qualité d’un agent par une revue de code. »

• Même code, même entrée, schémas d’appels d’outils différents à chaque fois
• Contrairement à une fonction comme handleSubmit(), la logique de branchement n’existe tout simplement pas dans le code
• Tester GPT-5.2 dix fois avec la même requête donne environ 40 % de cohérence dans l’ordre des appels d’outils
• Quand une erreur survient, il n’y a pas de bug dans le code — ce qui rend la reproduction impossible

C’est le changement fondamental. Dans le logiciel traditionnel, le code est le comportement. Dans un agent, le code n’est que l’échafaudage. Le comportement réel émerge à l’exécution, façonné par le raisonnement du modèle sur le contexte qu’il reçoit.

Les traces sont le nouveau code source

Une trace enregistre chaque pas de l’agent. Ce qu’il a raisonné à chaque étape, quel outil il a appelé et pourquoi — tout est capturé. Le débogage, les tests, l’analyse de performance qu’on faisait autrefois dans le code doivent maintenant se faire dans les traces.

Quand un agent voit un message d’erreur et répète quand même le même appel, ce n’est pas un bug dans le code. C’est un échec de raisonnement. Et on ne peut le voir que dans la trace.

• Comparer les traces avant et après un changement de prompt révèle instantanément les différences de qualité du raisonnement
• Dans LangSmith, charger une trace depuis un point précis dans le playground fonctionne comme poser un point d’arrêt
• Une seule trace peut montrer l’exact moment où le raisonnement de l’agent a déraillé — quelque chose qu’aucun volume de logs ne peut reproduire

Voyez-le ainsi : déboguer du code classique, c’est relire une recette pour trouver l’erreur. Déboguer un agent, c’est regarder les images de la caméra de cuisine pour voir où le chef a raté son geste. La recette est peut-être parfaite. C’est l’exécution qui s’est détraquée.

Les tests changent radicalement

Dans le logiciel traditionnel, on teste avant le déploiement et c’est réglé. Les agents sont non-déterministes : il faut continuer à les évaluer en production.

Sans un pipeline qui collecte des traces, construit des jeux de données d’évaluation et détecte les dégradations ou les dérives de qualité, il est simplement impossible de faire tourner des agents à l’échelle.

Les équipes qui ont adopté l’évaluation par traces constatent des améliorations mesurables dans les taux de succès des tâches. Le schéma est constant : les traces révèlent des modes d’échec qu’aucune suite de tests pré-déploiement ne pouvait prédire.

• Mettre en place un pipeline d’évaluation automatisé qui échantillonne les traces de production chaque semaine
• Les tests pré-déploiement seuls ne peuvent pas garantir la qualité d’un système non-déterministe
• Monitorer sans traces, c’est uniquement vérifier si le serveur tourne
• Un agent peut être « en fonctionnement normal » tout en exécutant des tâches complètement à côté — seules les traces le détectent

La collaboration et l’analyse produit passent aussi par les traces

La revue de code se fait sur GitHub. Mais où se fait la revue du jugement d’un agent ?

Les plateformes d’observabilité prennent ce rôle. Les équipes commentent des traces, partagent des points de décision précis, et examinent le raisonnement de l’agent comme elles examinaient autrefois des pull requests. Le modèle de collaboration lui-même est en train de changer.

L’analyse produit suit le même schéma. Quand une métrique indique que « 30 % des utilisateurs sont insatisfaits », il est impossible d’en trouver la cause sans ouvrir les traces. L’agent a peut-être accompli les tâches avec succès selon ses propres critères, tout en passant complètement à côté de ce que l’utilisateur voulait vraiment.

• Des outils comme Mixpanel et les outils de débogage convergent vers les traces comme substrat commun
• Analyser les schémas d’appels d’outils permet de faire remonter les fonctionnalités que les utilisateurs cherchent réellement

En résumé

À l’ère des agents, le code est le plan de construction et les traces sont les images de la caméra de surveillance. Quand quelque chose cloche dans le bâtiment, on ne déplie pas d’abord le plan — on rembobine les images.

Les équipes qui maîtrisent la qualité de leurs agents sont celles qui ont déplacé leur centre de gravité du code vers les traces. Non pas parce que le code n’a pas d’importance, mais parce que les vrais échecs — ceux qui vous coûtent des utilisateurs et de l’argent — se trouvent dans le comportement à l’exécution, que seules les traces capturent.