"OpenTelemetry en 2026 : cartographie de l'écosystème et guide de choix pour votre observabilité"

L'observabilité est fragmentée. OpenTelemetry la réunifie.

Prometheus pour les métriques, Jaeger pour les traces, Fluentd ou Promtail pour les logs. Trois agents, trois formats, trois pipelines à maintenir -- et une corrélation entre signaux qui repose sur du bricolage maison. Pendant des années, l'observabilité s'est construite en silos, chaque outil couvrant son périmètre sans se soucier des autres.

OpenTelemetry change la donne. Incubé par la CNCF, le projet fournit un standard unique pour instrumenter, collecter et transmettre les trois signaux de télémétrie. En 2026, les SDK pour les principaux langages sont stables, le protocole OTLP est supporté par tous les backends majeurs, et le Collector est déployé en production par des milliers d'organisations. OTel n'est plus un pari : c'est le socle de l'observabilité moderne.

Pour rendre ce panorama concret, cet article s'appuie sur deux cas fictifs qui reviendront tout au long du texte :

• NovaTech (PME, 15 développeurs) : stack Kubernetes, Prometheus + Grafana depuis trois ans. L'équipe veut moderniser vers une stack open-source complète couvrant métriques, traces et logs, sans vendor lock-in.
• Meridian Group (grand compte, 200+ développeurs) : dizaines de services, agents Datadog partout. La direction technique veut reprendre le contrôle de la collecte, normaliser la taxonomie des signaux via OTel, tout en conservant Datadog comme backend d'analyse.

Deux trajectoires différentes, un même outil.

Les composants fondamentaux d'OpenTelemetry

Les trois signaux : métriques, traces, logs

Prometheus, Jaeger et Fluentd collectaient déjà chaque signal très correctement. Ce qu'apporte OTel, c'est la corrélation native entre les signaux.

Concrètement, cela se traduit par trois mécanismes :

• Trace ID dans les logs. Chaque ligne de log émise pendant le traitement d'une requête porte l'identifiant de la trace correspondante. Depuis un log d'erreur, vous remontez en un clic à la trace complète -- toutes les spans de la requête, du point d'entrée jusqu'à l'origine du problème.
• Exemplars dans les métriques. Un pic de latence sur un dashboard Grafana ? L'exemplar rattaché à ce point de donnée pointe directement vers la trace qui l'a produit. Plus besoin de deviner quelle requête a causé le spike.
• Attributs de resource partagés. service.name, deployment.environment, k8s.pod.name -- les mêmes attributs annotent les trois signaux. Le filtre que vous posez sur un dashboard de métriques fonctionne aussi sur les traces et les logs.

Avant OTel, obtenir cette corrélation demandait de coller Prometheus, Jaeger et Fluentd avec du ruban adhésif : propagation manuelle de trace IDs, conventions d'attributs maison, scripts de jointure. OpenTelemetry rend tout cela natif et automatique.

Les SDK d'instrumentation

OpenTelemetry propose deux approches pour instrumenter vos applications.

La première : l'auto-instrumentation. Zéro modification de code. En Java, un agent JVM intercepte les appels aux frameworks courants (Spring, gRPC, JDBC). En Python, un hook site-packages instrumente automatiquement FastAPI, Flask, SQLAlchemy. En Node.js, un flag --require suffit. Vous obtenez des traces et des métriques sur toutes les couches d'infrastructure -- serveurs HTTP, clients SQL, files de messages -- sans toucher au code applicatif.

La seconde : l'instrumentation manuelle. Vous créez vos propres spans et attributs dans la logique métier. C'est indispensable pour capturer le contexte qui compte vraiment : l'identifiant du tenant, le flag de feature, le montant d'une transaction. L'auto-instrumentation vous dit que votre endpoint a répondu en 450 ms. L'instrumentation manuelle vous dit que c'est le calcul de tarification pour le client X qui a pris 380 ms.

Les deux approches se combinent. L'auto-instrumentation pose le squelette, l'instrumentation manuelle enrichit les points critiques.

Maturité des SDK par langage :

En pratique :

• NovaTech démarre avec l'auto-instrumentation sur ses services FastAPI, Express et Spring Boot. Le gain est immédiat : traces distribuées et métriques HTTP en quelques minutes de configuration. L'instrumentation manuelle viendra dans un second temps pour les flux métier critiques (paiements, calculs de scoring).
• Meridian Group fait l'inverse. Avec Datadog déjà en place pour la couverture de base, l'équipe déploie l'instrumentation manuelle ciblée pour enrichir les spans avec le contexte métier : tenant.id, feature.flag, business.unit. L'auto-instrumentation OTel remplace progressivement les agents Datadog comme source de collecte.

Le protocole OTLP

OTLP est le protocole natif d'OpenTelemetry. Un seul format pour les trois signaux, disponible en gRPC et HTTP/protobuf. Son adoption massive par les backends est ce qui rend OTel réellement viable en production : vous instrumentez une fois, vous exportez vers le backend de votre choix.

L'intérêt stratégique est direct. Avec OTLP, votre instrumentation est découplée de votre backend. Si vous décidez de migrer de Jaeger vers Grafana Tempo, ou d'ajouter un second backend pour un signal spécifique, vous changez la configuration de l'exporter -- pas une ligne de code applicatif.

Support OTLP par backend :

Le Collector

Le Collector est la pièce centrale de l'architecture OTel en production. C'est un proxy de télémétrie configurable par pipeline qui reçoit, transforme et réexpédie les données vers un ou plusieurs backends.

Son architecture repose sur trois types de composants chaînés :

• Receivers : points d'entrée. OTLP, Prometheus scrape, Jaeger Thrift, Zipkin, syslog -- le Collector parle tous les protocoles.
• Processors : transformation en transit. Filtrage de spans non pertinents, échantillonnage par taux ou par tail-based sampling, renommage d'attributs pour normaliser la taxonomie, ajout de métadonnées Kubernetes, batching pour optimiser les envois réseau.
• Exporters : sorties vers les backends. OTLP, Prometheus remote write, Datadog API, fichiers, Kafka -- chaque signal peut partir vers un backend différent.

Chaque signal (traces, métriques, logs) dispose de son propre pipeline. Vous pouvez échantillonner les traces à 10 % tout en gardant 100 % des métriques et en filtrant les logs de debug -- le tout dans une seule instance de Collector.

Deux modes de déploiement de base :

• Agent : déployé en sidecar ou DaemonSet, au plus près des applications. Léger, il fait du batching et du forwarding avec un minimum de transformation.
• Gateway : déployé en service centralisé. Il concentre le trafic de plusieurs agents et applique les traitements lourds : échantillonnage tail-based, enrichissement, routage.

L'architecture multiétages est le pattern qui déverrouille la scalabilité du Collector. Plutôt qu'un seul niveau de collecte, vous empilez les Collectors en couches, chacune avec un rôle précis :

• Étage 1 -- Agents légers. Collecte au plus près des applications. Batching basique, envoi vers l'étage suivant. Empreinte mémoire minimale, configuration simple.
• Étage 2 -- Gateways intermédiaires. Filtrage, échantillonnage intelligent (tail-based sampling sur les traces en erreur ou lentes), enrichissement avec les métadonnées Kubernetes, normalisation des noms d'attributs.
• Étage 3 -- Gateway central. Routage vers les différents backends selon le signal, le tenant ou la criticité. C'est ici que vous décidez que les traces vont vers Tempo, les métriques vers Mimir, et qu'une copie des logs critiques part vers un stockage long terme sur ClickHouse.

Tous les environnements n'ont pas besoin des trois étages. Le nombre de couches dépend du volume, de la complexité organisationnelle et du nombre de backends.

En pratique :

• NovaTech déploie une architecture à deux étages. Des agents OTel en DaemonSet sur chaque nœud Kubernetes collectent les trois signaux et les envoient à un gateway centralisé. Ce gateway applique un tail-based sampling sur les traces (conserve 100 % des traces en erreur, 5 % du trafic nominal) et exporte vers Grafana Tempo (traces), Mimir (métriques) et Loki (logs). Simple, efficace, adapté à la taille de l'équipe.
• Meridian Group a besoin de trois étages. Les agents applicatifs (étage 1) collectent les signaux bruts. Des gateways par domaine métier (étage 2) normalisent la taxonomie des attributs (team, business.unit, tenant.id) et appliquent les règles de filtrage propres à chaque équipe. Un gateway central (étage 3) route les données vers Datadog (backend principal) et vers un cluster ClickHouse interne (rétention longue durée, requêtes analytiques). Cette architecture permet à chaque équipe de garder ses conventions tout en alimentant un backend unifié.

Comparatif des backends compatibles OTel

Le choix du backend d'observabilité reste une décision structurante. Mais avec OTel, cette décision devient réversible. Le Collector absorbe la complexité d'intégration : changer de backend revient à modifier un exporter, pas à réinstrumenter vos applications. Voyons ce que le marché propose en 2026.

Backends open-source

Grafana Stack (Mimir / Tempo / Loki) reste le choix par défaut pour une stack open-source complète. Le trio couvre les trois signaux avec un support OTLP natif sur chaque composant. L'écosystème de dashboards est inégalé, et la communauté est massive. C'est la pile que la plupart des équipes évaluent en premier -- à juste titre.

SigNoz se positionne comme l'alternative tout-en-un. Un seul binaire, un backend ClickHouse, une interface unifiée pour les trois signaux. Moins flexible que la stack Grafana, mais considérablement plus simple à déployer et à opérer pour une petite équipe.

Jaeger, longtemps la référence pour le tracing distribué, perd du terrain en tant que projet autonome. Grafana Tempo absorbe progressivement son rôle, et l'investissement communautaire se déplace. Jaeger reste viable pour des déploiements existants, mais ce n'est plus le choix évident pour un projet greenfield.

VictoriaMetrics excelle sur les métriques. Compatible Prometheus, plus économe en ressources, avec une rétention longue durée efficace. Mais l'absence de support natif pour le tracing limite son périmètre. C'est un excellent complément, pas un backend universel.

ClickHouse est un moteur analytique redoutable pour le stockage long terme de télémétrie. Requêtes SQL sur des milliards de spans, coût de stockage maîtrisé, rétention sur plusieurs années. En revanche, ce n'est pas une plateforme d'observabilité clé en main : il faut construire ou intégrer la couche de visualisation et d'alerting.

Le cas Grafana Labs mérite une attention particulière. Depuis 2024, Grafana Labs opère un glissement progressif vers un modèle plus fermé. Les modes de déploiement single-binary pour Mimir, Tempo et Loki sont abandonnés au profit d'architectures microservices complexes. La documentation des Helm charts se raréfie, rendant le self-hosting plus ardu. Certaines fonctionnalités -- Adaptive Metrics, certains panneaux de visualisation avancés -- sont réservées à Grafana Cloud. Ce drift renforce l'argument en faveur d'OTel comme couche d'assurance : si le Collector est votre point d'abstraction, migrer hors de Grafana ne coûte qu'un changement de configuration d'exporter. L'investissement dans l'instrumentation, lui, reste intact.

Backends SaaS

Tous les grands SaaS supportent désormais OTLP en natif. Le verrouillage ne se situe plus au niveau du protocole, mais au niveau des fonctionnalités propriétaires construites par-dessus : alerting intelligent, corrélation automatique, interfaces de debug. Ces fonctionnalités ont de la valeur. Elles ne justifient plus, en revanche, de coupler votre instrumentation au SDK propriétaire du vendor.

Le message clé : avec OTel et le Collector comme point de routage, changer de backend SaaS revient à modifier la configuration d'un exporter. Pas une ligne de code applicatif à toucher, pas un agent à redéployer sur vos nœuds.

Quel backend pour quel contexte ?

• NovaTech opte pour la Grafana Stack (Mimir / Tempo / Loki). L'équipe utilise déjà Grafana pour ses dashboards Prometheus -- la transition est naturelle. Mimir remplace Prometheus comme stockage de métriques, Tempo apporte le tracing, Loki centralise les logs. Le Collector OTel alimente les trois. Et si Grafana Labs poursuit son drift vers un modèle plus fermé ? Le Collector protège l'investissement : un changement d'exporter suffit pour basculer vers SigNoz ou une autre stack.
• Meridian Group conserve Datadog comme backend principal d'analyse -- les équipes y sont formées, les dashboards et alertes sont en place. En parallèle, un cluster ClickHouse interne reçoit une copie des données via le Collector pour l'archivage long terme et les requêtes analytiques à moindre coût. Le vendor lock-in est cassé du côté de la collecte : les agents Datadog propriétaires sont progressivement remplacés par le Collector OTel, qui alimente les deux backends simultanément.

Semantic Conventions et taxonomie des signaux

Le référentiel des Semantic Conventions

Instrumenter avec OTel ne suffit pas. Encore faut-il que les attributs portés par vos signaux soient nommés de manière cohérente. C'est le rôle des Semantic Conventions.

Le projet OTel maintient un référentiel de noms d'attributs standardisés, couvrant les cas d'usage les plus courants :

• http.request.method, http.response.status_code pour les appels HTTP
• db.system, db.statement pour les requêtes base de données
• rpc.method, rpc.service pour les appels RPC
• service.name, service.version, deployment.environment pour les attributs de ressource
• k8s.pod.name, k8s.namespace.name pour le contexte Kubernetes

Sans ces conventions partagées, chaque équipe invente ses propres noms : method vs http_method vs request.method. Les dashboards deviennent impossibles à maintenir à l'échelle, les alertes cassent à chaque onboarding d'un nouveau service, et la corrélation entre signaux repose sur des conventions orales.

Les Semantic Conventions éliminent ce problème. Un attribut nommé http.request.method est compris par tous les backends, tous les dashboards, tous les outils de la chaîne.

Construire sa taxonomie interne

Les Semantic Conventions couvrent les attributs d'infrastructure. Mais votre métier a ses propres dimensions : identifiant du tenant, feature flag actif, domaine métier, niveau de criticité. Ces attributs ne figurent dans aucun référentiel OTel -- c'est à vous de les définir.

La bonne pratique : étendre les Semantic Conventions avec un préfixe interne. Par exemple biz.tenant.id, biz.feature.flag, biz.domain. Le préfixe évite les collisions avec les attributs standard actuels et futurs.

Le Collector joue un rôle central dans la gouvernance de cette taxonomie. Le transform processor permet de renommer les attributs non conformes, d'enrichir les signaux avec des métadonnées manquantes, et de valider la présence des attributs obligatoires. Le Collector devient ainsi le point de normalisation : même si une équipe instrumente avec des noms d'attributs légèrement différents, le pipeline corrige en transit.

• NovaTech s'en tient aux Semantic Conventions standard. Avec 15 développeurs et une stack homogène, la convention OTel couvre l'essentiel des besoins. Quelques attributs métier (tenant.id, plan.tier) sont ajoutés manuellement dans l'instrumentation.
• Meridian Group documente une taxonomie interne complète, publiée dans un référentiel partagé. Le gateway du Collector (étage 2) applique les règles de normalisation : renommage des attributs non conformes, ajout automatique du business.unit à partir du label Kubernetes du namespace. Les équipes instrumentent librement -- le gateway garantit la cohérence en sortie.

Stratégie d'adoption : par où commencer ?

Une adoption progressive

L'erreur classique : vouloir tout migrer d'un coup. L'adoption d'OTel se fait par étapes, en commençant par le signal qui apporte le plus de valeur immédiate.

Étape 1 -- Commencer par le tracing. C'est le signal où OTel apporte le plus par rapport à l'existant. La plupart des organisations ont déjà Prometheus pour les métriques et un agrégateur de logs. En revanche, le tracing distribué est souvent absent ou mal implémenté. L'auto-instrumentation OTel donne des traces exploitables en quelques heures de configuration.

Étape 2 -- Déployer le Collector en parallèle. Ne remplacez pas votre stack existante du jour au lendemain. Déployez le Collector en mode double-write : les données partent à la fois vers votre backend actuel et vers le nouveau. Pendant la période de transition, vous validez la qualité des données OTel sans risque de régression sur votre monitoring en place.

Étape 3 -- Migrer les métriques en dernier. Prometheus fonctionne. L'urgence n'est pas là. Quand le tracing et les logs sont stabilisés via OTel, vous pouvez envisager de remplacer le scrape Prometheus par une collecte OTLP. Mais ce n'est pas une priorité immédiate.

Un point fondamental : le tracing exige une coordination dev + infra. Contrairement aux métriques (souvent gérées par l'infra seule) ou aux logs (émis naturellement par les applications), le tracing distribué implique les deux mondes. Les développeurs doivent s'accorder sur les noms de spans, les attributs à propager, les points d'instrumentation manuelle. Sans cette coordination, vous obtenez des traces techniquement valides, mais fonctionnellement inutilisables -- des spans sans contexte métier, des attributs incohérents d'un service à l'autre.

• NovaTech : un atelier d'une demi-journée suffit pour aligner les 15 développeurs sur les conventions de nommage des spans et les attributs métier à propager. L'équipe est petite, la communication est directe.
• Meridian Group : avec 200+ développeurs répartis en dizaines d'équipes, l'alignement ne se décrète pas -- il se structure. Un "observability champion" par équipe porte les conventions et remonte les frictions. La taxonomie est documentée dans un référentiel partagé, et le Collector gateway normalise ce qui dévie.

Les pièges à éviter

• Vouloir tout instrumenter manuellement dès le premier jour. L'auto-instrumentation couvre 80 % des besoins. Commencez par là, ajoutez l'instrumentation manuelle sur les flux critiques ensuite.
• Ignorer le coût de cardinalité sur les métriques. Un attribut supplémentaire avec 1 000 valeurs distinctes multiplie par 1 000 le nombre de séries temporelles. La facture suit.
• Déployer le Collector sans pipeline de filtrage. Tout envoyer vers le backend revient à payer pour du bruit. Configurez dès le départ un échantillonnage sur les traces et un filtrage sur les logs de debug.
• Sous-estimer l'effort de gouvernance taxonomique à l'échelle. Cinq équipes qui instrumentent sans convention partagée produisent cinq dialectes d'attributs incompatibles. Le nettoyage après coup coûte plus cher que la standardisation en amont.
• Déployer OTel comme un projet purement infra. Si les développeurs ne sont pas embarqués, l'adoption stagne. Le tracing sans buy-in des devs produit des traces creuses -- techniquement présentes, mais fonctionnellement vides. L'observabilité est un sujet transverse qui exige l'adhésion des deux côtés.

Récapitulatif

Conclusion

OpenTelemetry s'est imposé comme le standard de facto de l'observabilité. L'adopter, c'est investir dans une couche d'abstraction qui découple durablement votre instrumentation de vos backends d'analyse. Les SDK sont stables, OTLP est supporté partout, le Collector offre une flexibilité de routage sans équivalent.

Le gain réel est stratégique avant d'être technique. Changer de backend sans réinstrumenter. Ajouter un signal sans refondre la collecte. Normaliser la taxonomie sans contraindre les équipes. Que vous soyez une PME de 15 développeurs comme NovaTech ou un grand compte de 200+ comme Meridian Group, l'approche reste la même -- seule l'échelle de la gouvernance change.

La question n'est plus de savoir s'il faut adopter OpenTelemetry. C'est de mesurer à quelle vitesse votre stack existante peut l'absorber.