LLM Observability
L'observabilité des LLM est la pratique consistant à instrumenter les applications LLM en production afin que les équipes puissent voir ce que fait le modèle, déboguer les défaillances, mesurer le coût et la latence, détecter la dérive de qualité et évaluer les sorties dans le temps. C'est l'équivalent, à l'ère des LLM, de l'observabilité applicative traditionnelle, logs, traces et métriques, adapté à des systèmes probabilistes où une même entrée peut produire des sorties différentes.
L'observabilité des LLM est la pratique consistant à instrumenter les applications LLM en production afin que les équipes puissent voir ce que fait le modèle, déboguer les défaillances, mesurer le coût et la latence, détecter la dérive de qualité et évaluer les sorties dans le temps. C'est l'équivalent, à l'ère des LLM, de l'observabilité applicative traditionnelle, logs, traces et métriques, adapté à des systèmes probabilistes où une même entrée peut produire des sorties différentes.
Pourquoi c'est important
Une application web traditionnelle fonctionne ou renvoie une erreur. Une application LLM peut « fonctionner » (renvoyer une réponse bien formatée) alors que la réponse est fausse, hors sujet, hallucinée, biaisée ou tout simplement moins bonne qu'hier. Sans observabilité, ces défaillances restent invisibles jusqu'à ce que les utilisateurs se plaignent, moment où la confiance est déjà entamée. Les années 2024-2025 ont vu l'observabilité des LLM devenir une catégorie distincte, avec des outils comme Langfuse, LangSmith, Helicone, Arize Phoenix, Weights & Biases Weave et Braintrust se taillant chacun une part. Pour toute équipe exploitant des LLM en production, l'observabilité est désormais un prérequis, pas un atout secondaire.
Ce qu'il faut instrumenter
Traces : le chemin d'exécution complet, chaque prompt, appel de récupération, invocation d'outil et réponse au sein d'une seule requête. Permet de rejouer ce que l'agent a réellement fait.
Paires entrée/sortie : le prompt exact envoyé et la complétion exacte reçue, versionnés par modèle de prompt.
Coût par requête : nombre de tokens × prix pour l'entrée et la sortie, par modèle. Agrégé par fonctionnalité, utilisateur ou locataire.
Latence : temps jusqu'au premier token, temps total de complétion et temps passé à chaque sous-étape.
Erreurs et nouvelles tentatives : erreurs de limitation de débit, expirations, échecs d'appels d'outils, erreurs d'analyse.
Signaux de qualité : pouces levés/baissés des utilisateurs, signaux implicites (sortie copiée, code exécuté, message envoyé) et scores LLM-as-judge sur les sorties récentes.
Dérive : évolution dans le temps de la distribution des sorties, de la qualité des réponses ou du taux d'appels d'outils, souvent le premier signal qu'une mise à jour de modèle ou un changement de prompt a cassé quelque chose.
En quoi elle diffère de l'observabilité traditionnelle
Les sorties ne sont pas déterministes : même entrée, sortie différente. Les métriques doivent traiter la variance comme un concept de premier ordre.
Les coûts sont par token, pas par requête : l'APM traditionnel ne sait pas ce que sont les tokens. L'observabilité des LLM le doit.
La qualité est subjective : on ne peut pas affirmer « sortie correcte » avec un simple test. L'évaluation nécessite une revue humaine, des juges LLM ou des comparaisons à une vérité terrain.
Les prompts sont du code : un changement de prompt est un déploiement. Sans versionnage des prompts, on ne peut pas savoir quelle version a produit le bug d'hier.
Les chaînes multi-étapes comptent : la plupart des applications LLM sont des pipelines. Il faut des traces imbriquées qui reflètent le graphe d'appels, pas des logs plats.
Le paysage de l'outillage (2026)
Langfuse (open source) : observabilité centrée sur les traces, avec évaluation, gestion des prompts et retours utilisateurs. Populaire auprès des équipes en auto-hébergement.
LangSmith (LangChain) : étroitement intégré à LangChain. Solide pour les équipes déjà sur cette stack.
Helicone : observabilité légère basée sur un proxy. Intégration en une ligne, facile à adopter.
Arize Phoenix / Arize AX : issu du monde de l'observabilité ML ; solide sur la dérive, les embeddings et la science de l'évaluation.
Braintrust : plateforme centrée sur l'évaluation, utile aux équipes qui veulent traiter le développement LLM comme un flux d'expérimentation.
Weave (Weights & Biases) : étend le suivi d'expériences ML de WandB au territoire des LLM.
Monitoring LLM de Datadog / New Relic : éditeurs d'APM classiques ajoutant des tableaux de bord spécifiques aux LLM.
Conventions sémantiques GenAI d'OpenTelemetry : un standard inter-éditeurs pour le traçage des LLM, gagnant en adoption en 2025-2026.
Ce qu'il faut surveiller
Coût par session utilisateur : des pics soudains signalent souvent un bug (boucle de nouvelles tentatives, agent emballé) avant de signaler une croissance.
Latence p95/p99 : les longues traînes tuent l'expérience utilisateur. Le pire cas compte plus que la moyenne.
Dérive du score d'évaluation : un score LLM-as-judge hebdomadaire sur des prompts représentatifs détecte les régressions silencieuses après des changements de prompt ou de modèle.
Principaux modes de défaillance : catégorisez les erreurs, refusée, hallucinée, hors sujet, mauvais format, pour savoir où investir.
Performance des versions de prompt : comparez les scores d'évaluation entre versions de prompt pour savoir si le dernier changement a aidé ou nui.
Distribution des tokens : les réponses longues font grimper le coût. Des traînes anormalement longues indiquent souvent une dérive de prompt ou des tokens d'arrêt cassés.
Erreurs courantes
Ne journaliser que les erreurs : les LLM échouent en silence. Journalisez aussi les succès, avec suffisamment de métadonnées pour évaluer la qualité.
Aucune stratégie d'échantillonnage : journaliser 100 % des requêtes à grande échelle coûte cher. Échantillonnez intelligemment par segment d'utilisateurs, palier de coût ou changement récent.
Ne pas relier les traces aux retours utilisateurs : un pouce baissé doit renvoyer à la trace exacte qui a produit la sortie.
Cloisonnement par équipe : produit, ML et infra construisent chacun leurs propres tableaux de bord. Une observabilité unifiée est le gain.
Ignorer les tests de régression : « ça a l'air correct » ne suffit pas. Construisez un jeu d'évaluation de régression et exécutez-le avant chaque changement de prompt.
Courir après la dépendance à un éditeur : les conventions GenAI d'OpenTelemetry permettent d'instrumenter une fois et de changer d'éditeur d'observabilité plus tard.
Sources: