La convergence IT OT est le processus qui consiste à réunir les technologies de l'information (systèmes de gestion, cloud, analytique) et les technologies opérationnelles (automates, SCADA, machines) sur un socle commun, afin que tous travaillent à partir des mêmes données. Dans cet article, vous verrez pourquoi ces deux mondes ont évolué si différemment, ce qui doit réellement changer sur le plan technique et culturel, et comment un namespace MQTT partagé offre aux équipes IT et OT une vue unique et en temps réel de l'usine, sans sacrifier les priorités de l'une ou de l'autre.
Deux mondes qui se sont éloignés
Les technologies opérationnelles sont nées dans l'atelier. Leur rôle est de maintenir un procédé physique en fonctionnement, en toute sécurité, à chaque seconde et pendant des décennies. Un automate qui pilote un four peut exécuter le même programme pendant quinze ans, et c'est considéré comme une réussite. Le changement est un risque, et une panne peut endommager l'équipement ou blesser des personnes.
Les technologies de l'information sont nées dans les bureaux. Leur rôle est de traiter l'information de l'entreprise de façon sûre et efficace. Les systèmes sont mis à jour chaque mois, remplacés tous les quelques ans, et une panne coûte cher mais est rarement dangereuse. Le changement est normal, et rester à jour fait partie de la sécurité.
Aucune de ces visions n'est fausse. Elles sont optimisées pour des conséquences de défaillance différentes. L'essentiel des frictions dans les projets de convergence vient de personnes qui appliquent les règles d'un monde à l'autre.
| Dimension | Priorités IT | Priorités OT |
|---|---|---|
| Préoccupation principale | Confidentialité des données | Disponibilité et sécurité du procédé |
| Cycle de vie typique | 3 à 5 ans | 15 à 30 ans |
| Correctifs | Réguliers, souvent automatisés | Rares, planifiés autour des arrêts |
| Protocoles | HTTP, SQL, REST, API cloud | Modbus, Profinet, OPC UA, protocoles constructeurs |
| Forme des données | Transactions, documents, enregistrements | Signaux continus, états, événements |
| Tolérance aux arrêts | Fenêtres de maintenance planifiées | Mesurée en perte de production par minute |
| Qui fait les changements | Administrateurs IT, DevOps | Automaticiens, intégrateurs |
Ce que signifie vraiment la convergence IT/OT
La convergence est souvent comprise à tort comme « mettre les automates sur le réseau de l'entreprise ». C'est la version qui inquiète les ingénieurs OT, et ils ont raison. Bien menée, la convergence IT OT recouvre trois choses plus ciblées :
- Des données partagées. Les données de production remontent de façon fiable vers les systèmes de gestion, et le contexte métier, comme les ordres de fabrication et les recettes, est accessible aux opérations.
- Des pratiques partagées. La sécurité, la gestion des identités, la supervision et la gestion des changements sont appliquées de manière cohérente, en s'adaptant aux contraintes de chaque côté.
- Des personnes qui se comprennent. Les équipes connaissent les priorités de l'autre et possèdent ensemble la couche d'intégration.
La convergence n'exige pas un réseau à plat. Le modèle de Purdue et les zones de l'IEC 62443 s'appliquent toujours. L'intégration se fait à une frontière définie, généralement une DMZ industrielle, et le réseau de l'usine reste segmenté. Notre comparaison du modèle de Purdue et de l'ISA-95 explique comment ces couches s'articulent.
Les briques techniques
Des données pilotées par les événements plutôt que des intégrations point à point
La méthode traditionnelle pour donner à l'IT l'accès aux données OT est l'intégration point à point : le MES interroge le SCADA, l'ERP interroge l'historian, un outil de reporting lit une base de données alimentée par l'historian. Chaque lien est sur mesure, fragile et appartient à celui qui l'a construit. Ajouter un nouveau consommateur signifie une intégration de plus.
La messagerie publish/subscribe change la donne. Chaque source OT publie ses données une seule fois vers un broker. Chaque consommateur IT s'abonne à ce dont il a besoin. Le côté OT n'a jamais besoin de savoir qui écoute, et le côté IT n'a jamais besoin d'une connexion entrante dans l'usine. Si le rôle du broker est nouveau pour vous, consultez ce que fait un broker MQTT.
Un Unified Namespace comme langage commun
Un broker seul ne rend pas les données compréhensibles. Un Unified Namespace (UNS) apporte la structure : chaque valeur se trouve sur un topic prévisible basé sur la hiérarchie ISA-95, par exemple connectmq/acme/plant1/assembly/line2/press04/state. Un ingénieur OT y reconnaît l'emplacement physique. Un développeur IT y voit une API stable et documentée. Les deux lisent le même topic, tout comme un éventuel jumeau numérique de la ligne. Notre guide pour construire un Unified Namespace détaille la conception.
Une connectivité uniquement sortante
Les passerelles OT se connectent vers le broker en sortie via TLS, et les consommateurs IT également. Aucun port entrant n'est ouvert vers l'usine. C'est la propriété la plus importante pour obtenir le soutien de l'équipe sécurité OT. Ce modèle est détaillé dans notre article sur MQTT dans une DMZ industrielle.
Une responsabilité claire sur la couche de données
Quelqu'un doit être responsable des règles de nommage des topics, des conventions de payload, des identifiants d'accès et de la qualité des données. Dans les organisations matures, cela devient une fonction de DataOps industriel placée entre l'IT et l'OT. Pour en savoir plus, lisez notre présentation du DataOps industriel.
Exemple : les deux équipes lisent les mêmes données en temps réel
Voici à quoi ressemble la convergence en pratique. Une passerelle OT publie l'état des machines sous forme de retained messages dans l'UNS. Un développeur IT écrit quelques lignes de Python pour transmettre cet état à une application métier, sans jamais toucher à l'automate ni à la passerelle.
Essayez d'abord sur le serveur MQTT public gratuit, réservé aux tests et aux prototypes. Publiez un état retenu en tant que « côté OT » :
mosquitto_pub -h broker.connectmq.com -p 1883 -i ot-sim-$RANDOM -r \
-t connectmq/demo/itot42/plant1/assembly/line2/press04/state \
-m '{"state":"RUNNING","order":"WO-1182","ts":"2026-10-16T09:12:00Z"}'
Lancez ensuite l'abonné « côté IT » :
import json
import uuid
import paho.mqtt.client as mqtt
TOPIC = "connectmq/demo/itot42/plant1/+/+/+/state"
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe(TOPIC, qos=1)
def on_message(client, userdata, msg):
parts = msg.topic.split("/")
area, line, machine = parts[4], parts[5], parts[6]
data = json.loads(msg.payload)
# Transmission à un système métier ; ici, on affiche simplement une ligne
print(f"{area:10} {line:6} {machine:8} {data['state']:8} order={data.get('order')}")
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"it-app-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()
L'abonné reçoit l'état retenu immédiatement à la connexion, puis chaque changement au moment où il se produit. L'ingénieur OT peut ouvrir un explorateur MQTT de bureau sur le même topic et voir exactement le même message. Cette vue partagée, c'est la convergence au quotidien. En production, chaque côté utilise ses propres identifiants auprès du broker sur le port 8883, et les vraies données d'usine ne passent jamais par une zone publique, lisible par n'importe qui.
Les étapes culturelles qui font durer la convergence
La technologie est la moitié la plus facile. Ces pratiques aident sur le plan humain :
- Partir d'un problème OT. Choisissez un cas d'usage qui compte pour l'usine, comme les arrêts non planifiés sur une machine goulot. Les projets portés par l'IT qui ne servent que le reporting obtiennent rarement le soutien de l'OT.
- Laisser l'OT maîtriser l'edge. Les automaticiens décident de ce qui est lu sur quel automate, à quelle fréquence et dans quel mode. L'IT est responsable des consommateurs.
- S'accorder sur la frontière. Écrivez noir sur blanc où s'arrête la responsabilité de l'OT, généralement à la connexion sortante de la passerelle, et où commence celle de l'IT.
- Utiliser un seul vocabulaire. La hiérarchie ISA-95 dans les noms de topics donne aux deux équipes des mots communs pour les sites, zones, lignes et machines.
- Constituer des binômes. Placez un développeur IT et un automaticien sur le même pilote. Deux semaines de travail en commun valent mieux que n'importe quel atelier.
- Respecter les fenêtres de changement. Les mises à jour des passerelles suivent les plannings de maintenance OT, pas le Patch Tuesday de l'IT.
Là où un broker MQTT managé aide
La couche de données partagée doit être sécurisée, toujours disponible et maintenue, ce qui relève typiquement du travail de l'IT. L'héberger sur du matériel d'usine confie ce travail à l'OT, qui n'en veut généralement pas. Un broker MQTT managé est un terrain neutre où les deux équipes se rencontrent. ConnectMQ détecte automatiquement les topics ISA-95 et Unified Namespace, affiche les appareils regroupés par niveau ISA-95, décode Sparkplug B pour les équipes qui l'utilisent et propose un explorateur de topics en temps réel utilisable aussi bien par un automaticien que par un développeur. Les organisations soumises à des règles strictes de résidence des données peuvent exécuter ConnectMQ BYOC dans leur propre compte cloud. Pour comparer plus largement les modèles d'hébergement, consultez notre guide des brokers MQTT cloud, et pour la vue industrielle complète, le guide de l'IoT industriel avec MQTT.
Donnez à l'IT et à l'OT un namespace commun sur ConnectMQ
Créez gratuitement un broker Serverless (Free) sur app.connectmq.com, sans carte bancaire. Publiez l'état d'une machine dans une arborescence de topics ISA-95, attribuez des identifiants aux deux équipes et laissez la discussion partir de données partagées plutôt que de tableurs concurrents.
Questions fréquentes
Qu'est-ce que la convergence IT OT, en termes simples ?
C'est faire travailler les systèmes de gestion et les systèmes de l'usine à partir des mêmes données, avec des pratiques communes en matière de sécurité et de changement. Cela ne signifie pas fusionner les réseaux ni donner à l'IT le contrôle des automates.
La convergence IT/OT augmente-t-elle le risque cyber ?
C'est possible si elle passe par l'aplatissement des réseaux. Menée avec de la segmentation, des connexions uniquement sortantes à travers une DMZ et des identifiants propres à chaque client, elle améliore généralement la visibilité et la sécurité par rapport à des intégrations ad hoc.
Pourquoi MQTT est-il populaire pour la convergence IT/OT ?
Les clients se connectent en sortie vers un broker, donc aucun port entrant vers l'usine n'est nécessaire. Le modèle publish/subscribe permet aussi à de nombreux consommateurs IT d'utiliser les mêmes données OT sans intégrations supplémentaires.
Qui doit être responsable du Unified Namespace ?
Idéalement, une équipe mixte ou une fonction de DataOps industriel. L'OT est responsable de ce qui est publié depuis l'edge, l'IT des consommateurs, et l'équipe mixte des règles de nommage et des standards de payload.
