OPC UA Pub/Sub vs Client/Server : choisir la bonne architecture pour des dizaines de PLC
Lorsqu'une flotte de S7-300 doit être migrée, la question ne porte pas seulement sur le remplacement des automates. C'est aussi le moment de revoir la façon dont ils communiquent. Remplacer les contrôleurs un par un sur le même schéma qu'il y a quinze ans peut reconduire une architecture qui n'est plus adaptée à la taille ou aux usages actuels de la flotte.
OPC UA propose deux façons fondamentalement différentes d'échanger de la donnée entre automates, SCADA, MES et couche cloud : Client/Server et Pub/Sub. Client/Server et Pub/Sub sont deux logiques de communication distinctes, pas deux versions du même protocole ni une option cosmétique à cocher dans TIA Portal. Elles n'ont pas le même comportement quand le nombre de PLC passe de cinq à cinquante. Cet article pose la grille de décision, avec les évolutions de standard qui rendent ce choix plus pressant en 2026 qu'il ne l'était il y a deux ans.
Client/Server et Pub/Sub : deux logiques, pas deux options de menu
Le mode Client/Server est celui qu'on connaît depuis les débuts d'OPC UA. Un client (un SCADA, un historian, un script d'intégration) ouvre une session avec un serveur (typiquement le PLC ou une passerelle), et demande explicitement une donnée : lecture, écriture, souscription à un changement de valeur. C'est une conversation point à point, avec état de session, sécurité par certificats gérée par connexion, et un modèle proche de ce qu'on fait avec une API REST classique. C'est un mode robuste et bien maîtrisé par les équipes de terrain. Il reste, pour cette raison, le standard par défaut sur la quasi-totalité des installations actuelles.
Le mode Pub/Sub inverse la logique. Un automate publie ses données sur un canal, sans savoir qui les lit, ni combien de clients sont à l'écoute. Les abonnés reçoivent le flux via un broker (MQTT, AMQP) ou en diffusion directe (UDP multicast, Ethernet TSN). Il n'y a plus de session à maintenir entre chaque paire client-serveur. Le publisher parle une fois, tout le monde qui écoute reçoit. Notre page lexique sur OPC UA rappelle que ce mode existe dans la norme depuis la version 1.04, et qu'il a été pensé pour couvrir les besoins temps réel et les architectures cloud que le Client/Server pur ne couvre pas bien.
La différence se voit surtout à l'échelle. En Client/Server, chaque nouveau consommateur de données (un dashboard supplémentaire, un second historian, une remontée MES) ajoute une connexion de plus sur chaque PLC source. En Pub/Sub, un nouveau consommateur s'abonne au flux existant sans toucher au PLC publisher. C'est ce qui change la donne dès qu'on dépasse la dizaine d'automates.
Ce qui bouge concrètement : latence, charge réseau, scalabilité
| Critère | Client/Server | Pub/Sub |
|---|---|---|
| Modèle de connexion | Session point à point par consommateur | Un flux publié, N abonnés |
| Charge sur le PLC source | Croît avec le nombre de clients connectés | Reste stable quel que soit le nombre d'abonnés |
| Latence typique | Bonne sur peu de clients, se dégrade en charge | Conçue pour le temps réel (UDP, TSN) |
| Ajout d'un consommateur | Nouvelle connexion à ouvrir et sécuriser sur le PLC | Nouvel abonnement, sans impact sur le publisher |
| Maturité et outillage | Très mature, standard depuis l'origine d'OPC UA | Mature depuis la version 1.04, écosystème encore en construction |
| Cas d'usage naturel | Poste opérateur, requêtes ponctuelles, petit parc | Flotte distribuée, ingestion temps réel, edge/cloud |
Sur un parc de cinq à dix automates avec un seul SCADA qui interroge chacun, le Client/Server ne pose aucun problème. C'est le mode le plus simple à mettre en œuvre, et le plus documenté. Toute la chaîne d'outillage, TIA Portal, Studio 5000, la plupart des SCADA du marché, le gère nativement depuis des années, sans réglage particulier.
Le calcul change quand on multiplie les sources et les consommateurs. Sur une flotte de plusieurs dizaines de PLC, chacun potentiellement lu par un SCADA local, un historian central, une remontée MES et un tableau de bord énergie, le nombre de connexions Client/Server explose de façon combinatoire. Chaque automate porte la charge de toutes ses connexions actives, ce qui pèse sur ses ressources CPU et mémoire, plus limitées sur un PLC que sur un serveur applicatif classique. Le Pub/Sub découple ce problème : le PLC publie une fois, la charge de distribution se déplace vers le broker ou l'infrastructure réseau, dimensionnée pour ça.
Compatibilité Siemens TIA Portal et Rockwell Studio 5000
Sur le terrain, la question n'est jamais uniquement théorique : elle se pose au moment où on ouvre TIA Portal ou Studio 5000 pour configurer la communication. Siemens documente le mode PubSub d'OPC UA comme une communication temps réel en un-vers-plusieurs (one-to-many) via UDP, positionnée explicitement comme complémentaire au mode Client/Server plutôt que comme un remplacement systématique. Ce positionnement compte : Siemens ne pousse pas ses clients à migrer tout leur parc vers Pub/Sub, mais recommande de l'activer là où le besoin de diffusion en temps réel vers plusieurs consommateurs le justifie, en gardant le Client/Server pour les échanges classiques de requête/réponse.
Côté Rockwell, l'écosystème Studio 5000 et FactoryTalk reste historiquement construit autour du protocole natif CIP sur EtherNet/IP pour la communication PLC à PLC et PLC à SCADA, avec OPC UA porté en Client/Server via des serveurs tiers ou le module intégré selon les gammes de contrôleurs. Le support natif du Pub/Sub OPC UA y est moins mûr que chez Siemens, ce qui veut dire concrètement, pour un site à dominante Rockwell qui envisage du Pub/Sub sur une flotte de ControlLogix ou CompactLogix, qu'il faut valider précisément la version de firmware et les modules disponibles avant de baser une architecture cible dessus, plutôt que de partir du principe que ça se configure comme sur TIA Portal. Notre comparatif Siemens vs Rockwell vs Beckhoff détaille par ailleurs les écarts d'écosystème entre ces trois plateformes, utile en amont de ce choix d'architecture de communication.
OPC UA FX : le standard pousse le Pub/Sub jusqu'au terrain
Ce qui rend ce choix plus structurant en 2026 qu'il y a deux ans, c'est l'évolution du standard lui-même. En novembre 2022, l'OPC Foundation a publié la première spécification OPC UA FX (Field eXchange), qui standardise la communication Controller-to-Controller en Pub/Sub sur TSN et 5G, avec une démonstration multi-fournisseurs organisée au salon SPS 2022 de Nuremberg. Cette première étape couvrait la communication entre automates, pas encore le niveau capteur et actionneur.
Courant 2026, les groupes de travail Field Level Communications de l'OPC Foundation ont fait savoir que l'étape suivante était en préparation : une release candidate qui étend OPC UA FX à la communication Controller-to-Device, c'est-à-dire jusqu'aux capteurs, actionneurs et E/S déportées, avec une démonstration multi-fournisseurs prévue pour SPS 2026 à Nuremberg en novembre 2026, illustrant la communication du terrain jusqu'à l'edge et au cloud. Concrètement, le Pub/Sub descend un niveau dans l'architecture. Le Pub/Sub passe d'un mode de communication PLC à PLC à un mode par défaut envisagé jusqu'au capteur.
Ce signal compte pour une décision d'architecture prise en 2026. Le parc installé de produits compatibles OPC/OPC UA est déjà très large, et il continue de s'étendre chaque année. Il s'agit donc d'une transition progressive d'un parc massif existant, pas d'un chantier greenfield théorique, et la direction que prend le standard pèse sur ce que vous choisissez d'installer aujourd'hui sur une flotte qui doit durer dix à quinze ans.
Le déclencheur : le cycle de vie réel du parc S7-300
Le deuxième point d'ancrage est le cycle de vie réel du parc. Pour les SIMATIC S7-300, le statut doit être vérifié par référence dans la documentation Siemens à jour, puis recoupé avec les pièces disponibles, les sauvegardes et les compétences internes. Une migration, souvent vers du S7-1500, peut aussi servir à préparer une connexion OPC UA pour une intégration MES ou un projet data.
C'est exactement le moment où la question Pub/Sub vs Client/Server cesse d'être abstraite. Un projet de migration de flotte est l'occasion naturelle de redessiner l'architecture de communication, pas seulement de remplacer le matériel à l'identique. Recopier le schéma de communication du S7-300 sortant sur le S7-1500 entrant est le choix par défaut, celui qui demande le moins de réflexion en amont. Ce n'est pas toujours le bon choix, surtout si la flotte compte plusieurs dizaines d'automates et que de nouveaux consommateurs de données (MES, plateforme énergie, historian cloud) sont déjà dans les cartons du même projet.
Cas d'usage : quand la flotte bascule vers le Pub/Sub
Le cas le plus net où le Pub/Sub s'impose est celui d'une flotte distribuée sur plusieurs sites ou plusieurs zones d'un même site, avec plusieurs consommateurs qui doivent recevoir le même flux de données en parallèle : un SCADA local pour l'opérateur, un historian central pour la traçabilité, une remontée MES pour l'exécution de fabrication, et de plus en plus souvent une couche de monitoring énergétique qui a besoin des mêmes signaux process pour calculer une consommation ou détecter une dérive. Ajouter ce quatrième consommateur en Client/Server veut dire ouvrir une quatrième connexion sur chacun des PLC de la flotte. En Pub/Sub, c'est un abonnement de plus au flux déjà publié, sans redimensionner la charge sur les automates.
Le même raisonnement s'applique directement aux sites énergie et utilities : dès qu'un poste ou une centrale doit remonter ses données vers plusieurs consommateurs à la fois (SCADA local, historian, monitoring de consommation), la logique de fan-out du Pub/Sub joue exactement ce rôle. Nous l'avons vu jouer, à plus grande échelle encore, sur un programme mené pour un acteur pharma majeur de la région bâloise, où l'architecture cible reposait sur une ingestion temps réel via MQTT et OPC UA pour unifier les flux issus de plus d'une vingtaine de systèmes hétérogènes de production, qualité, maintenance et supply chain, avec restitution vers des tableaux de bord et des notebooks d'analyse. Sur ce type de volumétrie, le choix pesait directement sur l'exploitation : une architecture qui aurait multiplié les connexions Client/Server point à point serait devenue ingérable à maintenir et aurait pesé sur la disponibilité des automates sources.
À l'inverse, un site avec cinq à huit automates, un seul SCADA local et pas de projet MES ou data à l'horizon n'a aucune raison de migrer vers Pub/Sub. La complexité additionnelle (gestion du broker MQTT, sécurité des abonnements, supervision d'un composant de plus dans la chaîne) ne se justifie pas pour un parc de cette taille. Le Client/Server reste plus simple à exploiter et à dépanner par une équipe de maintenance qui le connaît déjà.
La grille de décision pragmatique
Trois questions permettent de trancher avant de lancer un projet de migration de flotte.
Combien de consommateurs indépendants lisent la même donnée aujourd'hui, et combien en lisent d'ici trois ans ? Un seul SCADA, restez en Client/Server. Trois consommateurs ou plus prévus sur le même flux (SCADA, historian, MES, monitoring énergie), le Pub/Sub évite de redimensionner la charge des PLC à chaque nouveau projet.
La flotte dépasse-t-elle la vingtaine de PLC répartis sur plusieurs zones ou sites ? En dessous, le gain de scalabilité du Pub/Sub reste théorique face à sa complexité opérationnelle ajoutée. Au-dessus, la charge combinatoire du Client/Server devient un problème réel de dimensionnement réseau et de charge automate.
Le projet de migration inclut-il déjà un chantier MES, data ou monitoring énergétique dans le même horizon budgétaire ? Si oui, c'est le moment de construire l'architecture cible pour ces besoins futurs plutôt que de la refaire dans deux ans. Notre article sur le goulot d'étranglement entre IT et OT détaille pourquoi ces interfaces mal anticipées deviennent le point de blocage numéro un des projets de remontée de données industrielles.
Une précision importante : ce choix n'est pas binaire à l'échelle d'un site entier. Rien n'empêche de garder du Client/Server sur les échanges de commande et de configuration ponctuelle, et d'ajouter du Pub/Sub uniquement sur les flux de données process à forte fan-out. C'est d'ailleurs la position que défend Siemens sur TIA Portal : les deux modes coexistent sur le même automate, chacun sur le trafic pour lequel il est pertinent.
Ce que nous recommandons avant une migration de flotte PLC
Ne traitez pas le remplacement des S7-300 comme un projet purement matériel. C'est l'occasion de vérifier concrètement où le Pub/Sub apporte une vraie valeur de scalabilité, en croisant le nombre de PLC réellement concernés avec l'inventaire des consommateurs actuels et futurs de vos données process, plutôt que de reconduire par défaut une architecture Client/Server pensée pour un parc plus petit. Dans notre article sur MES, ISA-95 et intégration ERP/PLC en pharma, nous annoncions qu'un article dédié suivrait sur ce choix Pub/Sub vs Client/Server pour les interfaces de niveau 3-2 : c'est cet article.
Cette réflexion vaut particulièrement pour les sites énergie et utilities, où la supervision distribuée sur plusieurs postes ou plusieurs centrales combine déjà des exigences de temps réel et de multiplication des consommateurs de données. Notre page secteur énergie et utilities décrit les missions de supervision distribuée et de cybersécurité OT que nous menons sur ce type de parc. Et pour l'architecture d'intégration au sens large, ERP, MES, SCADA et plateformes data, notre page architecture solutions détaille l'approche que nous suivons pour poser ces choix avant qu'ils ne deviennent des contraintes héritées.
Si vous êtes en train de cadrer une migration de flotte PLC et que la question Pub/Sub vs Client/Server n'a pas encore de réponse claire dans votre projet, mieux vaut trancher maintenant, avant que le schéma de communication du S7-1500 ne se retrouve figé dans la documentation de câblage pour les dix prochaines années. Contactez-nous pour une revue technique sur votre cas précis.