Votre agent répond. Parfois bien, parfois à côté. Le coût mensuel grimpe sans qu'on sache trop pourquoi. Un utilisateur signale une réponse hallucinée — et vous n'avez aucun moyen de la rejouer. C'est le quotidien d'une application IA générative livrée sans observabilité. Ce guide pose le cadre : les questions nouvelles que vous devez pouvoir répondre, en quoi le tracing LLM diffère du tracing applicatif classique, et le paysage des outils open source que les guides suivants détaillent un par un. Il s'adresse aux DevSecOps, SRE et platform engineers qui prennent en charge — ou qui hériteront — d'une stack IA en production.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Identifier les quatre questions auxquelles l'observabilité LLM doit répondre
- Distinguer le tracing classique du tracing d'une chaîne LLM ou d'un agent
- Comprendre le tryptique : traces, evals, prompts management
- Choisir une stack OpenTelemetry-native ou un outil dédié (Langfuse, Phoenix)
- Savoir quand instrumenter — et quand l'effort n'est pas encore rentable
Le problème : ce qu'un APM classique ne vous dit pas
Section intitulée « Le problème : ce qu'un APM classique ne vous dit pas »Un APM (Application Performance Monitoring) traditionnel répond bien à « combien de temps a duré cette requête ? » ou « cette base de données ralentit-elle ? ». Sur une chaîne LLM, ces questions n'épuisent pas le sujet — il en arrive quatre nouvelles, propres à la nature non déterministe et payante du modèle :
| Question | Pourquoi un APM classique ne suffit pas |
|---|---|
| Quel prompt a réellement été envoyé au modèle ? | Le prompt final est souvent assemblé dynamiquement (template + RAG + historique). Sans le capturer, impossible de reproduire un incident. |
| Combien ça coûte par utilisateur, par feature, par run ? | Le coût se compte en tokens entrée/sortie, par modèle, par provider — pas en CPU/RAM. |
| Quelle est la latence de chaque étape de l'agent ? | Un agent enchaîne LLM → tool → LLM → tool. La latence totale ne dit rien ; il faut la décomposition par étape. |
| La réponse est-elle de qualité ? | Une requête peut être « 200 OK » et complètement hallucinée. La qualité demande une évaluation séparée, pas un code HTTP. |
Ces quatre dimensions — prompt, coût, latence par étape, qualité — sont le minimum vital. Aucune n'est couverte par défaut par Prometheus ou un APM classique.
Tracing distribué vs tracing LLM : où ça diverge
Section intitulée « Tracing distribué vs tracing LLM : où ça diverge »Le tracing distribué (OpenTelemetry, voir le guide OpenTelemetry) suit une requête à travers plusieurs services. Une trace est un arbre de spans, chacun annoté de métadonnées (durée, statut, attributs). Le modèle mental reste excellent — il s'applique aussi à un agent LLM.
Ce qui change : la forme des spans et la nature des attributs. Un span
LLM doit porter le modèle utilisé, le nombre de tokens entrée/sortie, le coût
estimé, le prompt complet, parfois la réponse. Les conventions sémantiques
OpenTelemetry GenAI (gen_ai.* attributes) standardisent ces champs —
c'est précisément ce qu'attaque le guide OpenTelemetry GenAI suivant de
la sous-section.
Côté agent ou chaîne RAG, un appel utilisateur produit typiquement 5 à 20 spans :
- 1 span racine « agent run »
- N spans LLM (un par appel au modèle)
- N spans « tool call » (recherche vectorielle, appel API externe, exécution de code)
- Éventuellement des spans « retrieval » (re-ranking, requêtes BM25)
C'est exactement le pattern que le tracing distribué sait représenter — d'où
la convergence en cours. Mais sans les conventions gen_ai.* et sans un
backend qui sache afficher prompts et complétions de manière lisible, on
perd 80 % de la valeur.
Le tryptique : traces, evals, prompts management
Section intitulée « Le tryptique : traces, evals, prompts management »L'observabilité LLM repose sur trois piliers complémentaires, qu'aucun outil unique ne couvre parfaitement aujourd'hui.
1. Traces
Section intitulée « 1. Traces »Le pilier classique. Capturer chaque appel LLM avec tout son contexte (prompt, complétion, modèle, tokens, latence, coût). Permet de rejouer, de comparer et de chercher les exécutions anormales.
Outils dominants en open source self-hostable : OpenLLMetry (auto-instrumentation OTel pour les SDK populaires), Langfuse, Arize Phoenix.
2. Evals
Section intitulée « 2. Evals »L'évaluation séparée de la qualité des sorties. On ne mesure pas la qualité au moment de la requête (trop coûteux, trop lent) — on échantillonne ou on batch : un jeu de données de référence, des scores automatiques (LLM-as-a-judge, métriques RAG), exécutés régulièrement ou en CI.
Outils : Ragas pour le RAG (faithfulness, answer relevancy, context precision), DeepEval pour les agents, promptfoo pour le testing en pipeline.
3. Prompts management
Section intitulée « 3. Prompts management »Versionner les prompts comme du code. Un prompt template, c'est une donnée de production au même titre qu'une migration de schéma : il a une version, un changelog, idéalement un A/B test avant déploiement. Sans cela, modifier un prompt en prod devient impossible à tracer.
Outils : Langfuse intègre nativement le prompts management ; certains équipes le font à la main avec Git + variables d'environnement.
Une chaîne RAG observée de bout en bout
Section intitulée « Une chaîne RAG observée de bout en bout »Pour fixer les idées, voici ce que doit produire l'observabilité sur une requête RAG agentique typique — celle du fil rouge Assistant souverain :
L'utilisateur envoie une question. L'orchestrateur (LangGraph) la transforme en plusieurs étapes :
- Span « embed » — calcul de l'embedding de la requête (modèle, latence)
- Span « retrieve » — recherche hybride Qdrant + BM25 (nombre de hits, scores, latence)
- Span « rerank » — cross-encoder sur les N candidats (modèle, latence)
- Span « llm.synthesis » — appel au LLM final avec le contexte assemblé (prompt, modèle, tokens in/out, coût, complétion)
- Span « guardrail » — vérification post-réponse (lien vers le guide Guardrails à venir)
À côté, en asynchrone : un eval Ragas tourne une fois par heure sur un échantillon des questions, calcule la faithfulness et la context precision, pousse les scores dans le même backend. La même interface permet alors de croiser : « sur les requêtes qui ont dégradé en faithfulness ces dernières 24h, quel modèle de re-ranking était utilisé ? »
Sans ces deux couches branchées sur la même infrastructure, vous avez soit des traces sans signal qualité, soit des scores qualité sans trace rejouable. Ni l'un ni l'autre ne suffit en production.
Le paysage des outils open source self-hostables
Section intitulée « Le paysage des outils open source self-hostables »Cette section sert de carte pour les guides suivants. Aucun outil ne fait tout — on les assemble.
| Outil | Pilier | Forces | Quand le choisir |
|---|---|---|---|
| OpenLLMetry | Traces | Auto-instrumentation OTel des SDK populaires, exporte vers Tempo/Grafana | Vous avez déjà une stack OTel et voulez juste y verser les traces LLM |
| Langfuse | Traces + prompts + evals légers | Couteau suisse, UI mature, prompts versionnés | Vous démarrez et voulez un outil unique pour 80 % du besoin |
| Arize Phoenix | Traces + evals + drift d'embeddings | Très bon sur l'analyse embeddings, dataset-driven | Vous itérez sur la qualité d'un RAG et voulez visualiser les drifts |
| Ragas | Evals (RAG) | Métriques de référence : faithfulness, answer relevancy, context precision | Vous mesurez la qualité d'une chaîne RAG |
| DeepEval | Evals (agents) | Couvre les agents multi-étapes, intégration pytest | Vous testez un agent en CI |
| promptfoo | Evals (prompts) | Testing CLI/CI, A/B tests faciles, multi-providers | Vous comparez des prompts ou des modèles dans un pipeline |
| NeMo Guardrails / Guardrails AI / LlamaGuard | Garde-fous | Filtrage entrée/sortie, protection prompt injection | Vous exposez l'agent à des utilisateurs externes |
Les guides à venir détaillent chacun de ces outils, avec un lab autonome : OpenTelemetry GenAI, Langfuse self-hosted, Phoenix, evals RAG/agents, guardrails, FinOps LLM, OWASP LLM Top 10.
Quand instrumenter — et quand attendre
Section intitulée « Quand instrumenter — et quand attendre »L'instrumentation a un coût : surcharge de code, latence (faible mais non nulle si les exports sont synchrones), volume de logs/traces à stocker. Tous les projets IA n'en sont pas au même point.
Instrumenter dès le premier prototype
Section intitulée « Instrumenter dès le premier prototype »- Capturer les prompts et complétions dans un fichier local ou un Langfuse de dev. Sans ces données brutes, impossible d'analyser un cas bizarre vu en démo.
- Logger les tokens et le coût estimé par appel. Le réflexe sauve la facture du mois de mise en prod.
Attendre la production pour le reste
Section intitulée « Attendre la production pour le reste »- L'eval automatisée en CI demande un dataset de référence — il se construit progressivement, pas en amont.
- Le prompt management versionné devient critique quand plusieurs personnes touchent aux prompts. Sur un projet solo, un fichier Markdown versionné Git suffit longtemps.
- Les guardrails s'imposent dès que l'agent est exposé à des utilisateurs externes — pas avant.
À retenir
Section intitulée « À retenir »- L'observabilité LLM répond à quatre questions que l'APM classique ignore : prompt réel, coût en tokens, latence par étape, qualité.
- Le tracing distribué (OTel) s'applique parfaitement aux agents — à
condition d'utiliser les conventions sémantiques
gen_ai.*. - Le tryptique traces / evals / prompts management structure le sujet ; aucun outil ne fait les trois aussi bien que trois outils complémentaires.
- En open source self-hostable, Langfuse est le meilleur point de départ pour 80 % des cas ; Phoenix complète bien dès qu'on travaille la qualité.
- L'instrumentation se paie au premier prototype — ne pas attendre la production pour capturer prompts et coûts.