OpenTelemetry permet de séparer l’instrumentation des applications du backend de supervision. Cela réduit une forme de dépendance — mais confie aussi à votre équipe un pipeline à exploiter.
Le plus coûteux, quand on change d’outil de supervision, se trouve souvent dans les applications
Une organisation veut changer de plateforme d’observabilité. Le nouveau backend sait stocker des traces, des métriques et des journaux (logs), mais des dizaines de services utilisent les agents, les bibliothèques, les noms de champs et les exportateurs de l’ancien fournisseur.
Le plus difficile n’est pas d’ouvrir un nouveau compte. C’est de modifier le code applicatif, la configuration de déploiement et les conventions d’exploitation de chaque service.
OpenTelemetry s’attaque précisément à cette frontière. Il offre aux applications un moyen indépendant des fournisseurs de générer, décrire, collecter et exporter la télémétrie. Les applications peuvent émettre des signaux standard vers un OpenTelemetry Collector, et le Collector peut traiter ces signaux puis les acheminer vers un ou plusieurs backends.
C’est pourquoi maîtriser le pipeline de télémétrie compte : la décision sur la destination des données peut sortir de chaque application pour rejoindre une couche de plateforme contrôlée.
Mais OpenTelemetry ne fournit pas une plateforme d’observabilité complète. Il ne stocke pas les données, n’exécute pas vos requêtes, ne construit pas de tableaux de bord et ne gère pas les alertes. Ces responsabilités restent assurées par d’autres systèmes.
Ce qu’OpenTelemetry standardise réellement
La télémétrie, ce sont les éléments de preuve produits par un système en fonctionnement :
- les traces suivent une requête d’un service à l’autre ;
- les métriques mesurent des valeurs dans le temps ;
- les journaux enregistrent des événements et des détails ;
- les profils, encore moins matures dans OpenTelemetry, décrivent où les programmes consomment des ressources.
OpenTelemetry fournit des API et des SDK pour créer ces données, des conventions sémantiques pour nommer les informations courantes, l’OpenTelemetry Protocol (OTLP) pour les transporter, et un Collector pour les recevoir, les traiter et les exporter.
Le Collector joue le rôle d’un pipeline programmable. Il peut regrouper les données par lots, ajouter des informations de ressource, supprimer des champs sensibles, échantillonner des traces, convertir des formats et envoyer des signaux différents vers des destinations différentes.
Ce que signifie « maîtriser le pipeline »
Maîtriser ne signifie pas forcément exploiter soi-même chaque composant. Cela signifie garder le contrôle du contrat entre les applications et les fournisseurs d’observabilité.
| Couche | Avec une conception centrée sur OpenTelemetry | Niveau de portabilité |
|---|---|---|
| Instrumentation des applications | API et SDK OpenTelemetry, instrumentation automatique | Relativement élevé |
| Nommage des signaux | Conventions sémantiques standard et règles propres à l’organisation | Élevé si les conventions sont respectées |
| Transport | OTLP ou formats ouverts pris en charge | Relativement élevé |
| Traitement et acheminement | Configuration et processeurs du Collector | Portable tant qu’aucun composant propre à un fournisseur n’est introduit |
| Stockage | Backend open source ou commercial choisi | Propre au backend |
| Langage de requête | Défini par le backend | Généralement faible |
| Tableaux de bord et alertes | Construits dans le backend ou dans une autre couche de visualisation | Souvent faible |
| Rétention et maîtrise des coûts | Choix de backend et d’architecture | Propre au backend |
OpenTelemetry réduit donc la dépendance liée à l’instrumentation. Il ne garantit pas que les tableaux de bord, les requêtes, les alertes ou les données historiques puissent migrer sans effort.
C’est déjà précieux. Remplacer des tableaux de bord est contraignant ; réinstrumenter des centaines de services tout en gardant la production stable est généralement bien plus difficile.
Le Collector crée un point de contrôle utile
Sans Collector, chaque application peut envoyer sa télémétrie directement à un backend. Cela peut suffire pour une petite expérimentation. À grande échelle, la configuration des points de terminaison, les identifiants, les règles d’échantillonnage et les exportateurs des fournisseurs se retrouvent dispersés dans tout le parc.
Un Collector offre un point unique pour :
- changer de destination sans reconstruire chaque application ;
- regrouper et compresser les données avant l’export ;
- supprimer les secrets ou les informations personnelles ;
- enrichir les signaux avec des métadonnées d’environnement et de responsabilité ;
- échantillonner les traces à fort volume ;
- envoyer les données de sécurité ou de fiabilité vers des systèmes distincts ;
- maintenir un double export temporaire pendant une migration.
Il devient aussi une infrastructure de production. Si le Collector est surchargé, mal configuré ou indisponible, la télémétrie peut être retardée ou perdue au moment précis où un incident la rend la plus précieuse.
Les standards ouverts ne suppriment pas le travail d’exploitation
L’argument marketing le plus fort d’OpenTelemetry est l’affranchissement de la dépendance à un fournisseur. La vérité moins confortable, c’est que la portabilité doit être conçue et entretenue.
Les équipes peuvent recréer une dépendance :
- en utilisant une distribution du Collector propre à un fournisseur sans comprendre ce qu’elle ajoute ;
- en s’appuyant fortement sur des processeurs ou des exportateurs propriétaires ;
- en nommant les attributs de façon incohérente d’une équipe à l’autre ;
- en concentrant toute la connaissance opérationnelle dans le langage de requête d’un seul backend ;
- en ne conservant aucun chemin testé vers une seconde destination ;
- en supposant que chaque SDK de langage et chaque signal ont la même maturité.
Le Collector lui-même exige une planification de capacité, des mises à niveau, une configuration sécurisée et une supervision. Les environnements de grande taille utilisent couramment des collectors proches des charges de travail et un niveau passerelle (gateway) pour le traitement et l’export centralisés. Un Collector global unique peut devenir un goulot d’étranglement et un domaine de défaillance.
OpenTelemetry et Prometheus ne sont pas concurrents
Prometheus est largement utilisé pour collecter, stocker et interroger des métriques sous forme de séries temporelles et pour alimenter des alertes. OpenTelemetry couvre une couche d’instrumentation et de transport plus large, qui englobe traces, métriques et journaux.
Une organisation peut continuer à utiliser Prometheus tout en adoptant les bibliothèques, les conventions sémantiques et les Collectors d’OpenTelemetry. Ces technologies peuvent se compléter. Remplacer un déploiement Prometheus qui fonctionne n’est pas un prérequis pour s’orienter vers OpenTelemetry.
La bonne question est de savoir où la standardisation supprime du travail en double. Pour une équipe, ce sera peut-être le traçage distribué. Pour une autre, des métadonnées de service cohérentes sur plusieurs clouds.
Quand OpenTelemetry vaut la peine d’ajouter une couche
Il prend davantage de valeur lorsque :
- de nombreux services utilisent des langages ou des frameworks différents ;
- plusieurs équipes ont besoin de conventions de télémétrie cohérentes ;
- les charges de travail s’étendent sur plusieurs clouds, clusters ou systèmes sur site ;
- l’organisation veut pouvoir acheminer les données vers plus d’un backend ;
- le filtrage ou le masquage des données doit avoir lieu avant l’export ;
- le coût de la télémétrie exige des contrôles centralisés d’échantillonnage et d’acheminement ;
- changer de backend imposerait sinon de modifier les applications.
Il peut être superflu au départ lorsqu’une petite application utilise un seul backend, que l’intégration native du fournisseur suffit et que personne n’est prêt à exploiter un composant de plus. Ajouter un Collector parce que c’est à la mode crée de l’infrastructure sans résoudre de problème réel.
Une démarche d’adoption pragmatique
1. Choisir un parcours de service
Commencez par une requête qui traverse quelques services importants. Définissez ce qu’un opérateur doit pouvoir apprendre lorsqu’elle est lente ou échoue.
2. Fixer le nommage et les responsabilités
Utilisez les conventions sémantiques d’OpenTelemetry là où elles s’appliquent. Ajoutez un petit ensemble encadré d’attributs propres à l’organisation, comme le responsable du service, l’environnement et la version de déploiement. Évitez les valeurs non bornées ou sensibles.
3. Instrumenter avant de tout centraliser
Générez des traces et des métriques utiles dans un groupe de services. Vérifiez la propagation du contexte au-delà des frontières. N’installez pas une grande flotte de Collectors avant d’avoir prouvé que les données émises répondent aux questions d’exploitation.
4. Introduire le Collector de façon délibérée
Utilisez-le pour répondre à un besoin réel : masquage, traitement par lots, acheminement, enrichissement ou indépendance vis-à-vis du backend. Surveillez sa file d’attente, les données refusées, les échecs d’export, la mémoire et les spans perdus.
5. Tester la portabilité
Exportez temporairement un ensemble contrôlé de signaux vers une seconde destination compatible. Notez quels attributs, requêtes, tableaux de bord et alertes ne se transposent pas. Une portabilité qui n’a jamais été testée n’est qu’une hypothèse.
Connaître, utiliser ou maîtriser ?
Connaître : les développeurs doivent comprendre les traces, les métriques et les journaux, et savoir qu’OpenTelemetry est un cadre d’instrumentation et de transport — pas un backend de supervision.
Utiliser : les développeurs, les SRE et les ingénieurs plateforme doivent instrumenter les services, propager le contexte, configurer les collectors et enquêter sur une télémétrie manquante ou excessive.
Maîtriser : les responsables de plateforme d’observabilité doivent concevoir la topologie des collectors, la gouvernance sémantique, l’échantillonnage, le masquage, l’acheminement multi-backend, la capacité et la gestion des défaillances.
Que faire ensuite ?
Choisissez un service important et répondez à trois questions :
- Son instrumentation est-elle directement liée à un fournisseur ?
- La destination pourrait-elle changer sans redéployer l’application ?
- Si le pipeline de télémétrie tombait en panne, quelqu’un le saurait-il avant un incident ?
Si la première réponse est oui et les deux suivantes non, OpenTelemetry peut résoudre un vrai problème d’architecture. Si vous ne parvenez pas à identifier ce problème, ne déployez pas encore une couche de plateforme supplémentaire.
Maîtriser le pipeline de télémétrie ne consiste pas à éviter tous les fournisseurs. Il s’agit de décider où la dépendance à un fournisseur est acceptable — et de l’empêcher de se propager de façon invisible dans chaque application.
Références et lectures complémentaires
- What is OpenTelemetry? — projet OpenTelemetry. Définit son rôle dans la génération, la collecte et l’export de la télémétrie, et précise qu’il ne s’agit pas d’un backend. Consulté en septembre 2026.
- OpenTelemetry documentation — projet OpenTelemetry. Documentation à jour sur les concepts, les SDK par langage, le Collector et les recommandations de déploiement. Consulté en septembre 2026.
- OpenTelemetry Collector deployment — projet OpenTelemetry. Recommandations pour déployer des collectors à côté des charges de travail et en tant que passerelles. Consulté en septembre 2026.
- OpenTelemetry Collector anti-patterns — projet OpenTelemetry, 1er mars 2024. Mises en garde pratiques sur la topologie, la supervision, les distributions et les mises à niveau ; l’article lui-même invite à revérifier les détails les plus anciens. Consulté en septembre 2026.
- CNCF announces OpenTelemetry graduation — CNCF, 21 mai 2026. Acte la graduation du projet et l’évaluation de sa maturité pour la production. Consulté en septembre 2026.