Comment réussir sa LLM observability en production ?

La LLM observability sert à voir pourquoi une IA répond mal alors que tout semble fonctionner. Je vous montre quoi instrumenter, comment lire traces, spans et métriques, puis comment transformer les hallucinations, lenteurs et erreurs d’outils en actions concrètes.

Que faut-il vraiment observer ?

Quand je mets une application LLM en production, je ne cherche pas juste à savoir si elle a répondu en 2 secondes ou si l’API a renvoyé 200. Je veux comprendre pourquoi elle a répondu ça. C’est là que l’observabilité devient vraiment utile.

Un LLM, donc un modèle de langage, peut avoir l’air de fonctionner alors qu’il se trompe complètement. Il peut produire une réponse fluide mais fausse, inventer une information, rater une règle métier, choisir le mauvais outil, ou appeler une API avec les mauvais paramètres. Et le pire, c’est que tout ça peut arriver sans erreur technique visible.

J’ai déjà vu un agent IA répondre correctement en apparence à une question client sur une facture. Le ton était bon, la réponse était claire, aucune erreur côté serveur. Sauf qu’en regardant la trace complète, l’agent avait récupéré une ancienne politique tarifaire dans la base vectorielle, puis il avait sauté l’étape de vérification dans l’ERP. Résultat : une réponse crédible, mais juridiquement fausse. Sans observabilité, personne ne le voit avant qu’un client se plaigne.

Ce que je veux observer, ce sont les signaux qui expliquent le comportement réel :

• La requête utilisateur, pour comprendre l’intention, le contexte et les formulations ambiguës.
• Le prompt envoyé au modèle, parce qu’un mauvais prompt système peut casser toute la logique.
• La réponse générée, avec sa qualité, sa cohérence et ses éventuelles hallucinations.
• Les étapes intermédiaires, surtout avec des agents qui raisonnent, planifient ou décident.
• Les appels d’outils, avec les paramètres envoyés, le résultat reçu et les erreurs masquées.
• Les recherches vectorielles, pour voir quels documents ont été remontés, avec quels scores de similarité.
• Les API externes, parce qu’un mauvais timeout ou une donnée obsolète change toute la réponse.
• Les latences, pour identifier si le problème vient du modèle, du retrieval, d’un outil ou d’un service tiers.

Empiler des logs bruts ne suffit pas. Des milliers de lignes illisibles, ce n’est pas de l’observabilité, c’est du bruit. Ce qui compte, c’est de collecter des signaux exploitables, reliés entre eux, avec une trace complète de la demande jusqu’à la réponse finale. Là, les échecs silencieux deviennent débogables.

Signal observé	Utilité	Action possible
Requête utilisateur	Comprendre l’intention réelle et les ambiguïtés	Améliorer le routage ou clarifier la demande
Prompt complet	Identifier une consigne contradictoire ou trop vague	Réécrire le prompt système ou les instructions métier
Sources récupérées	Vérifier si le modèle s’appuie sur les bons documents	Ajuster la recherche vectorielle ou filtrer les sources
Appels d’outils	Voir si l’agent utilise le bon outil avec les bons paramètres	Corriger le schéma, ajouter une validation ou bloquer certains appels
Réponse finale	Détecter hallucination, mauvaise logique ou non-conformité	Lancer une évaluation automatique ou une revue humaine
Latences et erreurs	Localiser les lenteurs et les défaillances cachées	Optimiser le modèle, les API ou les timeouts

Comment lire les traces et spans ?

Une fois que vous avez vos métriques de base, le vrai sujet c’est de comprendre ce qui s’est passé dans une exécution précise. Une trace, c’est le film complet d’une requête. Elle démarre avec la demande utilisateur, suit toutes les étapes internes, puis se termine avec la réponse finale.

Dans cette trace, les spans sont les scènes du film. Chaque span représente une opération importante et mesurable. Une recherche vectorielle. Un appel à une API métier. Une étape de raisonnement. Une génération LLM. L’usage d’un outil par un agent. Chaque span a une durée, un statut, parfois des entrées, des sorties, des métadonnées, et surtout une place dans la hiérarchie.

La logique est simple. La trace est le parent global. Les spans sont les enfants, parfois avec leurs propres sous-spans. Cette structure permet de voir où le temps part, où une erreur apparaît, et où le modèle prend une mauvaise direction.

Trace	Le parcours complet d’une requête utilisateur jusqu’à la réponse finale.
Span	Une opération précise dans ce parcours, avec sa durée et son résultat.
Span enfant	Une sous-opération liée à une étape plus large, par exemple un appel API dans un outil agentique.

Prenons une requête agentique classique. Un utilisateur demande : “Quels clients risquent de churner ce mois-ci et pourquoi ?”. La trace démarre. Premier span : classification de l’intention. Deuxième span : récupération du contexte client dans la base. Troisième span : recherche vectorielle dans les comptes rendus commerciaux. Quatrième span : appel à un outil CRM. Cinquième span : génération d’une synthèse par le LLM. Sixième span : vérification finale avant réponse.

Si la réponse est mauvaise, je peux lire la trace comme une enquête. Si la recherche vectorielle retourne des documents hors sujet, le problème vient peut-être du retrieval, c’est-à-dire la récupération d’information. Si l’API CRM répond avec un timeout, je vois la latence directement. Si les données sont bonnes mais que la synthèse invente une cause de churn, je regarde le span de génération LLM.

C’est beaucoup plus utile qu’un log plat. Un log plat dit souvent “Erreur” ou “Réponse générée”. Une trace montre le chemin, les dépendances, les durées, les entrées utiles. Pour comprendre une hallucination, ce contexte change tout.

OpenTelemetry aide justement à standardiser ça. C’est un standard ouvert pour collecter traces, métriques et logs dans un format cohérent, puis les centraliser dans vos outils d’observability. Pas besoin d’en faire une religion technique. L’idée importante, c’est d’avoir une lecture fiable et partagée de ce que votre application LLM fait vraiment en production.

Quelles métriques suivre en production ?

Je vois souvent la même erreur en prod : on regarde la latence, et on pense qu’on pilote l’application. C’est utile, oui, mais c’est trop court. Une application LLM peut répondre vite, coûter trop cher, halluciner, ou planter parce qu’une API externe répond mal. La vraie observability LLM doit couvrir quatre niveaux.

Le premier niveau, c’est la performance système. Je suis le débit, la latence globale, et surtout le time to first token. Le time to first token, c’est le temps avant que le premier mot arrive à l’utilisateur. Sur une interface chat, c’est souvent plus important que le temps total, parce que l’utilisateur sent que “ça démarre”.

Le deuxième niveau, c’est les ressources et le coût. Je mesure les tokens en entrée, les tokens en sortie, le coût par exécution, et parfois le coût par client ou par scénario métier. C’est là qu’on détecte les prompts qui gonflent sans raison. J’ai déjà vu un workflow multiplier sa facture par trois juste parce qu’on envoyait trop d’historique dans chaque appel.

Le troisième niveau, c’est la qualité de sortie. Là, c’est plus délicat. Certaines métriques sont objectives, comme le nombre d’erreurs JSON ou le taux de réponses vides. D’autres essayent de quantifier des choses plus linguistiques, comme la pertinence ou la groundedness. La groundedness, c’est le fait qu’une réponse reste bien ancrée dans les sources fournies, sans inventer.

Le quatrième niveau, c’est la santé des intégrations. Un LLM en prod appelle souvent une base vectorielle, un CRM, un outil interne, une API de paiement, un moteur de recherche. Si ces briques ralentissent, votre IA paraît mauvaise alors que le modèle n’est pas forcément en cause.

Catégorie	Exemples de métriques	Question business associée	Risque détecté
Performance système	Débit, latence, time to first token	Est-ce que l’expérience utilisateur reste fluide ?	Application lente, saturation, abandon utilisateur
Ressources et coût	Tokens input/output, coût par exécution	Est-ce que chaque réponse coûte un montant acceptable ?	Dérive budgétaire, prompts trop longs, mauvais modèle utilisé
Qualité de sortie	Groundedness, pertinence, erreurs de format	Est-ce que la réponse est utile, fiable et exploitable ?	Hallucination, réponse hors sujet, perte de confiance
Santé des intégrations	Taux de réussite API, temps de réponse, erreurs externes	Est-ce que toute la chaîne fonctionne correctement ?	Panne masquée, dépendance instable, diagnostic impossible

Le point important, c’est de ne pas tout mettre au même niveau. Une métrique de latence se lit facilement. Une métrique de pertinence demande souvent un juge LLM, des règles métier, ou un échantillonnage humain. Je préfère assumer cette différence plutôt que faire semblant que tout est parfaitement mesurable.

Pourquoi les LLM sont-ils plus difficiles ?

Les LLM sont plus difficiles à observer pour une raison simple : ils ne se comportent pas comme une API classique. Une API renvoie 200, 400, 500. Un LLM peut répondre quelque chose de propre, fluide, rassurant… et complètement faux. C’est là que les méthodes d’observabilité classiques montrent vite leurs limites.

Le premier sujet, c’est le non déterminisme. À prompt identique, un modèle peut produire une réponse différente. Pas forcément très différente, parfois juste un détail. Mais ce détail peut changer le sens, casser une règle métier, inventer une source ou déclencher le mauvais outil. Et le plus pénible, c’est qu’un modèle peut changer de comportement sans changement de code visible côté application. Une mise à jour du modèle, un changement dans le contexte, une variation de température, une récupération documentaire moins bonne, et le diagnostic devient moins évident que “qui a déployé quoi ?”.

Le deuxième sujet, c’est le volume de données à suivre. On ne parle plus seulement de logs techniques. Il faut regarder beaucoup plus de choses :

• Les prompts envoyés au modèle, avec le contexte complet.
• Les réponses générées, parfois longues et ambiguës.
• Les appels d’outils, comme une recherche dans une base, un CRM ou une API interne.
• Les résultats intermédiaires, souvent essentiels pour comprendre pourquoi la réponse finale est mauvaise.
• Les traces de raisonnement ou d’exécution quand elles existent, à manipuler avec prudence pour des raisons de sécurité et de confidentialité.

Le vrai piège, c’est que la qualité n’est pas binaire. Une réponse peut être pertinente mais incomplète. Bien formulée mais mal ancrée dans les données disponibles. Utile dans 80% des cas, dangereuse dans les 20% restants. C’est pour ça que les métriques de qualité dont on parlait avant sont indispensables : taux d’hallucination, groundedness, complétude, respect des consignes, satisfaction utilisateur, taux d’escalade, coût par requête, latence.

Sur le terrain, je vois souvent le même scénario. Les équipes pensent que tout va bien parce que les erreurs serveur sont basses et que la latence est correcte. Puis un utilisateur remonte un cas étrange. En creusant, on découvre que le problème existe depuis plusieurs jours, parfois plusieurs semaines. Il n’était juste pas visible dans les dashboards classiques.

Comment agir sur les signaux ?

Une observabilité LLM utile, ça ne se rajoute pas à la fin comme trois logs dans un coin. Je l’intègre dès la conception, parce que chaque signal doit servir à prendre une décision. Si une métrique ne déclenche jamais d’action, je la considère comme du bruit.

Le piège classique, je l’ai vu chez plusieurs clients, c’est de surveiller uniquement la latence, les erreurs HTTP et le nombre de tokens. C’est nécessaire, oui. Mais ça ne dit pas si l’agent fait vraiment le job. En production, je veux suivre des KPI qui parlent au métier autant qu’à la technique.

Les bons indicateurs doivent couvrir plusieurs angles :

• Taux de réussite des tâches. Est-ce que l’utilisateur obtient réellement ce qu’il voulait faire ?
• Coût par exécution. Combien coûte un workflow complet, pas juste un appel au modèle ?
• Qualité des réponses. Est-ce que la réponse est exacte, complète, utile, conforme au ton attendu ?
• Fiabilité des appels d’outils. Est-ce que les API, bases de données ou automatisations appelées par le LLM répondent correctement ?
• Taux de fallback. Combien de fois le système doit basculer vers une réponse générique, un humain ou un autre modèle ?

Je centralise ensuite les traces, les métriques et les erreurs dans un même endroit. OpenTelemetry aide bien pour ça. C’est un standard ouvert qui permet de suivre une requête de bout en bout, depuis l’entrée utilisateur jusqu’au modèle, aux outils, aux API et à la réponse finale. Sans cette vue globale, on devine. Avec elle, on diagnostique.

Les alertes doivent rester actionnables. Une alerte sur “le coût augmente” ne suffit pas. Je préfère une alerte du type “le coût par exécution a doublé sur ce workflow depuis le changement de prompt”. Là, on sait où regarder. Je prévois aussi des revues régulières, souvent hebdo au début, pour relire les traces, repérer les patterns d’échec et décider quoi améliorer.

Le vrai sujet, c’est le passage du signal à l’action. Une hallucination récurrente peut mener à une meilleure récupération d’information. Une erreur d’outil peut révéler une intégration API fragile. Une latence trop haute peut pousser à limiter un workflow, changer de modèle ou mettre en cache certaines réponses. C’est là que l’observabilité devient un levier produit, pas juste un tableau de bord technique.

Problème détecté	Signal observé	Décision possible
Réponses inexactes	Baisse du score qualité, retours négatifs utilisateurs	Ajuster le prompt, renforcer la récupération d’information, ajouter une validation
Coût trop élevé	Hausse du coût par exécution ou du nombre de tokens	Réduire le contexte, changer de modèle, mettre en cache, couper les étapes inutiles
Outil instable	Erreurs fréquentes sur appels API ou timeouts	Corriger l’intégration, ajouter des retries, prévoir un fallback
Workflow trop lent	Latence élevée sur certaines étapes	Paralléliser, limiter le workflow, simplifier les appels ou pré-calculer certaines données
Tâches non finalisées	Taux de réussite en baisse, abandon utilisateur	Revoir le parcours, clarifier les instructions, ajouter une escalade humaine

Et si votre IA fonctionnait sans être fiable ?

La LLM observability sert à arrêter de piloter une IA à l’aveugle. Une application peut répondre, générer du texte, appeler des outils, et pourtant se tromper dans son raisonnement. Pour moi, le vrai sujet est là. Il faut instrumenter les bons signaux, lire les traces et les spans, suivre les métriques de performance, de coût, de qualité et d’intégration, puis relier tout ça à des décisions concrètes. Pas à des dashboards décoratifs. Le bénéfice pour vous est simple vous détectez plus vite les erreurs silencieuses, vous réduisez les coûts inutiles et vous rendez vos agents IA vraiment exploitables en production.

FAQ

• Qu’est-ce que la LLM observability ?
  La LLM observability consiste à instrumenter une application basée sur un modèle de langage pour comprendre ce qui se passe vraiment pendant une exécution. Elle permet de voir les prompts, les réponses, les étapes intermédiaires, les appels d’outils, les traces, les spans, les métriques de qualité, les coûts et les erreurs.
• Pourquoi les logs classiques ne suffisent pas pour un LLM ?
  Les logs classiques disent souvent qu’un service a répondu ou qu’une API n’a pas planté. Avec un LLM, le problème peut être plus discret. La réponse peut être fluide mais fausse, logique en apparence mais mal fondée, ou basée sur un mauvais appel d’outil. Il faut donc observer le raisonnement opérationnel, pas seulement l’état technique.
• 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 opération précise dans cette trace, par exemple une recherche vectorielle, un appel d’API, une génération LLM ou l’utilisation d’un outil. Cette granularité aide à trouver où une latence, une erreur ou une mauvaise décision apparaît.
• Quelles métriques suivre pour une application LLM ?
  Je suivrais au minimum la latence, le débit, le time to first token, l’usage de tokens, le coût par exécution, la pertinence des réponses, le groundedness, le taux de réussite des tâches, le taux de succès des API externes et leur temps de réponse. Le but est de couvrir la performance, le coût, la qualité et la fiabilité des intégrations.
• Quand faut-il mettre en place l’observabilité LLM ?
  Le plus tôt possible. Si on l’ajoute après coup, on découvre souvent qu’il manque les signaux les plus utiles. L’idéal est de penser l’observabilité dès la conception, avec des KPI clairs, des traces structurées, des métriques exploitables et une façon simple de passer d’un problème détecté à une action concrète.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA, le SEO et le GEO. J’ai travaillé pour des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez mettre de l’observabilité, de la mesure et de l’automatisation propre dans vos projets IA, contactez-moi.