Comment réussir son LLM observability en prod ?

Réussir son LLM observability, c’est tracer les décisions, pas juste compter les erreurs. Un agent IA peut répondre vite et quand même raconter n’importe quoi. Je vais poser ce qu’il faut instrumenter, quelles métriques suivre, et comment agir quand ça dérape.

Pourquoi le monitoring ne suffit pas ?

Le monitoring ne suffit pas parce qu’il voit surtout ce qui casse en surface. Il mesure les erreurs, la latence, le débit, les timeouts, la disponibilité. C’est utile, je ne remets pas ça en question. Mais avec un LLM, le problème le plus dangereux, c’est souvent que tout a l’air de marcher.

Un logiciel classique échoue souvent de façon visible. Une API renvoie une 500. Une base ne répond plus. Un batch plante. Là, on sait qu’il y a un incident. Un LLM, lui, peut répondre en 800 ms, avec un statut 200, sans erreur technique, et pourtant sortir une réponse fausse, incohérente ou complètement hallucinée. C’est ça le vrai piège.

L’observabilité LLM doit donc aller plus loin que les métriques système. Elle doit aider à comprendre pourquoi le modèle a répondu ça. Pas juste constater qu’il a répondu. Pour y arriver, il faut pouvoir reconstruire toute la chaîne de décision :

• Le prompt utilisateur envoyé au départ.
• Le contexte injecté dans le prompt, souvent via du RAG, c’est-à-dire de la récupération documentaire avant génération.
• Les résultats de recherche vectorielle utilisés pour retrouver les bons documents.
• Les outils appelés, comme une API CRM, un moteur de pricing ou une base interne.
• Les réponses intermédiaires produites par le modèle.
• La sortie finale renvoyée à l’utilisateur.

C’est encore plus vrai avec les agents IA en production. Un agent ne fait pas juste une réponse. Il planifie, appelle des outils, interprète des résultats, choisit une prochaine action, parfois sur plusieurs étapes. L’erreur peut venir du modèle, mais aussi d’un outil externe qui renvoie une donnée ambiguë, d’une mauvaise récupération documentaire, ou d’une logique d’orchestration qui pousse l’agent dans la mauvaise direction.

Chez certains clients, le vrai problème n’était pas la latence. Les temps de réponse étaient corrects. Le vrai sujet, c’était l’impossibilité de savoir à quel moment l’agent avait pris la mauvaise direction. Et sans cette trace, on finit par débattre au feeling. Le modèle ? Le prompt ? Le RAG ? L’outil ? Personne ne sait vraiment.

Avant de corriger, il faut donc savoir quelles données capturer. Sinon, on pilote un système probabiliste avec des logs pensés pour du logiciel déterministe. Et là, on se raconte vite des histoires.

Quelles données faut-il instrumenter ?

Il faut instrumenter les traces, les spans, les métriques et les logs structurés, mais seulement ceux qui aident vraiment à diagnostiquer une réponse. Pas besoin de tout aspirer “au cas où”. C’est souvent comme ça qu’on finit avec un lac de logs inutilisable, cher, et que personne ne consulte.

Une trace, c’est la requête complète. Elle démarre au message utilisateur et elle va jusqu’à la réponse finale. Un span, c’est une opération précise à l’intérieur de cette trace. Par exemple un appel au LLM, une recherche dans une base vectorielle, un appel API, un outil déclenché, une étape de raisonnement ou la génération de la réponse.

C’est exactement la logique derrière des standards comme OpenTelemetry. OpenTelemetry, c’est un standard open source pour collecter et structurer les données d’observabilité. Il repose beaucoup sur cette idée de traces, spans et métriques. Et franchement, ça change tout. On passe d’un tas de logs illisibles à une lecture propre de ce qui s’est passé, dans quel ordre, avec quelle durée, et où ça a cassé.

Dans une application LLM en prod, je capture en général ces informations :

• Identifiant de session ou de conversation, pour suivre le parcours sans mélanger les utilisateurs.
• Modèle utilisé, parce qu’un changement de modèle peut changer complètement le comportement.
• Version du prompt, indispensable quand on teste plusieurs variantes.
• Paramètres du modèle, comme la température, le nombre maximal de tokens ou le mode de génération.
• Documents récupérés dans le RAG, avec leurs scores si possible.
• Outils appelés, leurs entrées, leurs sorties et leurs erreurs.
• Temps de réponse, coût estimé, nombre de tokens consommés.
• Entrées et sorties intermédiaires quand elles aident vraiment à comprendre le résultat.

Le point sensible, c’est la donnée personnelle. Tracer une conversation, ce n’est pas copier toute la vie de l’utilisateur dans un outil d’observabilité. Je filtre, j’anonymise ou je minimise dès que possible. Parfois, garder un hash, un identifiant technique ou un extrait tronqué suffit largement pour diagnostiquer.

Trace	Suit la requête complète, du message utilisateur à la réponse finale.
Span	Isole une opération précise, comme un appel LLM, un outil ou une recherche vectorielle.
Métrique	Mesure un indicateur agrégé, comme la latence, le taux d’erreur, le coût ou les tokens.
Log structuré	Ajoute un événement lisible et exploitable, avec des champs propres au lieu d’un texte libre.

Quelles métriques suivre en priorité ?

Je suivrais quatre familles de métriques, pas une liste infinie de dashboards. En prod, le piège c’est de tout mesurer et de ne plus rien regarder. Moi je veux savoir vite si le problème vient du modèle, du coût, d’un outil externe ou de la qualité de réponse.

Première famille : la performance système. Je regarde le throughput, donc le nombre de requêtes traitées sur une période donnée. Je regarde aussi la latence totale, c’est le temps entre la demande utilisateur et la réponse complète. Et surtout, je suis le time to first token, le délai avant que le premier morceau de réponse arrive.

Le time to first token est clé quand la réponse est streamée, c’est-à-dire affichée petit à petit. Même si la réponse complète prend 8 secondes, l’utilisateur peut avoir une bonne impression si le premier mot arrive en 700 millisecondes. À l’inverse, 4 secondes de silence, ça donne l’impression que l’agent est planté.

Deuxième famille : les ressources et le coût. Là, je suis les tokens en entrée, les tokens en sortie, le coût par exécution, puis le coût par utilisateur ou par tâche. 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 cher.

• Un agent peut être très utile, mais exploser le budget s’il appelle le modèle 12 fois pour une tâche simple.
• Un workflow peut devenir cher s’il interroge trop d’outils externes ou récupère trop de contexte inutile.
• Un client m’a déjà montré un assistant “rentable” en apparence, sauf qu’une demande sur trois coûtait plus cher que la marge du service vendu. Ça calme vite.

Troisième famille : la qualité de sortie. Je mesure la pertinence, la groundedness, la cohérence avec les sources et le taux de réussite de tâche. La groundedness, c’est simplement le fait que la réponse soit bien ancrée dans les documents ou données disponibles, au lieu d’inventer.

Ces métriques sont plus compliquées que la latence. Une latence, c’est un chiffre. La qualité, c’est du langage naturel, du contexte, parfois une appréciation subjective. Il faut souvent combiner des évaluations automatiques, des règles métier et quelques revues humaines.

Quatrième famille : la santé des intégrations. Je regarde le taux de succès des API externes, le temps de réponse des outils, les erreurs de connecteurs, les timeouts. Beaucoup de “problèmes LLM” sont en fait des problèmes Salesforce, Notion, CRM, base vectorielle ou outil interne.

Avec ces quatre familles, on diagnostique beaucoup plus vite. Une réponse lente avec un bon modèle peut venir d’un outil externe. Une réponse correcte mais trop chère peut venir d’un contexte trop large. Une réponse rapide mais fausse, c’est plutôt un sujet de qualité ou de grounding. C’est ça, une observability utile en prod.

Pourquoi les LLM sont difficiles à observer ?

Les LLM, les grands modèles de langage, sont difficiles à observer parce qu’ils sont non déterministes, verbeux, et souvent jugés sur une qualité qu’on réduit mal à un simple chiffre.

Le non-déterminisme, c’est le premier piège. À code identique, avec le même prompt, ou presque le même, le modèle peut répondre différemment. Ça dépend de ses paramètres, du contexte injecté, des documents récupérés, de la version du modèle, parfois même de l’ordre des messages dans l’historique. Vous ne surveillez pas une API classique qui renvoie toujours le même JSON. Vous surveillez un système qui produit du langage, avec une part de variation normale.

Et ce langage est compliqué à transformer en signal exploitable. Une réponse peut être bien écrite, mais fausse. Elle peut être polie, mais inutile. Elle peut être complète, mais ne pas respecter la consigne. Elle peut citer une source, mais mal l’interpréter. C’est là que beaucoup d’équipes se font avoir. Elles regardent juste le taux d’erreur technique, les latences, les coûts. C’est nécessaire, mais ça ne dit pas si la réponse aide vraiment l’utilisateur.

Le volume rend le sujet encore plus dur. En prod, on a beaucoup de conversations, beaucoup de texte, beaucoup d’étapes intermédiaires. Prompts système, prompts utilisateur, documents récupérés, appels d’outils, réponses partielles, reformulations. Personne ne peut relire ça à la main tous les jours. J’ai vu un client découvrir trois semaines trop tard qu’un assistant répondait correctement sur les cas simples, mais inventait des procédures dès qu’un utilisateur mélangeait deux sujets.

C’est pour ça que j’aime raisonner avec des signaux agrégés, pas avec un score magique. Le but n’est pas d’avoir une note parfaite. Le but, c’est de repérer les dérives assez tôt pour agir.

• Par type de tâche, pour voir si la recherche documentaire tient mieux que la génération d’email.
• Par modèle, pour comparer une version rapide, une version chère, ou un modèle fraîchement migré.
• Par version de prompt, pour détecter une régression après une modification apparemment anodine.
• Par outil appelé, pour comprendre si le problème vient du LLM ou d’une API métier.
• Par segment utilisateur, parce qu’un comportement peut être bon pour les experts et mauvais pour les débutants.

Ces difficultés changent la manière de mettre un LLM en production. L’observabilité ne peut pas être ajoutée à la fin comme un dashboard décoratif. Elle doit être pensée dès la conception, avec les traces, les scores, les cohortes et les alertes qui permettront de comprendre ce qui se passe vraiment.

Comment agir en production ?

En production, je fais simple : j’intègre l’observabilité dès la conception, je définis les bons KPI, puis j’utilise les traces pour corriger vite. Si on ajoute ça après coup, quand l’agent IA est déjà en prod et que personne ne comprend pourquoi il échoue, on est déjà en retard. J’ai vu ça chez un client : l’agent répondait “bien” en démo, mais en réel il appelait parfois le mauvais outil, utilisait de vieux documents, et personne ne pouvait le prouver.

La latence compte, bien sûr. Mais elle ne suffit pas. Un agent rapide qui donne une mauvaise réponse reste un mauvais agent. Les KPI, les indicateurs clés de performance, doivent coller au vrai usage métier.

• Taux de réussite de tâche : Est-ce que l’utilisateur obtient vraiment ce qu’il voulait ?
• Taux d’escalade vers un humain : Combien de fois l’IA abandonne ou doit passer la main ?
• Coût par tâche réussie : Pas juste le coût total, mais le coût utile.
• Taux de réponses non sourcées : Combien de réponses sortent sans document, citation ou preuve exploitable ?
• Taux d’échec des outils : API indisponible, mauvais paramètre, timeout, réponse vide.

Les traces, les métriques et les logs structurés servent surtout quand ça casse. Une trace montre le chemin complet d’une session : prompt utilisé, outil appelé, documents récupérés, réponse du modèle, version du workflow. Un log structuré, c’est un log lisible par une machine, avec des champs propres comme user_id, session_id, prompt_version ou tool_name. Ça permet de retrouver une session problématique, voir quel outil a répondu, vérifier quelles sources ont été utilisées, et comparer deux versions de prompts sans jouer aux devinettes.

La boucle d’action doit rester très concrète : détecter, isoler, comprendre, corriger, mesurer après correction. Dans les projets IA, ce qui manque souvent ce n’est pas un modèle plus gros. C’est une boucle de feedback propre.

Symptôme	Cause probable	Action possible
Latence élevée	Appels outils trop longs ou trop nombreux	Mesurer chaque étape, mettre en cache, réduire les appels inutiles
Coût trop haut	Prompts trop longs ou modèle surdimensionné	Compresser le contexte, router vers un modèle moins cher
Hallucination	Sources absentes ou contexte mal récupéré	Bloquer les réponses non sourcées, améliorer le RAG
Erreur outil	Paramètres invalides ou API instable	Logger les entrées, ajouter validation et retry
Réponse hors contexte	Mauvais documents ou mauvaise version de prompt	Tracer les sources, comparer les versions, ajuster le prompt

Alors, qu’est-ce qu’on trace dès maintenant ?

L’observabilité LLM sert à rendre les erreurs d’un agent IA explicables. Pas juste visibles. Le monitoring vous dit qu’il y a un problème. Les traces, spans, métriques et logs structurés vous montrent où il s’est produit et pourquoi. En production, je commencerais par tracer la chaîne complète, suivre les coûts, la latence, la qualité des réponses et la santé des intégrations. Puis je relierais tout ça à des KPI business simples, comme le taux de réussite de tâche. Le bénéfice est clair : vous corrigez plus vite, vous dépensez moins à l’aveugle, et vous livrez une IA plus fiable.

FAQ

• Quelle est la différence entre monitoring et LLM observability ?
  Le monitoring surveille surtout les symptômes comme la latence, les erreurs ou le trafic. Le LLM observability va plus loin : il capture le contexte, les étapes intermédiaires, les outils appelés et les réponses générées pour comprendre pourquoi un modèle ou un agent IA s’est trompé.
• Que faut-il tracer dans une application LLM ?
  Je tracerais au minimum la requête complète, les appels au modèle, les recherches documentaires, les appels d’outils, les temps de réponse, les erreurs, la version du prompt, le modèle utilisé et les principales sorties intermédiaires. Le but n’est pas de tout stocker, c’est de garder ce qui aide vraiment à diagnostiquer.
• Quelles métriques sont importantes pour un agent IA en production ?
  Les plus utiles sont la latence, le time to first token, le throughput, le nombre de tokens, le coût par exécution, le taux de réussite de tâche, la pertinence des réponses, la groundedness et la santé des intégrations externes. Ces métriques aident à savoir si le problème vient du modèle, d’un outil, du coût ou de la qualité.
• Pourquoi l’observabilité des LLM est plus complexe que celle d’une application classique ?
  Parce qu’un LLM peut produire une réponse techniquement valide mais factuellement fausse. Il y a aussi du non-déterminisme, beaucoup de texte non structuré et des critères de qualité parfois subjectifs. On doit donc combiner traces, métriques, scoring et analyse agrégée.
• Quand faut-il mettre en place l’observabilité LLM ?
  Le plus tôt possible, idéalement dès la conception. Si vous attendez la mise en production, vous risquez de découvrir les hallucinations, les coûts excessifs ou les erreurs d’outils sans avoir les données pour comprendre. Une bonne observabilité crée une vraie boucle de feedback.

 

 

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. Avec mon agence webAnalyste et mon organisme Formations Analytics, j’accompagne des équipes qui veulent instrumenter proprement leurs données, fiabiliser leurs parcours et industrialiser leurs usages IA. J’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez mettre en place une observabilité propre pour vos agents IA ou vos workflows data, contactez-moi.