Un agent qui utilise un grand modèle de langage ne se comporte pas comme un service web classique, et pourtant beaucoup d’équipes le mettent en production avec les seuls outils de surveillance qu’elles utilisaient avant : des logs d’erreur et un contrôle de disponibilité. Cela revient à surveiller la température d’un moteur sans jamais regarder la route.
La différence tient à la nature du système. Une API classique renvoie une réponse déterministe : à entrée identique, sortie identique, et une erreur est un événement binaire. Un agent produit une réponse non déterministe, dont la qualité varie d’un appel à l’autre, et dont les échecs sont souvent silencieux : la réponse arrive, elle est simplement mauvaise.
Cet article décrit ce qu’il faut mettre en place pour surveiller un agent en production : la trace complète, le suivi des coûts et de la latence, et surtout les moyens de détecter une dégradation de qualité avant que vos utilisateurs ne s’en aperçoivent. Ce sont des mécanismes concrets, réutilisables sur n’importe quel agent.
Pourquoi un agent en production ne se surveille pas comme une API classique
La première chose à comprendre est que la panne d’un agent prend rarement la forme d’une exception. Le service répond, avec un code HTTP correct, et la réponse est hors sujet, hallucinée, ou incomplète. Les indicateurs classiques, taux d’erreur et temps de réponse, restent verts pendant que la qualité s’effondre.
À cela s’ajoute la non-reproductibilité. Quand un utilisateur signale une mauvaise réponse, il n’est souvent pas possible de reproduire le problème en rejouant la même requête, parce que le modèle ne donnera pas la même réponse. Sans trace complète, le signalement devient impossible à traiter.
L’observabilité LLM consiste donc à enregistrer bien plus que les erreurs : chaque étape du raisonnement, les entrées et sorties du modèle, les documents récupérés, les outils appelés, les jetons consommés. C’est ce niveau d’enregistrement qui permet, ensuite, de comprendre ce qui s’est passé, et de mesurer la qualité sur la durée.
La trace complète, l’unité de base
L’unité de surveillance d’un agent n’est pas la requête, mais la trace : l’enregistrement structuré de tout ce que l’agent a fait pour produire une réponse. Une trace contient les messages envoyés au modèle, la réponse reçue, les appels d’outils et leurs résultats, les documents récupérés pour un RAG, et les temps de chaque étape.
Ces traces sont la matière première de tout le reste. Elles permettent de rejouer un incident a posteriori, de comprendre pourquoi une réponse a déraillé, et de constituer le jeu de cas sur lequel on évaluera la qualité. Sans elles, vous pilotez à l’aveugle, et chaque mauvaise réponse est un mystère.
Des outils dédiés existent pour capturer ces traces, qu’il s’agisse de bibliothèques d’instrumentation ou de plateformes d’observabilité LLM. L’important n’est pas l’outil mais le contenu : une trace doit contenir les entrées, les sorties, et le chemin complet. C’est un investissement modeste au départ qui devient décisif dès la première panne.
Surveiller les coûts et la latence par requête
Un agent a un coût variable à chaque appel : chaque interaction avec le modèle consomme des jetons, et ces jetons sont facturés. Contrairement à un serveur dont le coût est fixe, le coût d’un agent suit le volume d’usage, et peut dériver rapidement : un prompt qui s’allonge, un agent qui multiplie les tours, une récupération de documents qui s’emballe.
Il faut suivre le coût par requête et la latence par requête, et les regarder ensemble. Une augmentation de la latence est souvent le signe qu’un agent fait plus de tours de modèle qu’avant ; une augmentation du coût, qu’il consomme plus de jetons. Ces signaux sont les premiers à bouger quand un agent commence à se dégrader.
Le suivi doit descendre au niveau de chaque étape de la trace, pas seulement au niveau de la requête complète. C’est ce qui permet de voir, par exemple, que le coût explose spécifiquement sur les requêtes qui passent par un certain outil. On corrige alors ce point précis au lieu de chercher partout.
Détecter la dégradation de qualité, pas seulement les erreurs
Le défi central de l’observabilité LLM est de mesurer la qualité, alors que la qualité d’une réponse libre ne se mesure pas avec un simple seuil. La réponse à une question d’un utilisateur est-elle bonne ? La seule façon rigoureuse de le savoir est de la faire juger, et ce jugement doit être automatisé pour passer à l’échelle.
Deux familles de méthodes se complètent. La première utilise des évaluations à base de modèle : un autre modèle, ou le même, juge la réponse selon des critères prédéfinis. La seconde utilise des règles : la réponse cite-t-elle les bonnes sources, respecte-t-elle un format, contient-elle des éléments interdits. Aucune n’est parfaite, mais combinées elles donnent un signal exploitable.
L’objectif n’est pas d’obtenir une note exacte pour chaque réponse, mais de suivre la tendance. Un taux de réponses jugées bonnes qui passe de 85 % à 70 % en une semaine est un signal d’alerte, même si la note de chaque réponse est discutable. C’est la dérive qu’il faut détecter, et elle se voit dans les agrégats.
Les évaluations en continu sur les cas réels
Pour que la mesure de qualité soit fiable, elle doit porter sur un échantillon stable de cas réels, et être exécutée en continu, pas seulement au moment du développement. Un agent se dégrade souvent de façon insidieuse, au fil de changements de modèle, de prompt ou de sources de données.
La méthode consiste à maintenir un jeu d’évaluation : un ensemble de cas représentatifs, avec pour chacun la réponse attendue ou les critères de réussite. Ce jeu est exécuté à chaque changement, et régulièrement en production sur un échantillon des traces réelles. Toute baisse sur le jeu d’évaluation bloque le déploiement.
Ce mécanisme transforme la qualité d’une intuition en un processus vérifiable. Il est particulièrement utile dans les systèmes RAG, où une modification du découpage des documents ou de la stratégie de récupération peut améliorer un cas et en dégrader dix autres. Sans jeu d’évaluation, ces régressions passent inaperçues.
Ce qu’il faut brancher dès le premier jour
Beaucoup d’équipes repoussent la surveillance au lendemain du lancement, en se disant qu’elles brancheront tout cela quand le produit sera stabilisé. C’est une erreur : c’est précisément dans les premières semaines, quand le comportement du système est le plus imprévisible, que la surveillance est la plus utile.
Le minimum à mettre en place avant la mise en production tient en quatre éléments : la capture des traces complètes, le suivi du coût et de la latence par requête, un jeu d’évaluation exécuté en continu, et une alerte sur les dérives. Ces quatre éléments ne demandent pas un outillage lourd, et ils couvrent l’essentiel des incidents réels.
Tout ce qui vient ensuite, tableaux de bord élaborés, évaluations fines, rejeu d’incidents, s’appuie sur ces fondations. Ce qu’il faut retenir est simple : la qualité d’un agent est une grandeur qu’on mesure, pas une impression qu’on a.
L’accompagnement Agenticiel pour monitorer votre agent
Mettre en place l’observabilité d’un agent demande à la fois de connaître les outils d’instrumentation et de savoir quoi mesurer pour que la surveillance ait un sens métier. C’est un travail que nous réalisons pour des équipes qui veulent passer un agent en production sans perdre la main sur sa qualité.
Agenticiel intervient comme sous-traitant de développement : capture des traces, mise en place du jeu d’évaluation, alertes sur les dérives de coût et de qualité. L’équipe est composée de développeurs offshore francophones basés à Madagascar, ce qui permet de réduire le coût de ce type de chantier tout en conservant une communication directe, dans votre langue et sur votre fuseau.
Notre approche consiste à faire de l’observabilité un prérequis de la mise en production, pas une amélioration ultérieure : un agent qu’on ne peut pas mesurer est un agent qu’on ne peut pas exploiter.