OPC UA vs MQTT : quel protocole industriel choisir ?

OPC UA vs MQTT est l'un des débats les plus fréquents de l'IoT industriel, et il est généralement mal posé. Cette comparaison explique pour quoi chaque protocole a été conçu, en quoi ils diffèrent en matière de modélisation de l'information, de mode de communication, de sécurité et de connectivité cloud, et pourquoi la réponse la plus courante sur le terrain est « OPC UA à l'edge, MQTT vers le cloud ». À la fin, vous saurez lequel utiliser pour chaque couche de votre architecture.

Deux protocoles, deux missions différentes

OPC UA (Open Platform Communications Unified Architecture) est un cadre d'interopérabilité industrielle. Il définit non seulement la façon dont les octets circulent, mais aussi la façon dont une machine se décrit : objets, variables, méthodes, types, unités physiques, alarmes et historique. Un client se connecte à un serveur, parcourt son espace d'adressage et lit, écrit, s'abonne ou appelle des méthodes. Il est normalisé sous la référence IEC 62541 et intégré à de nombreux automates, CNC et systèmes SCADA modernes.

MQTT est un protocole de messagerie publish/subscribe léger. Les clients se connectent à un broker central, publient des messages sur des topics et s'abonnent aux topics qui les intéressent. MQTT ne dit volontairement rien de la signification du payload ; il transporte des octets de manière efficace et fiable sur des réseaux peu fiables. C'est une norme OASIS, et les versions 3.1.1 et 5.0 sont largement utilisées. Si le concept de broker est nouveau pour vous, commencez par ce que fait un broker MQTT.

La comparaison ressemble donc un peu à celle d'un schéma de base de données avec un bus de messages. Les deux transportent des données, mais la valeur que chacun apporte est différente.

OPC UA vs MQTT en un coup d'œil

Dimension	OPC UA (client/serveur)	MQTT
Mode principal	Sessions client/serveur ; abonnements par session	Publish/subscribe via un broker
Modèle d'information	Espace d'adressage riche, typé et navigable, avec métadonnées	Aucun intégré ; topics et payloads définis par vous ou par une spécification comme Sparkplug B
Découverte	Parcourir le serveur pour trouver nœuds et types	Abonnement avec wildcards ; pas de découverte de schéma intégrée
Couplage	Chaque consommateur se connecte à chaque serveur	Producteurs et consommateurs ne connaissent que le broker
Sens réseau	Le client doit joindre le serveur, généralement en entrée vers le réseau OT	Tous les clients se connectent en sortie vers le broker
Empreinte	Pile plus lourde, messages plus gros, état de session	Bibliothèques clientes très légères, en-tête minimal de 2 octets
Sécurité	Certificats d'application, signature et chiffrement, jetons utilisateur	TLS sur le transport, nom d'utilisateur/mot de passe ou certificats clients, autorisation côté broker
Écriture et appels de méthodes	Natifs : écriture de variables, appel de méthodes	Possibles via des topics de commande, mais par convention
Accès cloud et IT	Prise en charge native limitée dans les plateformes cloud	Pris en charge par pratiquement toutes les plateformes IoT et tous les langages
Terrain de prédilection	Automates, CNC, SCADA, MES sur le réseau de l'usine	Passerelles edge, applications cloud, tableaux de bord, mobile, appareils contraints

OPC UA dispose aussi d'une extension PubSub (partie 14) qui peut utiliser MQTT comme transport. Cela brouille considérablement la frontière ; le sujet est traité dans notre article sur OPC UA PubSub sur MQTT. Cette comparaison se concentre sur l'OPC UA client/serveur classique, car c'est ce qu'expose aujourd'hui la majorité des équipements installés.

Modélisation de l'information : le gros atout d'OPC UA

Le point fort d'OPC UA, c'est la sémantique. Un serveur peut dire : « ceci est une variable appelée SpindleTemperature, de type Double, son unité est le degré Celsius, sa plage va de 0 à 120, et elle appartient à un objet de type MachineToolType ». Les companion specifications vont plus loin et définissent des modèles standard pour des classes entières de machines, de sorte que les presses à injecter de deux fabricants peuvent apparaître identiques pour un client.

MQTT n'offre rien de tout cela d'emblée. Un payload 47.3 sur un topic n'est qu'une suite d'octets. Les équipes compensent de trois façons :

Des conventions de topics comme une hiérarchie ISA-95, pour que le chemin lui-même porte le contexte. Notre guide sur les topics MQTT ISA-95 présente une organisation pratique.
Un JSON autodescriptif avec valeur, unité, qualité et horodatage dans chaque message.
Sparkplug B, qui ajoute à MQTT un payload défini, des certificats de naissance et de mort et des métadonnées de métriques.

Si une modélisation riche est indispensable pour un cas d'usage, par exemple un MES qui lit des recettes et appelle des méthodes sur une machine, OPC UA est le choix naturel.

Mode de communication : sessions contre découplage

Avec l'OPC UA classique, chaque consommateur ouvre une session avec chaque serveur dont il a besoin. Dix applications lisant cinquante machines peuvent représenter des centaines de sessions, chacune consommant de la mémoire sur des automates qui n'ont jamais été dimensionnés pour cela. Ajouter un nouveau consommateur implique de toucher aux règles de pare-feu et à la configuration des serveurs.

Avec MQTT, chaque machine ou passerelle publie une seule fois vers le broker, et n'importe quel nombre de consommateurs s'y abonne. Ajouter un tableau de bord ou un traitement analytique ne touche à rien dans l'atelier. Ce découplage est la raison principale pour laquelle MQTT est devenu l'épine dorsale du modèle Unified Namespace.

Le revers de la médaille : MQTT place le broker sur le chemin critique. S'il tombe, plus rien ne circule ; la disponibilité, la supervision et la capacité du broker deviennent donc des sujets opérationnels. C'est l'une des raisons pour lesquelles de nombreuses équipes choisissent un broker MQTT managé plutôt que d'exploiter elles-mêmes leurs brokers.

Modèles de sécurité

Les deux protocoles peuvent être bien sécurisés, et les deux peuvent être déployés de façon non sécurisée.

La sécurité OPC UA se situe au niveau applicatif : chaque client et chaque serveur possède un certificat d'instance d'application X.509, et la session peut être signée, ou signée et chiffrée. L'authentification des utilisateurs vient s'ajouter par-dessus. La difficulté opérationnelle courante est la gestion de la confiance des certificats sur des dizaines d'appareils.

La sécurité MQTT se situe principalement au niveau du transport et du broker : TLS pour le chiffrement, identifiants ou certificats clients pour l'authentification, et règles côté broker pour définir ce que chaque client peut faire. L'avantage architectural tient au sens des connexions. Comme chaque client MQTT se connecte en sortie vers le broker, vous n'ouvrez aucun port entrant vers le réseau OT. Notre article sur les bonnes pratiques de sécurité MQTT liste l'essentiel.

Connectivité cloud

C'est ici que la comparaison est la plus déséquilibrée. Les services cloud, applications web, applications mobiles et outils de données parlent presque tous MQTT, HTTP ou les deux. Très peu parlent nativement l'OPC UA client/serveur, et exposer un serveur OPC UA directement sur Internet est une mauvaise idée. La faible empreinte de MQTT, sa tolérance aux liaisons instables, ses keep-alives et ses messages Last Will ont été conçus précisément pour ce type de connexion distante et intermittente.

Le modèle adopté par la plupart des usines : OPC UA à l'edge, MQTT vers le cloud

En pratique, la question est rarement « OPC UA ou MQTT », mais plutôt « où placer chacun ». Le modèle que l'on retrouve sans cesse :

 Level 0-2  Machines and PLCs      -> OPC UA servers (native or via drivers)
 Level 2-3  Edge gateway           -> OPC UA client: subscribes to tags
                                   -> maps nodes to a topic hierarchy, adds units and quality
 Level 3-4  MQTT broker            -> single hub (Unified Namespace)
 Level 4+   Consumers              -> dashboards, historian, MES, analytics, cloud apps

La passerelle conserve la sémantique d'OPC UA là où vivent les machines et la traduit en une structure de topics et un format de payload que tout le reste peut consommer. Notre tutoriel sur la création d'une passerelle OPC UA vers MQTT présente une implémentation Python fonctionnelle qui publie vers un broker via TLS.

Vous pouvez voir en quelques secondes à quoi ressemble le côté MQTT de ce modèle. Cette commande publie une valeur issue d'OPC UA, avec son contexte, sur le serveur MQTT public gratuit, réservé aux tests :

mosquitto_pub -h broker.connectmq.com -p 1883 -i opcua-vs-mqtt-5d2e \
  -t "connectmq/demo/5d2e/plant1/line1/cnc1/spindle_temp" -r -q 1 \
  -m '{"value":47.3,"unit":"degC","quality":"Good","source":"ns=2;s=Line1.CNC1.SpindleTemp"}'

Tout abonné à connectmq/demo/5d2e/# la reçoit désormais, sans rien savoir d'OPC UA.

Liste de décision

Utilisez cette liste pour décider cas d'usage par cas d'usage, et non usine par usine :

Un client doit parcourir une machine, écrire des consignes ou appeler des méthodes ? Utilisez l'OPC UA client/serveur.
De nombreux consommateurs ont besoin des mêmes données, dont certains hors du réseau de l'usine ? Publiez-les en MQTT.
Les appareils sont contraints (microcontrôleurs, capteurs sur batterie) ou sur liaison cellulaire ? MQTT.
Vous avez besoin de modèles de machines neutres vis-à-vis des fabricants, avec une sémantique standard ? OPC UA et ses companion specifications ; si vous faites le pont, transportez la sémantique dans les payloads MQTT.
Vous voulez un Unified Namespace ? MQTT comme hub, alimenté par OPC UA à l'edge.
Vous ne pouvez pas ouvrir de ports entrants dans le pare-feu ? Les connexions uniquement sortantes de MQTT conviennent.
Vous avez besoin d'un contrôle déterministe à faible latence entre contrôleurs ? Aucun des deux n'est l'outil adapté au contrôle temps réel strict ; utilisez le bus de terrain conçu pour cela.

La place de ConnectMQ

ConnectMQ constitue le côté MQTT de cette architecture : un broker MQTT managé prenant en charge MQTT 3.1.1 et 5.0 sur TCP, TLS et WebSockets. Il ne parle pas lui-même OPC UA, et c'est voulu ; votre passerelle edge gère OPC UA et publie en MQTT vers lui. ConnectMQ détecte les topics ISA-95 et Unified Namespace, les affiche dans un explorateur de topics en temps réel et une vue des appareils organisée par niveaux ISA-95, et peut décoder les payloads Sparkplug B si votre passerelle utilise ce format. Pour une vue d'ensemble de la pile complète, consultez notre guide de l'IoT industriel avec MQTT.

Démarrer avec ConnectMQ

Essayez le modèle edge-cloud sans installer de broker. Inscrivez-vous sur app.connectmq.com avec l'offre Serverless gratuite (sans carte bancaire), créez un broker et pointez votre passerelle OPC UA vers lui avec les identifiants générés. Les données de votre usine circuleront vers un broker MQTT privé dans le cloud dès l'après-midi même.

Questions fréquentes

MQTT est-il en train de remplacer OPC UA ?

Non. MQTT remplace les intégrations point à point au-dessus de l'atelier, tandis qu'OPC UA reste la manière standard dont de nombreuses machines exposent des données structurées. La plupart des architectures utilisent les deux.

OPC UA ou MQTT : lequel est le plus sécurisé ?

Les deux sont sûrs lorsqu'ils sont correctement configurés. OPC UA sécurise les sessions avec des certificats d'application ; MQTT s'appuie sur TLS et l'authentification au broker, avec l'avantage que les clients n'établissent que des connexions sortantes.

OPC UA peut-il utiliser MQTT directement ?

Oui. OPC UA partie 14 PubSub définit MQTT comme transport avec des encodages JSON ou binaire UADP, de sorte que des éditeurs OPC UA peuvent envoyer des messages via un broker MQTT standard.

OPC UA ou MQTT : lequel convient le mieux à un Unified Namespace ?

MQTT est le hub habituel d'un Unified Namespace grâce au découplage publish/subscribe. Les serveurs OPC UA alimentent généralement ce namespace via des passerelles edge.