Comment piloter le LLM observability en production ?

Je le pilote en instrumentant les traces, les spans, les métriques de coût, de qualité et les appels d’outils. Le vrai sujet, c’est qu’un LLM peut réussir techniquement et répondre n’importe quoi. Ici, je montre quoi observer, quoi mesurer, et comment agir sans se noyer.

Pourquoi le monitoring classique ne suffit pas ?

Le monitoring classique ne suffit pas parce qu’un LLM peut renvoyer une réponse techniquement valide mais fausse, incohérente ou inutilisable. Et c’est là que beaucoup d’équipes se font piéger au début. Tout est vert côté infra, l’API répond en 200, la latence est correcte, les logs n’affichent rien de dramatique… mais l’utilisateur reçoit une mauvaise réponse.

Le monitoring regarde surtout si le système fonctionne techniquement. Il surveille des signaux comme les erreurs HTTP, le temps de réponse, le CPU, la mémoire, les logs applicatifs, la disponibilité du service. C’est indispensable, je ne remets pas ça en question. Mais dans une application IA, ça ne suffit pas à savoir si le modèle a compris la demande, s’il a utilisé le bon contexte, s’il a appelé le bon outil, ou s’il a inventé une information avec aplomb.

Avec les LLM et les agents IA, on a un nouveau type de problème : les échecs silencieux. Une hallucination peut passer avec un statut 200. Une mauvaise décision d’agent peut être exécutée sans erreur serveur. Une réponse peut sembler bien écrite, mais ne pas être ancrée dans les bonnes sources. Et une erreur de raisonnement peut ne laisser aucune trace évidente dans les logs classiques.

J’ai déjà vu un cas très concret chez un client. Un assistant interne devait recommander la bonne procédure commerciale à suivre selon le type de contrat. Techniquement, tout allait bien. Réponse rapide, pas d’erreur API, coût normal. Sauf que l’assistant avait récupéré une ancienne version d’un document dans la base de connaissance. Il a donc donné une recommandation claire, bien formulée, mais mauvaise. Le monitoring disait “tout va bien”. Le métier disait “ça peut nous coûter cher”.

C’est exactement pour ça qu’on parle de LLM observability. L’objectif n’est pas seulement de savoir si l’application tourne. Il faut comprendre ce que le modèle a vu, quelles étapes ont été exécutées, quels outils ont été appelés, quelles données ont été utilisées, et pourquoi la sortie finale ressemble à ça.

En pratique, ça veut dire qu’on ne peut pas observer uniquement la réponse finale. Il faut instrumenter tout le parcours d’une requête : le prompt, le contexte récupéré, les appels aux outils, les réponses intermédiaires, les décisions de l’agent et les éventuelles validations. C’est ce parcours complet qu’on va devoir rendre visible pour piloter sérieusement une application IA en production.

Que faut il instrumenter en premier ?

J’instrumente d’abord le parcours complet d’une requête, avec une trace globale et des spans pour chaque opération importante. C’est le meilleur point de départ, parce que ça donne une vision lisible de ce qui se passe vraiment en production.

Une trace, dans une application LLM, c’est le parcours complet d’une demande utilisateur. Ça commence au prompt initial, ça traverse les étapes internes, et ça se termine avec la réponse finale renvoyée à l’utilisateur. Un span, lui, c’est une opération isolée dans ce parcours. Par exemple une reformulation de requête, une recherche vectorielle dans un RAG, un reranking, un appel à un outil externe, une requête API, une génération intermédiaire ou la génération finale.

Cette granularité change tout pour le debug. Sans trace, on sait juste que la réponse est mauvaise, lente, ou bizarre. Avec les spans, je peux voir où ça déraille. Est-ce que le prompt système est trop flou ? Est-ce que le contexte récupéré est hors sujet ? Est-ce que le modèle hallucine malgré un bon contexte ? Est-ce qu’un outil externe répond trop lentement ? Est-ce qu’un timeout coupe une étape ? Est-ce qu’une génération intermédiaire injecte une mauvaise hypothèse dans la suite ?

Je l’ai vu chez un client sur un assistant interne. Tout le monde accusait le modèle. En regardant les spans, le problème venait surtout du RAG : les bons documents étaient en base, mais les scores de similarité favorisaient des pages obsolètes. Sans instrumentation, on aurait changé de modèle pour rien.

Je capture les données utiles, pas toute la planète. Le minimum sérieux ressemble à ça :

• Le prompt utilisateur et le prompt système.
• La version du prompt, parce qu’un prompt change souvent sans qu’on s’en rende compte.
• Le modèle utilisé et les paramètres de génération quand ils comptent, comme la température ou le nombre maximal de tokens.
• Les documents récupérés dans un RAG, avec les scores de similarité.
• Les appels d’outils, avec les entrées, les sorties, les erreurs et les durées.
• La réponse finale, les erreurs, les timeouts, les identifiants de session ou de workflow.

Je standardise aussi dès le début. Une logique compatible OpenTelemetry aide beaucoup. OpenTelemetry, c’est un standard open source pour structurer traces, spans, logs et métriques. Quand plusieurs équipes, modèles ou outils interviennent dans la même chaîne, ça évite de se retrouver avec trois formats maison impossibles à recouper.

Objet	Rôle	Exemple LLM	Diagnostic possible
Trace	Parcours complet d’une requête utilisateur	Question utilisateur jusqu’à réponse finale	Voir où la chaîne globale se dégrade
Span	Étape précise dans une trace	Recherche vectorielle, reranking, appel API, génération finale	Identifier l’étape fautive ou lente
Métrique	Mesure agrégée dans le temps	Latence moyenne, taux d’erreur, coût par requête	Suivre la santé du système en production
Log	Événement détaillé à un instant donné	Erreur outil, timeout, payload refusé	Comprendre un incident précis

Quelles métriques suivre sans se disperser ?

Je suis quatre familles de métriques seulement au départ, performance, coût, qualité des sorties et santé des intégrations. Sinon on finit avec cinquante graphiques, personne ne les regarde, et l’application IA dérive en silence. Le vrai sujet, c’est de transformer les traces détaillées en signaux simples. Une trace dit “cet appel modèle a pris 3,2 secondes, cet outil a échoué, cette base vectorielle a répondu lentement”. Un KPI dit “ce workflow devient trop lent et coûte trop cher”.

Côté performance système, je regarde d’abord le débit, donc le nombre d’exécutions traitées sur une période. Puis la latence globale, du début à la fin de la demande. Mais la moyenne ment souvent. Si votre moyenne est à 4 secondes, mais que 10% des utilisateurs attendent 25 secondes, vous avez un problème réel. Je regarde donc les cas lents, avec des percentiles comme P95 ou P99. Le P95, c’est le temps sous lequel 95% des requêtes passent. Très utile pour voir ce que vivent les utilisateurs quand ça se dégrade.

Je descends ensuite par span. Un span, c’est une étape précise dans une trace, par exemple l’appel au LLM, la recherche dans la base vectorielle, ou l’appel à l’API CRM. C’est souvent là qu’on découvre qu’un agent bloque toujours sur le même outil. Je suis aussi le time to first token, le délai avant le premier mot généré, les timeouts, et les erreurs. Pour une interface conversationnelle, le premier token compte presque autant que la durée totale.

Sur les coûts, je garde des métriques très terre à terre :

• Nombre de tokens en entrée et en sortie.
• Coût par exécution.
• Coût par utilisateur.
• Coût par workflow ou par dossier traité.
• Nombre d’appels au modèle et aux outils par agent.

J’ai vu un client réduire ses coûts juste en modifiant le routage. Les demandes simples partaient vers un petit modèle, les demandes complexes vers un modèle plus puissant. Même expérience utilisateur, moins de tokens, moins d’appels inutiles, coût en baisse. Parfois, une consigne plus courte dans le prompt enlève aussi 20% de tokens sans changer la qualité.

Pour la qualité, je suis la groundedness, c’est-à-dire le fait que la réponse s’appuie bien sur les sources. Je regarde aussi la pertinence, la cohérence, le taux de réponse utile, le taux de réussite de tâche et le feedback utilisateur. Les scores automatiques sont pratiques, mais je reste prudent. Ils détectent des tendances. Ils ne remplacent pas des exemples concrets. Quand le sujet est sensible, juridique, médical, financier ou RH, je garde une validation humaine dans la boucle.

Les intégrations comptent autant que le modèle. Pour un agent IA, les APIs, les bases vectorielles, les outils métier et les services externes font partie du raisonnement. Je suis leur taux de succès, leur latence, leurs erreurs, et surtout leur impact sur la réponse finale. Une API lente peut transformer une bonne IA en mauvais produit.

Ma recommandation est simple. Je ne crée pas cinquante dashboards. Je démarre avec quelques KPIs reliés au business : taux de résolution, taux d’escalade, coût par dossier traité, satisfaction, taux de réponse fondée sur les sources. Le reste vient après, quand un signal mérite vraiment d’être creusé.

Comment agir quand les signaux dérivent ?

J’agis en reliant chaque alerte à une décision claire, corriger un prompt, changer une étape, ajuster un outil, relancer une évaluation ou escalader à un humain. Sinon l’observabilité devient juste un tableau de bord qu’on regarde quand ça brûle. Et ça, je l’ai vu chez un client avec un assistant interne très utilisé. Tout semblait marcher, jusqu’au jour où les réponses sont devenues plus lentes, plus chères, et parfois moins fiables. Le vrai problème n’était pas le modèle. C’était l’absence de traces exploitables.

L’observabilité doit être prévue dès la conception. Pas ajoutée à la fin. Dans un projet IA, je veux voir dès le départ les traces, les spans et les métriques. Une trace, c’est le parcours complet d’une requête. Un span, c’est une étape précise dans ce parcours, par exemple l’appel au moteur de recherche, au LLM, ou à un outil métier. Une métrique, c’est une mesure agrégée, comme la latence, le coût, le taux d’erreur ou le nombre de tokens. Sans ça, on pilote une boîte noire.

Les LLM compliquent les choses parce qu’ils ne sont pas totalement déterministes. Deux exécutions très proches peuvent produire deux réponses différentes. Les tests classiques ne suffisent pas. Je combine toujours plusieurs couches :

• Des tests automatisés sur les cas critiques.
• Des jeux d’évaluation avec des exemples attendus.
• Un suivi continu en production.
• Une analyse régulière de vraies conversations.
• Des métriques agrégées pour repérer les tendances.

La donnée non structurée ajoute une autre difficulté. Une réponse texte ne se valide pas comme un code HTTP 200. Il faut définir des critères simples. Pour un chatbot support, je regarde la pertinence, la résolution du problème et le ton. Pour un moteur RAG, c’est-à-dire un système qui répond à partir de documents, je suis la groundedness, donc l’ancrage dans les sources, la citation des bons passages et l’absence d’invention. Pour un agent automatisé, je regarde surtout si l’action finale est correcte.

Signal observé	Cause probable	Action recommandée
Latence en hausse	Un span lent, souvent la recherche documentaire, un outil externe ou le modèle utilisé.	Inspecter les spans les plus lents, réduire les appels inutiles, changer de modèle si besoin.
Coût qui explose	Trop de tokens, trop d’appels LLM, prompts trop longs ou boucles d’agent mal contrôlées.	Vérifier les tokens par étape, limiter le contexte, poser des garde-fous sur le nombre d’appels.
Groundedness en baisse	Sources mal récupérées, chunks trop larges, requête de recherche mal formulée.	Relire les documents récupérés, ajuster le retrieval, améliorer le découpage des sources.
Taux de succès métier en chute	Mauvaise décision de l’agent, prompt fragile, outil indisponible ou cas utilisateur non couvert.	Relire les traces complètes des cas ratés, corriger le prompt, ajouter une règle ou escalader à un humain.

Le bon réflexe, c’est de ne jamais traiter une alerte seule. Je la rattache à une hypothèse, puis à une action mesurable. Si je change un prompt, je relance une évaluation. Si je modifie une étape, je compare avant et après. C’est comme ça qu’on garde un système LLM fiable en production, sans naviguer au feeling.

Qu’est ce qu’on observe dès demain ?

La LLM observability sert à sortir l’IA de la boîte noire. Je ne regarde pas seulement si l’application répond. Je veux comprendre le chemin complet, les traces, les spans, les outils appelés, les coûts, la latence et surtout la qualité réelle des réponses. Le plus utile, c’est de relier ces signaux à des actions concrètes. Corriger un prompt, isoler une API lente, revoir une recherche vectorielle, réduire les tokens, améliorer un KPI business. Vous gagnez du temps, vous réduisez les coûts et vous rendez vos applications IA beaucoup plus fiables en production.

FAQ

• Qu’est ce que le LLM observability ?
  Le LLM observability, c’est la capacité à comprendre ce qui se passe dans une application basée sur un grand modèle de langage. Je ne regarde pas seulement la réponse finale. Je regarde aussi les prompts, les traces, les spans, les appels d’outils, les documents récupérés, les coûts, la latence et les signaux de qualité.
• Pourquoi le monitoring classique ne suffit pas pour un LLM ?
  Parce qu’un LLM peut répondre vite, sans erreur technique, tout en donnant une réponse fausse ou non pertinente. Le serveur peut renvoyer un statut correct, l’API peut fonctionner, et pourtant le raisonnement peut être mauvais. L’observabilité sert à repérer ces échecs silencieux.
• Quelle est la différence entre une trace et un span ?
  Une trace représente le parcours complet d’une requête utilisateur. Un span représente une étape précise de ce parcours, comme une recherche vectorielle, un appel API, un appel d’outil ou une génération de réponse. Les spans permettent d’isoler exactement où le problème apparaît.
• Quelles métriques faut il suivre sur une application LLM ?
  Je commence par quatre familles de métriques. La performance avec la latence et le time to first token. Le coût avec les tokens et le coût par exécution. La qualité avec la pertinence, la groundedness et le taux de réussite. Les intégrations avec la latence et le taux de succès des outils externes.
• Quand faut il mettre en place l’observabilité LLM ?
  Le plus tôt possible. Si on l’ajoute après coup, on risque de manquer les données utiles pour comprendre les erreurs. Dès la conception, je prévois les traces, les spans, les KPIs et les tableaux de bord. C’est beaucoup plus simple que de reconstruire le diagnostic quand l’application est déjà en production.

 

 

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 sur des sujets très concrets de mesure, d’automatisation et de pilotage data. J’ai travaillé avec des clients 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 projets IA, contactez-moi.