OPC-UA (Open Platform Communications Unified Architecture)
#Définition OPC-UA
Standard ouvert d'interopérabilité industrielle (IEC 62541) pour l'échange de données entre systèmes industriels hétérogènes (PLC Siemens, Schneider, Rockwell, capteurs IoT, MES, SCADA, ERP). Successeur d'OPC Classic (COM/DCOM Windows). Pour approfondir, consultez la page service Agents IA Nehos (gateway OPC-UA edge, maintenance prédictive).
Concrètement, Plateforme-indépendant (Linux, Windows, embedded), orienté service (architecture client-serveur + Pub/Sub depuis 2018), modèle d'information riche (donnée + métadonnée + sémantique). Sécurité native : chiffrement TLS, signature messages, authentification certificats X.509, profils standardisés.
Profil OPC-UA TSN (Time-Sensitive Networking) pour temps réel critique sous 10 ms. Pilier Industrie 4.0 et IIoT. Stack open source : open62541 (C), node-opcua (JS/Node), python-opcua / asyncua.
Appliqué correctement, OPC-UA peut devenir un avantage concurrentiel.
#OPC-UA expliqué simplement
OPC-UA, c'est l'esperanto des machines industrielles. C'est le standard qui permet à un automate Siemens, un capteur IoT et un système MES de se parler entre eux, quel que soit leur constructeur. Sans OPC-UA, chaque marque parle son propre langage propriétaire et l'intégration coûte une fortune en passerelles dédiées. Avec OPC-UA, tout devient interopérable, sécurisé nativement, et compatible avec une stack ouverte (open62541, node-opcua) plutôt que verrouillé par un éditeur.
Imaginez que vous dirigez une PME ou une scale-up.
#Cas d'usage concrets
Exemple de situation — ETI industrielle : interopérabilité OT/IT — Situation type : une ETI industrielle exploite un parc hétérogène : automates Siemens S7-1500, Schneider M580, Rockwell ControlLogix et d'anciens automates legacy en Modbus TCP. Une gateway OPC-UA centralisée (Kepware et open62541) expose l'ensemble dans un namespace unifié.
Les données alimentent InfluxDB pour la maintenance prédictive, des dashboards Grafana et des modèles ML de détection d'anomalies. Plusieurs passerelles propriétaires peuvent être supprimées, avec leurs licences.
Exemple de situation — énergéticien régional : smart grid et temps réel — Situation type : un énergéticien régional déploie le profil OPC-UA TSN (Time-Sensitive Networking) sur son réseau de distribution moyenne tension. Des disjoncteurs intelligents, des capteurs harmoniques et des transformateurs supervisés communiquent avec une latence de quelques millisecondes pour piloter la charge et le délestage en temps réel. Côté conformité NIS2 : chiffrement TLS de bout en bout, certificats X.509 par équipement et audit de l'ANSSI.
Exemple de situation — site SEVESO de la chimie : sécurité des travailleurs OT/IT — Situation type : un site chimique classé SEVESO relie ses capteurs ATEX (détection de H2S, de COV, présence en zone Ex) à son SOC industriel par une passerelle OPC-UA et MQTT-SN. OPC-UA est utilisé côté automates de sécurité (Siemens S7-1500F), MQTT-SN côté capteurs sans fil LoRaWAN. L'architecture se prête aux audits NIS2 et SEVESO seuil haut, avec des alertes en temps réel vers le poste de contrôle.
#OPC-UA chez Nehos Groupe
Notre service Agents IA Nehos (gateway OPC-UA edge, maintenance prédictive) couvre ce périmètre de A à Z.
La méthode Nehos est documentée sur méthode Legacy Strangler IA-assisted (modernisation OT via passerelle OPC-UA). Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. On livre, on mesure, on itère. Pas de slides sans livrable.
#Termes associés
Plusieurs concepts gravitent autour de ce sujet.
- IoT industriel (IIoT)
- Industrie 4.0
- MQTT
- MES (Manufacturing Execution System)
- GMAO
- NIS2
- SCADA
Tous ces termes sont interconnectés. Maîtriser l'un sans comprendre les autres, c'est voir le puzzle sans toutes les pièces.
#Points clés à retenir
Quelle différence concrète entre OPC-UA et OPC Classic ? Le saut générationnel est énorme. OPC Classic (DA, HDA, A&E, sorti fin années 1990) reposait sur COM/DCOM, technologie Microsoft propriétaire qui imposait Windows des deux côtés, ouvrait de larges plages de ports difficiles à filtrer, et n'avait aucune sécurité native sérieuse.
OPC-UA ou MQTT : lequel choisir pour un projet IIoT ? Les deux, le plus souvent. OPC-UA et MQTT ne sont pas concurrents mais complémentaires.
La sécurité native d'OPC-UA est-elle vraiment fiable en production ? Oui, à condition d'être réellement activée et configurée — et c'est là que le bât blesse. Le standard prévoit nativement chiffrement TLS, signature des messages, authentification mutuelle par certificats X.509, et plusieurs profils de sécurité (Basic256Sha256, Aes256_Sha256_RsaPss).
Applications Concrètes
« Situation type : une ETI industrielle exploite un parc hétérogène : automates Siemens S7-1500, Schneider M580, Rockwell ControlLogix et d'anciens automates legacy en Modbus TCP. Une gateway OPC-UA centralisée (Kepware et open62541) expose l'ensemble dans un namespace unifié. Les données alimentent InfluxDB pour la maintenance prédictive, des dashboards Grafana et des modèles ML de détection d'anomalies. Plusieurs passerelles propriétaires peuvent être supprimées, avec leurs licences. »
« Situation type : un énergéticien régional déploie le profil OPC-UA TSN (Time-Sensitive Networking) sur son réseau de distribution moyenne tension. Des disjoncteurs intelligents, des capteurs harmoniques et des transformateurs supervisés communiquent avec une latence de quelques millisecondes pour piloter la charge et le délestage en temps réel. Côté conformité NIS2 : chiffrement TLS de bout en bout, certificats X.509 par équipement et audit de l'ANSSI. »
« Situation type : un site chimique classé SEVESO relie ses capteurs ATEX (détection de H2S, de COV, présence en zone Ex) à son SOC industriel par une passerelle OPC-UA et MQTT-SN. OPC-UA est utilisé côté automates de sécurité (Siemens S7-1500F), MQTT-SN côté capteurs sans fil LoRaWAN. L'architecture se prête aux audits NIS2 et SEVESO seuil haut, avec des alertes en temps réel vers le poste de contrôle. »
Questions & réponses
Questions fréquentes sur OPC-UA
Le saut générationnel est énorme. OPC Classic (DA, HDA, A&E, sorti fin années 1990) reposait sur COM/DCOM, technologie Microsoft propriétaire qui imposait Windows des deux côtés, ouvrait de larges plages de ports difficiles à filtrer, et n'avait aucune sécurité native sérieuse. OPC-UA (IEC 62541, finalisé 2008, profil Pub/Sub ajouté 2018) tourne sur n'importe quel OS (Linux, Windows, RTOS embarqué), utilise un transport standardisé (TCP binaire ou HTTPS), embarque la sécurité dès la conception (TLS, signature, certificats X.509, profils standardisés), et propose un modèle d'information riche (donnée + métadonnée + relations sémantiques) au lieu d'un simple flux de tags. Sur un projet greenfield 2026, OPC Classic ne se justifie plus ; sur du legacy, une passerelle UA Wrapper fait le pont, et c'est généralement le bon premier livrable de modernisation OT.
Les deux, le plus souvent. OPC-UA et MQTT ne sont pas concurrents mais complémentaires. OPC-UA est le standard de communication OT côté terrain : il parle aux automates, expose un modèle d'information sémantique, supporte le temps réel critique via TSN, et gère la sécurité par certificats. MQTT (ISO/IEC 20922) est un protocole de messagerie applicative léger, idéal pour transporter des flux vers un broker central, le cloud ou des systèmes IT (MES, ERP, dashboards). Le pattern dominant en IIoT moderne combine les deux : OPC-UA depuis les automates vers une gateway edge, puis MQTT (souvent enrichi par la spécification Sparkplug B) entre la gateway et le broker central. Choisir MQTT seul est pertinent pour des capteurs simples et contraints ; OPC-UA seul reste valable pour des architectures fermées 100 % OT temps réel.
Oui, à condition d'être réellement activée et configurée — et c'est là que le bât blesse. Le standard prévoit nativement chiffrement TLS, signature des messages, authentification mutuelle par certificats X.509, et plusieurs profils de sécurité (Basic256Sha256, Aes256_Sha256_RsaPss). Ces briques sont auditées par l'OPC Foundation et largement déployées dans les secteurs régulés (énergie, défense, pharma). Le problème terrain, c'est qu'une part significative des installations tournent encore en mode SecurityPolicy = None et UserTokenType = Anonymous, héritage de projets pilotes jamais durcis. Sur un audit NIS2 sérieux, les premières remédiations consistent presque toujours à activer un profil chiffré, déployer une PKI interne pour les certificats équipements, et révoquer les comptes anonymes. C'est un standard fiable ; ce sont les déploiements qui sont souvent négligés.
Largement oui sur les générations récentes, mais avec des nuances importantes. Siemens (S7-1500 / TIA Portal), Schneider Electric (M580, M340 récents), Rockwell (ControlLogix, CompactLogix), Beckhoff (TwinCAT 3), B&R, Mitsubishi, Omron exposent tous un serveur OPC-UA natif depuis plusieurs années. Les automates legacy (10-20 ans, type S7-300, Modicon Quantum) ne le supportent pas et nécessitent une passerelle (Kepware, Ignition, open62541 custom, Node-RED industriel). Au-delà du support brut, l'interopérabilité réelle dépend des profils implémentés : un serveur peut limiter le namespace exposé, le sampling rate, ou les fonctionnalités Pub/Sub. Un test d'intégration sérieux reste indispensable, idéalement avec UaExpert (client de référence Unified Automation) pour valider le namespace et les permissions avant tout déploiement.
Oui, c'est même devenu un choix d'architecture pertinent pour les ETI industrielles soucieuses de souveraineté et de TCO. Côté serveurs/clients embarqués performants, open62541 (C/C++, licence Mozilla Public License 2.0) est la référence : utilisé en production par de gros industriels, supporte client, serveur, Pub/Sub, et tourne du Raspberry Pi à l'industrial PC. Côté Node.js / TypeScript, node-opcua couvre client + serveur + sécurité, idéal pour gateways edge modernes et intégrations applicatives. Côté Python, asyncua (anciennement python-opcua) est mature pour le prototypage, l'outillage et les scripts d'intégration. Pour le tooling : UaExpert (gratuit non-open mais référence), Prosys OPC UA Browser (gratuit), FreeOpcUa Modeler. Le pattern type : gateways edge sous Linux avec open62541 ou node-opcua, broker MQTT (EMQX), TimescaleDB ou InfluxDB, dashboards Grafana. Aucune licence runtime à payer, et un coût d'intégration maîtrisé.