Les critères pour choisir un broker MQTT industriel

Un broker MQTT industriel se trouve au centre des données de votre usine : chaque passerelle y publie et chaque SCADA, MES, historian et tableau de bord y lit. Dans ce guide, vous découvrirez les capacités qui distinguent un broker capable de tenir en atelier d'un broker qui se contente de passer les tests de protocole, et vous exécuterez un court script Python qui vérifie les comportements les plus importants sur n'importe quel broker que vous évaluez.

Pourquoi l'usage industriel change les exigences

Tout broker conforme sait acheminer un message d'un éditeur vers un abonné. Dans une application IoT grand public, cela suffit souvent. Dans une usine, le broker transporte plus que des messages. Il transporte un état : quelles machines sont en ligne, la valeur actuelle de chaque tag, et si une mesure est fraîche ou périmée. Les opérateurs prennent des décisions à partir de cet état, et dans certaines architectures, les systèmes SCADA en dérivent leurs alarmes.

Le trafic industriel est aussi différent. Des milliers de tags changent à des rythmes irréguliers, une ligne entière peut se reconnecter d'un coup après une coupure réseau, et les payloads peuvent être en protobuf Sparkplug B plutôt qu'en JSON lisible. Les clients vivent des années sur des passerelles que personne ne veut toucher. Un broker qui convient à un projet amateur peut peiner dans ces conditions. Si le rôle du broker lui-même est nouveau pour vous, commencez par ce qu'est un broker MQTT.

Les capacités essentielles d'un broker MQTT industriel

Prise en charge de Sparkplug

Sparkplug B définit une structure de topics, des certificats de naissance et de mort et un payload protobuf pour le MQTT industriel. À strictement parler, le broker n'a pas besoin de comprendre Sparkplug : c'est une spécification côté client, et tout broker MQTT 3.1.1 qui gère les retained messages, la QoS et les wills peut la transporter. En pratique, un broker capable de décoder les payloads Sparkplug fait gagner des heures. Pendant la mise en service, vous voulez voir Temperature = 72.4 plutôt qu'un bloc binaire. Lisez notre guide du payload Sparkplug B pour comprendre ce qu'il contient.

Une étape encore plus utile est la republication. Les topics Sparkplug comme spBv1.0/factory1/DDATA/line1/cnc1 sont compacts mais peu pratiques pour les consommateurs IT. Un broker capable de republier ces métriques dans des topics ISA-95 comme connectmq/factory1/production/line1/cnc1/telemetry permet au SCADA natif Sparkplug et aux applications métier orientées JSON d'utiliser les mêmes données. La relation entre les deux modèles est expliquée dans Sparkplug B et le Unified Namespace.

État retenu et sessions

Un Unified Namespace ne fonctionne que si un tableau de bord lancé à 9 h voit l'état de chaque machine à 9 h, et pas seulement après le prochain changement de chaque machine. C'est ce qu'apportent les retained messages, qui servent aussi de point de départ à un jumeau numérique de la ligne. Les sessions persistantes avec une expiration raisonnable protègent contre l'autre défaillance courante : une passerelle qui se reconnecte après une courte coupure réseau et manque tout ce qui a été publié sur ses abonnements entre-temps. Dans les systèmes Sparkplug, l'application hôte primaire s'appuie sur ces mécanismes, associés aux certificats de mort, pour suivre l'état des nœuds edge.

Une sécurité adaptée à la réalité OT

Les passerelles doivent s'authentifier avec leurs propres identifiants, se connecter via TLS et être bloquées si quelqu'un martèle la connexion avec de mauvais mots de passe. Des client IDs liés aux identifiants empêchent un appareil d'usurper l'identité d'un autre ou de le déconnecter en réutilisant son ID. Le broker doit aussi limiter le volume qu'un même client peut publier, afin qu'une passerelle mal configurée publiant un tag chaque milliseconde ne dégrade pas le service pour le reste de l'usine.

De la visibilité pour ceux qui mettent le système en service

La capacité la plus sous-estimée d'un broker est une bonne fenêtre sur son contenu. Quand un automaticien connecte une nouvelle passerelle, la première question est toujours : « les données arrivent-elles, et au bon endroit ? » Un explorateur de topics en temps réel, une vue des clients connectés et un topic d'état de connexion y répondent en quelques secondes. Les alertes à seuil transforment le broker, simple tuyau, en outil de supervision de base pour des valeurs comme les limites de température ou la santé des passerelles.

Disponibilité et modèle d'exploitation

Demandez qui met à jour le broker, qui renouvelle les certificats, qui surveille le disque et la mémoire, et qui est appelé à 3 h du matin. L'auto-hébergement offre un contrôle total mais rend l'équipe de l'usine responsable d'un serveur exposé à Internet. Un broker MQTT managé transfère ce travail au fournisseur. Quel que soit votre choix, prévoyez le comportement des clients lors d'un redémarrage du broker : reconnexion avec backoff, reprise des sessions et republication des births ou de l'état retenu si nécessaire.

Testez vous-même n'importe quel broker MQTT industriel

Les listes de fonctionnalités sont faciles à écrire. Ce script MQTT 5 vérifie quatre comportements importants en usine : la livraison des messages retenus, la reprise de session, le last will et les reason codes. Exécutez-le d'abord sur le serveur MQTT public gratuit, puis sur tout broker que vous évaluez.

import time
import uuid
import paho.mqtt.client as mqtt
from paho.mqtt.properties import Properties
from paho.mqtt.packettypes import PacketTypes

HOST, PORT = "broker.connectmq.com", 1883
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1/line1"

def make_client(cid):
    return mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                       client_id=cid, protocol=mqtt.MQTTv5)

def session_props(seconds):
    p = Properties(PacketTypes.CONNECT)
    p.SessionExpiryInterval = seconds
    return p

received = []

def on_message(client, userdata, msg):
    received.append((msg.topic, msg.payload.decode(), msg.retain))

# 1. La passerelle publie un état retenu et enregistre un last will
gw = make_client("gw-" + uuid.uuid4().hex[:6])
gw.will_set(f"{BASE}/gw1/status", "OFFLINE", qos=1, retain=True)
gw.connect(HOST, PORT, keepalive=5)
gw.loop_start()
gw.publish(f"{BASE}/gw1/status", "ONLINE", qos=1, retain=True)
gw.publish(f"{BASE}/cnc1/state", "RUNNING", qos=1, retain=True).wait_for_publish()

# 2. Un abonné tardif avec session persistante reçoit immédiatement l'état retenu
sub_id = "scada-" + uuid.uuid4().hex[:6]
sub = make_client(sub_id)
sub.on_message = on_message
sub.connect(HOST, PORT, clean_start=False, properties=session_props(300))
sub.loop_start()
sub.subscribe(f"{BASE}/#", qos=1)
time.sleep(2)
print("Retained on subscribe:", received)

# 3. L'abonné se déconnecte, la passerelle publie, l'abonné reprend sa session
sub.disconnect(); sub.loop_stop()
gw.publish(f"{BASE}/cnc1/state", "IDLE", qos=1).wait_for_publish()
received.clear()
sub = make_client(sub_id)
sub.on_message = on_message
sub.connect(HOST, PORT, clean_start=False, properties=session_props(300))
sub.loop_start()
time.sleep(2)
print("Delivered after resume:", received)

# 4. Simulation d'un crash de la passerelle : arrêt de la boucle réseau sans DISCONNECT
received.clear()
gw.loop_stop()
gw.socket().close()
time.sleep(10)  # attendre au-delà de 1,5 x keepalive
print("Last will:", received)
sub.disconnect()

Résultat attendu : les valeurs retenues ONLINE et RUNNING à l'abonnement, le changement IDLE livré après la reprise de session alors qu'il a été publié pendant l'absence de l'abonné, et OFFLINE qui arrive dès que le broker constate la disparition de la passerelle. N'oubliez pas que le serveur MQTT public gratuit est lisible par tous, réservé aux tests et aux prototypes (jamais aux données de production), et comporte des limites volontaires (messages de 64 Ko, 10 messages par seconde et par client, expiration de session jusqu'à 30 minutes) : réservez les tests de charge à votre propre broker.

Liste de contrôle pour l'évaluation

1. Exécutez le script ci-dessus sur le broker candidat avec TLS sur le port 8883.
2. Publiez du vrai trafic Sparkplug B depuis un simulateur et vérifiez que vous pouvez le lire dans les outils du broker.
3. Reconnectez 50 clients en même temps et surveillez les connexions refusées ou les CONNACK lents.
4. Publiez volontairement trop vite et vérifiez quel reason code vous recevez, par exemple 0x97 (quota dépassé) en MQTT 5.
5. Essayez cinq mauvais mots de passe d'affilée et confirmez que le broker réagit.
6. Demandez qui exploite le broker et comment fonctionne le renouvellement des certificats.

Pour une comparaison plus large, hors contexte industriel, consultez comment choisir un broker MQTT pour l'IoT.

L'approche de ConnectMQ pour l'industrie

ConnectMQ est un broker MQTT managé conçu en tenant compte de ces exigences. Il prend en charge MQTT 3.1.1 et 5.0 sur TCP, TLS, WebSocket et WebSocket sécurisé, les retained messages, l'expiration de session et l'ensemble des reason codes MQTT 5. Il détecte les topics ISA-95 et Unified Namespace, décode Sparkplug B (protobuf et JSON) et republie les métriques Sparkplug dans des topics ISA-95. Chaque broker expose l'état des connexions sur $SYS/broker/connection/{clientId}/state, et le portail ajoute un explorateur de topics en temps réel, une vue des appareils par niveau ISA-95 et des règles d'alerte à seuil. L'isolation multi-tenant, les quotas par offre, la protection anti-flood et le blocage d'IP après des échecs de connexion répétés protègent chaque tenant. Les offres vont du Serverless gratuit aux clusters Dedicated, en passant par BYOC dans votre propre compte cloud et Self Managed Enterprise. Pour les compromis d'hébergement en général, lisez notre guide des brokers MQTT cloud ; pour la vue industrielle d'ensemble, consultez l'IoT industriel avec MQTT.

Démarrer avec ConnectMQ

Créez gratuitement un broker Serverless sur app.connectmq.com, sans carte bancaire. Pointez le script de test et un simulateur Sparkplug vers ce broker, et voyez en quelques minutes les données de votre usine décodées et organisées par niveau ISA-95 dans le portail ConnectMQ.

Questions fréquentes

Un broker MQTT industriel doit-il prendre en charge Sparkplug B ?

Sparkplug B fonctionne sur tout broker conforme gérant les retained messages, la QoS et le last will. Un broker qui décode en plus les payloads Sparkplug facilite nettement la mise en service et le dépannage.

MQTT 5 est-il obligatoire pour un usage industriel ?

Non, Sparkplug B et de nombreuses passerelles utilisent MQTT 3.1.1. MQTT 5 ajoute des fonctionnalités utiles comme l'expiration de session, les reason codes et les abonnements partagés ; un broker doit donc prendre en charge les deux versions.

Faut-il auto-héberger un broker MQTT industriel ou opter pour un service managé ?

L'auto-hébergement offre un contrôle total mais rend votre équipe responsable des mises à jour, des certificats et de la supervision. Un broker MQTT managé supprime ce travail, et des options comme BYOC conservent le broker dans votre propre compte cloud.

Comment savoir si une passerelle est hors ligne ?

Configurez un last will retenu, par exemple OFFLINE, sur un topic de statut. Le broker le publie automatiquement lorsque la passerelle se déconnecte sans DISCONNECT propre.