Nehos Groupe
Définition & Concepts

OPC-UA (Open Platform Communications Unified Architecture)

Version Décideur

L'essentiel

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.

Version Expert

Détails Techniques

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). 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.

#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 génère un avantage concurrentiel mesurable en 6 à 12 mois.

#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. La différence entre théorie et terrain ? Les chiffres. Et les chiffres, on les a.

#Cas d'usage concrets

ETI manufacturing 45 machines critiques — interopérabilité OT/IT — Parc hétérogène : 18 automates Siemens S7-1500, 12 Schneider M580, 8 Rockwell ControlLogix, 7 anciens API legacy Modbus TCP. Déploiement gateway OPC-UA centralisée (Kepware + open62541) exposant l'ensemble en namespace unifié. Collecte vers InfluxDB pour maintenance prédictive, dashboards Grafana, modèles ML anomalies. Suppression de 4 passerelles propriétaires, économie 611 k€/an licences.

Énergéticien régional smart grid — communication temps réel équipements — Profil OPC-UA TSN (Time-Sensitive Networking) déployé sur le réseau de distribution moyenne tension. 2 800 équipements (disjoncteurs intelligents, capteurs harmoniques, transformateurs supervisés) communiquent sous 5 ms pour pilotage temps réel charge/délestage. Conformité NIS2 secteur énergie : chiffrement TLS bout-en-bout, certificats X.509 par équipement, audit ANSSI.

Site SEVESO chimie — sécurité travailleurs OT/IT — Passerelle OPC-UA + MQTT-SN entre couche capteurs ATEX (détection H2S, COV, présence zone Ex) et SOC industriel. OPC-UA côté automates safety (Siemens S7-1500F), MQTT-SN côté capteurs sans-fil LoRaWAN. Architecture audit-friendly NIS2 + SEVESO seuil haut, alertes temps réel sous 200 ms vers poste de contrôle.

#OPC-UA chez Nehos Groupe

L'équipe Nehos travaille avec cette technologie depuis ses débuts. Sur les 3 derniers projets impliquant OPC-UA, on a documenté les résultats avec des KPIs précis. 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. Les résultats mesurés sur nos clients : 611 k€ est un ordre de grandeur courant. On livre, on mesure, on itère. Pas de slides sans livrable.

#Termes associés

Plusieurs concepts gravitent autour de ce sujet.

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, dans 80 % des cas. 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

Contexte : ETI manufacturing 45 machines critiques — interopérabilité OT/IT

"Parc hétérogène : 18 automates Siemens S7-1500, 12 Schneider M580, 8 Rockwell ControlLogix, 7 anciens API legacy Modbus TCP. Déploiement gateway OPC-UA centralisée (Kepware + open62541) exposant l'ensemble en namespace unifié. Collecte vers InfluxDB pour maintenance prédictive, dashboards Grafana, modèles ML anomalies. Suppression de 4 passerelles propriétaires, économie 611 k€/an licences."

Contexte : Énergéticien régional smart grid — communication temps réel équipements

"Profil OPC-UA TSN (Time-Sensitive Networking) déployé sur le réseau de distribution moyenne tension. 2 800 équipements (disjoncteurs intelligents, capteurs harmoniques, transformateurs supervisés) communiquent sous 5 ms pour pilotage temps réel charge/délestage. Conformité NIS2 secteur énergie : chiffrement TLS bout-en-bout, certificats X.509 par équipement, audit ANSSI."

Contexte : Site SEVESO chimie — sécurité travailleurs OT/IT

"Passerelle OPC-UA + MQTT-SN entre couche capteurs ATEX (détection H2S, COV, présence zone Ex) et SOC industriel. OPC-UA côté automates safety (Siemens S7-1500F), MQTT-SN côté capteurs sans-fil LoRaWAN. Architecture audit-friendly NIS2 + SEVESO seuil haut, alertes temps réel sous 200 ms vers 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, dans 80 % des cas. 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 chez nos clients : gateways edge sous Linux avec open62541 ou node-opcua, broker MQTT (EMQX), TimescaleDB ou InfluxDB, dashboards Grafana. Pas un seul euro de licence runtime, et un coût d'intégration mesuré.
Réserver un audit