Observabilité des agents IA : pourquoi monitorer l’infrastructure ne suffit plus

Un agent peut être disponible et pourtant mal fonctionner

L’observabilité d’un agent IA consiste à pouvoir répondre, pour n’importe quelle exécution déjà passée en production, à deux questions que le monitoring ne couvre pas : qu’a fait l’agent, et pourquoi l’a-t-il fait ?

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.

Cette proximité entre supervision et évaluation appelle une distinction, qui délimite le périmètre de ce décryptage. Définir ce qu’est une bonne réponse, construire le jeu de cas qui le vérifie et prononcer un verdict avant l’ouverture aux utilisateurs relèvent de la mesure de qualité, que nous traitons à part dans notre méthode pour évaluer une application IA avant sa mise en production. L’observabilité, elle, commence le jour où le système rencontre ses vrais utilisateurs : elle enregistre ce qui s’est réellement passé, signale les écarts avec le comportement habituel et permet de reconstituer, longtemps après, une exécution que personne n’a vue se dérouler. L’une décide ce qui est correct, l’autre observe ce qui se produit et instruit les incidents.

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é.

L’exercice franchit un cap dès que plusieurs agents interviennent sur la même tâche. La trajectoire cesse alors d’être une chronologie unique pour devenir un enchaînement d’exécutions, et retrouver l’origine d’une erreur suppose qu’un identifiant commun circule d’un bout à l’autre, y compris lorsqu’une tâche est déléguée d’un agent à un autre. Sans ce fil, chaque agent produit une trace exacte et personne ne peut expliquer le résultat d’ensemble.

Les 5 dimensions à superviser sur un agent en production

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.

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. C’est aussi la ligne où les deux disciplines se rejoignent sans se confondre : l’évaluation fournit les critères, c’est-à-dire la définition de ce qui compte comme une réponse acceptable, et l’observabilité fournit la matière, c’est-à-dire les exécutions réelles auxquelles ces critères s’appliquent. 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. En production, cette antériorité n’est plus garantie. Un problème peut atteindre un utilisateur avant d’apparaître sur un tableau de bord, et tout se joue alors sur la capacité à le retrouver ensuite dans les traces : c’est cette asymétrie qui rend les deux dispositifs complémentaires plutôt que redondants.

Détecter une dérive quand rien ne tombe en panne

Une dérive ne se détecte pas au franchissement d’un seuil d’erreur, mais à la comparaison d’une période avec la précédente : le comportement d’un agent se déplace sans jamais produire de panne.

Le service reste disponible, les codes de retour restent bons, et pourtant l’agent ne fait plus tout à fait ce qu’il faisait. Une mise à jour de modèle, une modification du prompt système, un outil ajouté, une base documentaire réindexée ou une simple évolution des demandes adressées au système suffisent à déplacer son comportement sans rien casser. Aucun de ces événements ne déclenche d’alerte technique, et plusieurs surviennent sans que l’équipe qui exploite l’agent en soit informée.

La détection repose donc sur la comparaison dans le temps de quelques grandeurs que la trace fournit déjà : le nombre d’appels de modèle par exécution, la longueur des trajectoires, le taux d’échec par outil, la proportion d’exécutions comportant au moins une reprise, le coût médian d’une exécution, la part des demandes transférées à un humain. Aucune de ces valeurs n’a de bon niveau absolu, et chercher le seuil universel est une perte de temps. Ce qui renseigne est l’écart avec le niveau observé la semaine précédente, sur le même type de demandes.

Cette référence doit exister avant qu’on en ait besoin, et être tenue par segment d’usage plutôt que globalement. Une moyenne calculée sur l’ensemble du trafic masque précisément ce que l’on cherche : le cas d’usage minoritaire qui s’est dégradé pendant que la majorité restait stable. Le phénomène est le même que pour la facture, où un total parfaitement stable peut recouvrir un workflow devenu deux fois plus cher.

Une alerte comportementale n’annonce enfin pas une panne à réparer, mais une exécution à ouvrir. Elle n’a de valeur que si l’équipe peut passer rapidement de l’indicateur qui a bougé aux trajectoires qui l’expliquent. Une alerte que personne ne sait instruire subit le sort de toutes les alarmes qui sonnent trop souvent : on finit par la couper.

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é, et il échappe aux garanties négociées sur le trajet réel des données envoyées à un LLM.

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.

Ce qu’une trace doit contenir pour reconstituer une exécution

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. C’est la condition d’un diagnostic mené a posteriori, et elle 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é se décide avant l’écriture du premier agent

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, 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.