L'IoT industriel avec MQTT : le guide complet de l'IIoT

MQTT pour l'IoT industriel, c'est la manière dont les usines modernes acheminent les données des automates, capteurs et machines vers les systèmes qui les exploitent, sans les intégrations point à point fragiles d'autrefois. Ce guide explique pourquoi MQTT est devenu la colonne vertébrale de l'IIoT, comment se construit une architecture edge-to-cloud, où se placent Sparkplug B et les namespaces de topics ISA-95, et comment mettre en place un premier flux de données machine-broker avec du code exécutable. À la fin, vous disposerez d'une architecture de référence et d'une checklist à apporter à votre prochaine réunion de projet.

Pourquoi MQTT est devenu la colonne vertébrale de l'IoT industriel

L'automatisation classique suit le modèle en couches de Purdue : les capteurs parlent aux automates, les automates au SCADA, le SCADA à un historian, et le MES et l'ERP se trouvent au sommet. Chaque couche s'intègre à la suivante par des connexions point à point, souvent via des protocoles propriétaires. Ajouter un nouveau consommateur de données machine, comme un tableau de bord qualité ou un modèle de maintenance prédictive, implique de toucher plusieurs de ces liens.

MQTT rompt avec ce schéma grâce au publish/subscribe. Chaque source de données publie une seule fois vers un broker central, et un nombre quelconque de consommateurs s'abonnent exactement à ce dont ils ont besoin. Si ce modèle est nouveau pour vous, ce que fait un broker MQTT en couvre les fondamentaux. Pour l'usage industriel, plusieurs propriétés de MQTT comptent tout particulièrement :

• Des connexions uniquement sortantes. Les équipements edge ouvrent les connexions vers le broker ; rien n'a besoin d'entrer dans le réseau de l'usine. Cela correspond bien mieux aux politiques de sécurité OT que les protocoles de polling qui exigent un accès entrant.
• Le report by exception. Les équipements publient lorsqu'une valeur change au lieu d'être interrogés selon un cycle fixe, ce qui réduit considérablement la bande passante sur les liaisons lentes ou facturées au volume. Voir report by exception.
• La connaissance de l'état. Les messages Last Will and Testament, les valeurs retenues et les keep-alives indiquent à chaque consommateur si une machine est en ligne et quel était son dernier état connu.
• Une empreinte légère. Les clients MQTT fonctionnent sur des automates, des passerelles et même des microcontrôleurs, et passent par des liaisons cellulaires.
• Un standard ouvert. MQTT est un standard OASIS doté de clients dans tous les langages : vous n'êtes donc pas lié à la stack d'un seul fournisseur.

Cela ne rend pas OPC UA ni les protocoles de bus de terrain obsolètes. OPC UA reste excellent pour les modèles d'information riches et l'accès au niveau machine, ce qui explique pourquoi la plupart des architectures IIoT combinent les deux ; nous les comparons dans OPC UA vs MQTT.

Architecture de référence MQTT pour l'IoT industriel

Une architecture IIoT pragmatique comporte quatre couches. Chacune a un rôle clair, et le broker se trouve au centre.

L'article sur l'architecture IIoT approfondit chaque couche. Voici les décisions qui comptent le plus.

La passerelle edge

La plupart des machines installées ne parlent pas MQTT. Une passerelle edge IIoT les lit avec leur protocole natif et publie vers le broker. Elle doit interroger rapidement en local mais ne publier qu'en cas de changement, ajouter des horodatages et des unités, et mettre les messages en tampon lorsque la liaison montante tombe. Cette dernière tâche s'appelle le store and forward, et c'est elle qui empêche une panne réseau de se transformer en trou dans les données. Pour des protocoles spécifiques, voir Modbus TCP vers MQTT, le guide de la passerelle OPC UA vers MQTT et de l'automate au cloud.

Le positionnement réseau

Les usines séparent généralement les réseaux OT et IT, avec une DMZ entre les deux. Les schémas courants sont un broker dans la DMZ vers lequel publient les passerelles OT, un broker dans le cloud atteint via une règle de pare-feu sortante, ou les deux reliés par un bridge. Chacun présente des compromis en matière de latence, d'autonomie et de sécurité ; MQTT dans la DMZ industrielle les passe en revue.

Où s'exécute le broker

Les brokers sur site continuent de fonctionner quand Internet tombe, ce qui compte pour tout ce qui se trouve dans une boucle de régulation. Les brokers cloud simplifient considérablement l'agrégation multisite, l'accès à distance et les tableaux de bord. De nombreuses usines font les deux : la logique locale reste locale, et un broker MQTT cloud agrège les sites pour l'analytique et les systèmes d'entreprise. Quel que soit votre choix, les exigences industrielles en matière de disponibilité, d'isolation et de sécurité sont plus élevées que pour l'IoT grand public, comme nous l'expliquons dans choisir un broker MQTT industriel.

Conception des topics : ISA-95 et le Unified Namespace

MQTT seul ne dit rien de la structure des topics, et cette liberté est dangereuse à l'échelle d'une usine. Sans convention, vous vous retrouvez avec machine7/temp, Line-2/Temp_C et plant/oven/temperature dans le même broker, et personne ne peut s'abonner à « tout ce qui concerne la ligne 2 ».

La réponse industrielle consiste à aligner les topics sur la hiérarchie d'équipements ISA-95 :

enterprise/site/area/line/cell/measurement
acme/izmir/machining/line1/cnc1/spindle_temp

Un broker organisé de cette manière devient un Unified Namespace (UNS) : un lieu unique où l'état courant de toute l'entreprise est publié selon une structure que tout le monde comprend. Le MES s'abonne à acme/izmir/#, un tableau de bord de ligne à acme/izmir/machining/line1/#, et un modèle de maintenance à acme/+/+/+/+/vibration. Ajouter un consommateur n'exige jamais de toucher à un producteur.

Les règles qui tiennent dans les vraies usines :

1. Mettez-vous d'accord sur les noms de niveaux et les caractères autorisés avant la connexion du premier équipement.
2. Utilisez des minuscules, pas d'espaces et des identifiants stables (identifiants d'actifs, pas surnoms donnés par les opérateurs).
3. Séparez télémétrie, état, événements et commandes dans des topics feuilles distincts.
4. Placez les unités physiques et les horodatages dans le payload, pas dans le topic.
5. Publiez l'état courant sous forme de retained messages afin que les nouveaux consommateurs le reçoivent instantanément.

Les recommandations détaillées se trouvent dans les topics MQTT ISA-95, la structure des topics UNS et le guide pas à pas comment construire un Unified Namespace.

Sparkplug B : ajouter état et structure à MQTT

Sparkplug B est une spécification de l'Eclipse Foundation qui définit comment les équipements industriels doivent utiliser MQTT. Elle fixe trois éléments que MQTT laisse ouverts :

• Un namespace de topics : spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}.
• Un format de payload : des métriques encodées en Protobuf avec noms, types de données, horodatages et alias.
• La gestion de l'état : des certificats de naissance (NBIRTH, DBIRTH) et de décès (NDEATH, DDEATH), afin que chaque consommateur sache quels edge nodes et équipements sont en ligne et quelles métriques ils publient.

Les bénéfices sont l'interopérabilité entre produits compatibles Sparkplug et un état fiable. Le coût, c'est que les payloads Protobuf ne sont pas lisibles par un humain et que la structure de topics fixe ne reflète pas la hiérarchie de votre usine. Commencez par les explications sur le payload Sparkplug B et les certificats de naissance et de décès Sparkplug, et utilisez décoder Sparkplug B en Python lorsque vous devez inspecter le trafic brut.

Sparkplug B et ISA-95 ensemble

De nombreuses usines utilisent les deux : Sparkplug B à l'edge pour une communication efficace et consciente de l'état, et un namespace JSON ISA-95 pour tous les autres. La difficulté réside dans la couche de traduction entre les deux. Notre article sur Sparkplug B et le Unified Namespace compare les deux approches en détail, et la section suivante montre comment un broker peut effectuer la traduction à votre place.

En pratique : votre premier flux de données MQTT pour l'IoT industriel

Vous pouvez essayer dès maintenant des patterns de topics industriels sur le serveur MQTT public gratuit broker.connectmq.com. Utilisez un préfixe unique, limitez vos topics à 8 niveaux et rappelez-vous que l'espace public est lisible par tous : n'utilisez donc que des données simulées.

Abonnez-vous à l'ensemble de l'usine simulée :

mosquitto_sub -h broker.connectmq.com -p 1883 -i iiot-sub-m5q2 \
  -t "connectmq/demo/m5q2/#" -v

Publiez une mesure de style ISA-95 et un état machine retenu :

mosquitto_pub -h broker.connectmq.com -p 1883 -i iiot-pub-m5q2 -q 1 \
  -t "connectmq/demo/m5q2/machining/line1/cnc1/telemetry" \
  -m '{"spindle_temp":61.4,"spindle_rpm":8200,"unit_temp":"C","ts":1760600000}'

mosquitto_pub -h broker.connectmq.com -p 1883 -i iiot-pub-m5q2 -q 1 -r \
  -t "connectmq/demo/m5q2/machining/line1/cnc1/state" -m "RUNNING"

Une passerelle edge minimale Modbus TCP vers MQTT

Le script ci-dessous joue le rôle d'une passerelle edge. Il lit deux registres de maintien d'un équipement Modbus TCP chaque seconde, ne publie que lorsqu'une valeur varie au-delà d'une bande morte, et enregistre un Last Will pour que les consommateurs sachent quand la passerelle disparaît. Il utilise pymodbus 3.x et paho-mqtt 2.x :

pip install "pymodbus>=3.6" "paho-mqtt>=2.0"

import json
import time

import paho.mqtt.client as mqtt
from pymodbus.client import ModbusTcpClient

PLC_HOST = "192.168.1.50"      # votre équipement Modbus TCP ou simulateur
BASE = "connectmq/demo/m5q2/machining/line1/press1"
DEADBAND = 0.5                 # publier seulement si une valeur varie d'au moins cette quantité

def on_connect(client, userdata, flags, reason_code, properties):
    print("Broker connection:", reason_code)
    client.publish(f"{BASE}/state", "ONLINE", qos=1, retain=True)

mqttc = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id="edge-press1-m5q2",
    protocol=mqtt.MQTTv5,
)
mqttc.will_set(f"{BASE}/state", "OFFLINE", qos=1, retain=True)
mqttc.on_connect = on_connect
mqttc.reconnect_delay_set(min_delay=1, max_delay=30)
mqttc.connect("broker.connectmq.com", 1883, keepalive=30)
mqttc.loop_start()

plc = ModbusTcpClient(PLC_HOST, port=502)
last = {}

while True:
    if not plc.connected:
        plc.connect()
    rr = plc.read_holding_registers(address=0, count=2)
    if rr.isError():
        print("Modbus read failed:", rr)
        time.sleep(2)
        continue

    values = {
        "pressure_bar": rr.registers[0] / 10.0,  # mis à l'échelle x10 dans l'automate
        "temperature_c": rr.registers[1] / 10.0,
    }
    changed = {k: v for k, v in values.items()
               if k not in last or abs(v - last[k]) >= DEADBAND}
    if changed:
        changed["ts"] = int(time.time() * 1000)
        mqttc.publish(f"{BASE}/telemetry", json.dumps(changed), qos=1)
        last.update({k: v for k, v in changed.items() if k != "ts"})
    time.sleep(1)

Observez votre terminal abonné : les valeurs n'apparaissent que lorsqu'elles bougent, et OFFLINE arrive si vous tuez le script. La mise à l'échelle des registres, l'ordre des mots et l'adressage varient selon les fabricants d'automates : vérifiez donc la table des registres de l'équipement ; notre guide de passerelle Modbus vers MQTT couvre ces détails. Une passerelle de production mettrait aussi les données en tampon sur disque pendant les coupures et utiliserait TLS avec des identifiants.

Comment ConnectMQ prend en charge MQTT pour l'IoT industriel

ConnectMQ est un broker MQTT managé doté de fonctionnalités spécialement pensées pour le trafic industriel :

• Détection ISA-95 et UNS. Le broker reconnaît les structures de topics ISA-95 et Unified Namespace dans votre trafic.
• Décodage Sparkplug B. Les payloads Sparkplug B sont décodés (Protobuf ou JSON) pour que vous puissiez les lire dans le portail au lieu de fixer des octets.
• Republication de Sparkplug vers ISA-95. Les données Sparkplug B peuvent être republiées dans des topics ISA-95 avec des payloads lisibles ; par exemple, spBv1.0/factory1/DDATA/line1/cnc1 devient connectmq/factory1/production/line1/cnc1/telemetry. Les edge nodes continuent de parler Sparkplug pendant que le MES et les tableaux de bord consomment un namespace propre.
• Vue des équipements ISA-95 et alertes. Le portail affiche les équipements organisés selon les niveaux ISA-95, et des règles d'alerte à seuil avec un journal des alertes signalent des valeurs comme une température de broche qui franchit une limite.
• Choix du déploiement. Commencez sur le plan Serverless gratuit, puis passez à un cluster isolé Dedicated, à BYOC dans votre propre compte cloud, ou à Self Managed Enterprise pour les sites qui doivent rester sur site.

Pour voir à quoi cela ressemble de bout en bout, la démo web du jumeau numérique 3D de ConnectMQ montre une usine avec une CNC, un bras robotisé, un four, une cuve, un convoyeur et une pompe mis à jour en direct via Secure WebSocket. Le stockage et l'analytique sont traités de manière ouverte : historians, Telegraf, Node-RED ou vos propres services s'abonnent au broker comme des clients MQTT standard. Voir construire un historian MQTT pour ce pattern.

Checklist d'un projet MQTT pour l'IoT industriel

Utilisez cette liste pour cadrer un premier déploiement. La version complète se trouve dans notre checklist de connectivité IIoT.

1. Inventoriez les machines, les protocoles et les points de données qui répondent réellement à une question métier.
2. Convenez d'une hiérarchie de topics ISA-95 et de règles de nommage avec l'OT comme avec l'IT.
3. Choisissez le format de payload : Sparkplug B à l'edge, JSON pour les consommateurs, ou les deux.
4. Choisissez le matériel de passerelle et vérifiez qu'il prend en charge la mise en tampon et TLS.
5. Décidez où s'exécute le broker et comment le trafic franchit la frontière OT/IT.
6. Émettez des identifiants uniques par passerelle et imposez TLS sur le 8883.
7. Définissez la gestion de l'état : Last Will, topics d'état retenus, messages de naissance et de décès.
8. Prévoyez le stockage et la visualisation avec des outils abonnés, et non une magie côté broker.
9. Menez un pilote sur une ligne, mesurez, puis passez à l'échelle.

L'alignement organisationnel compte ici autant que la technologie ; la convergence IT/OT explique comment les équipes se répartissent les responsabilités. Pour une vue d'ensemble de la place de cette couche de connectivité dans un programme de transformation numérique, lisez notre guide de l'Industrie 4.0.

Construisez votre pilote IoT industriel sur ConnectMQ

Essayez les exemples ci-dessus sur le serveur MQTT public gratuit broker.connectmq.com, réservé aux tests, puis créez un broker privé sur app.connectmq.com. Le plan Serverless gratuit ne demande aucune carte bancaire et suffit pour un pilote sur une seule ligne avec quelques passerelles, des tableaux de bord, ainsi que le décodage Sparkplug B et les vues ISA-95 décrits ci-dessus.

Questions fréquentes

MQTT est-il adapté à l'automatisation industrielle ?

Oui, pour transporter les données entre machines, passerelles edge et applications. Les boucles de régulation temps réel strict restent du ressort des bus de terrain et des automates ; MQTT achemine les données qui les entourent vers le SCADA, le MES, les historians et l'analytique.

Faut-il Sparkplug B pour faire de l'IoT industriel avec MQTT ?

Non, mais il est utile lorsque les produits de nombreux fournisseurs doivent interopérer et que vous avez besoin d'un état en ligne/hors ligne fiable. Beaucoup d'usines utilisent Sparkplug B à l'edge et un namespace JSON ISA-95 pour les consommateurs.

Le broker MQTT industriel doit-il tourner sur site ou dans le cloud ?

Tout ce qui se trouve dans une boucle de régulation ne doit pas dépendre d'une liaison Internet ; les brokers locaux sont donc courants en usine. Un broker cloud est préférable pour l'agrégation multisite, les tableaux de bord à distance et l'intégration aux systèmes d'entreprise, et de nombreuses architectures utilisent les deux.

Comment connecter un automate qui ne prend pas en charge MQTT ?

Utilisez une passerelle edge qui lit l'automate via son protocole natif, comme Modbus, OPC UA, S7 ou EtherNet/IP, et publie vers le broker. De nombreux automates récents disposent aussi de clients MQTT intégrés.

ConnectMQ peut-il lire les messages Sparkplug B ?

Oui. ConnectMQ décode les payloads Sparkplug B et peut les republier dans des topics ISA-95 avec des payloads lisibles, afin que les consommateurs non Sparkplug puissent utiliser les données directement.