LangSmith ajoute une prise en charge d'OpenTelemetry de bout en bout pour LangChain et LangGraph

LangSmith, plateforme de supervision d'applications à base de LLM, prend désormais pleinement en charge OpenTelemetry (OTel). Les développeurs voient les appels aux modèles de langage et le reste de leurs services dans une trace unique, via des outils familiers comme Datadog, Grafana et Honeycomb. La prise en charge couvre à la fois les chaînes LangChain et les agents à base de graphes de LangGraph.

Traité par IA depuis LangChain Blog ; édité par Hamidun News
LangSmith ajoute une prise en charge d'OpenTelemetry de bout en bout pour LangChain et LangGraph
Source : LangChain Blog. Collage: Hamidun News.
Écouter l'article
Fiche synthèse et chiffres clés
ParamètreDonnées
Source primaireLangChain Blog ↗
Rédacteur en chef
Ingestion des tracesLangSmith reçoit les données via un collecteur OTel standard, sans SDK personnalisé ni adaptateur spécifique

LangSmith, la plateforme de débogage et de supervision d'applications à base de LLM développée par l'équipe de LangChain, annonce la prise en charge complète d'OpenTelemetry. Les développeurs peuvent désormais brancher le traçage des composants d'IA sur la même pile d'observabilité que les autres services de l'application, sans maintenir en parallèle deux outils de supervision isolés.

Pourquoi les services d'IA ont besoin d'OTel

OpenTelemetry (OTel) est un standard ouvert de la CNCF pour collecter traces distribuées, métriques et journaux. Presque toutes les grandes plateformes de supervision le prennent en charge : Datadog, Grafana, Honeycomb, Jaeger, AWS X-Ray, New Relic. En production, OTel est devenu une exigence de fait : il permet de suivre le parcours de la requête d'un utilisateur à travers des dizaines de microservices, de bases de données et d'API externes dans un contexte temporel unique.

Jusqu'ici, les composants d'IA vivaient dans une bulle à part. LangSmith stockait les traces des appels aux LLM dans un format propriétaire, tandis que le reste de l'infrastructure de l'équipe reposait sur un backend OTel. À chaque incident en production, les ingénieurs devaient jongler entre deux systèmes et rapprocher à la main horodatages et contexte des appels. Cela ralentissait le diagnostic et créait des angles morts dans l'observabilité.

Ce qui change dans LangSmith

La nouvelle prise en charge d'OTel fonctionne dans les deux sens et couvre toute la pile de l'écosystème LangChain :

  • Ingestion des traces : LangSmith reçoit les données via un collecteur OTel standard, sans SDK personnalisé ni adaptateur spécifique
  • Export des données : les appels aux LLM et les traces d'agents peuvent être envoyés vers n'importe quel backend compatible OTel, notamment Datadog, Grafana Tempo, Honeycomb et Jaeger
  • Contexte de bout en bout : les traces distribuées sont reliées à travers les frontières entre services, de la requête HTTP entrante de l'utilisateur à la réponse du modèle de langage, et retour
  • Prise en charge de LangGraph : au-delà des chaînes linéaires de LangChain, le traçage OTel couvre aussi les agents complexes de LangGraph, avec boucles, étapes parallèles et branchements conditionnels

Le changement clé pour les ingénieurs : il n'est plus nécessaire d'utiliser un SDK LangChain distinct pour instrumenter la partie IA. Un agent OTel standard, déjà configuré pour le backend, se met à collecter automatiquement aussi les données de LangSmith.

Ce que gagnent les équipes en production

Prenons un incident typique : un utilisateur se plaint que la réponse d'un chatbot met 10 à 15 secondes à arriver. Auparavant, l'ingénieur ouvrait LangSmith, examinait la trace de l'appel au modèle de langage, puis passait à Datadog pour vérifier les latences réseau, les files d'attente et la base de données, avant de recoller le tout à la main.

Désormais, tout le parcours de la requête, du frontend à l'appel au LLM et au traitement final de la réponse, en passant par la passerelle d'API et l'orchestrateur, apparaît dans une seule trace continue, avec une précision à la milliseconde.

Pour les équipes qui font passer des prototypes en charge de production, cela signifie que les pratiques OTel standard, comme les alertes sur la latence p95/p99, les métriques SLO et les error budgets, s'appliquent désormais aux composants d'IA sans configuration supplémentaire.

« L'observabilité de bout en bout n'est pas qu'un confort : c'est une

exigence obligatoire pour tout système d'IA en production qui sert de vrais utilisateurs sous une vraie charge. »

Pour les clients enterprise, un point compte particulièrement : les directions informatiques ont déjà investi dans l'infrastructure OTel et imposent des exigences strictes de standardisation. Un nouvel outil qui réclame son propre tableau de bord isolé constitue toujours un obstacle supplémentaire à l'approbation de son adoption. LangSmith lève cet obstacle.

Ce que cela signifie

LangSmith avance vers la standardisation de l'observabilité de l'IA. À l'approche propriétaire du « tout dans notre seule interface », il substitue un standard ouvert qui s'intègre naturellement à l'outillage existant de l'équipe. La supervision des systèmes d'IA devient ainsi une partie du processus d'ingénierie ordinaire, et non une discipline distincte avec son propre silo de données.

Pour le marché dans son ensemble, c'est un pas de plus vers une infrastructure d'IA perçue comme une composante standard de la pile de production, et non comme un ajout exotique.

Dossier

Questions clés sur cet article

Pourquoi les services d'IA ont besoin d'OTel?

OpenTelemetry (OTel) est un standard ouvert de la CNCF pour collecter traces distribuées, métriques et journaux. Presque toutes les grandes plateformes de supervision le prennent en charge : Datadog, Grafana, Honeycomb, Jaeger, AWS X-Ray, New Relic. En production, OTel est devenu une exigence de fait : il permet de suivre le parcours de la requête d'un utilisateur à travers des dizaines de microservices, de bases de données et d'API externes dans un contexte temporel unique. Jusqu'ici, les composants d'IA vivaient dans une bulle à part. LangSmith stockait les traces des app

Que sait-on sur Ce qui change dans LangSmith ?

La nouvelle prise en charge d'OTel fonctionne dans les deux sens et couvre toute la pile de l'écosystème LangChain : Ingestion des traces : LangSmith reçoit les données via un collecteur OTel standard, sans SDK personnalisé ni adaptateur spécifique Export des données : les appels aux LLM et les traces d'agents peuvent être envoyés vers n'importe quel backend compatible OTel, notamment Datadog, Grafana Tempo, Honeycomb et Jaeger Contexte de bout en bout : les traces distribuées sont reliées à travers les frontières entre services, de la requête HTTP entrante de l'utilisateur

Que sait-on sur Ce que gagnent les équipes en production ?

Prenons un incident typique : un utilisateur se plaint que la réponse d'un chatbot met 10 à 15 secondes à arriver. Auparavant, l'ingénieur ouvrait LangSmith, examinait la trace de l'appel au modèle de langage, puis passait à Datadog pour vérifier les latences réseau, les files d'attente et la base de données, avant de recoller le tout à la main. Désormais, tout le parcours de la requête, du frontend à l'appel au LLM et au traitement final de la réponse, en passant par la passerelle d'API et l'orchestrateur, apparaît dans une seule trace continue, avec une précision à la mil

ZK
Zhemal Khamidun — CPO d'Alpina Digital, product manager d'AlpinaGPT. Conçoit des produits IA depuis 2019. Hamidun News est un projet personnel devenu un agrégateur en production avec plus de 6 000 lecteurs.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
Qu'en pensez-vous ?
Chargement des commentaires…