LLM Observability comment surveiller vos agents IA en prod ?

Je surveille un LLM en capturant son contexte, ses traces, ses étapes intermédiaires et ses métriques utiles. Sinon, l’agent peut avoir l’air de marcher tout en inventant n’importe quoi. Le vrai sujet, c’est de transformer ces échecs silencieux en signaux exploitables.

Pourquoi observer un LLM ?

J’observe un LLM parce qu’un modèle peut répondre sans planter techniquement, mais produire une réponse fausse, inventée ou incohérente. C’est ça le piège. Tout a l’air normal côté interface. La requête part, la réponse revient, le temps de réponse est correct, aucun serveur ne tombe. Et pourtant, le contenu peut être mauvais.

Dans un logiciel traditionnel, une erreur se voit souvent assez vite. Une exception remonte. Un timeout bloque l’appel. Une API renvoie un code 500 ou 403. On sait qu’un truc a cassé. Dans un système avec LLM, c’est plus discret. Le modèle peut continuer à parler avec assurance même si une étape avant lui s’est mal passée. Il peut combler les trous, extrapoler, ou inventer une réponse crédible. C’est confortable pour l’utilisateur, mais dangereux pour la prod.

L’observabilité LLM sert à exposer ce qui s’est passé entre la question de l’utilisateur et la réponse finale. Pas juste “le modèle a répondu”. Ça, ce n’est pas suffisant. Je veux voir le chemin complet, surtout quand il y a un agent, des outils, une base documentaire ou une base vectorielle. Une base vectorielle, pour faire simple, c’est un système qui retrouve des documents proches d’une question en comparant leur sens, pas seulement des mots-clés.

Dans un vrai système IA, il faut capturer plusieurs choses pour comprendre ce qui s’est passé :

• La requête utilisateur, avec son contexte.
• Le prompt envoyé au modèle, pas seulement le prompt théorique.
• Les documents récupérés dans la base vectorielle.
• Les appels outils, comme une API CRM, une recherche web ou une base SQL.
• Les décisions intermédiaires de l’agent.
• La réponse finale générée par le modèle.

J’ai vu un cas très classique avec un agent support client. L’utilisateur demande pourquoi sa facture a augmenté. L’agent doit interroger un outil interne pour récupérer l’abonnement, les options activées et l’historique de facturation. Sauf que l’appel outil échoue silencieusement. Pas d’erreur visible côté utilisateur. Le modèle reçoit peu d’informations, récupère un ancien article d’aide dans la base vectorielle, puis répond que l’augmentation vient sûrement d’une option premium. La réponse est fluide, polie, crédible. Mais elle est fausse. Le vrai problème venait d’une remise expirée.

C’est exactement pour ça que je surveille un LLM différemment d’une application classique. Avant de corriger quoi que ce soit, il faut savoir quoi instrumenter.

Que faut il instrumenter ?

J’instrumente d’abord les traces, les spans, les métriques et les intégrations externes, parce que ce sont les signaux qui transforment des logs bruts en informations exploitables.

Une trace, dans un flux LLM, c’est le parcours complet d’une requête. Ça commence à l’entrée utilisateur, ça suit toutes les décisions prises par l’agent, puis ça va jusqu’à la réponse finale. Sans trace, on voit des événements isolés. Avec une trace, on comprend l’histoire.

Un span, c’est une unité de travail à l’intérieur de cette trace. Par exemple une recherche dans une base vectorielle, un appel à une API métier, l’exécution d’un outil, un reranking de documents, ou une génération par le modèle. Chaque span porte ses infos utiles : durée, entrée, sortie, statut, erreur, coût, modèle utilisé, nombre de tokens.

Prenons un agent RAG. RAG veut dire Retrieval Augmented Generation, donc génération augmentée par recherche documentaire. L’utilisateur pose une question. La trace démarre. Premier span : reformulation de la question. Deuxième span : recherche dans la base vectorielle. Troisième span : récupération des documents. Quatrième span : appel au LLM pour générer une réponse avec le contexte. Cinquième span : vérification ou post-traitement. Sixième span : réponse envoyée à l’utilisateur.

Cette hiérarchie change tout en prod. Si la réponse met 12 secondes, je vois tout de suite si le problème vient du modèle, de la base vectorielle ou d’une API externe. Si l’agent répond à côté, je peux remonter au span où les mauvais documents ont été récupérés. Si un outil a renvoyé une donnée incohérente, je le vois dans son span au lieu de fouiller 800 lignes de logs.

Le piège classique, c’est d’empiler des logs en pensant faire de l’observabilité. Ça aide un peu, mais ça ne suffit pas. Il faut relier les événements entre eux pour reconstruire le chemin de décision. C’est là qu’on comprend pourquoi l’agent a fait ce choix, pas juste ce qu’il a affiché à la fin.

Trace	Parcours complet d’une requête utilisateur, de l’entrée à la réponse finale.
Span	Étape précise dans la trace, comme un appel LLM, une recherche vectorielle ou un outil.
Métrique	Mesure agrégée comme latence, taux d’erreur, coût, tokens consommés ou taux de succès.
Intégration externe	Système appelé par l’agent, comme une API, une base de données, un CRM ou un moteur de recherche.

Quelles métriques suivre ?

Je suis quatre familles de métriques pour un LLM en production : la performance système, les ressources et le coût, la qualité de sortie, et la santé des intégrations.

La performance système, c’est ce qui me dit si l’agent répond vite et tient la charge. Je regarde le débit, donc le nombre de requêtes traitées sur une période donnée. Je regarde aussi la latence, c’est-à-dire le temps total entre la demande utilisateur et la réponse complète. Et je surveille le time-to-first-token, le délai avant l’arrivée du premier morceau de réponse. C’est souvent lui qui donne l’impression que “ça rame”, même si la réponse complète arrive ensuite correctement.

Les ressources et le coût, c’est le nerf de la guerre en prod. Je mesure l’usage des tokens en entrée et en sortie. Un token, pour faire simple, c’est un petit morceau de texte que le modèle lit ou génère. Plus il y en a, plus ça coûte. Je suis aussi le coût par exécution, surtout sur les agents qui appellent plusieurs outils ou relancent plusieurs fois le modèle. J’ai déjà vu un agent multiplier ses coûts par trois juste à cause d’une boucle mal maîtrisée. Côté utilisateur, rien ne changeait. Côté facture, si.

La qualité de sortie, c’est plus délicat, mais indispensable. Je regarde la groundedness, autrement dit est-ce que la réponse reste bien ancrée dans les données disponibles. Je regarde aussi la pertinence : est-ce que la réponse est vraiment utile pour la demande. L’objectif est simple : vérifier que l’agent ne répond pas juste avec un texte plausible, mais avec une réponse fiable et adaptée.

La santé des intégrations, c’est tout ce qui vit autour du modèle. API, outils externes, bases vectorielles, CRM, moteur de recherche interne. Je suis le taux de succès et le temps de réponse de ces composants. Une lenteur peut venir du modèle, oui. Mais très souvent, elle vient d’un outil externe qui met deux secondes de trop à répondre.

Famille de métriques	Ce que je mesure	Ce que ça m’aide à comprendre
Performance système	Débit, latence, time-to-first-token	Si l’agent répond vite, tient la charge, ou donne une impression de lenteur
Ressources et coût	Tokens utilisés, coût par exécution	Si un prompt est trop long, si une réponse coûte trop cher, ou si une boucle agentique dérape
Qualité de sortie	Groundedness, pertinence	Si la réponse reste ancrée dans les données disponibles et utile pour la demande
Santé des intégrations	Taux de succès, temps de réponse des API, outils externes et bases vectorielles	Si le problème vient du modèle ou d’un service autour de lui

Ces métriques évitent de tout mettre sur le dos du modèle. Une hallucination peut venir d’une mauvaise récupération d’information. Une lenteur peut venir d’un outil externe. Une hausse de coût peut venir d’un prompt trop long ou d’une boucle agentique mal maîtrisée. Et c’est là que les LLM deviennent particuliers à surveiller, parce que leurs problèmes ne ressemblent pas toujours à des pannes classiques.

Pourquoi c’est plus difficile ?

C’est plus difficile parce qu’un LLM est non déterministe, qu’il produit beaucoup de données non structurées et que la qualité d’une réponse n’est pas toujours facile à mesurer.

Le non-déterminisme, c’est simple à comprendre. Vous envoyez deux fois le même prompt, avec le même contexte, et le modèle peut répondre différemment. Pas forcément n’importe quoi, mais différemment. Une phrase change, une hypothèse apparaît, une étape de raisonnement part ailleurs. Donc quand un utilisateur remonte un bug, vous ne pouvez pas toujours le rejouer proprement comme avec une API classique. C’est frustrant, et c’est souvent là que les équipes découvrent que leurs réflexes de monitoring habituels ne suffisent plus.

Le deuxième sujet, c’est le volume. Un agent IA ne génère pas juste une réponse finale. Il manipule des prompts, des messages utilisateur, des réponses intermédiaires, des appels outils, des résultats de recherche, parfois plusieurs tentatives avant de répondre. Tout ça produit beaucoup de texte. Et ce texte est rarement bien rangé dans une colonne “status = success” ou “status = error”.

Il faut regarder plusieurs signaux en même temps :

• Les conversations complètes, parce qu’une mauvaise réponse peut venir d’un détail donné trois messages avant.
• Les prompts système et les instructions, parce qu’une consigne ambiguë peut créer des comportements bizarres.
• Les appels outils, parce qu’un agent peut donner une mauvaise réponse avec un bon modèle mais une mauvaise donnée récupérée.
• Les réponses finales, parce que c’est ce que voit vraiment l’utilisateur.

Le plus dur reste la qualité. Une réponse peut être grammaticalement parfaite et totalement inutile. Elle peut être pertinente, mais pas fidèle à la source. Elle peut être vraie en général, mais mauvaise pour votre métier. La fidélité à la source, ça veut dire que le modèle ne doit pas inventer au-delà des documents fournis. La qualité métier, c’est encore plus subtil. Chez un client, on avait des réponses “correctes” techniquement, mais inutilisables par les équipes support parce qu’elles ne respectaient pas le ton et les règles internes.

On ne peut donc pas valider un agent une fois pour toutes avec trois exemples propres dans un notebook. Il faut collecter en continu, sur des échanges réels, avec assez de contexte pour comprendre ce qui s’est passé. Les signaux seuls ne règlent rien, bien sûr. La vraie question arrive juste après : comment on s’en sert pour corriger, prioriser et améliorer l’agent sans piloter à l’aveugle.

Comment agir sur les signaux ?

J’agis sur les signaux en intégrant l’observabilité dès la conception, puis en reliant chaque alerte à une décision opérationnelle claire.

L’observabilité ne doit pas arriver à la fin, comme un joli tableau de bord qu’on montre en comité et qu’on n’ouvre plus jamais. Elle doit faire partie de l’architecture de l’agent IA ou de l’application LLM dès le départ. Je veux savoir ce que l’agent fait, pourquoi il le fait, combien ça coûte, combien de temps ça prend, et où ça casse.

La latence compte, bien sûr. Mais elle ne suffit pas. Un agent peut répondre vite et mal. Ou vite, mais en appelant trois outils inutiles. Les KPI vraiment utiles vont plus loin :

• Le taux de réussite des tâches : Est-ce que l’agent atteint vraiment l’objectif demandé ?
• La qualité des réponses : Est-ce que la réponse est correcte, utile, complète, et adaptée au contexte ?
• Le coût par exécution : Combien coûte une demande complète, tokens, outils et appels externes inclus ?
• La fiabilité des intégrations : Est-ce que les API, bases de données, outils métier et connecteurs répondent correctement ?

Le point clé, c’est de passer du signal à l’action. Si le time-to-first-token augmente, c’est-à-dire le délai avant le premier token généré, je regarde les appels au modèle, les outils déclenchés avant la réponse, et les éventuels goulets d’étranglement. Si le coût monte, j’analyse les tokens consommés, les prompts trop longs, les réponses verbeuses et les boucles d’agent qui tournent pour rien.

Si la groundedness baisse, donc si les réponses sont moins bien ancrées dans les sources, je regarde la recherche documentaire, le contexte injecté dans le prompt et les documents réellement utilisés. Si une API externe échoue, je surveille son taux de succès, son temps de réponse, ses erreurs, puis je décide si je mets un retry, un fallback ou une alerte métier.

Chez certains clients, le vrai gain vient moins du dashboard que de la discipline créée autour des signaux. Quand chaque alerte a un propriétaire, un seuil, et une action prévue, l’agent devient beaucoup plus simple à exploiter en prod.

Problème observé	Signal à regarder	Action possible
Réponse trop lente	Time-to-first-token, latence modèle, durée des outils	Optimiser le prompt, réduire les appels outils, changer de modèle
Coût qui augmente	Tokens en entrée et sortie, nombre d’itérations agent	Limiter le contexte, couper les boucles, router vers un modèle moins cher
Réponse moins fiable	Groundedness, sources utilisées, score de récupération documentaire	Améliorer la recherche, filtrer les sources, ajuster le contexte injecté
Échec d’un outil externe	Taux de succès API, temps de réponse, codes d’erreur	Ajouter retry, fallback, cache ou alerte vers l’équipe responsable

Alors on commence par quel signal ?

L’LLM Observability, ce n’est pas juste surveiller si une API répond. C’est comprendre comment une réponse a été fabriquée, où l’agent a cherché, quel outil il a appelé, combien ça a coûté, combien de temps ça a pris et si le résultat tient debout. Je commencerais simple. Traces, spans, métriques de coût, métriques de qualité et santé des intégrations. Puis je relierais chaque signal à une action concrète. C’est comme ça qu’on arrête de subir les hallucinations, les lenteurs et les dérives de coût. Le bénéfice pour vous, c’est un agent IA plus fiable, plus explicable et plus pilotable en production.

FAQ

• Qu’est-ce que l’LLM Observability ?
  L’LLM Observability consiste à suivre ce qui se passe dans une application ou un agent IA entre la requête utilisateur et la réponse finale. Je ne regarde pas seulement si le système répond. Je cherche à comprendre les étapes intermédiaires, les appels outils, les traces, les spans, la latence, les coûts et la qualité de sortie.
• Pourquoi les logs classiques ne suffisent pas pour un LLM ?
  Parce qu’un LLM peut produire une réponse techniquement valide mais fausse sur le fond. Un log classique peut dire que l’appel a réussi, alors que la réponse contient une hallucination ou une erreur logique. Il faut donc capturer le contexte, les étapes de décision et les signaux de qualité.
• Quelle est la différence entre une trace et un span ?
  Une trace représente le parcours complet d’une requête. Un span représente une étape précise dans ce parcours. Par exemple, une recherche dans une base vectorielle, un appel à une API externe ou une génération par le modèle. Cette structure aide à trouver précisément où ça ralentit ou où ça déraille.
• Quelles métriques suivre en priorité ?
  Je suivrais d’abord la latence, le time-to-first-token, l’usage des tokens, le coût par exécution, la pertinence des réponses, la groundedness et la santé des intégrations externes. Ces métriques couvrent les trois problèmes les plus fréquents en production, la lenteur, les hallucinations et les coûts qui montent.
• Quand faut-il intégrer l’observabilité dans un projet IA ?
  Dès la conception. Si on ajoute l’observabilité après coup, on voit souvent les symptômes mais pas les causes. Quand elle est pensée dans l’architecture, chaque appel modèle, outil externe ou étape de recherche peut être relié à une trace exploitable. C’est beaucoup plus simple pour corriger et améliorer l’agent.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent instrumenter proprement leurs données, leurs workflows et leurs systèmes IA, avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous avez besoin de rendre vos agents IA plus observables, plus fiables et plus utiles pour votre business, contactez-moi.