Un assistant répond vite, sans erreur technique, mais applique une ancienne politique de remboursement. Le temps de réponse est bon. L’appel au modèle a réussi. La réponse reste incorrecte.
La LLM observability consiste à relier les étapes d’un traitement pour comprendre comment une réponse a été produite. Elle devient utile quand on rapproche cette trace des évaluations, des versions et des coûts. Une trace seule ne prouve ni la justesse d’une réponse ni son utilité pour l’utilisateur.
Ce guide propose une méthode pour une équipe data qui exploite un assistant, une extraction documentaire ou un workflow agentique. Il comprend un atelier OpenTelemetry à télécharger et un tableau de bord de démonstration. L’atelier a été exécuté localement. Tous ses cas, durées, montants et évaluations sont fictifs : aucun modèle ni service payant n’a été appelé.
Partir d’une décision, puis construire la trace
L’objectif n’est pas de remplir un écran de métriques. Il est de pouvoir décider : corriger un document, changer un prompt, limiter les reprises, ajuster un modèle ou suspendre une fonctionnalité.
Une trace regroupe les opérations d’un parcours. Un span décrit une étape avec un début, une fin et des attributs. Pour un assistant documentaire, le parcours peut contenir la recherche des passages, l’appel au modèle et la vérification de la réponse. Un identifiant commun permet de retrouver les étapes associées.
OpenTelemetry fournit les API et SDK nécessaires à cette instrumentation. Dans Langfuse, les étapes sont appelées observations ; elles appartiennent à une trace, et plusieurs traces peuvent être regroupées dans une session. Un tour de conversation constitue un périmètre pratique, à définir explicitement dans votre application. Instrumentation Python OpenTelemetry ; modèle de données Langfuse.
Avec des logs isolés, l’équipe peut connaître une erreur et son heure sans retrouver le document sélectionné, la version du prompt ou les tentatives précédentes. Une trace corrélée réduit ce travail de reconstruction. Elle doit toutefois porter les bonnes informations : ajouter un SDK sans définir les décisions à éclairer produit surtout davantage de données.
Trois questions différentes : technique, qualité, usage
Une réussite technique signifie que le traitement s’est terminé selon les contrôles prévus. Une acceptation qualité signifie que la réponse respecte un critère explicite. Un succès d’usage signifie que l’utilisateur a obtenu le service attendu. Ces événements peuvent diverger.
| Question |
Signal à conserver |
Ce que le signal ne prouve pas |
| Le workflow s’est-il terminé ? |
Statut du parcours, erreurs et reprises |
La réponse est correcte |
| La réponse respecte-t-elle la règle ? |
Évaluation datée, méthode et version de la grille |
Tous les cas non évalués sont corrects |
| L’utilisateur a-t-il terminé sa démarche ? |
Événement métier réellement instrumenté |
Une note automatique équivaut à une conversion |
Commencez par une grille courte. Pour un remboursement : règle en vigueur, conditions applicables, montant cohérent et présence d’une source utilisable. Rattachez l’évaluation à la réponse exacte, pas simplement au nom du modèle. Une validation humaine et un jugement automatique doivent rester identifiables séparément.
Gardez deux dénominateurs : les réponses acceptées parmi les réponses évaluées, puis les réponses évaluées parmi les réponses produites. Un score élevé sur quelques cas sélectionnés ne décrit pas toute la production. Le golden dataset de classification complète cette approche pour comparer des versions sur des exemples contrôlés.
Le minimum à enregistrer dans un workflow LLM
Conservez un identifiant de requête, l’environnement, la version applicative et celle du prompt. Ajoutez le modèle réellement appelé, les références et versions des documents utilisés, les statuts, les temps et la consommation disponible. Pour chaque évaluation, gardez la méthode, la grille et son résultat.
Enregistrez les reprises comme des opérations visibles. Une tentative échouée peut avoir consommé des ressources. Si le SDK fournit seulement une opération logique contenant plusieurs retries internes, documentez cette granularité ; ne prétendez pas disposer du détail de chaque tentative. Évitez aussi de compter un coût à la fois sur un parent et sur ses enfants.
Le choix des noms mérite une vérification de version. Les conventions GenAI d’OpenTelemetry sont désormais hébergées dans un dépôt séparé et portent le statut Development dans la documentation consultée le 3 octobre 2026. Elles ne constituent pas un contrat immuable. L’atelier utilise donc des attributs pédagogiques app.*, sans les présenter comme la convention GenAI officielle. Conventions GenAI et statut.
Pour une équipe française, préparez aussi la circulation des données : contenu envoyé à la plateforme de traces, région choisie, accès des intervenants et durée de conservation. Le premier essai peut fonctionner avec des identifiants techniques et des versions, sans copier les messages clients. Langfuse documente un masquage avant export, qui doit être vérifié sur les attributs réellement produits par chaque instrumentation. Masquage des données.
Trois cas concrets à diagnostiquer
Support client : une bonne exécution, une mauvaise règle. Dans ce cas fictif, la recherche retrouve une fiche de remboursement ancienne. La réponse est rapide et techniquement valide, mais l’évaluation la refuse. La trace doit permettre d’identifier la version documentaire utilisée. Le premier correctif porte sur la sélection des sources ; changer de modèle serait une hypothèse à tester ensuite. Le critère de recette est l’application de la bonne règle sur les cas affectés, sans dégrader les autres.
Extraction de factures : un JSON valide, un montant incorrect. Un traitement peut produire les clés attendues tout en confondant montant hors taxes et montant total. Le contrôle de structure ne suffit pas. Reliez le résultat à une vérification métier et à l’exemple de référence. Mesurez séparément les rejets techniques et les champs erronés, puis vérifiez les corrections sur une cohorte comparable. Le guide des sorties structurées traite la partie structurelle, complémentaire de cette évaluation.
Agent opérationnel : une réponse acceptée après plusieurs essais. Une reprise peut améliorer le taux de réussite tout en augmentant la consommation et le délai. Tracez les tentatives accessibles, leur statut et leur coût connu. Vérifiez que les opérations avec effet de bord ne sont pas répétées par erreur. Le critère de succès associe réponse acceptable, nombre de reprises maîtrisé et absence d’action dupliquée. Les droits d’action d’un agent restent un sujet distinct de sa seule observabilité.
Ces exemples sont des scénarios de travail, pas des missions clients ni des résultats de benchmark.
Atelier local : six parcours, trois pièges visibles
L’exercice utilise Python 3.13 et le SDK OpenTelemetry 1.45.0 dans un environnement isolé. Le script crée de vrais objets spans, propage leur contexte parent et les exporte localement en JSONL. Il impose les horodatages et résultats du scénario : les latences affichées ne mesurent pas la vitesse de votre machine.
Le JSONL est un export pédagogique du SDK, pas un message OTLP prêt à envoyer à un collecteur. L’atelier ne valide aucune intégration Langfuse ou LangSmith. Il permet de tester la structure des traces et les calculs avant de connecter une application réelle.
1. Préparer un dossier de travail
Téléchargez le script Python, les scénarios et les dépendances figées dans un même dossier. Créez l’environnement puis installez les dépendances :
python3.13 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements-lock.txt
python atelier-observabilite.py --self-test
python atelier-observabilite.py --output resultats-observabilite
L’installation télécharge des bibliothèques. L’exécution du script n’appelle aucun service distant et ne demande aucune clé API. Les versions exactes testées figurent dans le fichier de dépendances.
2. Lire la sortie et ouvrir le tableau de bord
Le dossier de sortie contient traces.jsonl, resultat.json et tableau-de-bord.html. Ouvrez ce dernier fichier dans un navigateur. Vous pouvez aussi consulter l’exemplaire publié et le résultat de référence.
Les six parcours produisent 19 spans et 7 tentatives modèle. Cinq parcours réussissent techniquement ; trois réponses sont évaluées, dont deux acceptées. Le parcours t2 réussit techniquement mais sa réponse est refusée, avec la référence policy-v1. Le parcours t3 aboutit après une tentative en erreur, qui reste incluse dans son coût.
Ces nombres décrivent uniquement le jeu fourni. Ils ne constituent ni un taux de qualité mesuré sur un modèle ni une estimation représentative d’un usage entreprise.
3. Vérifier qu’une valeur manquante reste inconnue
Six tentatives ont un coût renseigné sur sept. Leur sous-total fictif vaut 0,009 USD. Le coût total reste null, comme le coût par parcours accepté, puisqu’un montant manque. Le transformer en zéro afficherait une précision inexistante.
Le test intégré vérifie aussi les parents des spans, les doublons, le jeu vide, la conservation d’une tentative en erreur et les dénominateurs de qualité. Il contrôle que le montant complet devient calculable lorsqu’on renseigne réellement le coût manquant.
Pour rejouer, choisissez un nouveau dossier avec --output. Le script refuse un dossier contenant déjà des fichiers afin de ne pas mélanger deux exécutions. Pour nettoyer, supprimez uniquement le dossier de résultats et l’environnement virtuel que vous avez créés. Conservez les scénarios et les références si vous voulez comparer une modification.
Lire latence et coût sans fabriquer de conclusion
La latence utilisateur correspond à la durée du parcours, pas à la somme automatique de ses enfants. Si deux étapes s’exécutent en parallèle, additionner leur durée surestime le délai. Pour une interface en streaming, distinguez aussi le premier contenu affiché et la fin de la réponse.
L’atelier calcule un p95 par rang supérieur sur six cas synthétiques. Il vaut 2 200 ms parce que le scénario l’impose. Ce calcul sert à vérifier la formule ; il ne suffit pas pour choisir un objectif de service. En production, examinez le volume, la fenêtre, les segments et la couverture des traces avant d’interpréter un percentile.
Pour le coût, séparez modèle, outils externes, évaluation, stockage des traces et temps de revue. Langfuse distingue les consommations et coûts transmis par l’application des valeurs calculées à partir du modèle et de ses tarifs connus. Une correspondance manquante ou un usage incomplet doit apparaître comme une limite de mesure. Suivi des tokens et coûts.
Un coût par réponse acceptée exige une cohorte claire, un périmètre de coût et une couverture d’évaluation affichée. Le ratio ne mesure pas une conversion métier. Comparer deux versions avec des méthodes d’évaluation ou des échantillons différents peut conduire à choisir la mauvaise option.
Langfuse, LangSmith ou votre plateforme existante ?
Si l’entreprise dispose déjà d’un collecteur et d’une plateforme d’observabilité, commencez par vérifier ce qu’ils permettent : propagation du contexte, recherche par requête, accès aux versions et rattachement des évaluations. Une interface spécialisée peut réduire le travail de revue des prompts et réponses, mais introduit un service supplémentaire à administrer.
Langfuse organise traces, observations, évaluations et suivi des coûts. Au 3 octobre 2026, son offre cloud Hobby affiche 50 000 unités mensuelles gratuites et 30 jours d’accès aux données. Core affiche 29 USD par mois avec 100 000 unités incluses et 90 jours d’accès. La page propose notamment une région européenne. Les dépassements se facturent séparément : ne comparez pas ces unités directement à un nombre de requêtes utilisateur. Tarifs Langfuse.
LangSmith propose une observabilité indépendante du framework, avec des intégrations et des fonctions d’évaluation. Son offre Developer affiche un utilisateur et 5 000 traces de base incluses par mois ; Plus affiche 39 USD par siège et 10 000 traces de base incluses. Les usages supplémentaires et autres composants de la plateforme ont leur propre facturation. Observabilité LangSmith ; tarifs LangSmith.
La rétention compte dans la comparaison. LangSmith distingue 14 jours en base et 180 jours en extended. Sa documentation précise qu’à partir du 14 septembre 2026, le maximum de rétention longue SaaS passe à 180 jours pour les nouvelles traces. Certaines fonctions peuvent prolonger la rétention et augmenter le coût, selon leur configuration. Facturation et rétention.
Ces tarifs sont des repères datés, pas un devis équivalent entre fournisseurs. Chiffrez votre nombre d’étapes, vos évaluations, votre conservation et vos besoins d’accès avant de comparer. L’effort d’adoption comprend l’instrumentation, le masquage, la grille métier et la personne responsable de la revue.
Commencer par un seul parcours vérifiable
Choisissez un workflow fréquent avec une décision métier identifiable. Reliez une requête à ses versions et à ses étapes, puis ajoutez une petite grille d’acceptation. Constituez un échantillon représentatif pour suivre la qualité ; conservez séparément les cas difficiles sélectionnés pour le diagnostic.
Définissez ensuite une alerte qui mène à une action : vérifier une nouvelle version documentaire, examiner les reprises ou suspendre une modification. Faites apparaître le nombre de cas et les valeurs manquantes dans le tableau de bord. Une métrique sans propriétaire ni procédure de vérification n’accélère pas la résolution d’un incident.
Le premier livrable utile est une réponse explicable de bout en bout, accompagnée d’une décision de correction. Pour cadrer ce parcours avec votre équipe data, échangeons sur votre workflow IA.
