Pourquoi MQTT et OPC UA ne sont pas rivaux : guide d’architecture industrielle

By Mirko Peters · 2026-10-21

Découvrez pourquoi MQTT et OPC UA ne sont pas rivaux dans l’IoT industriel. Apprenez à combiner l’efficacité de transport et la sémantique des machines dans l’industrie manufacturière.

Automatically translated with AI from the original post. Read the English original

Découvrez les différences d’architecture entre MQTT et OPC UA dans la fabrication moderne. Si MQTT assure un transport de messages léger et découplé sur des réseaux d’usine instables, OPC UA définit la signification côté machine, les modèles de données structurés et la sécurité native. Ensemble, ils constituent le socle d’une stratégie IoT industrielle fiable.

Points clés

• MQTT joue le rôle de couche de transport : il achemine efficacement les messages bruts des passerelles de périphérie vers plusieurs consommateurs, sans connexions directes.
• OPC UA joue le rôle de couche de sens : il établit un espace d’adressage navigable, avec un contexte structuré des machines, des variables et des unités.
• Considérer MQTT et OPC UA comme des protocoles concurrents est une erreur d’architecture ; ils remplissent des fonctions fondamentalement différentes dans la pile de l’usine.
• Se fier uniquement à des mécanismes de transport comme MQTT, sans définition sémantique, mène à des silos de données et à des indicateurs de production contradictoires.
• Une intégration industrielle réussie exige de séparer la distribution des données de la logique métier, afin de garantir des tableaux de bord opérationnels fiables.

Transport contre sens : deux fonctions industrielles différentes

Lorsque les équipes d’ingénierie entreprennent de moderniser la connectivité de l’atelier, un débat surgit immédiatement : faut-il bâtir notre architecture autour de MQTT ou d’OPC UA ? Cette approche traite la connectivité industrielle comme une bataille où un seul l’emporte. En réalité, choisir entre ces deux technologies revient à se demander si TCP ou JSON est préférable pour le développement web. Elles opèrent à des niveaux totalement différents de la pile de données et répondent à des problématiques distinctes.

Pour construire un environnement de fabrication réellement connecté, en s’appuyant sur des outils comme Azure IoT Operations et Microsoft Fabric, il faut séparer la mécanique de déplacement des données de la définition de leur contexte. Sans cette séparation, les usines se retrouvent souvent avec des pipelines cloud coûteux et des tableaux de bord impeccables qui affichent des indicateurs auxquels personne sur le terrain ne fait confiance.

Ce que MQTT fait le mieux : l’acheminement efficace des messages

MQTT est avant tout un protocole de publication-abonnement léger, conçu pour l’efficacité réseau et une communication découplée. Dans un scénario de fabrication typique, une passerelle de périphérie collecte les données d’un automate programmable (PLC) et les publie sur un sujet précis d’un courtier MQTT. Plusieurs systèmes en aval, comme les applications de maintenance, les interfaces homme-machine (IHM) locales et les pipelines d’ingestion dans le cloud, peuvent s’abonner à ce sujet.

L’éditeur n’a pas besoin de savoir qui écoute, et il n’entretient pas de connexions point à point avec chaque système consommateur. Ce modèle découplé convient parfaitement aux environnements dotés de réseaux industriels instables, de Wi-Fi intermittent ou de liaisons cellulaires. MQTT réduit le volume du trafic réseau et fournit des sessions persistantes pour gérer les reconnexions en douceur, de sorte que les coupures réseau passagères ne interrompent pas l’ensemble de votre pipeline de données.

Ce qu’OPC UA apporte : un contexte machine riche

Alors que MQTT se concentre entièrement sur l’acheminement de l’enveloppe, OPC UA s’intéresse à son contenu. Un serveur OPC UA expose un espace d’adressage navigable qui modélise les machines physiques, les processus et leurs relations. Au lieu de manipuler une liste plate d’adresses mémoire brutes d’automate PLC, un client OPC UA peut découvrir des objets structurés, des types de variables, des unités d’ingénierie et une sécurité au niveau de la couche application.

Prenons l’exemple d’un code d’état numérique simple émis par une machine. Une valeur entière brute comme « 1 » ne signifie rien en soi : sur une ligne de conditionnement, elle peut indiquer un fonctionnement normal, tandis que sur une autre, elle correspond à une séquence de réinitialisation après panne. OPC UA fournit le contexte côté machine et les types de données normalisés nécessaires pour comprendre ce que représente réellement cette variable. Il intègre en outre nativement des protocoles de sécurité industrielle, dont les certificats et le chiffrement.

Le danger des divergences sémantiques dans l’IoT industriel

De nombreux pilotes d’IoT industriel réussissent dans un premier temps, car ils reposent sur des charges utiles JSON simples publiées sur des topics MQTT. Un développeur connecte une passerelle, crée des noms de champs lisibles et alimente rapidement un tableau de bord dans le cloud. Cependant, lorsque ces pilotes passent à l’échelle d’un programme d’entreprise, des incohérences de nommage apparaissent rapidement.

Une ligne de production publie la température sous le nom « temperature », une autre utilise « temp », et une troisième « zone_one_actual ». Pire encore, deux lignes peuvent publier une mesure nommée « speed », l’une mesurant des mètres par minute de convoyeur, l’autre comptant des unités par minute à la remplisseuse. Lorsque ces fragments contradictoires atteignent votre couche de reporting ou votre data lake, ils génèrent des graphiques précis de séquences d’événements qui ne se sont jamais réellement produits.

Un broker de transport ne peut pas inspecter un atelier et déduire l’intention derrière un code numérique. Attendre d’un broker MQTT qu’il comprenne la sémantique des machines revient à demander à un service de tri postal de lire une enveloppe et de vérifier si les documents qu’elle contient approuvent une modification de recette ou signalent un roulement défaillant. Le transport et la signification doivent être conçus délibérément.

Construire une architecture équilibrée avec Azure et Fabric

Les architectures cloud modernes conçues pour l’industrie manufacturière, comme le motif de plan de données en périphérie de Microsoft reposant sur Azure IoT Operations et Microsoft Fabric, s’appuient largement sur la combinaison de ces deux protocoles complémentaires. Les passerelles en périphérie peuvent utiliser OPC UA pour normaliser les données des machines au plus près de la source, en préservant les structures sémantiques et les unités d’ingénierie.

Une fois que ces données disposent d’un contrat sémantique orienté machine, MQTT intervient comme plan de distribution évolutif, acheminant ces événements structurés de manière sécurisée à travers les frontières entre IT et OT hybrides. Cette répartition des rôles évite la prolifération des intégrations point à point et garantit que les moteurs d’analyse, les modèles de machine learning et les tableaux de bord de direction exploitent des données de production fiables et riches en contexte.

Conclusion

En définitive, résoudre le problème des données de production déconnectées impose de dépasser l’effet de mode autour des protocoles et de traiter d’abord la sémantique de la production. En comprenant que MQTT et OPC UA sont des partenaires complémentaires plutôt que des technologies rivales, les architectes cloud et les administrateurs IT peuvent bâtir des environnements industriels résilients et évolutifs. Pour approfondir ce sujet, avec des stratégies concrètes pour Microsoft 365, Azure IoT et les architectures de données industrielles, n’hésitez pas à écouter l’épisode complet et à vous abonner au podcast pour des analyses quotidiennes sur l’écosystème cloud de Microsoft.

Questions fréquentes

MQTT peut-il remplacer OPC UA dans les environnements de production industrielle ?

Non, MQTT et OPC UA répondent à des problématiques différentes. MQTT est un protocole de transport léger, conçu pour acheminer efficacement des messages, alors qu’OPC UA fournit des modèles de données structurés, le contexte des machines et des définitions sémantiques. Ils sont conçus pour fonctionner ensemble au sein d’une architecture industrielle moderne.

Pourquoi les tableaux de bord ne résolvent-ils souvent pas le problème de visibilité des données sur le terrain ?

Les tableaux de bord n’affichent que les données qu’ils reçoivent ; ils ne peuvent pas deviner la signification des variables PLC brutes, ni résoudre les conventions de nommage, fuseaux horaires et définitions d’unités divergents établis d’une ligne de production à l’autre.

Quel rôle joue un broker MQTT dans la convergence entre IT et OT ?

Un broker MQTT dissocie les éditeurs des consommateurs : les passerelles de périphérie publient les événements de l’usine une seule fois, et plusieurs systèmes autorisés (outils de maintenance, plateformes MES, analyse dans le cloud) ne s’abonnent qu’aux données dont ils ont besoin, sans ouvrir de connexions directes vers le réseau des machines.

Comment OPC UA gère-t-il la sécurité, par rapport aux protocoles de messagerie de base ?

OPC UA intègre la sécurité directement dans sa couche applicative, avec la prise en charge des certificats X.509, des canaux sécurisés, de la signature et du chiffrement. Il fournit ainsi un modèle de sécurité industriel standardisé, sans qu’il soit nécessaire de recourir à des implémentations ad hoc.