OpenTelemetry et Prometheus convergent enfin, et les chiffres 2026 le confirment
Une enquête 2026 montre que l’interopérabilité entre OpenTelemetry et Prometheus a nettement progressé : la note de facilité d’usage grimpe de 3,1 à 3,6 et la part de ceux qui les jugent difficiles à combiner chute de 29 % à 10 %. Pour une équipe SRE qui hésite encore, le moment est venu de consolider sur le Collector OTel sans abandonner Prometheus.
22 septembre 2026. Une enquête sur l’interopérabilité OpenTelemetry/Prometheus est publiée : près de la moitié des répondants mélangent les deux instrumentations pour leurs métriques d’infrastructure. 23 septembre 2026. Atlassian documente sa migration de 100 000 hôtes vers OpenTelemetry sur le blog de la CNCF. 23 septembre 2026. New Relic publie son Observability Forecast 2026, selon lequel 73 % des équipes sont standardisées sur OTel. Pourquoi c’est important : après deux ans de travail, les deux écosystèmes dominants de l’observabilité cessent d’être rivaux pour devenir complémentaires — et le choix d’architecture redevient simple.
Deux standards qui se tournaient le dos
OpenTelemetry et Prometheus occupent le même terrain sans avoir toujours bien cohabité. Prometheus reste la référence pour les métriques d’infrastructure, avec son modèle de scrape et son langage PromQL. OpenTelemetry, devenu un projet diplômé de la CNCF en mai 2026, s’impose comme la couche d’instrumentation et de collecte universelle, portée par un Collector capable de recevoir, transformer et exporter les télémétries.
Longtemps, les équipes ont dû choisir leur camp ou subir une double instrumentation coûteuse. L’enquête 2026 sur l’interopérabilité mesure précisément ce point : environ la moitié des répondants mélangent une instrumentation Prometheus et une instrumentation OTel pour les métriques d’infrastructure, et 30,7 % utilisent les deux pour les métriques applicatives. L’hybride n’est plus l’exception, c’est la norme.
Les chiffres qui disent que ça marche
Les progrès se lisent dans deux indicateurs. La note de facilité d’usage moyenne du duo est passée de 3,1 à 3,6 sur l’échelle de l’enquête, soit une hausse de 0,5 point. Surtout, la part de ceux qui jugent les deux outils difficiles à combiner a chuté de 29 % à 10 %.
Les contributeurs impliqués dans ce rapprochement le résument sans détour. Dhruv Ahuja de SigNoz, Andrej Kiripolsky et Arthur Sens de Grafana Labs, et Ana Muenz, écrivent : « Deux ans de travail sur l’interopérabilité portent leurs fruits. » Reste des chantiers identifiés : un meilleur alignement des modèles de données, une gestion plus propre des attributs de ressources et des métadonnées, et la réduction des problèmes de nommage et de formatage.
La preuve par Atlassian : 100 000 hôtes migrés
Le cas Atlassian transforme la promesse en preuve chiffrée. L’éditeur a migré sa collecte de métriques depuis gostatsd, son implémentation open source du protocole StatsD d’Etsy, vers OpenTelemetry. Le pipeline d’origine, qui traitait les métriques d’environ 100 000 hôtes répartis sur 14 régions, était de plus en plus décalé par rapport à la bascule générale vers OTel : « C’est devenu le standard de fait, et une part croissante de ce qui alimentait notre pipeline émettait des données OTel que nous ne prenions tout simplement pas en charge », écrivent les ingénieurs.
La méthode a consisté à remplacer la mécanique de collecte et de pipeline par OTel tout en conservant l’interface exposée aux services. Résultat : une migration à l’échelle de l’organisation, devenue ce que les auteurs appellent une « migration d’équipe plateforme ». Les gains sont mesurables : l’agrégation consomme environ deux fois moins de CPU pour le même trafic, l’usage du CPU est mieux réparti entre les shards d’ingestion, et le coût des sidecars baisse d’environ 30 % à l’échelle de la flotte.
Le coût de l’inobservabilité, selon New Relic
New Relic complète le tableau avec son Observability Forecast 2026, fondé sur 2 575 responsables et praticiens interrogés. Le rapport confirme que 73 % des organisations sont standardisées sur OTel, en migration active vers lui ou en phase de test. Il relie aussi l’observabilité à l’adoption de l’IA : 83 % des répondants jugent l’observabilité essentielle pour le code généré par IA, et les organisations qui surveillent leurs agents IA sont deux fois plus susceptibles de constater un retour sur investissement triple.
Le coût de l’absence d’observabilité est chiffré. Les ingénieurs passent 37 % de leur temps à traiter des perturbations, et 42 % des organisations n’en prennent connaissance que par des canaux inefficaces — vérifications manuelles ou plaintes clients. New Relic évalue la perte moyenne liée aux incidents majeurs à 74 millions de dollars par an, soit 1,85 million de dollars par heure, ou plus de 30 000 dollars par minute d’indisponibilité.
Le pattern qui se dégage
La convergence aboutit à un schéma d’architecture lisible. Prometheus reste le socle du stockage et de l’alerte pour les métriques d’infrastructure, tandis que le Collector OTel devient le point de passage unique pour recevoir, transformer et router l’ensemble des télémétries. Les deux se connectent via l’exporteur de remote write de Prometheus, ce qui évite la double instrumentation tout en conservant PromQL et l’écosystème d’alertes existant.
receivers:
otlp:
protocols:
grpc:
http:
exporters:
prometheusremotewrite:
endpoint: "http://prometheus:9090/api/v1/write"
service:
pipelines:
metrics:
receivers: [otlp]
exporters: [prometheusremotewrite]La suite s’annonce logique : Prometheus v3.15 est entré en release candidate avec des gains de performance, et la convergence devrait continuer à se resserrer sur les deux chantiers restants — l’alignement des modèles de données et la gestion des attributs de ressources.
Pourquoi maintenant
Ce rattrapage n’est pas un hasard de calendrier. OpenTelemetry a été diplômé par la CNCF en mai 2026, un signal de maturité qui a accéléré l’adoption en production. La graduation a aussi libéré l’énergie nécessaire pour lisser les aspérités avec Prometheus : les deux projets partagent désormais des contributeurs et une feuille de route sur l’alignement des modèles de données.
Le mécanisme est technique. Le Collector OTel embarque un récepteur et un exporteur Prometheus matures, et le modèle de données de métriques d’OTel a convergé vers les conventions de Prometheus — noms de métriques, labels, exposition HTTP. Ce qui était autrefois une traduction approximative entre deux formats est devenu un pont stable, et c’est ce pont qui rend la double instrumentation inutile.
L’observabilité des agents IA, nouveau front
La convergence OTel/Prometheus arrive au moment où l’observabilité change de cible. Le Observability Forecast 2026 de New Relic lie directement la maturité d’observation au succès de l’IA : les organisations qui surveillent leurs agents IA obtiennent un meilleur retour que celles qui les laissent tourner sans supervision. Un agent qui exécute des tâches en production émet des métriques, des traces et des logs comme n’importe quel service — mais avec une dimension supplémentaire : on veut savoir non seulement s’il est lent, mais s’il a fait ce qu’on attendait.
C’est là qu’OpenTelemetry trouve sa justification la plus forte. Sa neutralité vis-à-vis des fournisseurs en fait la couche naturelle pour instrumenter des agents dont le comportement doit être audité, pas seulement surveillé. Prometheus reste en aval pour stocker ces signaux et déclencher les alertes. Les deux écosystèmes ne sont pas seulement réconciliés : ils se répartissent les rôles sur le front le plus récent de l’observabilité. À mesure que les agents IA sortent du bac à sable et touchent à la production, la question n’est plus de choisir entre OTel et Prometheus, mais de les brancher ensemble assez tôt pour auditer ce que les agents font réellement.
Verdict
Si vous êtes déjà sur Prometheus et que vous hésitez à adopter OTel pour vos métriques applicatives, foncez : les deux ne sont plus concurrents, et le Collector OTel avec l’exporteur remote write vous épargne la double instrumentation. Si vous démarrez un projet neuf, standardisez l’instrumentation sur OTel et conservez Prometheus pour le stockage et l’alerte — c’est désormais le chemin le moins risqué. Si vous êtes en cours de migration, inspirez-vous d’Atlassian : remplacez la mécanique de collecte sous l’interface existante, et mesurez le CPU d’agrégation avant et après. Le verdict n’est plus « choisissez un camp » : il est « consolidez sur OTel, et gardez Prometheus là où il excelle ».