OpenTelemetry pour agents IA : guide 2026

Introduction

OpenTelemetry agents IA devient un vrai sujet dès qu'un agent cesse d'être un prototype isolé pour s'insérer dans un système multi-services. Le standard ouvert promet des traces, métriques et logs portables entre backends, sans coupler l'observabilité à un éditeur précis dès le premier jour. Si vous n'avez qu'un seul script Python qui appelle un LLM, ce n'est probablement pas le bon choix de monter une stack OpenTelemetry pour agents IA tout de suite : restez sur des logs applicatifs et un SDK plus léger. L'objectif de ce guide est de vous aider à trancher : à quel moment le standard devient un vrai levier, et à quel moment il ne fait qu'ajouter de la surface à maintenir.

Résumé rapide

Situation	OpenTelemetry (OTel)	SDK vertical (Langfuse, Phoenix…)	Logs applicatifs seuls
1 agent, 1 service, < 5 outils	Surdimensionné	Surdimensionné	Bon choix par défaut
2–4 services autour de l'agent	Bon choix pour corréler	Acceptable, mais vendor lock-in	Difficile à debugger
Workflow multi-agents + workers	Très bon choix	Bon choix, couplé au vendor	Insuffisant
Besoin de router les traces vers 2+ backends	Très bon choix (OTLP)	Limité	Non applicable
Coût d'observabilité déjà élevé	Moyen : exporter et échantillonner	Élevé sur volume	Quasi nul

À retenir vite : OpenTelemetry n'est pas un outil, c'est une couche de portage. Sa valeur apparaît quand vous voulez choisir votre backend, corréler plusieurs services ou migrer sans réécrire l'instrumentation. Pour un seul service, il est presque toujours trop tôt.

Ce que couvre réellement OpenTelemetry pour un agent IA

OpenTelemetry (OTel) est un projet CNCF qui standardise la production et l'export de traces, métriques et logs vers un backend d'observabilité. Pour un agent, cela se traduit concrètement par :

• une span par appel LLM, avec le modèle, le nombre de tokens, la latence et le coût estimé ;
• une span par appel d'outil (recherche web, RAG, API métier), rattachée à la span parente ;
• un trace_id partagé entre l'agent, le worker qui l'exécute, l'API qui l'a déclenché et le front qui l'appelle ;
• des métriques agrégées (taux d'erreur, tokens/s, coût par requête) exportables vers Prometheus, Grafana, Datadog, Honeycomb, etc.

L'API OTel est neutre. Le SDK s'instrumente dans le code de l'agent, puis l'OTLP exporter envoie les données vers le backend de votre choix. C'est cette neutralité qui rend le standard utile : vous pouvez commencer avec un backend gratuit, puis basculer sans réécrire l'instrumentation. Pour comprendre comment cet arbitrage s'inscrit dans une vision plus large, la lecture de Observabilité agents IA en production pose le décor complet de la stack d'observabilité agentique, et Evals vs observabilité agents IA clarifie ce que OTel couvre — et ce qu'il ne couvre pas.

Concrètement, OTel ne réinvente pas la roue pour les agents : il réutilise les conventions de tracing classiques (HTTP, gRPC, bases de données) et y ajoute progressivement des conventions GenAI. Ces conventions définissent des attributs stables pour les spans LLM (gen_ai.system, gen_ai.request.model, gen_ai.usage.input_tokens, etc.), ce qui permet à un backend compatible d'afficher automatiquement des vues LLM sans avoir à interpréter un schéma propriétaire. Si vous instrumentez votre agent en respectant ces conventions, vous gagnez à la fois la portabilité d'OTel et la lisibilité LLM qu'apporte un outil vertical — sans dépendre d'un éditeur en particulier.

Quand adopter OpenTelemetry et quand rester sur un SDK simple

Trois configurations où le standard apporte un vrai levier

1. Vous opérez plusieurs services autour de l'agent. Un agent moderne n'est jamais seul : il y a l'API qui reçoit la requête, le service de mémoire, le vector store, le worker asynchrone, parfois un orchestrateur de workflows. Sans standard, vous recollez les logs à la main. Avec OTel, chaque service émet ses spans, et le backend reconstruit la timeline complète à partir d'un trace_id propagé par headers HTTP ou contexte asynchrone.

2. Vous voulez éviter le couplage à un éditeur. Les SDK verticaux comme Langfuse ou Arize Phoenix sont excellents sur leur périmètre, mais leurs propres schémas d'événements restent attachés à leur plateforme. Si vous changez de backend ou si vous devez en combiner plusieurs, vous réécrivez l'instrumentation. OTel vous laisse cette porte ouverte.

3. Vous voulez corréler l'agent avec l'observabilité classique. Les équipes plateforme ont déjà Prometheus, Grafana, Datadog ou Honeycomb. En adoptant OTel, l'agent devient une brique comme une autre : mêmes dashboards, mêmes alerting, même culture d'observabilité. C'est le levier le plus sous-estimé : la réduction du coût cognitif pour les SRE qui doivent débugger un incident impliquant l'agent.

Trois cas où il vaut mieux rester sur un SDK vertical ou plus simple

Vous n'avez qu'un seul service et peu de volume. Le coût d'instrumentation OTel (dépendances, configuration, sampling, OTLP exporter) ne se justifie pas. Un SDK vertical qui capture automatiquement les appels LLM vous apporte 80 % de la valeur en 10 % du temps.

Vous avez besoin d'analyses spécifiques aux LLM. Les SDK verticaux exposent des vues préconstruites : qualité des prompts, drift des réponses, evals, comparaison de modèles. Reproduire cela dans Grafana avec OTel brut demande du travail. Sur ce périmètre, l'outil vertical gagne.

Vous êtes en phase d'exploration. Avant de figer une stack, vous voulez comparer rapidement plusieurs approches. Brancher OTel ajoute du bruit de configuration. Mieux vaut des logs JSON structurés et un SDK léger, puis migrer vers OTel quand l'architecture se stabilise.

Dans ces trois cas, le piège classique consiste à instrumenter trop tôt, à subir la dette de configuration pendant trois sprints, puis à abandonner OTel en gardant un hybride bancal. Mieux vaut décider explicitement : ou bien le standard dès le premier service qui prend de l'ampleur, ou bien un SDK léger jusqu'à la stabilité de l'architecture. Une fois la stack stabilisée, la migration vers OTel reste progressive et peu coûteuse.

Tableau de décision rapide selon maturité observabilité

Maturité de votre stack	Choix recommandé	Pourquoi
Prototype, 1 service, < 100 requêtes/jour	Logs JSON + SDK léger	OTel est surdimensionné
MVP, 1 service, volume en croissance	SDK vertical (Langfuse, Phoenix)	Démarrage rapide, vues LLM natives
Production, 2–4 services, besoin de corrélation	OTel + backend existant	Corrélation native, portage entre backends
Production, multi-agents, SLOs stricts	OTel + SDK vertical sur les spans LLM	Le meilleur des deux mondes
Multi-cloud, audit, contraintes réglementaires	OTel + collecteur + backend open source	Souveraineté des données, format ouvert

Exemple concret : instrumenter un agent multi-services avec OTel

Prenons un cas réel : un agent support qui répond à des tickets. Trois services coopèrent — une API FastAPI qui reçoit le ticket, un worker qui exécute l'agent, et un service RAG qui interroge un vector store. L'objectif : voir en un coup d'œil quel service a ralenti lors d'un incident.

Étape 1 — Installer le SDK et l'auto-instrumentation.

pip install opentelemetry-sdk \
            opentelemetry-exporter-otlp \
            opentelemetry-instrumentation-fastapi \
            opentelemetry-instrumentation-httpx

Étape 2 — Configurer le tracer une fois pour toutes.

from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

provider = TracerProvider(
    resource=Resource.create({"service.name": "support-agent-api"})
)
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="http://otel-collector:4317"))
)
trace.set_tracer_provider(provider)

Étape 3 — Instrumenter l'agent avec des spans explicites.

from opentelemetry import trace

tracer = trace.get_tracer("support-agent")

def handle_ticket(ticket_id: str):
    with tracer.start_as_current_span("agent.run") as span:
        span.set_attribute("ticket.id", ticket_id)

        with tracer.start_as_current_span("rag.retrieve"):
            context = rag.search(ticket_id)

        with tracer.start_as_current_span("llm.generate") as llm_span:
            response = llm.complete(context, ticket_id)
            llm_span.set_attribute("llm.model", "gpt-4o")
            llm_span.set_attribute("llm.tokens", response.usage.total_tokens)

Étape 4 — Propager le contexte entre services. Avec l'auto-instrumentation opentelemetry-instrumentation-httpx, chaque appel HTTP propage automatiquement les headers traceparent et tracestate. Le backend reconstruit la timeline complète : ticket reçu → RAG → LLM → réponse, sur un seul diagramme.

Étape 5 — Configurer le collecteur OTel. En production, on ne laisse jamais les services écrire directement dans le backend : on passe par un OpenTelemetry Collector qui reçoit l'OTLP, déduplique, échantillonne et route vers le bon backend (Grafana Tempo, Datadog, Honeycomb). Le collector permet aussi d'enrichir les spans avec des métadonnées d'environnement (deployment.environment, k8s.pod.name) avant export.

Étape 6 — Définir les conventions GenAI sur les spans explicites. Pour que les spans LLM soient interprétables par n'importe quel backend, fixez les attributs recommandés par les conventions OpenTelemetry GenAI : gen_ai.system (ex. openai), gen_ai.request.model, gen_ai.usage.input_tokens et gen_ai.usage.output_tokens. Cela évite d'avoir à interpréter un schéma maison et prépare la migration vers un autre backend sans réécrire l'instrumentation.

Résultat attendu : en cas de pic de latence, vous identifiez en quelques secondes si le goulot d'étranglement vient du RAG, du LLM ou du réseau — sans avoir à corréler des logs de trois services différents.

Bonnes pratiques

Trois règles terrain pour ne pas se planter avec OTel sur des agents.

Échantillonnez dès que le volume dépasse quelques centaines de requêtes par minute. L'export OTLP coûte cher en egress et en stockage. Un sampling head-based à 10 % suffit en général pour les requêtes saines, et conservez 100 % sur les erreurs. Le pattern inverse (100 % par défaut, sampling à la baisse) est plus simple mais brûle le budget.

Propagez systématiquement le contexte via HTTP et files de messages. Sans propagation, chaque service émet ses propres traces orphelines. La valeur d'OTel est dans la corrélation. Configurez l'auto-instrumentation sur les clients HTTP, gRPC et les workers asynchrones dès le départ, même si vous ne l'exploitez pas tout de suite.

Séparez les attributs techniques des attributs métier. Sur la span llm.generate, gardez llm.model, llm.tokens, llm.latency. Les attributs métier (score de satisfaction, intent détecté, présence d'un tool call) vont dans des events ou dans une plateforme d'evals. Mélanger les deux pollue les dashboards.

Limite connue : OTel ne sait pas juger la qualité d'une réponse. Il vous dit que l'agent a répondu en 1,2 s avec 800 tokens, pas si la réponse est correcte. Pour cela, gardez un SDK vertical ou une plateforme d'evals en complément — par exemple, le guide Queues pour agents IA : quand passer à l'asynchrone montre comment instrumenter ces workers avec OTel sans perdre la propagation du contexte.

Versionnez votre instrumentation comme du code applicatif. Les changements d'attributs ou de sampling sont des décisions techniques : documentez-les dans le repo, associez-les à un changeset, et prévenez l'équipe plateforme avant de modifier la config du collecteur. Une instrumentation OTel qui change silencieusement casse souvent les dashboards et les alertes qui en dépendent, et le diagnostic prend plus de temps que l'incident initial.

Questions fréquentes

Qu'est-ce qu'OpenTelemetry apporte de plus qu'un SDK vertical ?

OpenTelemetry est une couche de portage neutre vis-à-vis du backend. Un SDK vertical comme Langfuse ou Phoenix est couplé à son propre backend et à ses propres schémas d'événements. OTel vous laisse exporter vers plusieurs backends, migrer sans réécrire l'instrumentation, et réutiliser votre stack d'observabilité existante.

OpenTelemetry est-il gratuit ?

La spécification, les SDK et les protocoles (OTLP) sont open source et gratuits. Le coût vient du backend vers lequel vous exportez les données (Datadog, Honeycomb) et du volume ingéré. Pour démarrer sans frais, un collecteur OTel auto-hébergé vers Grafana Tempo ou Jaeger suffit.

Faut-il adopter OpenTelemetry dès le premier agent ?

Non. Pour un prototype ou un MVP mono-service, un SDK léger ou un outil vertical est plus rapide à mettre en place. Adoptez OTel quand vous avez au moins deux services à corréler, ou quand vous voulez éviter le couplage à un éditeur précis. Plus tôt, c'est du travail qui ne paie pas encore.

OpenTelemetry remplace-t-il Langfuse ou Phoenix ?

Pas nécessairement. OTel gère les traces et métriques ; Langfuse et Phoenix gèrent aussi les analyses spécifiques aux LLM (qualité des prompts, evals, comparaison de runs). En production, beaucoup d'équipes combinent OTel pour la corrélation multi-services et un outil vertical pour les vues LLM natives.

Quels sont les pièges fréquents avec OTel sur des agents ?

Trois pièges classiques : oublier la propagation du contexte entre services, surdimensionner l'instrumentation sur un prototype mono-service, et confondre observabilité technique (traces) et observabilité produit (qualité des réponses). Le premier se corrige avec l'auto-instrumentation HTTP, le second en démarrant avec un SDK léger, le troisième en gardant un outil d'evals en complément.

Articles liés

OpenTelemetry pour agents IA n'est pertinent qu'à partir du moment où l'agent s'insère dans une stack multi-services. Pour cadrer d'abord la vision d'ensemble de l'observabilité agentique et comprendre où se place OTel, commencez par Observabilité agents IA en production. Pour comparer l'approche standard aux outils verticaux les plus utilisés, lisez Langfuse et Arize Phoenix. Pour bien distinguer ce qu'OTel voit de ce qu'une plateforme d'evals juge, le guide Evals vs observabilité agents IA est le complément direct. Enfin, si vous opérez déjà des workers asynchrones, Queues pour agents IA : quand passer à l'asynchrone montre comment propager le contexte OTel à travers une file sans casser la corrélation.

• Observabilité agents IA en production
• Langfuse
• Arize Phoenix
• Evals vs observabilité agents IA
• Queues pour agents IA : quand passer à l'asynchrone