Dans presque chaque projet IIoT, la même question revient : OPC UA ou MQTT? Parfois, il y a derrière un vrai besoin de décision. Souvent, il y a surtout l'espoir qu'une réponse claire existe — « prends X et c'est réglé. »
La réponse honnête, c'est : ça dépend. Mais « ça dépend » n'est utile que si l'on sait de quoi ça dépend. C'est exactement ce que j'essaie d'expliquer ici — du point de vue de quelqu'un qui utilise régulièrement les deux protocoles dans de vrais environnements de fabrication.
Ce qu'est OPC UA — et ce qu'il n'est pas
OPC UA (Open Platform Communications Unified Architecture) est un standard de communication industriel publié en 2008 par l'OPC Foundation. Le point essentiel : OPC UA n'est pas qu'un protocole de transport. Il définit aussi un modèle de données sémantique.
Qu'est-ce que cela signifie concrètement? Quand un automate Siemens S7 exporte via OPC UA un point de données « vitesse de broche », un client OPC UA ne sait pas seulement que la valeur est 3 200. Il sait aussi ce que cette valeur signifie, quelle est son unité, quelles limites s'appliquent et quand elle a été modifiée pour la dernière fois.
C'est le grand avantage d'OPC UA : les données portent leur propre signification. L'intégration en devient nettement plus robuste, parce que l'émetteur et le récepteur ont moins de connaissances implicites à convenir entre eux.
Ce qu'est MQTT — et pourquoi il est devenu si populaire
MQTT (Message Queuing Telemetry Transport) a été développé en 1999 par IBM pour des applications dans des environnements à connexion réseau médiocre — à l'origine pour des oléoducs dans le désert. Léger, robuste, faible latence, overhead minimal (l'en-tête ne fait que 2 octets).
MQTT est un pur protocole pub/sub : les appareils (publishers) envoient des messages sur des topics. Un broker (p. ex. Mosquitto ou HiveMQ) les distribue à tous les subscribers. Cela fonctionne remarquablement bien — mais MQTT lui-même ne définit pas ce que contiennent ces messages. L'émetteur et le récepteur doivent en convenir à l'avance.
Quand une machine envoie une valeur « 3200 » via MQTT, le récepteur n'en sait d'abord rien — à part ce que contient le nom du topic. Qu'il s'agisse de tours par minute, de watts ou de grammes dépend entièrement de l'implémentation.
La comparaison directe
| Aspect | OPC UA | MQTT |
|---|---|---|
| Origine | Standard industriel (OPC Foundation, 2008) | Protocole IoT (IBM, 1999) |
| Architecture | Client-serveur & pub/sub (dès v1.04) | Pub/sub (basé sur un broker) |
| Modèle de données | Typé, sémantique (address space) | Indépendant du payload (binaire, JSON, etc.) |
| Sémantique | Intégrée — les données ont une signification | Aucune — la signification doit être convenue |
| Sécurité | TLS + certificats en natif | TLS optionnel, implémentation variable |
| Overhead | Plus élevé (XML/binaire, handshake) | Très faible (en-tête : 2 octets) |
| Latence | Faible à moyenne | Très faible |
| Usage idéal | Connexion des machines, intégration OT | Capteur→cloud, edge→backend |
Quand je recommande OPC UA
OPC UA est le bon choix quand la connexion à la commande de la machine est au premier plan — donc quand vous voulez lire des données directement depuis un automate programmable, un contrôleur CNC ou un système SCADA.
- Connexion des machines: Siemens, Beckhoff, B&R, Bosch Rexroth — ces automates prennent en charge OPC UA en natif. L'intégration est propre, typée et bien documentée.
- Interopérabilité: Quand il faut intégrer différentes machines de différents fabricants, OPC UA offre un standard commun. Avec MQTT, vous devez définir une structure de topics propre à chaque machine.
- Intégration IT/OT: OPC UA dispose d'un cadre de sécurité clair (certificats, authentification, sessions chiffrées). C'est important dans les environnements réglementés et partout où les réseaux IT et OT sont reliés.
- Exigences sémantiques: Quand des points de données doivent être interprétés de manière cohérente dans plusieurs systèmes — p. ex. simultanément dans l'historian, le SCADA et l'analytique — le modèle de données typé d'OPC UA est un avantage considérable.
Quand je recommande MQTT
MQTT est le bon choix pour tout ce qui se passe entre l'équipement edge et le backend — en particulier quand de nombreux points de données doivent être transmis à haute fréquence et que la connexion réseau peut être peu fiable.
- Connexion de capteurs: Raspberry Pi, Arduino, ESP32 — ces appareils implémentent rarement OPC UA. MQTT tourne sur tous, avec un minimum de ressources.
- Fonctionnement hors ligne: Les brokers MQTT peuvent mettre les messages en mémoire tampon (QoS niveaux 1 et 2) jusqu'à ce que le subscriber soit de nouveau joignable. C'est précieux dans les environnements de production au réseau instable.
- Débit élevé: Quand il faut transmettre 500 points de données par seconde, MQTT est nettement plus efficace qu'OPC UA grâce à son overhead minimal.
- Connexion au cloud: AWS IoT Core, Azure IoT Hub — les grandes plateformes IoT cloud parlent MQTT en natif. OPC UA y a toujours besoin d'un adaptateur.
La réponse la plus fréquente dans la pratique : les deux
Dans presque tous les projets que nous réalisons, les deux protocoles sont utilisés — à des endroits différents de l'architecture. Typiquement, cela ressemble à ceci :
Automate (Siemens S7) ──OPC UA──▶ passerelle edge
Passerelle edge ──MQTT──▶ broker (Mosquitto/HiveMQ)
Broker ──MQTT──▶ InfluxDB / Grafana / backend
OPC UA lit la commande de la machine — de façon typée, sémantiquement correcte, avec authentification par certificat. La passerelle edge (typiquement un PC industriel ou un Raspberry Pi) normalise les données et les transmet via MQTT — légèrement, hors ligne si nécessaire, compatible cloud.
Ce n'est pas un compromis. C'est l'architecture qui exploite les points forts de chaque protocole au bon endroit.
Aide pratique à la décision
La machine a OPC UA en natif?
→ Utiliser directement OPC UA.
La machine a une interface propriétaire (FOCAS, SHDR, Siemens S5)?
→ Adaptateur sur la passerelle edge, sortie via MQTT.
Capteur sans protocole réseau (E/S analogiques, numériques)?
→ Passerelle edge avec matériel capteur, sortie via MQTT.
Les données doivent aller sur une plateforme cloud (Azure, AWS)?
→ MQTT vers le broker, puis au-delà.
Plusieurs machines de fabricants différents doivent être harmonisées?
→ OPC UA comme protocole cible, adaptateurs si nécessaire.
Débit de données très élevé (>100 points/s)?
→ Privilégier MQTT.
Environnement réglementé, exigences d'audit?
→ OPC UA, pour son cadre de sécurité et d'authentification.
Ce que change MQTT Sparkplug B
Une brève remarque pour ceux qui veulent aller plus loin : MQTT Sparkplug B est une spécification qui s'appuie sur MQTT et définit un modèle de données et une structure de topics standardisés pour les applications industrielles. Elle tente de transposer à MQTT l'avantage sémantique d'OPC UA.
Dans la pratique, nous voyons Sparkplug B surtout dans des projets greenfield avec une infrastructure homogène. Pour les environnements mixtes avec des machines legacy, OPC UA reste le choix le plus robuste au niveau machine.
Conclusion
OPC UA et MQTT ne sont pas concurrents — ils résolvent des problèmes différents à des endroits différents d'une architecture IIoT. La question « OPC UA ou MQTT? » est souvent la mauvaise. La bonne question est : « Que faut-il transmettre, où, dans quelles conditions, avec quelles exigences de sécurité et de sémantique? »
Si vous voulez passer ces questions en revue pour votre situation concrète — quelles machines vous avez, quels protocoles elles parlent et à quoi ressemblerait une architecture pragmatique : contactez-nous.