Comparatif protocoles industriels

OPC UA vs Modbus : faut-il moderniser son legacy OT ?

OPC UA porte la sémantique Industrie 4.0 et la sécurité IEC 62443 ; Modbus reste le bus terrain le plus simple à intégrer.

Dernière mise à jour: Mai 20264 sections

Le débat OPC UA contre Modbus revient à chaque audit d'architecture OT en France, qu'il s'agisse d'une usine pharmaceutique sous PA-DIM, d'un atelier mécanique avec quelques variateurs ou d'un site Seveso préparant sa mise en conformité IEC 62443. Modbus, publié par Modicon en 1979 et désormais maintenu par Modbus Organization, reste le protocole le plus déployé sur les bus terrain : registres 16 bits, function codes lisibles, implémentation tenant dans quelques kilooctets de firmware. OPC UA, normalisé sous IEC 62541 et porté par l'OPC Foundation, vise plus haut : modèle d'information orienté objet, Address Space typée, SecureChannel chiffré et signé, services Pub/Sub depuis la version 1.04, plus une cinquantaine de Companion Specifications (PA-DIM, Robotics, AutoID, Machine Vision) qui standardisent la sémantique métier.

Ce comparatif s'adresse aux intégrateurs OT/IT, ingénieurs MES/SCADA et architectes Industrie 4.0 qui doivent arbitrer entre un legacy Modbus stable et une migration vers OPC UA — souvent dans le cadre de France 2030, du dispositif Première Usine ou d'un projet de jumeau numérique. Nous croisons la documentation OPC Foundation, les retours d'éditeurs français (Codra Panorama, Schneider EcoStruxure OPC UA Server Expert, Systerel Safe & Secure OPC), les recommandations ANSSI mises à jour en 2025 et 2026, et les analyses des blogs spécialisés (iotindustriel.com, integral-system.fr, Mesures, Industrie Techno).

Verdict détaillé plus bas : OPC UA pour les nouveaux projets IIoT, les architectures MES/SCADA modernes et toute exigence IEC 62443 SL2 ou supérieur ; Modbus pour l'intégration rapide d'équipements simples ou comme adressage de terrain sous un broker OPC UA. Les deux coexistent presque toujours — OPC UA en haut, Modbus en bas.

CritèreOPC UAModbus
Type de protocoleArchitecture orientée services, client/server, normalisée IEC 62541Protocole requête/réponse historique de 1979, controller/device (ex-maître/esclave)
Modèle de donnéesAddress Space orientée objet, NodeId typés, références entre nœuds, métadonnées richesTables plates de registres 16 bits (coils, discrete inputs, holding, input registers)
Sémantique métierCompanion Specifications (PA-DIM, Robotics, AutoID, Machine Vision, Energy)Aucune sémantique intrinsèque, mapping registre → grandeur documenté hors protocole
Sécurité nativeSecureChannel avec signing et encrypting, profils Basic256Sha256, Aes256_Sha256_RsaPssAucune sécurité native, ni authentification ni chiffrement (Modbus à nu)
AuthentificationCertificats X.509, jetons utilisateur (username, X.509, JWT), audit trail intégréAucune, sauf via VPN, firewall industriel ou diode (Stormshield, Seclab, Systerel)
Pub/Sub disponibilitéServices Pub/Sub depuis la version 1.04 (UDP, MQTT, AMQP), Subscriptions et MonitoredItemsPolling cyclique uniquement, pas de notification événementielle native
Découverte d'équipementLocal Discovery Server, Global Discovery Server, Browse Services dans l'Address SpaceAucune découverte, l'intégrateur fournit manuellement IP et carte des registres
Companion SpecificationsPlus de 70 publiées : PA-DIM (procédé), VDMA Robotics, AutoID, OPC UA for MachineryAucune, chaque fabricant publie sa table de registres dans un PDF
PlateformesWindows, Linux, RTOS embarqué, microcontrôleurs (open62541, OPC UA PubSub embedded)Toutes plateformes, des microcontrôleurs 8 bits aux PLC haut de gamme
Compatibilité PLC/SCADASchneider M580/M340, Siemens S7-1500, Rockwell, Wago, B&R, Beckhoff, supervisés par Codra Panorama, Aveva, Ignition, GE DigitalQuasi tous les PLC, variateurs, compteurs, capteurs depuis 40 ans
Maturité IIoT / Industry 4.0Couche communication obligatoire dans RAMI 4.0, brique de référence Industrie 4.0Bus terrain mature mais hors périmètre RAMI 4.0, sans sémantique vertical IT/OT
OutilsKepware KEPServerEX, Inductive Automation Ignition, Node-RED (node-red-contrib-opcua), UaExpert, Prosys, MatrikonModbus Poll, QModMaster, modpoll, Node-RED (node-red-contrib-modbus), drivers natifs SCADA

Pourquoi un modèle d'information change-t-il tout face à Modbus ?

La rupture la plus profonde entre OPC UA et Modbus n'est ni la sécurité ni Pub/Sub : c'est l'Address Space. Un serveur OPC UA expose un graphe de nœuds typés (Objects, Variables, Methods, References), chacun identifié par un NodeId qualifié par un namespace. Quand un client lit une variable, il récupère la valeur, son type (Double, Float, UInt16), l'unité d'ingénierie (EUInformation, par exemple °C IEC 60050), l'horodatage source et serveur, la qualité (Good, Bad, Uncertain), les limites d'alarme et les relations vers les objets parents. Le client peut découvrir l'arborescence à l'exécution via les services Browse, sans configuration préalable.

Modbus livre seize bits. Le registre 40001 contient une valeur — il faut un PDF du constructeur pour savoir que c'est une température exprimée au dixième de degré, encodée en complément à deux. Aucune unité, aucune qualité, aucun horodatage, aucune méta-information. Toute la sémantique est implicite et redocumentée à chaque intégration.

C'est cette différence qui rend les Companion Specifications stratégiques. PA-DIM (Process Automation Device Information Model), publiée avec NAMUR et FieldComm Group, aligne les paramètres d'un capteur de pression sur le dictionnaire IEC 61987. Robotics Companion Specification, portée par VDMA, expose un cobot Stäubli ou un robot KUKA avec la même arborescence quel que soit le fabricant. AutoID unifie RFID, UWB et RTLS. Avec OPC UA, un MES interroge la flotte sans ouvrir un seul classeur Excel ; avec Modbus, c'est l'intégrateur qui maintient le mapping à la main.

Comment OPC UA répond-il aux exigences IEC 62443 que Modbus ignore ?

Modbus a été conçu en 1979 pour un bus série isolé, sans aucun mécanisme de sécurité : pas d'authentification, pas de chiffrement, pas de contrôle d'intégrité, pas d'audit. N'importe quel équipement sur le segment peut envoyer une fonction 06 (Write Single Register) et reconfigurer un variateur ou un automate. Modbus TCP a hérité de cette absence : la sécurisation se fait par segmentation réseau, firewall industriel, VPN site-à-site, voire diode unidirectionnelle (Systerel, Seclab, Stormshield).

OPC UA intègre la sécurité dans la spécification IEC 62541-2. Un SecureChannel est négocié au-dessus de TCP : authentification mutuelle par certificat X.509, signature et chiffrement applicatifs (Basic256Sha256, Aes256_Sha256_RsaPss), gestion de session avec jetons utilisateur (username/password, X.509, JWT, Kerberos), audit trail des connexions et opérations. Les profils de sécurité sont normalisés et auditables.

Ces propriétés cochent les exigences IEC 62443. L'ANSSI a publié en novembre 2025 la version 2 de son guide ANSSI-PA-108 (Mesures détaillées) et un nouveau référentiel le 6 février 2026, qui alignent explicitement les recommandations OT avec IEC 62443 et précisent les attentes pour SL2 (entités importantes NIS 2) ou SL3 (entités essentielles). Côté éditeurs français, Panorama de Codra est le premier SCADA certifié CSPN par l'ANSSI ; Systerel propose Safe & Secure OPC, un stack OPC UA certifié pour les environnements critiques. Sur un appel d'offres NIS 2 ou un site Seveso, OPC UA arrive avec les bons artefacts ; Modbus impose d'ajouter une couche de cyberdéfense périphérique.

Quel intérêt pour Pub/Sub OPC UA face au polling Modbus historique ?

Le modèle natif de Modbus est le polling : le controller (ex-maître) interroge périodiquement chaque device (ex-esclave) avec un function code (03 Read Holding Registers, 04 Read Input Registers), attend la réponse, recommence. Sur un atelier de 200 capteurs polleés à 100 ms, le bus sature vite et la latence se dégrade. Aucune notification événementielle native : un seuil franchi n'est connu qu'au cycle suivant.

OPC UA propose deux modes complémentaires. Le mode client/server avec Subscriptions et MonitoredItems permet à un client de s'abonner aux changements d'une variable selon un sampling interval et une deadband, le serveur ne notifie qu'en cas de variation significative. Depuis la version 1.04, OPC UA Pub/Sub découple émetteurs et récepteurs via un broker (MQTT, AMQP) ou un transport UDP/Ethernet TSN. Un capteur publie son dataset, n clients consomment sans connexion point-à-point. Le payload peut être JSON (lisibilité, intégration cloud) ou UADP binaire (performance).

Cette flexibilité ouvre la porte à des architectures edge-to-cloud : un broker MQTT central, OPC UA Pub/Sub côté machine, Sparkplug B (spec MQTT industrielle d'Eclipse Foundation) pour le payload, et un MES qui consomme les topics. Côté Modbus, l'astuce courante reste l'EoN node (Edge of Network), un gateway type Prosoft PLX32 ou Moxa MGate qui poll les esclaves Modbus et republie en OPC UA ou MQTT Sparkplug. OPC UA Pub/Sub est nativement IIoT ; Modbus reste un bus terrain qu'on intègre via passerelle.

Quel coût TCO et quelle complexité d'implémentation faut-il anticiper ?

La gratuité apparente d'OPC UA cache un coût d'ingénierie significatif. Une stack Modbus RTU tient dans 5 à 10 € de silicium et quelques jours de firmware ; un serveur OPC UA correct demande un processeur capable, plusieurs mégaoctets de RAM, la gestion des certificats X.509, le maintien d'une Address Space cohérente, le respect d'une Companion Specification quand elle existe, et plusieurs semaines d'ingénierie. Les SDK certifiés (Unified Automation, Prosys, Matrikon, open62541 côté open source) accélèrent le travail mais imposent licences et formation.

Côté infrastructure, OPC UA suppose une PKI opérationnelle (autorité de certification, processus de renouvellement, révocation), un serveur de découverte (LDS/GDS) pour les grosses topologies, et une supervision capable d'auditer les sessions. Schneider EcoStruxure OPC UA Server Expert démarre vers 1 500 € HT pour la licence simple, plus l'effort d'intégration. Une migration complète Modbus → OPC UA sur une ligne existante coûte couramment plusieurs dizaines de milliers d'euros entre matériel, licences, ingénierie et formation OT/IT.

D'où la stratégie hybride dominante observée chez les intégrateurs français : conserver Modbus au niveau terrain (variateurs, compteurs Schneider Acti9, capteurs Wago, Phoenix Contact) et placer une gateway OPC UA en amont (Ignition, Kepware KEPServerEX, Panorama COM de Codra, ProSoft PLX32, Beckhoff TwinCAT OPC UA). Le MES, le SCADA et le data historian dialoguent en OPC UA chiffré ; les automates et capteurs continuent à parler Modbus en aval. C'est la trajectoire pragmatique financée par France 2030 dans la plupart des dossiers Première Usine et Industrie du Futur.

Quand choisir

OPC UA

  • Vous lancez un nouveau projet IIoT, un MES/SCADA moderne ou un jumeau numérique aligné RAMI 4.0
  • Vous devez répondre à IEC 62443 SL2 ou SL3, NIS 2 ou aux recommandations ANSSI-PA-108 v2
  • Vous travaillez sur une ligne avec sémantique métier riche (procédé, robotique, vision, AutoID)
  • Vous voulez fédérer plusieurs sites et fabricants sous une Address Space unique et auditée
Quand choisir

Modbus

  • Vous intégrez rapidement un équipement simple (variateur, compteur, capteur, automate isolé)
  • Le budget unitaire impose une stack minimale dans un microcontrôleur 8 ou 16 bits
  • Vous gérez une petite flotte vendor-agnostic où chaque PDF de registres suffit
  • Vous servez d'adressage terrain sous une gateway OPC UA en couche supérieure

Questions fréquentes

OPC UA remplace-t-il Modbus dans une usine existante ?
Rarement de façon directe. Les retours d'intégrateurs publiés sur iotindustriel.com et FlowFuse convergent : OPC UA n'est pas un remplaçant de Modbus, c'est une couche d'abstraction au-dessus. Les variateurs, capteurs et compteurs continuent à parler Modbus RTU ou TCP au niveau terrain ; une gateway OPC UA (Kepware, Ignition, Panorama COM de Codra, ProSoft PLX32, Beckhoff TwinCAT) republie ces données dans une Address Space normalisée pour le MES, le SCADA et le data historian. La migration totale n'a de sens que sur du matériel neuf ou lors d'un retrofit lourd.
Quelle infrastructure faut-il pour déployer OPC UA en production ?
Au minimum : un serveur OPC UA (embarqué dans le PLC ou hébergé sur un edge gateway), une PKI pour la gestion des certificats X.509, une politique de rotation et de révocation, un Local Discovery Server pour les topologies dépassant quelques serveurs, et une supervision capable d'auditer les SecureChannels. Pour les déploiements Pub/Sub, ajoutez un broker MQTT (HiveMQ, EMQX, Mosquitto durci) ou une infrastructure UDP/TSN. Sur les sites critiques, l'ANSSI recommande d'aligner l'architecture sur IEC 62443 SL2 minimum, ce qui implique segmentation Purdue, journalisation centralisée et plan de gestion des vulnérabilités.
Faut-il choisir entre OPC UA et MQTT Sparkplug pour l'IIoT ?
Les deux ne s'opposent pas. OPC UA Pub/Sub peut justement transporter ses datasets sur MQTT, et la spec Sparkplug B portée par Eclipse Foundation standardise le payload MQTT industriel avec birth/death certificates et report-by-exception. Une architecture typique aujourd'hui : capteurs Modbus → gateway OPC UA → broker MQTT (avec Sparkplug B) → MES/cloud. OPC UA apporte la sémantique métier et la sécurité, MQTT apporte le découplage broker-centric. Le choix dépend des outils SCADA en place : Ignition d'Inductive Automation et Codra Panorama supportent les deux, AVEVA et GE Digital privilégient OPC UA.
Quels sont les frais de licence OPC UA et les coûts cachés ?
La spécification IEC 62541 est libre d'usage ; ce sont les implémentations qui coûtent. Côté open source, open62541 (C) et Eclipse Milo (Java) sont gratuits mais nécessitent une expertise interne. Côté éditeurs, les stacks certifiés Unified Automation, Prosys ou Matrikon démarrent vers 5 000 à 15 000 € selon le périmètre (server, client, Pub/Sub, GDS). Schneider EcoStruxure OPC UA Server Expert démarre à environ 1 500 € HT en licence simple. À cela s'ajoutent la PKI, la formation OT/IT, l'intégration Companion Specs et plusieurs semaines d'ingénierie. Comptez 30 à 50 k€ pour une première mise en œuvre robuste sur un site industriel.
Comment l'ANSSI positionne-t-elle OPC UA face à Modbus dans ses guides 2026 ?
L'ANSSI ne prescrit pas un protocole plutôt qu'un autre, mais sa mise à jour ANSSI-PA-108 v2 (novembre 2025) et son nouveau référentiel du 6 février 2026 imposent des objectifs de sécurité (segmentation, authentification, journalisation, gestion des vulnérabilités) qu'OPC UA couvre nativement et que Modbus ne peut atteindre que par compensation périphérique (firewall industriel, VPN, diode, sonde de détection comme celles décodant Modbus, Profinet et OPC UA pour repérer les commandes anormales). Pour les opérateurs NIS 2 et OIV, OPC UA réduit la dette de mise en conformité IEC 62443.
Quelle place pour OPC UA dans RAMI 4.0 et Industrie 4.0 ?
La plateforme allemande Industrie 4.0 (Plattform Industrie 4.0, portée par ZVEI, VDMA et BITKOM) a rendu OPC UA obligatoire sur la couche Communication du modèle RAMI 4.0 (Reference Architectural Model Industrie 4.0). C'est OPC UA, combiné à AutomationML pour les modèles d'ingénierie et à l'Asset Administration Shell (Verwaltungsschale) pour la représentation des actifs, qui constitue la trame sémantique de l'Industrie 4.0. Modbus n'a aucune place dans ce référentiel : c'est un protocole terrain hors périmètre RAMI 4.0, intégré uniquement via passerelles.

Pour aller plus loin

Mise en pratique

Testez vos connaissances KNX gratuitement

10 questions d'examen réelles, sans inscription. Voyez où vous en êtes en moins de 5 minutes.

Comparatif éditorial indépendant. Les noms de protocoles cités sont les marques de leurs ayants droit respectifs ; CertifBus n'est affilié à aucun d'eux.

Dernière mise à jour: Mai 2026

Mets ces connaissances en pratique
Catalogue