OpenTelemetry et réversibilité : la donnée est portable, l'exploitation ne l'est pas

Mode de lecture

IngénieurDécideur

OpenTelemetry a rendu les données d’observabilité portables. Il n’a pas rendu l’exploitation réversible, c’est-à-dire la capacité à changer d’outil sans repartir de zéro. Envoyer de l’OTLP, le format d’échange d’OpenTelemetry, à un éditeur ne constitue pas une stratégie de sortie : l’enfermement a simplement quitté le format des données pour se loger plus haut, dans les requêtes, les tableaux de bord, les alertes et la façon de piloter les collecteurs (les relais qui reçoivent les données et les réexpédient vers le stockage).

Cet article propose une lecture en six couches de la réversibilité, une manière de la mesurer plutôt que de l’affirmer et les raisons pour lesquelles la question devient urgente en 2027.

Le malentendu : OTLP n’est pas une stratégie de sortie

L’argument est devenu un réflexe commercial : « nous sommes natifs OpenTelemetry, vous n’êtes donc pas enfermés ». Il repose sur une confusion entre deux choses distinctes.

La portabilité de la donnée signifie qu’un span (une étape d’une trace), une métrique ou un log peut être émis une fois et lu par n’importe quel backend compatible, c’est-à-dire n’importe quel outil de stockage et d’analyse. OpenTelemetry l’a réellement obtenue et c’est un acquis important.

La réversibilité de l’exploitation signifie qu’une équipe peut changer de backend sans perdre sa capacité à détecter, diagnostiquer et piloter. Elle dépend de tout ce qui a été construit au-dessus de la donnée. OTLP n’en dit rien.

Une organisation qui envoie de l’OTLP à un éditeur, puis construit ses tableaux de bord, ses alertes et ses SLO (ses objectifs de service chiffrés) dans l’interface de cet éditeur, n’est pas plus réversible qu’avant. Elle est enfermée plus tard dans la chaîne, ce qui est plus confortable à court terme et plus coûteux le jour du départ.

Où l’enfermement s’est déplacé ?

Avant OpenTelemetry, l’enfermement commençait à l’instrumentation : changer d’outil voulait dire changer d’agent et parfois toucher au code. Aujourd’hui, il se concentre dans quatre zones que l’on audite rarement.

• Le langage de requête. PromQL, ES|QL, DQL, KQL, chacun propre à un outil : chaque requête écrite dans le langage d’un outil est une ligne à réécrire si le backend d’arrivée ne le parle pas.
• Le contenu opérationnel. Tableaux de bord, règles d’alerte, SLO et runbooks (les procédures d’intervention) construits dans une interface plutôt que dans un dépôt de code n’existent que tant que le contrat court.
• Les traitements faits côté éditeur. Échantillonnage (ne garder qu’une partie des données), enrichissement, normalisation des attributs ou détection d’anomalies réalisés dans le backend disparaissent avec lui. La donnée brute qui reste n’a plus la même forme.
• Le pilotage des collecteurs. Une flotte gérée depuis la console d’un éditeur dépend de cet éditeur, même si chaque collecteur parle OTLP.

Aucune de ces zones n’est couverte par la spécification du protocole OTLP. C’est pourtant dans ces quatre zones que se décide la réversibilité réelle.

Six couches de réversibilité

Un système d’observabilité est réversible quand chacune de ses couches peut changer de fournisseur sans entraîner les autres. La souveraineté se joue sur les six, pas seulement sur le lieu de stockage.

Couche	Réversible quand…	Piège courant
1. Instrumentation	le code n’utilise que l’API et les SDK OpenTelemetry, avec les conventions sémantiques standard	un agent éditeur, ou une API propriétaire appelée depuis le code
2. Collecte	le Collector est la version du projet, ou une distribution construite avec OCB à partir de composants communautaires	une distribution éditeur qui embarque des composants absents du projet
3. Pilotage	la flotte est gérée par OpAMP depuis un dépôt Git, avec une configuration versionnée	une console de gestion de flotte en SaaS, propriété d’un éditeur
4. Contrat de données	les attributs sont définis, versionnés et vérifiés en intégration continue, par exemple avec OTel Weaver	des attributs improvisés, normalisés ensuite dans le backend
5. Contenu opérationnel	tableaux de bord et alertes vivent dans un dépôt, dans des formats ouverts comme Perses ou les règles Prometheus	tout est construit dans l’interface de l’outil
6. Stockage et analyse	le backend est interchangeable et peut être hébergé chez un acteur qualifié si le contexte l’exige	des données et des requêtes dans un format qu’un seul outil sait lire

Quelques termes du tableau. Les SDK sont les bibliothèques que le code appelle pour produire les signaux ; les conventions sémantiques fixent le nom et le sens des attributs. Une distribution est une version du Collector assemblée et livrée par un tiers. OCB (OpenTelemetry Collector Builder) est l’outil du projet pour assembler son propre Collector à partir de composants choisis. OpAMP est le protocole ouvert de gestion à distance des agents. OTel Weaver est l’outil du projet pour décrire et vérifier des conventions sémantiques. L’intégration continue désigne les vérifications automatiques lancées à chaque modification du code. Perses est une spécification ouverte de tableaux de bord.

Les couches 3, 4 et 5 sont les plus négligées. Ce sont aussi celles où l’on peut agir sans renégocier aucun contrat.

Reconnaître l’OTel de façade

« Compatible OpenTelemetry » couvre aujourd’hui des réalités très différentes. Cinq questions suffisent à faire la part des choses face à un éditeur ou à une offre d’intégration. Elles valent pour toutes les offres, commerciales comme open source.

1. Le collecteur livré est-il la version du projet, ou une distribution qui contient des composants absents du projet ?
2. Les fonctions clés (échantillonnage, masquage, routage) sont-elles réalisées dans le collecteur, ou seulement dans le backend ?
3. Les tableaux de bord et les alertes peuvent-ils être exportés dans un format ouvert, puis réimportés ailleurs ?
4. La gestion de flotte repose-t-elle sur OpAMP standard, pilotable par un autre serveur que celui de l’éditeur ?
5. Que deviennent la configuration et l’outil de pilotage si l’éditeur change de propriétaire ?

La dernière question n’a rien de théorique. Le 8 avril 2026, Dynatrace a annoncé un accord pour racheter Bindplane, plateforme de chaîne de collecte bâtie sur OpenTelemetry. Les configurations OpenTelemetry restent portables ; l’outil qui les pilote, lui, change de mains. Une gouvernance de flotte construite sur un dépôt Git et un protocole ouvert ne dépend pas de ce genre d’événement.

Mesurer : le Mean Time To Exit

Une réversibilité qui n’a jamais été testée est une hypothèse. Je propose de la mesurer avec un indicateur simple : le Mean Time To Exit, c’est-à-dire le temps nécessaire pour qu’un service retrouve sur un autre backend un niveau d’exploitation équivalent. C’est une proposition personnelle, pas un indicateur normalisé.

L’exercice de sortie se déroule en cinq étapes, sur un périmètre limité :

1. Choisir un service représentatif, avec ses tableaux de bord, ses alertes et ses SLO.
2. Ajouter dans le Collector un second exporter (le composant qui envoie les données vers une destination) vers un backend cible, sans toucher à l’instrumentation.
3. Rejouer depuis le dépôt le contenu opérationnel vers ce backend : tableaux de bord, règles d’alerte, SLO.
4. Comparer les deux environnements pendant une période d’exploitation réelle : alertes déclenchées, requêtes de diagnostic, couverture.
5. Noter le temps passé et lister ce qui a dû être réécrit à la main, couche par couche.

Le résultat ne se résume pas à un chiffre. La liste de ce qui a été réécrit à la main est le livrable le plus utile : elle désigne précisément les couches où l’enfermement subsiste. Refait chaque année, l’exercice montre si la dette de réversibilité diminue ou s’accumule.

Pourquoi maintenant ?

Deux règlements européens transforment la réversibilité d’une bonne pratique en exigence vérifiable. Ce qui suit est ma lecture d’ingénieur, pas un avis juridique.

DORA. L’article 28 impose aux entités financières des stratégies de sortie pour les services informatiques qui soutiennent des fonctions critiques ou importantes. Ces stratégies doivent tenir compte de la défaillance du prestataire, de la dégradation du service et de la fin du contrat. Le texte demande des plans de sortie complets, documentés et suffisamment testés. Une plateforme d’observabilité qui surveille des fonctions critiques peut entrer dans ce champ : une stratégie de sortie jamais exercée convainc mal un auditeur.

Data Act. Le chapitre VI organise le changement de fournisseur de services de traitement de données, ce qui comprend les offres IaaS, PaaS et SaaS (infrastructure, plateforme ou logiciel loués en ligne). Ses règles s’appliquent depuis le 12 septembre 2025. À partir du 12 janvier 2027, les frais de changement disparaissent, y compris les frais de sortie de données. La barrière financière tombe. Il ne restera que la barrière technique, c’est-à-dire celle que décrivent les six couches.

En 2027, partir ne coûtera donc plus rien en frais, mais pourra encore coûter beaucoup en réécriture.

Par où commencer ?

Inutile de tout migrer pour gagner en réversibilité. Quatre gestes, dans cet ordre, déplacent l’essentiel du risque vers des actifs que l’organisation possède.

1. Faire l’inventaire du contenu opérationnel : combien de tableaux de bord, d’alertes et de SLO existent uniquement dans une interface ?
2. Mettre ce contenu dans un dépôt, dans un format ouvert, pour en faire la source de vérité plutôt qu’une copie de sauvegarde.
3. Écrire le contrat de données : les attributs attendus, leurs valeurs et leurs versions, vérifiés en intégration continue avant le déploiement.
4. Ramener les traitements dans le Collector : masquage, échantillonnage et routage décidés côté organisation, pas côté backend.

C’est la logique que je suis avec REVERSOTEL, un plan de contrôle open source dont je suis l’auteur : un poste central qui pilote une flotte de collecteurs par OpAMP depuis un dépôt Git. Le contrat de données y est versionné, le contenu opérationnel est livré à l’identique vers plusieurs backends et changer de backend revient à un commit d’une ligne, une seule modification enregistrée dans le dépôt.

Conclusion

OpenTelemetry a résolu la partie la plus visible du problème. La réversibilité ne s’achète pas avec un protocole : elle se construit couche par couche, en gardant dans ses propres dépôts ce qui fait la valeur de l’exploitation.

Face à un éditeur, je remplacerais donc « êtes-vous compatible OpenTelemetry ? » par « combien de temps nous faudrait-il pour partir ? ». Une organisation qui sait y répondre, chiffres à l’appui, est souveraine sur son observabilité.

Pour aller plus loin

• Entities, Profiles, Injector : trois briques du projet et leur maturité.
• Labs OpenTelemetry : REVERSOTEL et son banc de bascule entre backends.
• Comment comparer des solutions équitablement ? : les mêmes critères pour toutes les offres.
• Gouverner les données d’observabilité : le contrat de données et ses propriétaires.

Sources

Consultées le 10 octobre 2026.

• Dynatrace, Dynatrace to Acquire Bindplane, communiqué du 8 avril 2026 : accord de rachat, clôture alors attendue dans le mois.
• Règlement (UE) 2022/2554 (DORA), article 28, paragraphe 8 : stratégies de sortie pour les services qui soutiennent des fonctions critiques ou importantes, plans complets, documentés et suffisamment testés.
• Règlement (UE) 2023/2854 (Data Act), chapitre VI et article 29 : changement de fournisseur de services de traitement de données, application au 12 septembre 2025, suppression des frais de changement au 12 janvier 2027.
• OpenTelemetry, spécification OpAMP : protocole de gestion à distance des agents.
• OpenTelemetry, Building a custom collector : OpenTelemetry Collector Builder.
• OpenTelemetry, Observability by Design: Unlocking Consistency with OpenTelemetry Weaver : description et vérification d’un registre de conventions.
• Perses, projet « sandbox » de la CNCF : spécification ouverte de tableaux de bord.

PasserellesCe que cette page change au-delà de l'équipe technique.

BusinessValeur, coût, risque

La question à poser à un éditeur n'est plus « êtes-vous compatible OpenTelemetry ? » mais « combien de temps nous faudrait-il pour partir ? ». La liste de ce qui a dû être réécrit à la main chiffre la dette de réversibilité avant une négociation.

OrganisationQui décide, qui possède

Le contenu opérationnel et le contrat de données doivent avoir un propriétaire et vivre dans un dépôt : voir Gouverner les données d'observabilité. Pour une entité financière, la stratégie de sortie exigée par DORA doit être testée, pas seulement écrite.

HumainÉquipes, astreinte, compétences

Le jour d'un changement de backend, ce sont les équipes d'astreinte qui perdent leurs alertes et leurs repères si le contenu n'existe que dans une interface.

MétiersProduit, finance, risque, relation client

Les tableaux de bord et les objectifs de service que lisent les équipes produit font partie de ce qu'il faut pouvoir emporter.

Pourquoi des passerelles →