Observabilité LLM
Langfuse, AgentOps, LangSmith, Phoenix — les dashboards qui détectent les fuites de tokens avant votre CFO.
Ce que contient ce pack
On ne corrige pas ce qu'on ne voit pas. Le jour où une régression de prompt triple silencieusement votre facture de tokens, c'est le jour où vous regrettez de ne pas avoir installé une couche d'observabilité au trimestre dernier. Ce pack rassemble les sept ressources qui transforment une boîte noire LLM opaque en un système débogable, alertable et optimisable.
| # | Ressource | Catégorie | Ce qu'elle fait |
|---|---|---|---|
| 1 | Langfuse | open-source | traces complètes, eval, gestion de prompts — self-host ou cloud |
| 2 | AgentOps | open-source | observabilité spécifique aux agents avec replay de session |
| 3 | Arize Phoenix | open-source | traces OpenInference avec évaluateurs intégrés |
| 4 | LangSmith | hosted | plateforme de tracing et datasets de LangChain |
| 5 | Dashboards coût de tokens | pattern | ventilation par utilisateur, feature, version de prompt |
| 6 | Alertes budget de latence | pattern | p95 / p99 câblé à PagerDuty |
| 7 | Diffs de versions de prompt | pattern | replay côte-à-côte de traces entre deux versions |
Pourquoi c'est important
Trois modes d'échec en production que l'observabilité attrape et que l'intuition rate :
- Inflation silencieuse de tokens. Une édition "mineure" ajoute un rappel de 200 tokens. Multipliez par 1M de requêtes/jour et c'est 2-6k$/mois en plus que vous n'aviez pas budgété. La vue par version de prompt de Langfuse l'expose dès le premier jour.
- La queue du 95e percentile. La latence moyenne paraît bien — mais les 5% de requêtes qui tapent du cache froid, des boucles de retry ou des payloads RAG énormes plombent l'expérience utilisateur. Les dashboards p99 de Phoenix ou LangSmith rendent la queue visible.
- Régression de qualité invisible au niveau unitaire. Chaque réponse individuelle paraît plausible. Agrégez les scores d'évaluateurs (LLM-as-judge, recall de retrieval, taux d'hallucination) sur les 24 dernières heures vs les 7 jours précédents, et la régression saute aux yeux.
Installer en une commande
# Installer le pack entier
tokrepo install pack/llm-observability
# Ou choisir la plateforme par laquelle commencer
tokrepo install langfuse
tokrepo install agentops
tokrepo install phoenix
Le TokRepo CLI dépose la config SDK et le scaffolding de dashboards dans votre projet, donc les traces commencent à couler à la prochaine requête — pas de walkthrough d'instrumentation manuelle.
Pièges fréquents
- Logger les prompts complets et la PII vers un SaaS tiers. Si vos prompts contiennent des données utilisateur, self-host Langfuse ou Phoenix ; n'envoyez pas de payloads bruts à LangSmith Cloud sans rédaction. Les trois options open-source tournent sur une seule VM sous 4GB RAM pour des charges typiques.
- Pas de sampling sur les endpoints à fort volume. Tracer 100% des requêtes à 1M/jour submerge votre stockage et votre porte-monnaie. Échantillonnez 10% par défaut, 100% sur les erreurs. Langfuse et Phoenix le supportent nativement.
- Tracker les tokens mais pas les dollars. Différents modèles facturent différemment par token. Configurez le pricing modèle dans votre plateforme une fois ; trackez le coût en dollars, pas seulement en compte de tokens. Les CFO se soucient des dollars.
- Un dashboard générique pour tout le monde. Construisez un dashboard par persona — ing (latence, taux d'erreur), produit (coût par feature), exec (coût par utilisateur actif, tendance semaine sur semaine). Les dashboards génériques sont ignorés.
- Pas d'alerte sur le delta de coût par version de prompt. Ajoutez une alerte qui se déclenche quand le coût-par-appel moyen d'une nouvelle version de prompt dévie de >20% par rapport à la précédente. C'est l'alerte au plus haut ROI que vous configurerez.
Relation avec les autres packs
L'Observabilité LLM est la couche de télémétrie runtime. Le pack complémentaire LLM Eval & Guardrails est la couche de scoring offline — DeepEval, Promptfoo, Ragas. Vous voulez les deux : l'observabilité montre ce qui se passe en production, l'eval dit si un changement proposé est meilleur avant déploiement.
Les Frameworks Multi-Agent (CAMEL, LangGraph, DeepAgents) sont les systèmes instrumentés. Si vous lancez un workflow LangGraph et ne voyez pas quel nœud a échoué, vous n'avez pas d'observabilité — vous avez un debugger à print. Associez le pack framework avec celui-ci dès le premier jour.
7 ressources prêtes à installer
Questions fréquentes
Est-ce gratuit ?
Langfuse, Phoenix et AgentOps sont open-source sous MIT/Apache 2.0 et tournent sur une seule VM. Self-hosted, c'est gratuit ; vous ne payez que stockage et compute. LangSmith est seulement hosted et facturé par trace — le tier gratuit couvre les petites équipes, les prix montent à l'enterprise. Pour la plupart des équipes la bonne réponse est de commencer par Langfuse self-host, et de basculer vers LangSmith uniquement si vous êtes déjà profondément dans l'écosystème LangChain et voulez l'intégration first-party.
Comment Langfuse se compare-t-il à LangSmith ?
Langfuse est open-source, auto-hébergeable et agnostique au framework — il fonctionne avec LangChain, LlamaIndex, SDK OpenAI brut, code custom. LangSmith est closed-source, hosted et étroitement couplé à LangChain. Côté features, ils sont à peu près équivalents sur le tracing et la gestion de prompts ; LangSmith a un léger avantage sur les features spécifiques LangChain, Langfuse a un framework d'évaluateurs plus fort et une meilleure histoire de self-host. Choisissez Langfuse si la souveraineté des données compte, LangSmith si vous voulez zero-ops et êtes LangChain-natif.
Est-ce que ça fonctionnera avec Cursor ou Codex CLI ?
L'observabilité se situe au niveau de l'appel API, pas de l'éditeur — donc tout outil qui appelle une API LLM peut être instrumenté. L'install TokRepo ajoute le code init SDK à votre projet. Si vous proxiez via Claude Code, Cursor ou Codex CLI, instrumentez le backend de l'agent (le framework ou service qui appelle le LLM), pas l'éditeur. Le SDK de chaque plateforme fait 5 lignes d'import.
Quelle est la différence vs le pack LLM Eval ?
L'eval est du scoring offline — étant donné un prompt et une réponse de référence, à quel point la sortie est-elle bonne. L'observabilité est de la télémétrie runtime — ce qui s'est passé en production : latence, coût, erreurs, traces. L'eval nourrit le CI ; l'observabilité nourrit dashboards et alertes. Vous avez besoin des deux. Pattern courant : les scores d'eval de votre golden set sont loggés dans votre plateforme d'observabilité pour que qualité, coût et latence vivent sur le même dashboard.
Combien d'overhead cette instrumentation ajoute-t-elle ?
Le logging async batched ajoute ~1-3ms p50 de latence aux appels LLM — négligeable comparé à la latence modèle elle-même (souvent 500-3000ms). Les quatre plateformes livrent des SDKs async qui batchent les traces en arrière-plan. Mettez le sampling à 10% sur les endpoints à fort volume pour garder des coûts de stockage sains. L'overhead réel sur le hot-path est si bas qu'il n'y a pas de bonne raison de livrer en prod sans observabilité.
12 packs · 80+ ressources sélectionnées
Découvrez tous les packs curatés sur la page d'accueil
Retour à tous les packs