TechniqueDécouverte10 min de lecture
OpenTelemetry dans l'industrie : état des lieux
Où en est OpenTelemetry dans les usines en octobre 2026 ? Ce qui pousse l'adoption, ce qu'il observe déjà, ce qui freine, la maturité brique par brique et par où commencer.
Pour : ingénieurs et SRE · architectes · managers d’équipe · direction et DSIPrérequis : Savoir ce que sont OTLP et le Collector : voir OpenTelemetry de bout en bout.
En octobre 2026, OpenTelemetry est un standard acquis côté IT (l’informatique de gestion, les serveurs, les applications) et un sujet ouvert côté usine, ce qu’on appelle l’OT (les technologies opérationnelles : automates, capteurs, supervision des machines). OpenTelemetry est gradué à la CNCF depuis mai 2026, c’est-à-dire reconnu comme mature par la fondation qui l’héberge. Le projet lui-même publie sur les environnements industriels et une session sur la standardisation de l’observabilité IIoT (l’internet des objets industriels) figurait au programme de KubeCon Japan en juillet. Mais il n’existe toujours ni receiver industriel officiel (le composant du Collector qui sait lire un protocole d’usine), ni conventions sémantiques pour l’OT, c’est-à-dire de noms communs pour décrire les données.
Cet article fait le point : ce qui pousse l’adoption, ce qu’OpenTelemetry observe déjà dans les usines, ce qui freine et par où commencer. Il complète un article plus technique, consacré à la collecte au plus près des machines : OpenTelemetry au plus près des machines.
Pourquoi maintenant ?
Section intitulée « Pourquoi maintenant ? »Quatre mouvements se rejoignent et obligent les équipes industrielles à se poser la question.
- L’usine s’est remplie de logiciel. Passerelles edge (des serveurs installés près des machines), conteneurs, MES légers (les logiciels qui pilotent l’exécution de la production), applications de vision : ces briques tombent en panne comme n’importe quel service IT et doivent être observées comme tel. Le SCADA, le système de supervision des installations, ne les voit pas.
- Le standard est mûr. OpenTelemetry a obtenu le statut de projet gradué de la CNCF en mai 2026. Selon la CNCF, il réunit plus de 12 000 contributions venues de plus de 2 800 entreprises. Pour un industriel qui raisonne en décennies, c’est un signal de pérennité que les formats propriétaires n’offrent pas.
- La gestion de flotte edge se standardise. Margo, initiative hébergée par la Linux Foundation pour l’edge industriel, fonde son observabilité sur OpenTelemetry. Sa spécification, encore au stade de pré-projet, impose au moins un Collector sur chaque équipement et demande aux applications qui publient leurs traces, métriques et logs de le faire en OTLP.
- L’IA arrive dans l’atelier. Les agents et modèles déployés près des machines ont besoin de traces pour être audités. OpenTelemetry dispose déjà de conventions sémantiques pour l’IA générative, encore en développement, ce qui en fait un support naturel pour cette traçabilité.
Ce qu’OpenTelemetry observe déjà
Section intitulée « Ce qu’OpenTelemetry observe déjà »Les usages qui fonctionnent aujourd’hui n’observent pas le process lui-même. Ils observent tout ce qui le sert.
| Cas d’usage | Signaux | Composants utilisés | Maturité |
|---|---|---|---|
| Santé des passerelles et serveurs edge | Métriques, logs | hostmetrics, filelog, journald | Éprouvé |
| Applications edge conteneurisées | Traces, métriques, logs | SDK, OTLP, Collector local | Éprouvé |
| Réseau d’atelier (switchs, routeurs) | Métriques | Receiver snmp | Éprouvé |
| Qualité de la chaîne de collecte (pertes, retards, déconnexions) | Métriques, logs | Métriques et logs internes du Collector | Éprouvé |
| Chaînes MES et intégration ERP | Traces | SDK, instrumentation automatique | En cours d’adoption |
| Variables de process issues des automates | Métriques | Pont tiers ou receiver sur mesure | Expérimental |
| Traçabilité d’agents IA en atelier | Traces, logs | Conventions GenAI | Émergent |
La ligne de partage est nette. Tout ce qui tourne sur un système d’exploitation généraliste s’observe avec les outils standard. Tout ce qui passe par un protocole industriel demande encore un pont.
Ce qui freine
Section intitulée « Ce qui freine »Les freins sont moins techniques qu’organisationnels. Le projet OpenTelemetry le reconnaît lui-même : son guide de sécurité pour les environnements legacy, publié en mai 2026, part du constat que les hypothèses du cloud-natif ne tiennent pas en usine.
- La sûreté passe avant la visibilité. Toute modification en zone de contrôle passe par une gestion du changement stricte. Un agent installé sur un poste d’automatisme est souvent exclu d’office.
- Les systèmes ne se modifient pas. Beaucoup d’équipements ne supportent ni agent, ni TLS moderne (le chiffrement des échanges réseau), ni authentification. Le guide OTel en tire la conséquence : la chaîne de collecte devient le point de contrôle et le placement du Collector compte autant que sa configuration.
- Les cycles de vie sont décalés. Le Collector suit un cycle de version de deux semaines, un automate peut rester dix ans sans mise à jour. Le guide recommande de faire tourner le Collector en pont, hors du périmètre legacy, pour pouvoir le patcher indépendamment.
- Les données sensibles ne sont pas celles qu’on croit. Recettes de production, configurations machine et rendements d’usine valent plus qu’une adresse IP. Il faut filtrer et minimiser avant la sortie de zone, pas après.
- Les compétences sont rares. Les équipes OT connaissent OPC UA (le protocole d’échange standard des équipements industriels) et l’IEC 62443 (la norme de cybersécurité des systèmes industriels), les équipes IT connaissent OTLP et Kubernetes. Peu de profils font le lien.
- L’historian est déjà là. L’usine dispose souvent d’un historian, la base qui archive les mesures du process, amorti et maîtrisé. OpenTelemetry doit prouver qu’il apporte autre chose qu’une copie des mêmes données.
Maturité brique par brique
Section intitulée « Maturité brique par brique »Le socle généraliste est prêt ; la couche spécifique à l’industrie reste à construire.
| Brique | État en octobre 2026 | Ce que cela permet en usine |
|---|---|---|
| Traces, métriques, logs | Disponibilité générale | Observer passerelles, applications edge et chaînes MES |
| Profils | Alpha publique | Pas encore d’usage industriel réaliste |
| Collector et file persistante (tampon sur disque) | Utilisé en production, distribution sur mesure avec ocb | Tenir les coupures réseau, limiter la surface d’attaque |
| OpAMP et superviseur | Disponibles dans contrib | Piloter une flotte de Collectors depuis l’edge |
| Configuration déclarative des SDK | Spécification et schéma stables, prise en charge variable selon les langages | Configurer les applications edge de façon homogène |
| Conventions IA générative | En développement | Tracer agents et modèles déployés en atelier |
| Receivers OPC UA, MQTT, Sparkplug B, Modbus | Absents de contrib (v0.162.0) ; receivers communautaires hors contrib | Passer par un pont tiers, un receiver communautaire à évaluer ou un receiver maison |
| Conventions sémantiques industrielles | Absentes ; exploration ouverte par OpenTelemetry Industrial | Chaque site invente son modèle |
Dans ce tableau, contrib désigne le dépôt des composants communautaires du Collector et ocb l’outil qui sert à assembler une distribution sur mesure. Les deux dernières lignes expliquent à elles seules la plupart des projets bloqués au stade de la preuve de concept.
Qui fait avancer le sujet ?
Section intitulée « Qui fait avancer le sujet ? »Quatre cercles bougent, à des rythmes différents.
- Le projet OpenTelemetry. Il s’intéresse explicitement aux environnements traditionnels : un guide de sécurité dédié au legacy et à l’industrie (mai 2026), un groupe de travail sur les mainframes et, au programme de KubeCon Japan (28 au 30 juillet 2026), une session d’ingénieurs d’Apple intitulée « Standardizing Industrial IoT observability with OpenTelemetry ». Je n’en ai pas trouvé le contenu en ligne : je ne peux donc pas dire ce qui y a été proposé.
- OpenTelemetry Industrial. Cette initiative communautaire est née d’une proposition faite à la communauté OpenTelemetry en mai 2026, qui posait publiquement la question de l’organisation du support des protocoles industriels. Elle tient un catalogue des receivers et des ponts existants, publie un receiver EtherNet/IP expérimental, explore des conventions sémantiques industrielles, prévoit une distribution industrielle du Collector et travaille avec Margo. Sa feuille de route est publique et couvre 2026 et 2027. Elle se présente elle-même comme indépendante : ce n’est ni un projet officiel d’OpenTelemetry, ni un de ses groupes de travail.
- Margo et l’edge industriel. La spécification Margo fait du Collector OpenTelemetry le point de collecte sur les équipements edge. Sa sandbox de référence, un environnement d’essai fourni par le projet, le déploie côté équipement, avec Prometheus, Grafana, Jaeger et Loki côté orchestrateur. C’est aujourd’hui le cadre le plus concret pour un industriel qui veut une observabilité edge neutre.
- Les éditeurs. La plupart des grandes plateformes d’observabilité acceptent OTLP et plusieurs publient leur propre distribution du Collector. Leur discours industriel porte surtout sur la convergence IT/OT ; le travail d’intégration des protocoles reste, lui, largement à la charge des projets.
Le chantier du receiver industriel et des conventions OT a donc un porteur, mais pas encore de place officielle dans le projet. La prochaine étape dépend de la place que le projet lui fera.
Par où commencer ?
Section intitulée « Par où commencer ? »La bonne entrée est celle qui ne touche pas au process et qui rend un service visible en quelques semaines.
- Observer ce qui tourne déjà sur des serveurs. Passerelles edge, hôtes de virtualisation, applications conteneurisées :
hostmetrics,fileloget l’instrumentation des applications suffisent. - Poser un Collector par zone, en pont. Hors du périmètre des équipements, avec une file persistante et un seul flux sortant vers la DMZ, la zone tampon du réseau entre l’usine et l’informatique de gestion.
- Écrire le modèle de données avant d’étendre. Hiérarchie ISA-95 (site, zone, ligne, cellule, équipement) en attributs de ressource, unités UCUM (un code standard pour les unités de mesure), liste fermée de tags utiles, les variables lues sur les automates. Ce document vaut plus que la première configuration.
- Ajouter les variables de process par un pont, à petite échelle. Quelques dizaines de tags par ligne pilote, en lecture seule, validés avec l’équipe OT.
- Mesurer ce qui n’était pas visible. Pertes de collecte, déconnexions de passerelles, dérives d’horloge : c’est souvent là que le projet fait la preuve de sa valeur face à l’historian.
Conclusion
Section intitulée « Conclusion »OpenTelemetry est prêt pour l’usine, à condition de commencer par ce qu’il sait déjà faire : observer les systèmes qui entourent le process. La graduation CNCF règle la question de la pérennité, Margo donne un cadre edge neutre et le projet commence à regarder l’IIoT de près.
Ce qui manque est identifié : un receiver industriel intégré au projet et des conventions sémantiques pour l’OT. OpenTelemetry Industrial a ouvert les deux chantiers. Les industriels et les intégrateurs qui participeront à ces chantiers pèseront sur la forme que prendra l’observabilité industrielle.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- OpenTelemetry au plus près des machines : le pont entre les protocoles industriels et le Collector, zone par zone.
- Que surveiller, de l’usine au modèle d’IA ? : les couches d’observabilité, du capteur d’atelier au modèle.
- OpenTelemetry et réversibilité : ce qu’un standard ouvert rend portable et ce qu’il ne rend pas portable.
- Entities, Profiles, Injector : la maturité de trois autres briques du projet.
Consultées le 11 octobre 2026.
- OpenTelemetry, OpenTelemetry Has Graduated… Now what?, 15 juillet 2026 : statut gradué obtenu en mai 2026, chiffres de la CNCF.
- OpenTelemetry, Applying OpenTelemetry Security Practices in Legacy Environments, 19 mai 2026 : hypothèses du cloud-natif, placement du Collector, Collector en pont, données sensibles.
- OpenTelemetry, OpenTelemetry @ KubeCon + CloudNativeCon Japan 2026, 23 juillet 2026 : programme des sessions.
- OpenTelemetry, liste des modules du Collector contrib, v0.162.0 : aucun receiver OPC UA, MQTT, Sparkplug B ni Modbus ; receiver SNMP, extension OpAMP et superviseur présents.
- OpenTelemetry, processus de publication du Collector : cycle de version de deux semaines.
- OpenTelemetry, Declarative configuration is stable! : ce qui est stable et ce qui ne l’est pas encore.
- Margo, spécification (pré-projet), collecte et publication des données d’observabilité : Collector obligatoire sur l’équipement, OTLP pour les applications.
- Margo, sandbox : Collector côté équipement, stockages côté orchestrateur.
- OpenTelemetry Industrial : présentation de l’initiative, travaux en cours, statut indépendant, feuille de route.
- Communauté OpenTelemetry, Proposal: OpenTelemetry for Industrial / IoT / Legacy Environments, 12 mai 2026.