MQTT, OPC UA ou communication directe avec l’automate programmable : comment choisir le modèle d’échange de données adapté à un projet industriel ?

Le choix entre MQTT, OPC UA et une communication directe avec l’automate n’est plus une décision purement technique. Aujourd’hui, il influe à la fois sur l’architecture du système, le coût de mise en service, le périmètre de responsabilité des fournisseurs et le rythme des réceptions. En pratique, la vraie question n’est pas de savoir quel protocole est « meilleur », mais quel modèle d’échange de données correspond à la fonction réelle du projet : faut-il une intégration simple des signaux d’une seule machine, une supervision de ligne, un échange de données avec des systèmes de niveau supérieur, ou un pilotage distribué appelé à évoluer dans les années à venir. Une erreur à ce stade n’apparaît généralement pas tout de suite en laboratoire, mais plus tard : au démarrage, lors de la validation, au moment d’un changement de fournisseur d’automate, ou lorsque le service maintenance cherche à reconstituer l’origine d’un dysfonctionnement et découvre que les données sont incohérentes, retardées ou dépourvues de contexte.

Du point de vue du projet, le plus risqué est d’adopter un modèle de communication « par habitude ». La communication directe avec l’automate est souvent séduisante, car elle donne un accès rapide aux registres et raccourcit fréquemment la première phase de déploiement. Mais ce choix lie facilement l’application de supervision à un automate précis, à un adressage mémoire donné et au mode d’implémentation du constructeur. Lors d’un changement de version du programme, d’une migration matérielle ou d’une extension de ligne, le coût réapparaît sous forme de modifications, de tests de régression et de litiges sur la responsabilité des données de process. À l’inverse, MQTT est bien adapté lorsque l’on recherche une diffusion légère de l’information et une séparation entre émetteurs et récepteurs, mais il exige une définition maîtrisée de la sémantique des données, de la qualité de service et des règles d’exploitation du broker. OPC UA est souvent retenu comme compromis entre interopérabilité et structuration de l’information, mais lui non plus ne résout pas les problèmes à lui seul : si le modèle de données est mauvais, une communication formellement correcte continuera à produire de mauvaises décisions opérationnelles.

Le critère pratique de décision est simple, même s’il est souvent négligé : il faut d’abord déterminer si l’échange concerné porte sur de l’information, du pilotage ou une fonction ayant un impact sur la sécurité de fonctionnement de la machine. Si le canal sert uniquement à la surveillance, au reporting ou au transfert de recettes dans un mode maîtrisé, on peut comparer les solutions sous l’angle de la maintenance, de la scalabilité et de l’intégration. En revanche, si ce même chemin doit aussi véhiculer des commandes influant sur le mouvement, la séquence de fonctionnement, les interverrouillages ou l’état de disponibilité de l’équipement, le sujet cesse immédiatement d’être uniquement informatique. Il faut alors évaluer non seulement la latence et la fiabilité de transmission, mais aussi la prévisibilité du comportement en cas de perte de liaison, après un redémarrage du système, après un changement de version logicielle et après une mauvaise interprétation d’état par un système externe. C’est à ce moment que la question relève naturellement d’une analyse de risque appliquée aux décisions de conception, et parfois aussi du domaine de la prévention du redémarrage intempestif.

Dans les sites de production, le scénario type se répète souvent : au départ, l’objectif est simplement de lire les données de la machine pour la visualisation ou pour un système de reporting, et l’équipe opte donc pour une connexion rapide directement sur l’automate. Quelques mois plus tard, le même canal sert à écrire des consignes, à acquitter des alarmes, puis aussi à transmettre des commandes de maintenance à distance. Formellement, le système « fonctionne » toujours, mais l’architecture ne correspond plus aux responsabilités réelles. On ne sait plus quelle couche fait foi pour l’état de la machine, qui est responsable de l’autorisation des modifications, ni comment démontrer que la communication externe n’ouvre pas une voie vers un démarrage non intentionnel. À ce stade, les questions ne portent plus seulement sur le protocole, mais aussi sur la répartition des fonctions entre les couches de commande, de supervision et de sécurité, ainsi que, dans les scénarios de communication directe avec l’automate, sur les conséquences pour la partie électrique et les liaisons de la machine.

La portée normative et de conformité de ce choix apparaît donc dès lors que le modèle d’échange de données influence le comportement de la machine en régime normal comme en situation perturbée. Toute intégration ne relève pas d’emblée des exigences applicables aux fonctions de sécurité, mais chacune doit être évaluée au regard des conséquences d’une erreur, d’une perte de communication et d’une séquence d’actions erronée. Si une interface externe permet de modifier l’état de la machine, de libérer un interverrouillage, de relancer un cycle ou de contourner une logique prévue localement, alors la décision relative à la communication doit être reliée à l’analyse de risque et, dans les cas appropriés, aussi aux exigences de prévention du redémarrage intempestif. C’est pourquoi ce sujet doit être tranché dès maintenant, au stade des hypothèses et de l’architecture, et non seulement lors de la mise en service. C’est précisément à ce moment qu’il est encore possible de définir des critères mesurables : qui est propriétaire du modèle de données, quel est l’effet admissible d’une perte de liaison, combien de points d’intégration devront être maintenus après un changement d’automate, et comment il sera démontré que la communication ne transfère pas la responsabilité au-delà du périmètre prévu du système.

Où les coûts ou les risques augmentent le plus souvent

La plupart des difficultés ne viennent pas du choix entre MQTT, OPC UA et une communication directe avec le PLC, mais d’une mauvaise attribution du rôle de cette communication dans l’architecture de la machine ou de l’installation. Le projet commence à coûter plus cher lorsque le canal prévu pour l’échange de données auxiliaires se met à porter des décisions opérationnelles dont dépendent la continuité du procédé, l’état de l’équipement ou le comportement de l’opérateur. En pratique, cela signifie que l’équipe déploie une solution apparemment moins coûteuse et plus rapide, puis ajoute ensuite des contournements : signaux matériels supplémentaires, verrouillages locaux, exceptions dans la logique de l’automate, mécanismes séparés d’acquittement et de restauration de l’état après perte de communication. Ce sont précisément ces corrections tardives qui génèrent des coûts, des retards et des désaccords sur les responsabilités entre l’intégrateur, le fournisseur du logiciel et l’utilisateur final. Le critère d’évaluation pratique est simple : il faut déterminer si, en cas de perte de communication, le système doit seulement « cesser de remonter des informations » ou s’il peut basculer dans un état dangereux, technologiquement incorrect ou coûteux pour la production.

Dans les modèles fondés sur une communication directe avec le PLC, le risque augmente généralement lorsque l’interface devient dépendante d’un fabricant donné, d’une version logicielle et de la structure mémoire de l’automate. Lors de la mise en service, cela fonctionne souvent correctement, mais le coût apparaît au moment d’un changement d’automate, d’une modernisation de ligne ou de l’ajout d’un nouveau système de supervision. Chaque modification de ce type impose de remapper les données, de vérifier les types, les adresses, les droits d’accès et le comportement en cas d’erreur de transmission. Du point de vue du propriétaire du produit, c’est un point essentiel, car la maintenance cesse d’être prévisible : la documentation devient rapidement obsolète, le savoir reste chez le prestataire et la responsabilité de l’exactitude des données se disperse. Si l’équipe n’est pas capable d’identifier le responsable du modèle de données ainsi que la procédure de modification après une mise à jour du PLC, alors le coût de l’intégration future est déjà inscrit dans le projet, même s’il n’est pas encore visible aujourd’hui.

Avec MQTT et OPC UA, l’erreur la plus fréquente est différente : on suppose que la couche de communication résoudra à elle seule les problèmes de sémantique des données et de fiabilité des décisions. Or, MQTT transporte bien les événements et la télémétrie, mais sans définition rigoureuse des topics, de la qualité de service, de la rétention et de l’identification de la source, on aboutit facilement à une situation où le destinataire reçoit des données formellement correctes, mais inutilisables ou arrivées trop tard par rapport au procédé. OPC UA, de son côté, structure le modèle d’information et facilite l’interopérabilité, mais son déploiement est souvent sous-estimé lorsque les équipements ne disposent pas d’une structure cohérente d’objets, d’états et de méthodes. Un exemple concret apparaît avec les recettes, la validation des lots ou la reprise à distance d’un cycle : si l’on n’a pas défini sans ambiguïté quelle partie confirme la réception de la commande, laquelle confirme son exécution et laquelle ne fait qu’enregistrer l’écriture dans le registre, il devient difficile, dès le premier incident, d’établir si l’erreur provient de la couche applicative, de la couche de communication ou de la logique de la machine. Ici, le bon critère de décision n’est pas la « modernité » du protocole, mais la capacité à décrire sans ambiguïté l’état, l’origine de la commande, les conditions de validité et la manière de rétablir le fonctionnement après une perturbation.

Une autre source de coûts réside dans le mélange entre exigences d’exploitation, exigences de sécurité et exigences de conformité. Si MQTT, OPC UA ou l’accès direct au PLC permettent d’agir sur le mouvement de la machine, la levée de verrouillages, la séquence de démarrage ou des paramètres ayant une fonction de protection, le sujet cesse d’être purement informatique. À ce stade, la question rejoint naturellement une analyse de risque appliquée aux décisions de conception : il faut évaluer non pas le protocole lui-même, mais les conséquences d’une commande erronée, de données devenues obsolètes, d’une modification non autorisée des réglages et d’une incohérence entre l’état local et l’état externe. Dans les systèmes d’actionnement, y compris hydrauliques, le choix du mode de communication peut influer sur la mise en œuvre des fonctions d’arrêt, de décharge, de blocage du mouvement et de retour sûr en production ; il peut donc être lié aux exigences de conception appliquées lors de l’évaluation de conformité. Si l’interface externe commence à agir sur des fonctions de protection ou sur des comportements que l’opérateur perçoit comme faisant partie du dispositif de sécurité, il faut la traiter comme un élément de l’architecture de sécurité, et non comme un simple ajout pratique d’intégration.

Du point de vue de la gestion de projet, la décision la plus sûre est celle qui peut être défendue non seulement sur le plan technique, mais aussi sur le plan organisationnel. C’est pourquoi, avant de choisir un modèle d’échange de données, il est utile de définir plusieurs critères mesurables : le temps nécessaire pour rétablir un fonctionnement correct après une perte de communication, le nombre d’endroits où le mapping des données doit être maintenu, la méthode de gestion des versions du modèle d’information, l’étendue des tests de régression après modification du PLC, ainsi que la preuve que la communication externe ne contourne pas les mécanismes de protection locaux. Lorsque les réponses à ces questions restent floues, le projet entre généralement déjà dans une zone où la seule décision de communication devrait faire l’objet d’une évaluation des risques plus formelle et, dans certaines applications, être également coordonnée avec les exigences de conception relatives aux organes d’actionnement et aux moyens de verrouillage. C’est à ce moment-là que le choix entre MQTT, OPC UA et la communication directe cesse d’être une simple préférence technique pour devenir une décision qui engage les coûts de maintenance, la frontière des responsabilités et la robustesse de l’ensemble de la solution face aux erreurs.

Comment aborder le sujet en pratique

En pratique, le choix entre MQTT, OPC UA et une communication directe avec l’automate PLC doit partir non pas de la technologie, mais d’une question simple : quel effet opérationnel l’échange de données doit-il produire, et qui en assume la responsabilité. Si les données servent uniquement à la supervision, au reporting ou à l’alimentation de systèmes de niveau supérieur, la priorité sera la robustesse de l’intégration face aux changements et la clarté du modèle d’information. En revanche, dès lors que l’autre extrémité émet des commandes qui influencent le déroulement du cycle, les recettes, les états de fonctionnement ou les conditions de démarrage, la décision ne relève plus seulement de l’informatique. Le mode de communication détermine alors la frontière de responsabilité entre l’intégrateur, le constructeur de la machine, la maintenance et le propriétaire du procédé. Cela a des conséquences directes sur le projet : périmètre différent des essais de réception, documentation des modifications différente, ampleur différente des régressions après modification du programme automate et coût de maintenance différent après la mise en service.

Un bon critère de décision consiste à déterminer où doit se situer la source de vérité concernant l’état de la machine et la logique d’autorisation de fonctionnement. La communication directe avec le PLC peut se justifier là où priment la simplicité de la chaîne d’exécution, le faible nombre d’intermédiaires et la prévisibilité totale du comportement côté automate. En contrepartie, la solution se retrouve généralement fortement liée à un programme PLC précis, à une adresse de données donnée et aux pratiques d’un seul fournisseur. OPC UA est un choix pertinent lorsque le projet exige un modèle de données plus stable, une meilleure séparation entre la couche applicative et le programme automate, ainsi qu’une sémantique des signaux plus lisible. MQTT est surtout adapté lorsque les données doivent être distribuées à plusieurs destinataires, au-delà d’une relation unique système–automate, et qu’un modèle de communication indirecte est acceptable. Ce n’est toutefois pas un choix neutre : plus il y a de couches intermédiaires, de brokers, de traducteurs et de mappings, plus la surface d’erreur augmente, et plus il devient difficile de démontrer qu’une modification côté intégration ne remet pas en cause les hypothèses retenues pour la commande locale.

Une erreur de conception fréquente consiste à choisir un modèle pratique pour l’intégration au moment de la mise en service, puis à découvrir plus tard le coût réel de la maintenance. Exemple concret : un système de niveau supérieur doit enregistrer des recettes et commuter les modes de fonctionnement de plusieurs postes. Si cela est réalisé par écriture directe dans les zones mémoire du PLC, la solution sera rapide au départ, mais chaque modification de la structure des données dans l’automate déclenchera des tests des deux côtés de l’interface, et la responsabilité de la cohérence des recettes deviendra floue. Si le même cas est fondé sur des objets et des états clairement définis côté OPC UA, il devient plus facile de dissocier une modification du programme machine d’une modification du système de niveau supérieur, mais il faut alors maintenir le modèle d’information et son versionnement. À l’inverse, l’utilisation de MQTT dans un tel scénario n’a de sens que si la distribution des données vers plusieurs systèmes est réellement nécessaire et si la maîtrise des délais, de l’accusé de réception et de la reconstitution de l’état après perte de communication a été décrite et vérifiée par des tests. Dans le cas contraire, l’équipe s’offre une flexibilité qu’elle n’exploitera pas, tout en héritant de points de défaillance supplémentaires.

C’est aussi le moment où le sujet conduit naturellement vers une analyse de risque concrète appliquée aux décisions de conception. Si le canal de communication peut modifier l’état de la machine, débloquer une séquence, relancer le fonctionnement après une perte de liaison ou influencer indirectement les actionneurs, il faut évaluer non seulement la fiabilité de la transmission, mais aussi les conséquences d’une commande erronée ou tardive. Dans certaines applications, cette question rejoint déjà les exigences de protection contre le démarrage intempestif, car même une intégration techniquement correcte ne peut pas créer une voie de contournement des moyens locaux de verrouillage ou des procédures de coupure d’énergie. Dans ce périmètre, le choix du mode de communication doit être coordonné avec l’architecture de commande, la couche électrique et les règles de gestion des modifications logicielles, et non être traité comme une décision d’intégration autonome. Du point de vue du manager, cela se résume à une règle simple : le modèle d’échange de données n’est pertinent que s’il est possible de démontrer qui valide la modification, comment l’état sûr est rétabli après une défaillance et quels KPI seront mesurés après le déploiement, par exemple le temps de remise en service, le nombre d’incidents après modification et le nombre de points où le mapping des données est maintenu.

Points de vigilance lors du déploiement

Lors du déploiement, le risque principal ne vient pas du seul choix entre MQTT, OPC UA et la communication directe avec le PLC, mais des hypothèses implicites que l’équipe adopte sans validation formelle. En pratique, les situations les plus coûteuses sont celles où le modèle d’échange de données est choisi pour démontrer une fonction, et non pour répondre au mode réel d’exploitation, de maintenance et de responsabilité sur les modifications. MQTT est parfois déployé avec l’idée d’un simple transfert de données vers des systèmes de niveau supérieur, puis, quelques mois plus tard, commence à transporter des commandes opérationnelles. OPC UA est retenu comme solution « universelle », sans que soient définis les services, les modèles de données et les mécanismes d’autorisation réellement utilisés. La communication directe avec le PLC semble être la voie la plus courte, jusqu’au moment où l’on constate que chaque nouveau destinataire des données exige son propre mapping, des tests de régression et des échanges avec le fournisseur de l’automate. Pour le manager, la conséquence est simple : le coût du déploiement ne s’arrête pas à l’établissement de la connexion, il s’étend à tout le cycle des modifications, des pannes et des réceptions techniques.

La vraie question de décision ne devrait donc pas être « qu’est-ce que nous pouvons mettre en service le plus vite ? », mais « où s’arrête la responsabilité quant à la signification des données et aux conséquences de leur utilisation ? ». Si la communication sert uniquement à observer le procédé, les critères d’évaluation ne seront pas les mêmes que lorsque ce même canal doit agir sur les recettes, les paramètres de fonctionnement, les verrouillages ou les séquences de commande. À ce stade, le sujet conduit naturellement vers une analyse de risque concrète appliquée aux décisions de conception : il faut évaluer non seulement la probabilité d’une perte de communication, mais aussi déterminer si une valeur erronée, une mise à jour retardée ou un mappage ambigu d’une variable peut provoquer un fonctionnement incorrect de la machine ou de la ligne. Si la réponse est oui, l’architecture de communication ne relève plus uniquement de l’intégration. Elle devient un élément qui influe sur la fonction de commande, la réception de l’installation et la responsabilité de l’intégrateur lors de l’interconnexion des sous-systèmes.

En pratique, cela se voit très bien dans un scénario simple : le système de supervision doit lire les états de plusieurs automates, puis, une fois le projet mis en service, l’utilisateur demande en plus la modification à distance des consignes. Avec une communication directe avec les PLC, on finit souvent par ajouter des registres supplémentaires, des exceptions et des contournements dépendants d’un fabricant donné. Avec MQTT, le problème tient souvent à la perte d’univocité : le message arrive, mais sans contexte clairement défini, le destinataire ne sait pas si la valeur est actuelle, validée, ni de quel mode de fonctionnement elle provient. Avec OPC UA, le piège ne vient pas du protocole lui-même, mais de l’hypothèse trop optimiste selon laquelle le modèle d’information côté équipement correspond à ce qu’exige l’application de niveau supérieur. C’est pourquoi un critère d’évaluation pertinent devrait couvrir trois points : qui est propriétaire de la sémantique des données, comment la validité et l’actualité des valeurs sont confirmées, et quelle est la procédure de modification après la mise en service. Si, à l’une quelconque de ces questions, l’équipe répond de manière générale ou en fonction du fournisseur, cela signifie que le coût des modifications futures vient d’être reporté à la phase de maintenance.

Un autre piège consiste à sous-estimer les conséquences physiques et d’installation. Dans les projets où le choix du modèle d’échange de données influe sur l’emplacement des équipements intermédiaires, l’alimentation supplémentaire, le cheminement des câbles ou la segmentation du réseau, le sujet touche alors à la conception de la couche électrique et des liaisons dans la machine. Cela concerne en particulier les solutions avec des passerelles de communication supplémentaires, des ordinateurs industriels ou des commutateurs qui, dans la documentation, paraissent anodins, mais qui, dans l’armoire de commande, impliquent de l’espace, du refroidissement, des protections, de la maintenance et de nouveaux points de défaillance. Dans ce cas, la décision relative à la communication ne peut pas être dissociée du projet d’exécution. L’équipe doit être en mesure d’indiquer ce qui se passera en cas de perte d’alimentation de l’équipement intermédiaire, comment l’état de la communication sera rétabli et si une défaillance de la couche de transmission ne créera pas, pour l’opérateur ou le système de niveau supérieur, une représentation ambiguë de l’état de la machine.

La référence aux exigences de conformité n’apparaît qu’à partir du moment où le canal d’échange de données influe sur la fonction de commande, le mode d’utilisation de la machine ou les limites de responsabilité entre fournisseurs. Dans ce périmètre, il ne suffit pas d’affirmer que le protocole est « industriel » ou largement utilisé. Il faut démontrer que l’architecture retenue a été évaluée dans le contexte des états de défaillance prévisibles, des changements en exploitation et des interfaces entre sous-systèmes, ce qui conduit en pratique à une évaluation méthodique des risques conforme au périmètre de projet retenu. Si le système est assemblé à partir de modules standard, d’automates et de couches de communication provenant de plusieurs entités, l’importance d’une attribution formelle des responsabilités de l’intégrateur augmente également. C’est généralement le moment où il vaut la peine d’arrêter le projet et de vérifier non seulement le schéma d’échange de données, mais aussi les limites de modification après réception, les règles de validation des changements ainsi que les KPI de maintenance : le temps de rétablissement de la communication, le nombre d’incidents après les mises à jour et le nombre d’interfaces nécessitant un mappage manuel.