Il y a quelque chose d’un peu paradoxal dans la situation des entreprises industrielles aujourd’hui. D’un côté, les capteurs, les automates et les équipements connectés génèrent des volumes de données qui n’ont jamais été aussi importants. De l’autre, selon des travaux de Forrester repris par plusieurs analyses sectorielles, environ 70 % de ces données collectées restent inexploitées. Pas parce qu’elles sont inutiles – mais parce qu’elles n’arrivent tout simplement pas là où elles devraient.
Le problème n’est donc pas la production de données. C’est leur circulation. Et c’est précisément là que la gestion des flux de données industriels entre en jeu : non pas comme une couche technique accessoire, mais comme l’infrastructure nerveuse sans laquelle aucune décision en temps réel n’est possible.
Avant d’entrer dans le détail des architectures et des protocoles, il faut comprendre pourquoi ce problème persiste alors que l’industrie dispose depuis longtemps d’outils de supervision et de contrôle.
La réponse tient en un mot : les silos. Historiquement, les environnements industriels ont été conçus pour la performance et la robustesse, pas pour l’ouverture. Un automate Siemens d’il y a vingt ans n’avait pas vocation à dialoguer avec un ERP SAP. Un système SCADA d’une usine chimique n’était pas pensé pour envoyer des données à un data lake cloud. Ces équipements fonctionnaient en circuit fermé, et c’était délibéré : moins de connexions, moins de risques de défaillance ou d’intrusion.
Aujourd’hui, cette logique se heurte aux exigences de l’industrie connectée. Les équipes de production veulent des indicateurs en temps réel, les directions souhaitent consolider les données de plusieurs sites, tandis que les équipes de maintenance cherchent à détecter les anomalies avant qu’elles ne provoquent un arrêt. Tout cela suppose que la donnée voyage – du capteur jusqu’à l’application qui en a besoin – de façon fiable, cohérente et sécurisée.
Selon l’Observatoire IT/OT 2024 mené par NXO et Cisco auprès de 135 décideurs industriels, 64 % des répondants placent la circulation de la donnée en première priorité de leur programme de convergence entre réseaux informatiques et réseaux de production. Seulement 11 % de ces entreprises avaient finalisé cette convergence à la date de l’étude, même si 44 % l’avaient initiée. Le chantier est donc en cours, mais il est loin d’être achevé.
Pour faire circuler une donnée depuis un capteur de pression vers un système de supervision ou un pipeline cloud, il faut d’abord se mettre d’accord sur la langue parlée. C’est le rôle des protocoles de communication industriels – et le paysage est beaucoup moins unifié qu’on pourrait le croire.
Conçu en 1979 par Modicon, Modbus est probablement le protocole le plus répandu dans les ateliers. Il fonctionne selon un modèle maître-esclave simple : un contrôleur interroge un équipement, qui répond avec ses données. Sa version TCP/IP (Modbus TCP) lui a permis de survivre à l’ère Ethernet. Sa force, c’est sa simplicité et son universalité : presque tout équipement industriel le supporte.
Mais Modbus a été conçu pour un monde différent. Il ne gère pas nativement la sécurité, ne propose pas de modèle de données standardisé, et son architecture polling (le maître doit interroger chaque esclave) devient un goulot d’étranglement quand le nombre d’équipements augmente. Il reste incontournable pour les parcs machines existants, mais il n’est pas fait pour alimenter un flux de données temps réel vers le cloud.
OPC-UA (Open Platform Communications Unified Architecture) est une autre paire de manches. Développé par l’OPC Foundation, il repose sur un modèle objet hiérarchisé. Il permet de décrire les valeurs des variables (température, pression, débit), mais aussi leur contexte sémantique : à quel équipement elles appartiennent, leur unité et leurs plages normales de fonctionnement.
Cette richesse sémantique distingue OPC-UA de Modbus. Il ne transporte pas seulement des nombres bruts, mais de l’information structurée et interprétable.
OPC-UA supporte également le mode publish/subscribe (Pub/Sub), qui s’affranchit du modèle maître-esclave : les équipements publient leurs données dès qu’elles changent, et les abonnés les reçoivent sans avoir à les solliciter. C’est un changement d’architecture important, notamment pour les applications temps réel. Sa sécurité native (chiffrement, authentification, signature des messages) en fait également un candidat sérieux pour les environnements soumis à des contraintes réglementaires comme la directive NIS 2.
Le revers de la médaille est la complexité de mise en œuvre. Établir une session OPC-UA entre deux équipements implique plusieurs échanges préalables – handshake, négociation de sécurité, établissement de session – ce qui génère un overhead de connexion plus important que Modbus ou MQTT. Sur des réseaux à faible bande passante ou pour des équipements embarqués à ressources limitées, ce coût peut être rédhibitoire.
MQTT (Message Queuing Telemetry Transport) a une origine différente : il a été conçu pour des environnements à ressources contraintes – réseaux instables, équipements à faible mémoire, connexions intermittentes. Son protocole binaire est extrêmement léger, son overhead de connexion minimal, et son modèle Pub/Sub via un broker central le rend très adapté à des architectures distribuées où de nombreux équipements publient des données vers un point de collecte unique.
Dans un déploiement typique, les passerelles industrielles ou les automates publient leurs mesures sur des topics MQTT (par exemple usine/ligne3/presse/temperature). Un broker – souvent une instance d’Eclipse Mosquitto ou d’EMQX – reçoit ces messages et les redistribue aux applications abonnées : système de supervision, pipeline de données, outil de maintenance prédictive. En cas de coupure réseau, MQTT peut conserver les messages dans une file d’attente et les retransmettre à la reconnexion, ce qui garantit qu’aucune donnée n’est perdue.
La limite de MQTT réside dans son absence native de modélisation sémantique. Un message MQTT transporte une valeur sur un topic – mais rien dans le protocole ne dit ce que cette valeur signifie, à quel capteur elle correspond, ni dans quelle unité elle est exprimée. C’est pourquoi l’industrie a développé des surcouches comme Sparkplug B, une spécification qui définit un format de payload standardisé au-dessus de MQTT pour apporter la sémantique qui lui fait défaut.
En pratique, OPC-UA et MQTT ne sont pas des concurrents : ils sont complémentaires. OPC-UA s’impose souvent pour les communications dans le réseau local de l’atelier, là où la richesse sémantique et la sécurité sont prioritaires. MQTT prend le relais pour le transit vers le cloud ou vers des systèmes distants, là où la légèreté et la résistance aux coupures priment.
Comprendre les protocoles ne suffit pas si on n’a pas en tête l’architecture globale dans laquelle ils s’inscrivent. Un flux de données industriel moderne traverse généralement 3 couches distinctes.
C’est là que tout commence. Des capteurs (température, vibration, pression, débit, courant…) génèrent des signaux analogiques ou numériques. Ces signaux sont acquis par des équipements de contrôle – automates programmables (PLC), unités d’acquisition, DCS pour les procédés continus – qui les exposent via les protocoles mentionnés plus haut.
Une ligne de production sérieusement équipée peut générer plusieurs milliers de points de mesure à des fréquences allant de quelques millisecondes à quelques secondes. Tout remonter brut vers le cloud serait techniquement possible mais économiquement absurde – et souvent inutile : un échantillonnage à 10 Hz d’une température qui varie lentement produit du bruit, pas de l’information.
C’est ici que se joue beaucoup de choses. Une passerelle edge industrielle (souvent un PC industriel durci ou un appareil dédié comme les gammes Siemens SIMATIC, Moxa, ou les solutions Advantech) assure plusieurs fonctions critiques en local.
D’abord, la normalisation protocolaire : elle peut ingérer des données venant de Modbus RTU, Profinet, OPC-UA, capteurs 4-20 mA et les convertir dans un format unifié avant de les transmettre en amont. C’est ce qu’on appelle parfois une passerelle de protocole. Ensuite, le filtrage et la réduction : plutôt que de transmettre toutes les valeurs à chaque cycle, la passerelle peut n’envoyer que les variations significatives (change of value, ou CoV), les agrégats sur des fenêtres temporelles, ou les alertes déclenchées par des seuils. Cela divise considérablement les volumes transmis.
Enfin – et c’est de plus en plus fréquent – la passerelle peut embarquer de la logique de traitement locale : des règles de détection d’anomalies simples, des algorithmes de pré-qualification des données, voire des modèles de machine learning légers compilés pour tourner sur des architectures ARM ou x86 embarquées (avec des frameworks comme TensorFlow Lite ou OpenVINO). Cette capacité de traitement local permet des temps de réaction de l’ordre de la milliseconde, sans dépendre de la disponibilité d’un cloud distant.
Une fois les données normalisées et filtrées par l’edge, elles rejoignent la couche d’intégration. C’est ici qu’entrent en scène les pipelines de données et les brokers de messages.
Des outils open source comme Apache Kafka sont utilisés pour créer des pipelines robustes et évolutifs, capables de gérer des flux en temps réel avec une haute disponibilité et une tolérance aux pannes. Dans une architecture industrielle typique, Kafka agit comme un bus de messages central : les passerelles edge publient leurs données dans des topics Kafka, et les applications consommatrices (ERP, outil de maintenance, data lake, système de supervision) s’abonnent aux topics qui les concernent. Apache Flink ou Spark Streaming permettent d’effectuer des traitements en temps réel – agrégation, filtrage, enrichissement – sur les flux de données.
Pour les sites de taille plus modeste, des outils d’orchestration comme Apache NiFi offrent une alternative visuelle pour définir des flux de données entre sources et destinations, avec une gestion intégrée des erreurs, du routage conditionnel et du chiffrement des échanges.
L’un des enjeux fréquemment sous-estimés à ce stade est la gouvernance du schéma de données. Quand une passerelle envoie une mesure de température, le système récepteur doit savoir que c’est bien une température, exprimée en degrés Celsius, rattachée à tel équipement de telle ligne. Sans registre de métadonnées (souvent appelé schema registry dans l’écosystème Kafka/Confluent), les pipelines deviennent des boîtes noires difficiles à maintenir.
L’absence de métadonnées rend impossible de comprendre l’origine ou le sens des données, et le manque de lineage complique l’identification des problèmes en cas d’erreur. C’est exactement le phénomène du “data swamp” – un lac de données où plus personne ne sait ce que contient quoi.
La théorie des architectures en couches est séduisante sur le papier. La réalité des projets est souvent plus rugueuse.
Dans la quasi-totalité des usines, les équipements coexistent sur plusieurs générations technologiques. Un atelier peut mélanger des automates des années 1990 encore parfaitement fonctionnels, des variateurs installés en 2012 et des capteurs IoT déployés en 2023. Ces équipements anciens ne supportent parfois que Modbus RTU sur RS-485, sans aucune capacité de connexion Ethernet. Les intégrer dans une architecture de flux moderne nécessite des convertisseurs de protocoles, des passerelles intermédiaires, parfois des contournements créatifs – et rarement autant de budget que prévu.
Qui est en charge de la donnée produite par une ligne de production ? L’équipe de maintenance qui gère les automates ? La DSI qui administre le réseau ? Les équipes méthodes qui utilisent les données pour piloter la qualité ? Dans la plupart des sites, cette question n’a pas de réponse claire. Résultat : personne ne documente le schéma de données, personne ne vérifie la qualité des mesures, et les projets avancent par couches successives de correctifs.
L’ouverture des réseaux OT vers l’IT multiplie les surfaces d’attaque. Modbus, en particulier, ne comporte aucun mécanisme d’authentification ou de chiffrement : n’importe quel équipement sur le réseau peut envoyer des commandes à un automate Modbus si le réseau n’est pas correctement segmenté. La directive NIS 2 oblige désormais de nombreuses entreprises industrielles à adresser ce problème sérieusement – et à documenter leur architecture de flux de données pour pouvoir en évaluer les risques.
Un pipeline de données sophistiqué ne peut pas compenser des capteurs mal étalonnés, des mesures horodatées incorrectement ou des variables dont la signification n’est pas documentée. Pourtant, dans beaucoup de sites, la qualité des données au niveau du terrain n’a jamais été auditée. On constate des dérives de capteurs non détectées, des valeurs aberrantes qui polluent les historiques, des tags Modbus mal nommés qui ne permettent pas d’identifier ce qu’ils mesurent. Corriger ces problèmes en amont est souvent le travail le plus ingrat – et le plus rentable.
Face à ces obstacles, quelques principes structurants font la différence entre les projets qui aboutissent et ceux qui s’étirent indéfiniment.
Cartographier avant de connecter. Avant d’installer la moindre passerelle, il faut savoir quels équipements existent, quels protocoles ils supportent, quelles variables ils exposent et à quelle fréquence. Cette cartographie, souvent réalisée avec des outils de découverte de réseau industriel, est la base sur laquelle tout le reste s’appuie.
Privilégier les protocoles ouverts et standardisés dès que possible. Quand un équipement neuf est acheté, imposer la compatibilité OPC-UA dans le cahier des charges est un investissement minimal pour un gain de flexibilité considérable à long terme. Pour les équipements existants, une passerelle de protocole (Modbus vers MQTT ou OPC-UA) suffit généralement à les intégrer sans les remplacer.
Traiter la gouvernance des données comme un projet à part entière. Définir les conventions de nommage des topics MQTT ou des nœuds OPC-UA, maintenir un registre de métadonnées, documenter les unités et les plages de valeur normales : ces tâches semblent administratives mais conditionnent directement la maintenabilité des pipelines sur plusieurs années.
Segmenter les réseaux OT et IT avec des passerelles contrôlées. Une DMZ industrielle – zone démilitarisée entre le réseau de production et le réseau informatique – permet de faire circuler les données tout en limitant les risques. Les données remontent de l’OT vers l’IT via des passerelles unidirectionnelles ou des règles de filtrage strictes, sans que le réseau informatique n’ait d’accès direct aux automates.
Commencer petit, documenter tout, reproduire. Les projets qui réussissent commencent généralement par un périmètre limité – une ligne, un atelier, un type d’équipement – avec une architecture bien documentée. C’est beaucoup plus simple à industrialiser ensuite qu’un projet qui essaie de tout connecter d’un coup et se noie dans la complexité.
Sources :
Observatoire IT/OT 2024, NXO & Cisco (135 répondants) ; Forrester Research, taux d’inexploitation des données industrielles ; Linux Embedded, architectures edge et pipelines industriels (2025) ; OPC Foundation, spécifications OPC-UA.
Copyright © 2026. MOTILDE. All rights reserved.