OPC UA vs MQTT — quel protocole choisir pour l'IoT industriel

Si vous concevez une architecture IoT industriel en 2026, vous vous êtes forcément posé la question : faut-il utiliser OPC UA ou MQTT ? Internet regorge de réponses partisanes — les spécialistes OPC UA disent « OPC UA », les spécialistes MQTT disent « MQTT ». Aucune des deux réponses n'est utile.

Voici la vraie réponse, par une équipe d'ingénieurs qui a déployé les deux en production : ils résolvent des problèmes différents, et la plupart des architectures sérieuses utilisent les deux.

La différence en une phrase

OPC UA donne à vos données une structure et un sens. MQTT transporte des octets du point A au point B.

C'est aussi simple que ça. OPC UA est un modèle d'information plus un transport. MQTT est un transport uniquement. Tout le reste découle de cette distinction.

Où chaque protocole excelle

OPC UA : sémantique riche des données

OPC UA définit un système de types pour les données industrielles — types de données, relations, unités, plages, droits d'accès. Une pompe n'est pas un simple nombre flottant ; c'est une pompe avec un débit en litres par minute, un état opérationnel, un seuil d'alarme et un calendrier de maintenance. C'est cette richesse sémantique qui rend OPC UA interopérable entre fabricants sans mapping custom.

MQTT : publish-subscribe léger

MQTT a été conçu pour les appareils contraints et les réseaux instables. Un client minuscule, un topic sous forme de chaîne, des niveaux de QoS et un broker au milieu. Excellent pour envoyer de la télémétrie de capteurs vers une plateforme cloud avec un overhead minimal. Mais les topics MQTT sont de simples chaînes — le protocole ne dit rien sur la signification des données.

OPC UA : sécurité intégrée

OPC UA inclut l'authentification par certificat X.509, le chiffrement, la signature et le contrôle d'accès par rôle directement dans la spécification. La sécurité n'est pas optionnelle — c'est le comportement par défaut. Cela compte quand votre système doit se conformer à l'IEC 62443 ou au Cyber Resilience Act (CRA).

MQTT : simplicité du broker

Un broker MQTT est trivial à déployer et opérer. Mosquitto tourne sur un Raspberry Pi. Les fournisseurs cloud (AWS IoT Core, Azure IoT Hub, HiveMQ Cloud) proposent des brokers managés avec des millions de connexions. La simplicité opérationnelle est imbattable pour les cas purement télémétriques.

Le tableau comparatif

Quand utiliser OPC UA

Utilisez OPC UA quand le consommateur a besoin de comprendre les données, pas simplement de les recevoir.

Intégration SCADA et MES. Votre système de supervision doit explorer le modèle de données, lire des valeurs process avec unités d'ingénierie, appeler des méthodes sur l'automate et s'abonner aux alarmes. C'est le terrain de prédilection d'OPC UA.

Interopérabilité multi-constructeurs. Vous connectez des machines de fournisseurs différents et avez besoin d'un modèle sémantique partagé. Les Companion Specifications comme PackML, Euromap 77/83 et PADIM fournissent des modèles standards que les fabricants partagent.

Modernisation du parc existant. Vous voulez exposer des automates legacy (Siemens S7, Modbus, EtherNet/IP) via une interface unique et standardisée sans réécrire le firmware.

Conformité réglementaire. L'IEC 62443, NIS2 ou le CRA exigent une sécurité documentée et une traçabilité. Le modèle de sécurité intégré d'OPC UA répond à ces exigences nativement.

Quand utiliser MQTT

Utilisez MQTT quand vous avez besoin d'un transport léger et scalable et que le consommateur sait déjà ce que les données signifient.

Télémétrie capteur-vers-cloud. Des milliers de capteurs poussant de petits payloads vers une plateforme cloud pour stockage et analyse.

Appareils contraints. Microcontrôleurs et appareils basse consommation où l'overhead de la pile OPC UA est trop important.

Microservices événementiels. Services découplés communiquant via un message broker.

Dashboards mobiles et web. MQTT over WebSockets est bien supporté en JavaScript et dans le navigateur.

Quand utiliser les deux : OPC UA PubSub sur MQTT

C'est le pattern vers lequel convergent la plupart des architectures de production en 2026. OPC UA PubSub permet de publier des données OPC UA — avec toute la sémantique, les types, les unités et la structure — sur un broker MQTT comme couche de transport.

Au niveau edge, un serveur OPC UA se connecte aux automates et capteurs, expose un espace d'adressage structuré et sert les outils SCADA et d'ingénierie locaux via le modèle Client/Serveur standard. Le même serveur edge publie ensuite des données sélectionnées sous forme de messages OPC UA PubSub vers un broker MQTT — en préservant le modèle de données tout en exploitant la scalabilité du broker et l'intégration cloud.

Ce pattern « le meilleur des deux mondes » vous donne :

• Des données sémantiques à chaque couche — les consommateurs dans le cloud reçoivent des données OPC UA typées et structurées, pas des blobs JSON opaques.
• La scalabilité du broker — des millions de connexions, des services cloud managés, la QoS.
• Une seule source de vérité — le modèle d'information OPC UA est la définition unique des données, qu'elles soient consommées via Client/Serveur ou PubSub.

L'erreur que font la plupart des équipes

L'erreur architecturale la plus fréquente que nous constatons : utiliser MQTT comme seul protocole et réinventer le modèle d'information en payloads JSON.

Ce qui se passe en pratique :

1. L'équipe A définit un schéma JSON pour la télémétrie des pompes.
2. L'équipe B définit un schéma JSON différent pour la même pompe.
3. Six mois plus tard, personne ne sait quel champ est le débit et lequel est la pression.
4. Quelqu'un crée un tableur « dictionnaire de données » pour mapper les noms de champs.
5. Le tableur est toujours obsolète.

OPC UA résout ce problème par conception. Le modèle d'information est le contrat entre producteur et consommateur. Les Companion Specifications fournissent des modèles standardisés que les fabricants partagent — pas besoin de tableur.

En résumé

Arrêtez de demander « lequel ? » Demandez-vous « lequel, où ? »

Nous sommes les créateurs de node-opcua et l'équipe derrière Omni-Edge — le serveur OPC UA qui publie en PubSub sur MQTT nativement. Si vous avez besoin d'aide pour concevoir votre architecture OPC UA + MQTT, parlez à nos ingénieurs.