Un agent peut être disponible et pourtant mal fonctionner
L’observabilité d’un agent IA doit permettre de comprendre non seulement si le système fonctionne, mais ce qu’il fait pour parvenir à son résultat.
Superviser une application a longtemps consisté à répondre à quatre questions : le service est-il disponible ? Quel est son temps de réponse ? Combien d’erreurs produit-il ? Les ressources techniques sont-elles correctement dimensionnées ? Ces indicateurs restent indispensables pour une application fondée sur l’IA générative, mais ils cessent d’être suffisants dès qu’un système devient agentique.
Un agent peut choisir le mauvais outil, multiplier les appels inutiles à un modèle, récupérer un contexte inadapté, répéter une action déjà effectuée ou suivre une trajectoire très différente de celle attendue. Aucun de ces comportements ne lève d’exception, ne modifie le code de retour ni n’allonge nécessairement le temps de réponse. Vu de l’infrastructure, l’exécution s’est parfaitement déroulée.
Anthropic décrit précisément l’origine de cette difficulté : les agents fonctionnent sur plusieurs tours, appellent des outils, modifient un état et adaptent leur comportement aux résultats intermédiaires. Les propriétés qui les rendent utiles (autonomie, intelligence, flexibilité) sont exactement celles qui les rendent plus difficiles à évaluer. Le constat vaut pour la supervision autant que pour l’évaluation : plus un système décide par lui-même, moins son état technique renseigne sur la qualité de ce qu’il produit.
Ce que le monitoring classique ne peut pas voir d’un agent
Le monitoring traditionnel reste la première couche, et elle ne disparaît pas : disponibilité des services, latence, taux d’erreur, consommation processeur et mémoire, santé des API appelées, saturation des files d’attente. Ces signaux disent si la plomberie tient. Ils ne disent rien de ce que l’agent a décidé. Trois objets échappent complètement à cette couche, et ce sont précisément ceux qui déterminent son comportement.
Les appels aux modèles
Un agent n’émet pas un appel de modèle par requête utilisateur, mais un nombre variable d’appels décidé à l’exécution. Savoir quel modèle a répondu conditionne l’interprétation de tout le reste : une même chaîne peut router vers un modèle léger ou vers un modèle avancé selon l’étape, et un changement de version explique souvent une dérive de comportement que rien d’autre ne signale. Le nombre d’appels par exécution est, lui, le meilleur révélateur de boucle : c’est ce compteur qui distingue un agent qui converge d’un agent qui tourne en rond.
Le volume de tokens, séparé entre entrée et sortie, indique où part réellement l’argent ; le contexte étant réinjecté à chaque tour, l’entrée pèse souvent plus lourd que la sortie. La latence se mesure par appel autant que de bout en bout, sans quoi il reste impossible de dire si un agent lent est ralenti par un modèle ou par un outil. Les paramètres enfin (température, prompt système, outils exposés) sont ce qui rend une exécution rejouable : sans eux, un incident cesse d’être reproductible et le diagnostic se réduit à des hypothèses.
Prises ensemble, ces mesures permettent de détecter qu’un agent parfaitement fonctionnel consomme cinq appels de modèle là où deux suffiraient, un écart invisible en supervision technique mais qui pèse directement sur le coût réel d’un agent en production.
Les appels aux outils
Un agent connecté au système d’information interroge un CRM, une base documentaire, une API métier ou un moteur de recherche. Ce qui doit être reconstituable n’est pas la seule liste des outils appelés, mais la boucle complète : quel outil, avec quels paramètres, quel résultat retourné, et quelle décision l’agent a prise ensuite. Ce dernier maillon est le plus important, parce que c’est là que se joue la différence entre un outil qui a mal répondu et un agent qui a mal interprété une bonne réponse. Les deux cas produisent le même symptôme et appellent deux correctifs opposés, l’un sur l’intégration, l’autre sur le prompt ou le choix du modèle.
Anthropic fait de la transparence l’un des trois principes de conception d’un agent : montrer explicitement ses étapes de planification. Utile au moment de la conception, cette visibilité devient une exigence d’exploitation dès que l’agent agit sur des systèmes réels.
La trajectoire
Deux exécutions peuvent produire exactement la même réponse finale en suivant des chemins très différents. L’une passe par deux étapes. L’autre effectue huit appels, rencontre plusieurs erreurs, reprend, et finit par produire la bonne réponse. Du point de vue de l’utilisateur, le résultat est identique. Du point de vue de l’exploitation, ce sont deux systèmes différents : le second coûte plusieurs fois plus cher, répond plus lentement, et surtout n’offre aucune garantie de reproduire ce succès la fois suivante.
Cet enregistrement complet d’une exécution porte plusieurs noms : Anthropic emploie indifféremment transcript, trace ou trajectoirepour désigner le même objet, c’est-à-dire le relevé intégral d’un essai avec ses sorties, ses appels d’outils, son raisonnement, ses résultats intermédiaires et ses autres interactions. Le suivre importe d’autant plus que les erreurs se propagent et se cumulent d’un tour à l’autre : une décision approximative au troisième tour se paie au huitième, et seule la trajectoire permet de remonter du symptôme final à l’étape qui l’a causé.
Les 5 dimensions à superviser
Ces trois objets se combinent avec le monitoring d’infrastructure et avec la mesure de qualité pour former cinq niveaux de lecture d’un même système.
| Dimension | Question à laquelle répondre |
|---|---|
| Infrastructure | Le système est-il disponible et performant ? |
| Modèle | Quels LLM sont appelés, combien de fois et à quel coût ? |
| Outils | Quelles actions l’agent exécute-t-il ? |
| Trajectoire | Comment arrive-t-il à son résultat ? |
| Qualité | Le résultat obtenu est-il réellement correct ? |
La dernière ligne est celle qui manque le plus souvent. Une chaîne peut être disponible, économe et parfaitement tracée tout en produisant des réponses fausses : l’observabilité ne prend son sens qu’une fois reliée à l’évaluation de la qualité. Anthropic résume ainsi la fonction d’une suite d’évaluations : rendre visibles les problèmes et les changements de comportement avant qu’ils n’affectent les utilisateurs. L’exercice ne s’arrête d’ailleurs pas au lancement : les évaluations menées avant la mise en production sont relayées par un suivi de production, chargé de repérer les dérives et les défaillances que le jeu de test n’avait pas anticipées.
Tracer ne signifie pas tout stocker sans discernement
La réaction naturelle, une fois mesuré ce qui manquait, consiste à tout journaliser. C’est une impasse, pour deux raisons de nature différente.
La première tient à la nature des données transportées. Les échanges d’un agent contiennent des données personnelles, des secrets techniques et des informations métier sensibles : jetons d’accès, extraits de dossiers clients, éléments contractuels. Une trace intégrale en crée une copie dans un système d’observabilité rarement soumis au même niveau de contrôle que la base d’origine, souvent accessible à davantage de personnes et parfois hébergé chez un tiers. Le périmètre de la donnée sensible s’élargit sans que personne ne l’ait décidé.
La seconde est opérationnelle. Le stockage a un coût, qui suit le nombre d’exécutions et la taille des contextes transportés plutôt que le nombre d’utilisateurs. Surtout, une trace exhaustive finit par devenir inexploitable : le signal utile se noie dans le bruit, et l’équipe qui cherche la cause d’un incident passe plus de temps à filtrer qu’à comprendre. Tout conserver sans rien pouvoir retrouver produit le même résultat pratique que ne rien conserver.
Une stratégie d’observabilité tranche donc explicitement quatre questions : ce qui est tracé, pourquoi, pendant combien de temps et qui peut y accéder. Les champs sensibles sont masqués ou remplacés par des identifiants au moment de l’écriture, jamais au moment de la lecture.
Une architecture minimale d’observabilité
Pour un agent connecté à des systèmes métier, nous retenons un critère pratique : à partir des seules traces conservées, une personne qui n’assistait pas à l’exécution doit pouvoir la reconstituer du début à la fin, plusieurs semaines après. Cela suppose une chronologie, pas une collection de compteurs.
Elle commence par la demande initiale et par le contexte réellement fourni au modèle. Les deux vont ensemble : sans le contexte, rien ne distingue un agent qui a mal raisonné d’un agent correctement alimenté par une donnée fausse, et c’est cette distinction qui décide si le correctif porte sur le prompt, sur la recherche documentaire ou sur la source elle-même. S’y ajoute l’identifiant du modèle et de sa version, seul moyen d’attribuer une dérive à un changement de modèle plutôt qu’à un changement de code.
Vient ensuite la partie active : les outils sélectionnés, les paramètres des actions importantes et les résultats retournés. Les paramètres font ici la différence entre une trace lisible et une trace inutile. Savoir qu’un agent a appelé une fonction de mise à jour n’apprend rien ; savoir qu’il a modifié tel enregistrement avec telle valeur apprend tout. Les erreurs et les reprises méritent le même traitement que les succès : un agent qui réussit après trois échecs n’est pas un agent qui réussit, c’est un agent fragile, et la trace le signale avant que la fragilité ne devienne un incident.
La chronologie se referme sur la réponse finale, sur le coût et la latence rattachés à l’exécution complète, et sur les éventuelles validations humaines. Ces dernières ne sont pas un détail de conformité : elles indiquent où la responsabilité a changé de mains. C’est ce qui rend la chaîne auditable lorsqu’un agent peut effectuer des actions réelles, et c’est le même socle que celui exigé par les contrôles de sécurité d’un agent connecté au SI.
L’observabilité devient un composant d’architecture
Pour une application traditionnelle, une seule question suffisait à décider d’une mise en production : le système est-il disponible ? Pour un système agentique, elle en recouvre trois.
Le système est-il disponible, produit-il le résultat attendu, et pouvons-nous expliquer son comportement lorsqu’il ne le fait pas ?
La troisième partie de la question est celle qui change la conception. Une sonde de disponibilité s’ajoute après coup à un système existant ; une trajectoire, non. Reconstituer le cheminement d’un agent suppose que l’orchestration ait été instrumentée dès le départ, que chaque exécution porte un identifiant propagé jusqu’aux appels d’outils, et que le format des traces ait été pensé pour alimenter ensuite les évaluations. Ce sont des décisions d’architecture, prises avant l’écriture du premier agent, et l’une des différences les plus coûteuses à rattraper entre un prototype et un système industrialisé.
À retenir
Un agent en production ne se supervise pas comme un service : son état technique ne dit presque rien de la qualité de ses décisions. L’observabilité agentique consiste à pouvoir répondre à trois questions sur n’importe quelle exécution passée : qu’a-t-il fait ? Pourquoi ? Et le résultat était-il conforme à ce que nous attendions ? Tant que ces trois réponses existent, la qualité, le coût et la sécurité restent pilotables. Dès qu’il en manque une, ils deviennent des sujets d’opinion.
