Modbus, MQTT, OPC-UA : quel protocole industriel choisir en 2026 ?

· 14 minutes de lecture
14 min read
Équipe Eziwan
Équipe Eziwan
Infrastructure IoT

La question "quel protocole utiliser pour mon projet IoT industriel ?" revient systématiquement dans les projets de modernisation d'usine. Modbus, MQTT et OPC-UA sont les trois protocoles les plus cités — mais ils ne sont pas des alternatives symétriques. Ils opèrent à des couches différentes, répondent à des besoins différents, et souvent se complètent plutôt que se concurrencent.

Cet article clarifie leurs différences fondamentales, leurs forces et leurs limites, et vous donne un guide de décision pour choisir le bon protocole selon votre cas d'usage.

Comprendre d'abord : des protocoles de nature différente​

Avant de comparer, il faut comprendre que Modbus, MQTT et OPC-UA n'opèrent pas au même niveau :

Modbus est un protocole de lecture de données : il permet d'interroger un équipement pour lire ses registres (mesures, états). C'est un protocole de terrain, maître/esclave, conçu pour l'acquisition de données sur des équipements industriels.

MQTT est un protocole de messagerie : il permet de publier et de s'abonner à des flux de données via un broker centralisé. C'est un protocole de transport de messages, pas d'acquisition directe sur un équipement.

OPC-UA est une architecture de services : il combine acquisition de données, accès au modèle de données, sécurité, alarmes, et historique en un seul standard industriel unifié. C'est la solution la plus complète — et la plus complexe.

En pratique : La plupart des architectures IoT industrielles modernes utilisent les trois. Modbus pour lire les équipements de terrain. MQTT pour transporter les données vers le cloud. OPC-UA pour l'interopérabilité entre systèmes complexes.

Modbus RTU et Modbus TCP​

Qu'est-ce que Modbus ?​

Modbus a été créé en 1979 par Modicon (aujourd'hui Schneider Electric). C'est le protocole industriel le plus ancien encore en service actif — et de loin le plus répandu sur le terrain industriel français.

Modbus RTU fonctionne sur liaison série RS-485 (ou RS-232). Il est asynchrone, maître/esclave, avec une topologie bus linéaire (multidrop). Jusqu'à 247 esclaves sur un même bus RS-485.

Modbus TCP est Modbus encapsulé dans des paquets TCP/IP. Il fonctionne sur Ethernet, port 502. Il conserve le modèle maître/esclave mais permet des topologies réseau arbitraires (étoile, arbre). Pas de limite stricte d'esclaves au niveau du réseau.

Ce que Modbus permet de lire​

Modbus expose 4 types de données :

  • Coils (0x) : sorties numériques read/write (booléens)
  • Discrete Inputs (1x) : entrées numériques read-only (booléens)
  • Input Registers (3x) : registres 16-bit read-only (mesures capteurs)
  • Holding Registers (4x) : registres 16-bit read/write (setpoints, paramètres)

Pour lire une mesure de température sur un capteur : le maître envoie une requête "lire les registres 3x01 à 3x02", l'esclave répond avec les deux registres contenant la valeur (en general un float 32-bit sur deux registres contigus).

Forces de Modbus​

Universalité absolue : Si vous avez un équipement industriel avec un port RS-485 ou un port Ethernet et ne savez pas quel protocole il utilise, commencez par tester Modbus. La probabilité est très élevée qu'il supporte Modbus.

Simplicité : Le protocole est simple — des registres numérotés, des fonctions de lecture/écriture standard. N'importe quel développeur peut implémenter un client Modbus en quelques heures.

Résilience : Pas de dépendance à un broker ou un serveur central. Le maître poll directement chaque esclave. Une panne du maître n'affecte pas les esclaves entre eux.

Maturité : 45 ans de déploiement industriel. Les bibliothèques Modbus existent dans tous les langages de programmation (Python, C, Java, JavaScript...).

Limites de Modbus​

Architecture pull uniquement : Le maître doit interroger proactivement chaque esclave. Les équipements n'envoient pas de données spontanément. Sur un bus avec 50 esclaves interrogés toutes les secondes, la fréquence réelle par esclave peut descendre à 20 secondes.

Pas de sécurité native : Modbus RTU et Modbus TCP n'ont aucun mécanisme d'authentification ni de chiffrement. N'importe quel appareil sur le réseau peut lire ou écrire les registres d'un équipement Modbus exposé. La sécurité doit être ajoutée au niveau réseau (VPN, segmentation).

Pas de découverte automatique : Il n'existe pas de mécanisme de découverte des équipements Modbus sur un bus. Vous devez connaître l'adresse esclave et les adresses de registres de chaque équipement.

Pas de nommage sémantique : Le registre 40001 ne dit pas ce qu'il contient — vous avez besoin de la documentation constructeur pour savoir que c'est "température entrée eau". Pas d'auto-description.

Quand utiliser Modbus​

  • Lecture de données sur équipements de terrain (compteurs d'énergie, capteurs de pression, variateurs, automates PLC)
  • Réseaux de terrain existants avec câblage RS-485 en place
  • Projets avec des équipements hétérogènes de constructeurs différents (Modbus est le plus universel)
  • Budgets limités ou équipes sans expertise spécialisée

MQTT (Message Queuing Telemetry Transport)​

Qu'est-ce que MQTT ?​

MQTT a été créé en 1999 par IBM pour la télémétrie sur des liaisons satellitaires à faible débit. Il a été standardisé par OASIS en 2014 (MQTT 3.1.1) et 2019 (MQTT 5.0).

MQTT est un protocole publish/subscribe : les publishers envoient des messages sur des topics, les subscribers reçoivent les messages sur les topics auxquels ils sont abonnés. Un broker MQTT central route les messages entre publishers et subscribers.

Architecture MQTT​

Le broker est le cœur de l'architecture MQTT. Les clients (publishers et subscribers) se connectent au broker — ils ne communiquent jamais directement entre eux.

Forces de MQTT​

Architecture push : Les publishers envoient des données quand ils ont quelque chose à dire. Pas de polling — le subscriber reçoit les données immédiatement à la publication. Latence typique : 10-50ms end-to-end.

Lightweight : Le protocole a été conçu pour des appareils contraints (microcontrôleurs, modems 2G). Un message MQTT peut tenir dans 2 octets (header minimum). Très économe en bande passante.

QoS configurable : Trois niveaux de qualité de service : QoS 0 (at most once), QoS 1 (at least once), QoS 2 (exactly once). Pour les applications critiques, QoS 2 garantit la livraison exactement une fois.

Interopérabilité cloud : Tous les grands cloud providers (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) exposent un broker MQTT natif. MQTT est le protocole de facto pour les architectures IoT cloud.

TLS natif : MQTT supporte TLS 1.3 nativement. La sécurité est intégrée au protocole, pas un ajout.

Limites de MQTT​

Ne peut pas lire les équipements directement : Un équipement Modbus RTU ne parle pas MQTT nativement. Il faut un gateway ou une passerelle qui lit les données Modbus et les publie en MQTT. C'est pourquoi Modbus et MQTT sont souvent utilisés ensemble dans les architectures IoT industrielles.

Dépendance au broker : Si le broker MQTT tombe, toute l'architecture de messagerie s'effondre. La résilience du broker est critique. Les brokers managés (AWS IoT, HiveMQ Cloud) sont très fiables, mais créent une dépendance à un service externe.

Pas de modèle de données standardisé : MQTT ne définit pas le format des messages ni la structure des topics. Chaque implémentation est libre — ce qui nuit à l'interopérabilité. Deux systèmes MQTT d'éditeurs différents ne communiquent pas forcément sans adaptation.

Pas de requête/réponse natif : MQTT est orienté événements unidirectionnels. Pour implémenter un pattern requête/réponse (ex: demander un paramètre à un équipement), il faut utiliser MQTT 5.0 avec des topics de réponse corrélés — c'est possible mais plus complexe.

Quand utiliser MQTT​

  • Transport de données de terrain vers le cloud (Modbus → Gateway → MQTT → Cloud)
  • Architectures événementielles où les données changent irrégulièrement
  • Déploiements IoT embarqué sur microcontrôleurs ou devices contraints
  • Intégration avec les brokers cloud natifs (AWS IoT, Azure IoT Hub)

OPC-UA (OPC Unified Architecture)​

Qu'est-ce que OPC-UA ?​

OPC-UA (IEC 62541) a été développé par l'OPC Foundation à partir de 2006 comme successeur de l'OPC Classic (basé sur COM/DCOM Windows). C'est le standard industriel le plus ambitieux : il combine acquisition de données, modèle sémantique, sécurité, historique, alarmes, et accès aux méthodes en un seul protocole.

OPC-UA est aujourd'hui le protocole préféré des constructeurs d'automates pour les architectures Industry 4.0 : Siemens TIA Portal (S7-1500), Rockwell ControlLogix, Beckhoff TwinCAT, B&R Automation — tous supportent OPC-UA nativement depuis 5 à 10 ans.

Forces d'OPC-UA​

Modèle de données sémantique : Contrairement à Modbus (des registres numérotés anonymes), OPC-UA expose un arbre d'objets nommés et typés. Le nœud "ns=2;i=1001" peut s'appeler "Machine1/MoteurPrincipal/TemperatureRoulement" avec des métadonnées (unité, plage, description). L'auto-description est native.

Sécurité intégrée : Authentification, autorisation, chiffrement, intégrité des messages — tout est dans le protocole. OPC-UA supporte plusieurs profils de sécurité (None, Sign, SignAndEncrypt) avec des algorithmes modernes (AES-256, RSA-2048+).

Publish/Subscribe depuis OPC-UA PubSub (2017) : OPC-UA peut maintenant fonctionner en mode publication asynchrone (push), pas seulement en mode requête/réponse (pull). Il peut publier sur des brokers MQTT, rendant OPC-UA et MQTT complémentaires plutôt que concurrents.

Accès aux méthodes : OPC-UA permet d'appeler des méthodes sur les équipements — pas seulement lire des valeurs. Un actionnement de vanne, une commande de démarrage moteur — tout est modélisé comme un objet OPC-UA.

Sémantique et interopérabilité : Les "Companion Specifications" OPC-UA définissent des modèles standardisés par secteur : OPC-UA for Plastics, for Robotics, for PackML (emballage), for Mining... Un logiciel SCADA supportant OPC-UA for PackML peut se connecter à n'importe quelle ligne d'emballage conforme, sans configuration spécifique.

Limites d'OPC-UA​

Complexité : OPC-UA est le protocole le plus complexe à implémenter et à configurer. Les spécifications font plus de 1000 pages. La courbe d'apprentissage est significative pour les équipes sans expérience OPC-UA préalable.

Ressources requises : Un serveur OPC-UA complet nécessite plus de ressources qu'un esclave Modbus. Les automates anciens ou les microcontrôleurs contraints ne peuvent pas embarquer un stack OPC-UA complet (il existe cependant des profils "nano" allégés).

Pas universel sur le terrain : Les équipements anciens (avant 2010-2015) ne supportent pas OPC-UA. Sur un parc industriel hétérogène, vous rencontrerez beaucoup plus de Modbus que d'OPC-UA sur les équipements de terrain existants.

Overhead réseau : Les messages OPC-UA sont plus volumineux que les messages Modbus (XML ou Binary selon le transport). Sur des liaisons 4G à faible débit, cela peut être un facteur.

Quand utiliser OPC-UA​

  • Automates Siemens S7-1200/1500 récents avec TIA Portal (OPC-UA natif)
  • Architectures Industry 4.0 avec interopérabilité SCADA/MES/ERP
  • Projets nécessitant une sécurité et une traçabilité fortes sur les accès
  • Environnements multi-constructeurs avec besoin d'interopérabilité sémantique

Guide de décision : quelle combinaison pour votre projet ?​

Architecture typique IoT industrielle simple​

Usage : Supervision de process, alertes, historique. 80% des projets IoT industriels français correspondent à ce schéma.

Architecture avec bus d'intégration cloud​

Usage : Projets avec plusieurs consommateurs des données (SCADA + ERP + BI). MQTT comme bus d'intégration.

Architecture Industry 4.0 avec OPC-UA​

Usage : Usines avec automates récents, projets Industry 4.0, intégration MES.

Matrice de décision​

BesoinModbus RTUModbus TCPMQTTOPC-UA
Lire capteurs terrain RS-485✓✓———
Lire automates sur réseau✓✓✓—✓
Envoyer données vers cloud——✓✓✓
Interopérabilité SCADA/MES✗✗Partiel✓✓
Sécurité intégrée✗✗TLS✓✓
Équipements anciens✓✓✓—✗
Automates récents (>2015)✓✓—✓✓
Architectures cloud-native✗✗✓✓✓
PME sans expertise protoco✓✓✓✓✓✗

Comment Eziwan gère les trois protocoles​

Le gateway Eziwan est agnostique aux protocoles côté terrain :

  • Modbus RTU : port RS-485 natif, mode maître, jusqu'à 247 esclaves par bus, polling configurable de 1s à 15min
  • Modbus TCP : client Modbus TCP, connexions simultanées vers plusieurs serveurs Modbus
  • MQTT : publisher MQTT (publication des données collectées), subscriber possible pour les commandes
  • OPC-UA : client OPC-UA (lecture de nœuds, abonnement aux changements de valeur) — disponible sur demande pour les déploiements OPC-UA

Côté cloud, les données sont normalisées en interne et exposées via :

  • API REST (JSON) pour les applications cloud
  • Webhooks pour les événements temps réel
  • MQTT sortant pour les intégrations en bus

Vous pouvez combiner Modbus RTU sur les équipements de terrain et MQTT vers votre cloud AWS/Azure sans modifier quoi que ce soit — le gateway fait la translation.

Conclusion​

En 2026, la réponse à "Modbus ou MQTT ou OPC-UA ?" est généralement "les trois ensemble" :

  • Modbus pour lire vos équipements de terrain (c'est ce qu'ils parlent)
  • MQTT pour transporter les données vers votre cloud et les distribuer à plusieurs applications
  • OPC-UA si vous avez des automates récents Siemens/Rockwell/Beckhoff et besoin d'interopérabilité SCADA/MES

Ce n'est pas une compétition — c'est une architecture en couches. Le choix n'est pas "quel protocole" mais "quel protocole à quelle couche pour quel équipement".

FAQ — Modbus, MQTT et OPC-UA​

Peut-on utiliser Modbus et MQTT simultanément sur la même gateway ?

Oui, et c'est l'architecture la plus courante en IIoT. La gateway collecte les données des automates en Modbus TCP ou RTU (couche terrain) et les publie en MQTT vers le cloud (couche transport). Modbus s'arrête à la gateway — il n'est jamais exposé sur Internet. MQTT prend le relais pour le transport vers le cloud, avec TLS 1.3 et authentification.

OPC-UA peut-il remplacer Modbus sur des automates existants (S7-1200, M340) ?

Sur les Siemens S7-1200, OPC-UA serveur n'est disponible qu'à partir du firmware V4.4 et nécessite une configuration explicite dans TIA Portal. Sur les S7-1500, c'est natif depuis le firmware V2.0. Sur les Schneider M340, OPC-UA n'est pas natif — il faudrait un module additionnel. En pratique, pour les parcs existants, Modbus TCP reste la solution universelle ; OPC-UA est pertinent principalement pour les nouveaux projets avec des automates récents.

MQTT avec QoS 0 vs QoS 1 vs QoS 2 — que choisir pour la supervision industrielle ?

Pour la supervision de données process (températures, pressions), QoS 1 (At Least Once) est le bon équilibre : la livraison est garantie même après reconnexion, au risque de quelques doublons (acceptables pour des données de monitoring). QoS 2 (Exactly Once) est plus lourd à cause de l'aller-retour de confirmation et rarement nécessaire pour des mesures. QoS 0 (At Most Once) convient pour des données très fréquentes (> 1/s) où une perte occasionnelle est acceptable.

Un broker MQTT public (HiveMQ, EMQX cloud) est-il suffisant pour l'industriel ?

Pour des pilotes ou des non-critiques, oui. Mais pour une production avec contraintes de confidentialité (données process, identités des équipements), un broker privé hébergé en France est préférable. Les données MQTT passant par des brokers publics américains sont potentiellement soumises au CLOUD Act — à évaluer selon la sensibilité des données et le secteur d'activité.

OPC-UA a-t-il un impact sur les performances de l'automate par rapport à Modbus ?

OPC-UA est nettement plus gourmand en CPU et mémoire que Modbus TCP. Sur un S7-1500 CPU 1511 avec un serveur OPC-UA actif et 50 connexions clients, le temps de cycle peut augmenter de 5 à 15 %. Sur un S7-1200, les ressources sont plus limitées — tester systématiquement l'impact avec le programme de production complet avant de déployer OPC-UA en production.

Pour aller plus loin​

Ressources complémentaires​