Observabilité LLM en 2026 : guide pratique de Langfuse, Helicone et LangSmith

Six mois après la mise en production de votre fonctionnalité IA, les mêmes questions reviennent au stand-up. Pourquoi la latence p95 de l'assistant a doublé la semaine dernière. Pourquoi la facture OpenAI a bondi de 38 pour cent d'un mois sur l'autre sans changement de trafic. Pourquoi un client signale que l'agent propose en boucle le même appel d'outil cassé. Personne dans l'équipe ne peut répondre avec certitude, parce que la seule observabilité disponible, ce sont les logs applicatifs et un tableau Datadog qui ne sait rien des prompts, des tokens ou des traces.

C'est précisément le vide que les plateformes d'observabilité LLM viennent combler. En 2026, trois projets dominent la conversation : Langfuse, Helicone et LangSmith. Ils se recouvrent dans les pages marketing et divergent fortement à l'usage quotidien. Cet article détaille ce que chacun fait vraiment bien, où apparaissent les coutures, et comment choisir sans s'enfermer chez un fournisseur.

Ce que l'observabilité LLM signifie réellement

L'observabilité applicative — logs, métriques, traces — suppose du code déterministe. Même entrée, même sortie, erreurs typées, et une pile d'appels qui pointe vers une ligne. Rien de cela n'est vrai pour un appel LLM. Le même prompt, le même modèle, la même température peuvent produire des sorties différentes d'une exécution à l'autre. Les erreurs sont en général sémantiques, pas exceptionnelles. Un appel "réussi" peut renvoyer un JSON halluciné qui fera planter l'étape suivante trois secondes plus tard.

L'observabilité LLM doit donc capturer une forme de données différente. Le minimum utile :

• Les traces — l'arbre complet des appels LLM, appels d'outils, retrievals et décisions intermédiaires pour une seule requête utilisateur. Sans cela, déboguer un agent multi-étapes relève de la divination.
• Les entrées et sorties intégrales — pas seulement les métadonnées. Il faut le prompt réel qui est entré et la complétion réelle qui est sortie, y compris les system prompts, les définitions d'outils et les schémas de sortie structurée.
• Le nombre de tokens et le coût par requête — ventilés par modèle, par utilisateur, par fonctionnalité, par tenant. Le tableau OpenAI ne sait pas répondre à "quelle fonctionnalité fait monter la facture" parce qu'il n'a aucun contexte applicatif.
• La latence à chaque nœud — latence modèle, latence réseau, temps d'attente, temps d'exécution d'outil. Agréger la latence end-to-end masque le vrai goulot d'étranglement.
• Les signaux de feedback utilisateur — pouce levé, pouce baissé, régénérer, sortie copiée. La boucle fermée entre la réaction utilisateur et la trace est le point de départ des évaluations.
• Les résultats d'évaluation — scores programmatiques ou LLM-as-judge sur les traces de production, exécutés en continu, pas seulement en CI.
• Les versions de prompts — quel prompt était déployé quand, qui l'a modifié, et quelles traces ont tourné contre quelle version.

Une plateforme qui vous offre moins de cinq de ces éléments n'est pas de l'observabilité, c'est du logging avec une plus belle interface. Avec cette barre posée, voici comment les trois leaders s'alignent.

Langfuse : le standard open source

Langfuse est une plateforme open source d'ingénierie LLM, avec une offre cloud hébergée et un déploiement Docker entièrement auto-hébergeable. C'est le projet vers lequel la plupart des équipes convergent quand elles veulent un tracing sérieux sans s'engager auprès d'un éditeur fermé.

Le modèle de données est le plus solide de la catégorie. Une trace est un arbre d'observations imbriquées, où chaque observation est une génération, un span, un événement ou un score. Vous pouvez attacher des métadonnées arbitraires, des user IDs, des session IDs, des tags et des charges utiles input/output structurées à n'importe quel niveau. Cela paraît ennuyeux jusqu'au moment où vous essayez de filtrer "toutes les traces du tenant 42 sur les dernières 24 heures où le dernier appel d'outil est payment_charge et où l'évaluation utilisateur est négative" — Langfuse répond à cette requête en deux clics.

L'instrumentation est indépendante du fournisseur. Les SDK Python et TypeScript enveloppent n'importe quel client LLM ; il existe des décorateurs de première classe pour OpenAI, Anthropic, LangChain, LlamaIndex, Vercel AI SDK, et un mode générique compatible OpenTelemetry qui ingère des traces de tout ce qui émet de l'OTel. Une intégration typique :

from langfuse.decorators import observe
from langfuse.openai import openai
 
@observe()
def answer_question(user_id: str, question: str):
    return openai.chat.completions.create(
        model="gpt-5-turbo",
        messages=[{"role": "user", "content": question}],
    )

Le décorateur @observe crée une trace et attache la génération OpenAI comme observation imbriquée automatiquement. Ajoutez langfuse_context.update_current_trace(user_id=user_id, tags=["beta"]) pour attacher du contexte, et la trace apparaît dans l'interface avec input/output complets, comptes de tokens et latence ventilée par étape.

L'histoire des évaluations est l'endroit où Langfuse a pris de l'avance ces douze derniers mois. Vous pouvez définir des évaluateurs depuis l'interface (LLM-as-judge, Python custom, regex) et les exécuter automatiquement sur un échantillon de traces de production, à la demande sur des traces historiques, ou en CI contre un dataset fixe. Le même évaluateur tourne dans les trois contextes, donc le score que vous calibrez sur un dataset CI est celui que vous regardez sur le trafic de production. Peu de plateformes réussissent cette boucle.

La gestion des prompts est intégrée. Les prompts vivent comme des objets versionnés avec des labels A/B optionnels (production, staging, expérimental), et le SDK les récupère par label à l'exécution. Combinée aux traces, vous pouvez répondre à "le taux de clic a-t-il chuté après le déploiement du prompt v17" sans quitter la plateforme.

L'auto-hébergement est le différenciateur qui remporte les deals entreprise dans les industries régulées. La plateforme complète tourne sur Postgres plus ClickHouse pour l'analytique, se déploie avec Docker Compose ou Helm, et n'envoie jamais un octet à Langfuse Cloud. Pour les entreprises MENA confrontées à des exigences de résidence des données — PDPL saoudien, PDPL émirati, Loi 63 tunisienne — c'est souvent non négociable.

Le compromis : Langfuse est une plateforme, pas un produit. L'onboarding est plus lourd que ce que les SDK laissent croire. Le tableau de bord est dense, le pipeline d'évaluation suppose que vous comprenez ce qu'un LLM-as-judge mesure vraiment, et la stack auto-hébergée demande quelqu'un capable de faire tourner ClickHouse sans broncher. Pour les équipes qui livrent des fonctionnalités IA dans l'urgence, c'est de la friction.

Helicone : le tracker de coûts en mode proxy

Helicone fait un pari architectural différent. Au lieu de vous demander d'instrumenter votre code, il s'installe en proxy devant le fournisseur de modèle. Vous changez une seule URL — api.openai.com devient oai.helicone.ai — vous ajoutez un header d'authentification, et chaque requête passe par l'edge Helicone avec logging complet, cache, rate limiting et tracking de coût.

from openai import OpenAI
 
client = OpenAI(
    base_url="https://oai.helicone.ai/v1",
    default_headers={
        "Helicone-Auth": f"Bearer {HELICONE_API_KEY}",
        "Helicone-User-Id": user_id,
    },
)

Trois lignes, zéro refactor. Pour les équipes avec des bases de code en désordre où instrumenter signifierait toucher quarante fichiers, c'est franchement magique. Pour les équipes qui font tourner des fonctions serverless ou des edge workers où le poids du SDK compte, l'approche proxy évite aussi la taxe de cold-start d'un SDK de tracing lourd.

La surface de contrôle des coûts est la raison la plus forte de choisir Helicone. Des fonctionnalités intégrées qui prennent des jours à câbler ailleurs :

• Tableaux de coûts par utilisateur et par organisation prêts à l'emploi, indexés par les headers que vous passez
• Cache de prompts avec TTL configurables au niveau du proxy, transparent pour l'application
• Rate limiting par utilisateur, par clé API, par modèle, avec règles personnalisées ("les utilisateurs free tier ont 50 requêtes par jour à gpt-5")
• Retries et fallbacks vers un autre modèle quand le primaire renvoie une erreur, configurés depuis le tableau de bord
• Alertes de coût qui vous bipent quand un seul utilisateur franchit un seuil (l'explosion de facture classique due à une injection de prompt)

Le modèle de tracing est plus plat que celui de Langfuse. Helicone groupe les requêtes en sessions via un header que vous passez, mais n'exprime pas nativement les relations parent-enfant dont les agents multi-étapes ont besoin. Un modèle de custom-properties vous emmène presque jusqu'au bout, mais si vous construisez des flux agentiques profondément imbriqués, vous sentirez la contrainte.

Les évaluations existent mais sont moins matures. La gestion des prompts s'améliore mais reste secondaire derrière l'histoire du tracking de coûts.

Le positionnement honnête : Helicone est le bon choix quand votre principale douleur opérationnelle est la visibilité des coûts et le rate limiting, quand votre stack est principalement des appels directs aux API OpenAI/Anthropic, et quand vous ne voulez pas toucher au code applicatif. C'est moins le bon choix quand vous construisez des frameworks d'agents où l'arbre de trace est l'artefact de debug principal.

L'auto-hébergement est supporté via Docker, mais l'architecture proxy signifie que vous devez aussi faire tourner un ingress haute disponibilité devant chaque appel modèle, ce qui élève la barre opérationnelle.

LangSmith : l'outil de pouvoir natif LangChain

LangSmith est construit et opéré par l'équipe LangChain, et cette origine se voit dans chaque décision produit. Si votre stack est LangChain ou LangGraph, LangSmith est la voie de moindre résistance. Définissez deux variables d'environnement et chaque chaîne, agent et exécution de graph apparaît comme une trace, avec l'imbrication et les métadonnées correctes, sans aucun décorateur :

export LANGCHAIN_TRACING_V2=true
export LANGCHAIN_API_KEY=ls__...
export LANGCHAIN_PROJECT=production

Pour les utilisateurs de LangGraph en particulier, LangSmith restitue la topologie du graphe, les transitions d'état entre les nœuds et les entrées/sorties de chaque nœud avec une fidélité qu'aucun concurrent n'égale. Déboguer un agent bloqué en boucle dans LangGraph sans LangSmith est pénible ; avec lui, vous pouvez rejouer n'importe quelle trace depuis n'importe quel nœud, échanger un prompt et relancer.

Le framework d'évaluation est le plus opinionné du marché. LangSmith livre des évaluateurs par paires, des évaluateurs basés sur des références, des évaluateurs custom et des suites de régression pilotées par dataset avec un support de première classe pour les files d'annotation humaine. La fonctionnalité "Annotation Queue" — où vous poussez des traces de production dans une UI de labellisation pour des reviewers humains — est l'implémentation la plus propre du pattern "humains dans la boucle d'évaluation" que vous trouverez.

La gestion des prompts est mature, avec un hub public de prompts (templates forkables), un historique de versions et un playground qui vous laisse changer de modèle et rejouer n'importe quel prompt contre n'importe quel dataset.

Trois choses à savoir avant de s'engager.

Premièrement, LangSmith est opinionné en faveur de l'écosystème LangChain. Le SDK générique fonctionne avec n'importe quel appel LLM, mais la magie — l'auto-tracing, le rendu de graphe, l'introspection profonde de l'état de l'agent — a besoin de LangChain ou LangGraph. Si votre stack est Vercel AI SDK, Pydantic AI, Mastra ou des appels OpenAI faits à la main, vous obtenez une expérience plus mince.

Deuxièmement, LangSmith est un produit hébergé. Une offre entreprise auto-hébergée existe mais le pricing est verrouillé derrière la vente, et l'histoire du déploiement est plus lourde que Langfuse. Pour les équipes qui ont besoin d'on-premise dès le jour un et qui n'ont pas d'appétit pour AWS marketplace, c'est de la friction.

Troisièmement, le pricing s'est déplacé vers le haut à mesure que la plateforme mûrissait. La facturation par trace au-delà du tier gratuit est raisonnable à petite échelle mais s'accumule rapidement quand vous franchissez les millions de traces par mois, ce qui est où vivent les produits IA en production. Budgétez-le avant de vous engager.

Choisir un : un cadre de décision

Le verdict honnête après avoir déployé les trois sur des projets différents :

• Choisissez Langfuse si vous voulez la plateforme la plus équilibrée, si vous valorisez l'open source et l'auto-hébergement, et si vous avez au moins un ingénieur capable de porter la stack d'observabilité. C'est le pari long terme le plus sûr pour une équipe produit IA sérieuse qui veut éviter le vendor lock-in.

• Choisissez Helicone si la visibilité des coûts et le rate limiting sont vos douleurs principales, si votre application est principalement des appels API directs sans imbrication d'agents profonde, et si vous voulez livrer l'intégration en un après-midi sans toucher au code applicatif. C'est le chemin le plus rapide vers "on sait maintenant ce que la facture va être".

• Choisissez LangSmith si vous êtes déjà sur LangChain ou LangGraph et que la topologie de l'agent est la chose principale que vous avez besoin de déboguer. Le tracing conscient du graphe est franchement un cran au-dessus de ce que les deux autres font pour cette charge précise.

Ces choix ne sont pas mutuellement exclusifs. Le pattern pragmatique vers lequel beaucoup d'équipes convergent : Helicone comme proxy pour le contrôle des coûts et le rate limiting (parce que l'intégration est gratuite et que le tableau de coûts se rembourse en une semaine), plus Langfuse ou LangSmith pour les traces, les évaluations et la gestion des prompts. Les deux couches ne se battent pas ; elles capturent des signaux différents.

La question du coût

Une note sur ce que ces plateformes coûtent vraiment en production. Pour une app qui fait un million d'appels LLM par mois avec une profondeur moyenne de trace de trois observations par appel (donc environ trois millions d'observations), comptez dépenser entre 200 et 500 USD par mois sur les tiers hébergés. Langfuse auto-hébergé sur une seule machine Hetzner gère ce volume pour bien en dessous de 50 USD par mois d'infrastructure, au prix d'une journée-ingénieur par mois de maintenance.

Comparez cela à la facture des modèles — les mêmes un million d'appels sur gpt-5 avec 2K de contexte moyen coûtent au-delà de 8 000 USD par mois — et l'observabilité devient une erreur d'arrondi. Les équipes qui sautent cette dépense pour des raisons de coût optimisent en général la mauvaise variable. Le bon cadrage : dépenser 3 pour cent de la facture des modèles pour savoir exactement où passent les 97 pour cent restants.

Par quoi commencer

Pour une équipe qui monte une observabilité LLM à partir de zéro, l'ordre à plus fort levier :

1. Faites couler les traces. Choisissez l'un des trois, instrumentez le chemin à plus fort trafic, acceptez que la première semaine de traces sera moche. La visibilité bat l'élégance.
2. Attachez les user IDs. Sans user IDs sur les traces, vous ne pouvez pas répondre au ticket support "pourquoi le bot a fait ça à mon compte mardi".
3. Taggez les traces par fonctionnalité. Sans tags de fonctionnalité, vous ne pouvez pas répondre à "quelle feature fait monter la facture" — et cette question arrivera dans le premier mois.
4. Ajoutez la capture de feedback utilisateur. Pouce levé et pouce baissé sur chaque message d'assistant, liés à l'ID de trace. C'est le dataset dont dépendent toutes les évaluations futures.
5. Câblez une seule évaluation. Commencez avec un seul LLM-as-judge sur un seul type de trace — "l'agent a-t-il répondu à la vraie question de l'utilisateur, oui ou non". Faites-la tourner sur chaque trace de production. Regardez le score dans le temps.
6. Ensuite seulement parlez de gestion de prompts. Tant que vous n'avez pas les traces, les user IDs, les tags de fonctionnalité, le feedback et au moins une évaluation, le versioning de prompts est prématuré.

La plupart des équipes essaient de commencer par la gestion de prompts et un framework d'évaluation, puis bricolent le tracing plus tard quand elles se heurtent à un incident côté client. L'ordre devrait être inversé. Le tracing est la fondation ; tout le reste est une couche au-dessus.

Où va cette histoire

La frontière en 2026 se déplace vers l'observabilité des agents — des outils qui comprennent la différence entre un appel LLM, un appel d'outil, une étape de planification et une écriture en mémoire, et qui peuvent rejouer les trajectoires d'agents avec les mutations d'état intactes. Langfuse et LangSmith livrent tous deux dans cette direction ; attendez-vous à un mouvement de fonctionnalités significatif sur les deux prochains trimestres.

Pour un contexte plus profond sur la façon de structurer des flux d'agents réellement observables, notre guide d'évaluation des agents IA couvre le cadre des métriques, et le guide sur la mémoire des agents IA couvre la surface de mutation d'état que les plateformes d'observabilité doivent modéliser.

L'équipe qui gagnera les douze prochains mois d'ingénierie IA ne sera pas celle qui a les meilleurs prompts. Ce sera celle qui sait, à n'importe quel moment, exactement quels prompts ont tourné, ce qu'ils ont coûté, ce qu'ils ont renvoyé, et ce que l'utilisateur a fait ensuite. C'est ce que ces trois plateformes existent pour rendre possible.