Relier un automate au système d’information : OPC UA, Modbus, MQTT comparés
Modbus, OPC UA et MQTT ne jouent pas le même rôle. Les opposer comme trois concurrents mène à de mauvais choix ; les comparer sur les mêmes critères montre où chacun a sa place entre l'atelier et le système d'information.
Dans une salle de réunion, la direction informatique demande « une API » pour récupérer les données de production. Dans l’atelier, l’automaticien répond qu’il peut ouvrir « un accès Modbus ». Un intégrateur suggère MQTT, un autre ne jure que par OPC UA. Chacun a raison dans son domaine, et le projet piétine. Comparer OPC UA, Modbus et MQTT sur les mêmes critères permet de sortir de ce dialogue de sourds : ces trois protocoles ne répondent pas à la même question.
Ce comparatif s’adresse aux responsables industriels, aux DSI et aux chefs de projet qui doivent faire remonter des données d’automates vers une supervision, un MES, un entrepôt de données ou un jumeau numérique. DOSOBE n’édite ni ne distribue aucun produit lié à ces protocoles.
Trois protocoles, trois métiers
Modbus : lire et écrire des registres
Créé à la fin des années 1970 pour les automates Modicon, Modbus est aujourd’hui une spécification ouverte, maintenue par l’organisation Modbus. Il existe en liaison série (Modbus RTU) et sur réseau Ethernet (Modbus TCP). Son principe est d’une grande simplicité : un client demande à un équipement la valeur de registres numérotés, ou y écrit. Le protocole ne transporte que des nombres. Que le registre 40 017 soit une température en dixièmes de degré ou un compteur de pièces, seul le document de l’intégrateur le dit.
OPC UA : décrire et échanger des données qualifiées
OPC UA (Unified Architecture) est publié par la fondation OPC et normalisé dans la série IEC 62541. Il ne se contente pas de transporter des valeurs : il expose un modèle d’information, où chaque variable a un nom, un type, une unité, un horodatage et un indicateur de qualité, organisés en objets navigables. Des « spécifications compagnons », élaborées avec des fédérations industrielles, décrivent des machines types (machines d’injection, robots, machines-outils) pour que deux équipements de marques différentes présentent leurs données de la même façon. La sécurité (certificats, chiffrement, contrôle des droits) fait partie de la spécification.
MQTT : distribuer des messages
MQTT est un protocole de messagerie publication-abonnement, normalisé par OASIS (versions 3.1.1 et 5.0) et repris dans la norme ISO/IEC 20922. Les équipements publient des messages sur des sujets (« usine/ligne2/four/temperature ») auprès d’un courtier ; les applications s’abonnent aux sujets qui les intéressent. MQTT est léger, tolère les liaisons instables et passe facilement les pare-feu, puisque toutes les connexions partent des clients vers le courtier. En revanche, il ne dit rien du contenu des messages : leur format est libre, sauf si l’on ajoute une convention comme Sparkplug, publiée par la fondation Eclipse.
Modbus répond à « comment lire ce registre ? », OPC UA à « que signifie cette donnée et qui peut y accéder ? », MQTT à « comment faire circuler des milliers de messages vers ceux qui en ont besoin ? ». Une architecture sérieuse répond aux trois questions.
Le comparatif, critère par critère
Les huit critères ci-dessous sont appliqués de la même façon aux trois protocoles. Ils portent sur ce que la spécification permet et sur ce que l’on rencontre en pratique, pas sur un produit particulier.
| Critère | Modbus (RTU / TCP) | OPC UA | MQTT |
|---|---|---|---|
| Modèle d’échange | Client-serveur, interrogation cyclique | Client-serveur avec abonnements ; mode PubSub en option | Publication-abonnement par courtier |
| Signification des données | Aucune : registres numérotés | Modèle d’information riche, types, unités, qualité | Aucune par défaut ; Sparkplug ou convention maison |
| Sécurité native | Aucune dans la version classique ; une variante sécurisée existe mais reste peu répandue | Authentification par certificats, chiffrement, droits, journaux | TLS et authentification possibles, à configurer ; rien par défaut |
| Découverte des données | Impossible sans documentation | Navigation dans l’espace d’adressage | Possible avec Sparkplug (déclaration des points) |
| Passage à l’échelle | Limité : chaque client interroge chaque équipement | Bon, mais connexions point à point en client-serveur | Très bon : un courtier sert de nombreux abonnés |
| Liaisons instables | Mal tolérées | Reprise de session, mais conçu pour des réseaux fiables | Conçu pour : file d’attente, niveaux de garantie de livraison |
| Présence dans le parc existant | Quasi universelle, y compris sur des équipements anciens | Croissante sur les automates et machines récents | Rare dans l’automate lui-même ; fréquent dans les passerelles |
| Effort de mise en œuvre | Faible pour lire ; élevé pour documenter et maintenir | Élevé au départ (modèle, certificats), faible ensuite pour les consommateurs | Faible pour démarrer ; élevé si l’on néglige les conventions |
Lecture par protocole
Modbus reste imbattable par sa présence : variateurs, compteurs d’énergie, régulateurs, automates des années 1990 et 2000 le parlent presque tous. Sa faiblesse n’est pas technique, elle est documentaire. Une table de registres non tenue à jour, un décalage d’adresse ou un ordre d’octets inversé produisent des valeurs fausses qui semblent plausibles. Et l’absence de sécurité impose de le cantonner à un réseau d’atelier isolé, derrière une passerelle.
OPC UA apporte ce qui manque à Modbus : le sens et la sécurité. C’est le choix naturel pour exposer les données d’une cellule ou d’une ligne vers le système d’information, surtout lorsqu’une spécification compagnon existe pour le type de machine. Son coût est réel : gestion des certificats, conception du modèle d’information, compétences rares. Un serveur OPC UA mal configuré, avec la sécurité désactivée « pour que ça marche », annule l’essentiel de son intérêt.
MQTT excelle pour distribuer des données d’un grand nombre de sources vers plusieurs applications, sur des sites dispersés ou des liaisons fragiles. Il découple les producteurs des consommateurs : ajouter un tableau de bord ne demande pas de toucher aux équipements. Son point faible est la tentation du « chacun son format » : sans convention de sujets et de messages, on reconstruit en quelques mois le problème documentaire de Modbus, à une plus grande échelle.
Le protocole le plus risqué n’est pas celui qui a le moins de fonctions, c’est celui dont personne n’a écrit les conventions.
Les architectures qui fonctionnent
Dans la pratique, la question n’est pas « lequel choisir ? » mais « lequel à quel étage ? ». Trois schémas reviennent souvent.
- Équipements anciensModbus sur le réseau d’atelier, sans exposition directe
- Passerelle de sitelit Modbus, nomme et qualifie les données, les expose en OPC UA
- Distributionpublication MQTT (Sparkplug) ou OPC UA PubSub vers un courtier
- Applicationssupervision, MES, entrepôt de données, jumeau numérique
Atelier récent, peu de consommateurs. Les automates exposent un serveur OPC UA ; la supervision et le MES s’y connectent directement. C’est simple et sûr, tant que le nombre de clients reste limité.
Parc hétérogène, plusieurs applications. Une passerelle par site lit les équipements dans leur protocole d’origine, construit un modèle cohérent et publie vers un courtier MQTT, en suivant Sparkplug ou une convention documentée. Les applications s’abonnent sans jamais toucher aux automates.
Sites dispersés, liaisons fragiles (stations de pompage, sous-stations, équipements mobiles). MQTT est presque incontournable pour sa tolérance aux coupures, avec une mise en tampon locale dans la passerelle.
Dans les trois cas, les principes de segmentation de la norme IEC 62443 s’appliquent : les automates restent dans leur zone, et seule la passerelle traverse le conduit vers le système d’information. Notre guide pour exposer les données d’un automate de façon sûre détaille cette architecture, et celui sur les passerelles IoT industrielles aide à choisir l’équipement intermédiaire.
Comment choisir, et les limites de ce comparatif
Quatre questions suffisent souvent à orienter le choix. Que parlent réellement vos équipements, inventaire à l’appui ? Combien d’applications consommeront les données, aujourd’hui et dans trois ans ? Les sites sont-ils reliés par des réseaux fiables ? Qui maintiendra le dictionnaire des données, et avec quel outil ? Si la dernière question reste sans réponse, aucun protocole ne sauvera le projet.
Ce comparatif porte sur les protocoles, pas sur les produits qui les implémentent : la qualité d’un serveur OPC UA, d’un courtier MQTT ou d’une passerelle varie fortement d’un fournisseur à l’autre, et doit être vérifiée par des essais sur vos équipements. Il ne traite pas des protocoles propriétaires des constructeurs ni des bus de terrain temps réel (PROFINET, EtherNet/IP), qui relèvent de la commande des machines plutôt que de la remontée de données.
Notre expertise industrie et automates accompagne ces choix, de l’inventaire du parc jusqu’aux essais de passerelles. Le dossier de référence sur les automates et le système d’information replace ces protocoles dans une démarche d’ensemble.
- Modbus Organization, Modbus Application Protocol Specification V1.1b3, et Modbus Messaging on TCP/IP Implementation Guide.
- OPC Foundation, OPC Unified Architecture Specification ; IEC 62541 (série), OPC Unified Architecture.
- OASIS, MQTT Version 5.0, OASIS Standard, 2019 ; ISO/IEC 20922:2016 (MQTT v3.1.1).
- Eclipse Foundation, Sparkplug Specification, version 3.0.
- IEC 62443 (série), Sécurité des systèmes d’automatisation et de commande industriels.
Questions fréquentes
Faut-il remplacer Modbus par OPC UA ?
Pas nécessairement au niveau de l'automate. Beaucoup d'équipements anciens ne parlent que Modbus et continuent de bien fonctionner. On place souvent une passerelle qui lit les registres Modbus et les expose en OPC UA ou en MQTT, avec leur nom, leur unité et leur qualité. Le remplacement se décide équipement par équipement, au moment d'une modernisation.
MQTT est-il sûr pour des données industrielles ?
Il peut l'être s'il est configuré correctement : chiffrement TLS, authentification de chaque client, droits par sujet de publication, courtier placé dans une zone réseau maîtrisée. Le protocole ne protège rien par défaut. Les courtiers exposés sur Internet sans authentification restent une erreur fréquente.
Qu'est-ce que Sparkplug ?
Sparkplug est une spécification publiée par la fondation Eclipse qui ajoute à MQTT ce qui lui manque pour l'industrie : une structure des sujets, un format de message, la déclaration des points de mesure et la gestion de l'état des équipements connectés. Elle rend des messages MQTT interprétables par des logiciels de fournisseurs différents.
OPC UA peut-il fonctionner avec MQTT ?
Oui. La partie 14 de la spécification OPC UA, dite PubSub, définit un mode publication-abonnement qui peut utiliser MQTT comme transport. On conserve alors le modèle d'information d'OPC UA tout en profitant de la distribution par courtier.