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.
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ère | OPC UA | Modbus |
|---|---|---|
| Type de protocole | Architecture orientée services, client/server, normalisée IEC 62541 | Protocole requête/réponse historique de 1979, controller/device (ex-maître/esclave) |
| Modèle de données | Address Space orientée objet, NodeId typés, références entre nœuds, métadonnées riches | Tables plates de registres 16 bits (coils, discrete inputs, holding, input registers) |
| Sémantique métier | Companion Specifications (PA-DIM, Robotics, AutoID, Machine Vision, Energy) | Aucune sémantique intrinsèque, mapping registre → grandeur documenté hors protocole |
| Sécurité native | SecureChannel avec signing et encrypting, profils Basic256Sha256, Aes256_Sha256_RsaPss | Aucune sécurité native, ni authentification ni chiffrement (Modbus à nu) |
| Authentification | Certificats 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 MonitoredItems | Polling cyclique uniquement, pas de notification événementielle native |
| Découverte d'équipement | Local Discovery Server, Global Discovery Server, Browse Services dans l'Address Space | Aucune découverte, l'intégrateur fournit manuellement IP et carte des registres |
| Companion Specifications | Plus de 70 publiées : PA-DIM (procédé), VDMA Robotics, AutoID, OPC UA for Machinery | Aucune, chaque fabricant publie sa table de registres dans un PDF |
| Plateformes | Windows, Linux, RTOS embarqué, microcontrôleurs (open62541, OPC UA PubSub embedded) | Toutes plateformes, des microcontrôleurs 8 bits aux PLC haut de gamme |
| Compatibilité PLC/SCADA | Schneider M580/M340, Siemens S7-1500, Rockwell, Wago, B&R, Beckhoff, supervisés par Codra Panorama, Aveva, Ignition, GE Digital | Quasi tous les PLC, variateurs, compteurs, capteurs depuis 40 ans |
| Maturité IIoT / Industry 4.0 | Couche communication obligatoire dans RAMI 4.0, brique de référence Industrie 4.0 | Bus terrain mature mais hors périmètre RAMI 4.0, sans sémantique vertical IT/OT |
| Outils | Kepware KEPServerEX, Inductive Automation Ignition, Node-RED (node-red-contrib-opcua), UaExpert, Prosys, Matrikon | Modbus 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.
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.
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
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 ?
Quelle infrastructure faut-il pour déployer OPC UA en production ?
Faut-il choisir entre OPC UA et MQTT Sparkplug pour l'IIoT ?
Quels sont les frais de licence OPC UA et les coûts cachés ?
Comment l'ANSSI positionne-t-elle OPC UA face à Modbus dans ses guides 2026 ?
Quelle place pour OPC UA dans RAMI 4.0 et Industrie 4.0 ?
Pour aller plus loin
Testez vos connaissances KNX gratuitement
10 questions d'examen réelles, sans inscription. Voyez où vous en êtes en moins de 5 minutes.
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.