Observabilité LLM : monitorer un agent en production

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.

Voici 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 la détection d’une dégradation de qualité avant que vos utilisateurs ne s’en aperçoivent.

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. On détaille ce qu’il faut y mettre dans notre article sur les logs et traces d’un agent.

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 : Langfuse, open source et auto-hébergeable, LangSmith, très intégré à LangChain et LangGraph, ou une instrumentation OpenTelemetry qui alimente vos outils existants comme Datadog ou Grafana (on les passe en revue dans notre comparatif des outils d’évaluation d’agents). L’important n’est pas l’outil mais le contenu : une trace doit contenir les entrées, les sorties, et le chemin complet.

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. Langfuse et LangSmith calculent ce coût automatiquement à partir des tokens et du tarif de chaque modèle. 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. Combinées, elles donnent un signal exploitable. Ragas (pour un RAG) et DeepEval fournissent des évaluateurs prêts à l’emploi, que Langfuse peut appliquer à un échantillon des traces de production.

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. Pour transformer ces tendances en seuils d’alerte, la logique des SLO appliqués à un service IA est un bon cadre.

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, par exemple avec Promptfoo dans GitHub Actions, 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.

Tableaux de bord élaborés, évaluations fines, rejeu d’incidents : tout le reste s’appuie sur ces fondations.

En pratique : monitorer votre agent

Sur les agents qu’on met en production, ces quatre briques (traces, coût et latence par étape, jeu d’évaluation, alertes de dérive) sont branchées avant le lancement, pas après le premier incident.

Si votre agent tourne déjà sans cette visibilité, ou si vous préparez sa mise en production, notre méthode décrit comment on outille les evals, la CI/CD et les garde-fous pour que la qualité reste une grandeur mesurée, semaine après semaine.