Connectivité automate vers le cloud : architectures et compromis

Connecter les automates au cloud est désormais une exigence courante : la maintenance veut des données d'état à distance, la direction veut l'OEE de tous les sites et les équipes data veulent des séries temporelles propres pour l'analyse. Ce guide compare les trois architectures qui fonctionnent réellement en usine, MQTT natif dans l'automate, passerelles edge et relais par le SCADA, et détaille les décisions de sécurité et de fiabilité propres à chacune. Vous repartirez avec une checklist pour choisir l'architecture de votre site.

Pourquoi MQTT sert habituellement de pont

Les automates parlent des protocoles terrain conçus pour une communication locale et déterministe : PROFINET, EtherNet/IP, Modbus, communication S7, ADS. Aucun n'a été conçu pour traverser Internet. Les applications cloud, elles, veulent des flux d'événements sur des connexions chiffrées et authentifiées qui traversent les pare-feu.

MQTT s'insère entre les deux grâce à trois propriétés :

• Connexions sortantes uniquement. Le côté usine ouvre une connexion TLS vers le broker. Rien dans le cloud n'a besoin d'entrer dans l'usine, aucun port entrant n'est donc ouvert sur le pare-feu.
• Découplage publish/subscribe. Le côté automate publie une fois ; tableaux de bord, historians, jumeaux numériques, outils d'analyse et d'alerte s'abonnent indépendamment. Ajouter un consommateur ne touche pas à l'usine.
• Léger et tolérant aux liaisons médiocres. En-têtes compacts, keep alive, niveaux de QoS, messages retenus et sessions persistantes gèrent bien les liaisons cellulaires ou les WAN congestionnés.

Si la notion de broker est nouvelle pour vous, commencez par découvrir ce que fait un broker MQTT avant de choisir une architecture.

Architecture 1 : MQTT natif dans l'automate

Le contrôleur exécute lui-même un client MQTT et se connecte au broker. Siemens propose une bibliothèque pour S7-1200 et S7-1500, CODESYS dispose d'une bibliothèque cliente MQTT et Beckhoff TwinCAT de fonctions IoT ; les tutoriels pas à pas se trouvent dans le tutoriel Siemens S7 MQTT et ses équivalents.

Points forts : aucun matériel supplémentaire, latence minimale, payloads définis par la personne qui connaît le mieux le process.

Points faibles : le code réseau et la gestion des certificats résident désormais dans le programme de commande, chaque modification implique un chargement de l'automate, le stockage et la retransmission (store-and-forward) sont limités par la mémoire du contrôleur, et l'automate doit disposer d'une route vers Internet ou vers un broker en DMZ, ce à quoi de nombreuses équipes sécurité s'opposent.

Convient quand : un constructeur livre des machines connectées, ou quand une poignée de contrôleurs doit fournir quelques dizaines de signaux et qu'ajouter du matériel n'est pas réaliste.

Architecture 2 : passerelle edge

Une passerelle placée sur le réseau d'automatisme lit les automates via leurs protocoles natifs et publie en MQTT vers l'amont. Ce peut être un PC industriel avec un serveur de connectivité commercial, un conteneur sur une plateforme edge, Node-RED ou un court service Python. Le guide des passerelles edge IIoT détaille les choix matériels et logiciels.

Points forts : les programmes automates restent intacts, une passerelle dessert de nombreux contrôleurs et marques, la mise en tampon sur disque survit aux coupures WAN, et la mise en forme des payloads, les bandes mortes et l'encodage Sparkplug B se font là où les outils logiciels sont performants.

Points faibles : un équipement de plus à mettre à jour, superviser et sauvegarder ; la passerelle devient un nœud critique ; et les lectures en protocole natif doivent être activées sur les automates, ce qui affaiblit parfois des protections côté contrôleur, comme la désactivation de PUT/GET.

Convient quand : vous connectez une ligne, une usine ou un parc hétérogène. C'est le choix par défaut pour la plupart des sites existants.

Architecture 3 : relais par le SCADA

Le serveur SCADA ou IHM existant interroge déjà chaque automate. Un module ou un script MQTT sur ce serveur transmet des tags sélectionnés au broker, souvent en Sparkplug B. Ignition en est un exemple courant ; consultez Ignition avec MQTT.

Points forts : réutilisation de la base de tags, de la configuration des alarmes et du nommage existants ; aucune nouvelle connexion aux automates ; un seul endroit pour gérer ce qui sort de l'usine.

Points faibles : les données cloud dépendent désormais de la disponibilité et des licences du SCADA ; les noms de tags SCADA peuvent ne pas correspondre au standard de nommage de l'entreprise ; et le serveur SCADA, généralement un actif OT de grande valeur, dispose maintenant d'un chemin sortant vers Internet.

Convient quand : le SCADA couvre déjà les actifs qui vous intéressent et que son équipe porte l'intégration.

Les architectures automate vers le cloud côte à côte

Beaucoup d'usines finissent par les combiner : les constructeurs livrent des équipements connectés nativement, les lignes anciennes passent par des passerelles et le SCADA transmet ses synthèses d'alarmes et de production.

Modèles de sécurité pour la connexion des automates au cloud

C'est sur la sécurité que ces projets réussissent ou s'enlisent. Les modèles ci-dessous s'appliquent quelle que soit l'architecture.

1. Sortant uniquement. Les équipements de l'usine initient les connexions TLS vers le broker. Pas de redirection de port entrante, pas de VPN vers les réseaux de contrôleurs pour la collecte de données.
2. Segmentez par niveau. Gardez les automates dans la zone de contrôle. Placez les passerelles en bordure ou dans une DMZ industrielle, et n'autorisez que la passerelle à joindre le broker. Le modèle de DMZ MQTT explique où placer le broker entre OT et IT.
3. TLS partout hors de la cellule. Utilisez le port 8883 avec validation des certificats ; ne désactivez jamais la vérification pour faire fonctionner une connexion.
4. Une identité par publieur. Chaque automate ou passerelle reçoit son propre nom d'utilisateur, mot de passe et client ID, de sorte qu'un équipement compromis puisse être révoqué sans toucher aux autres.
5. Lecture seule par défaut. Traitez les écritures du cloud vers l'automate comme un projet distinct, avec listes blanches, contrôle des plages, verrouillages côté automate et piste d'audit.
6. Gardez les secrets hors des projets. Ne versionnez pas les mots de passe du broker dans des projets automates ou des dépôts de passerelle partagés entre équipes.
7. Surveillez les abus. Utilisez un broker qui limite les débits anormaux et bloque les échecs de connexion répétés, et déclenchez une alerte quand un publieur attendu disparaît.

ConnectMQ, par exemple, applique sur chaque broker des quotas par plan, une protection contre les inondations de messages et le blocage d'IP après des échecs de connexion répétés : ces protections ne dépendent donc pas de la bonne configuration de chaque usine.

Fiabilité et qualité des données

Une connexion qui fonctionne en démonstration n'est pas la même chose qu'une connexion qui fournit des données fiables pendant des années. Vérifiez ces points avant la mise en service :

• Report by exception avec heartbeats. Publiez sur changement significatif, plus un rafraîchissement périodique, afin de distinguer les valeurs stables des liaisons mortes.
• Last Will et statut retenu. Un état online ou offline retenu par publieur permet à chaque consommateur de savoir ce qui est à jour.
• Horodatage à la source. Horodatez les valeurs là où elles sont lues, pas là où elles sont reçues, et synchronisez les horloges via NTP.
• Mise en tampon. Décidez de ce qui se passe pendant une coupure WAN : abandon, tampon en mémoire, ou tampon sur disque avec relecture dans l'ordre.
• Nommage. Convenez d'une hiérarchie de topics fondée sur ISA-95 avant que le deuxième site ne se connecte. Renommer plus tard coûte cher.

Tester le chemin réseau

Avant de construire quoi que ce soit, prouvez que le réseau de l'usine peut atteindre un broker en TLS. Depuis une machine de la zone où tournera votre publieur :

mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i plant-path-test-9x2c -t 'connectmq/demo/9x2c/path-test' -m 'hello from the plant'

Si la commande échoue sur un timeout, le pare-feu bloque le 8883 sortant. Si elle échoue pendant le handshake, un proxy d'inspection TLS remplace peut-être les certificats : c'est une discussion à avoir tôt avec l'équipe réseau. Le serveur MQTT public gratuit est partagé, lisible par tous et réservé aux tests : n'envoyez que des chaînes de test, jamais de données de production.

Où placer le broker

Vous avez le choix entre un broker sur site, un broker que vous exploitez vous-même dans le cloud, ou un broker MQTT managé. Les brokers sur site sont utiles pour les consommateurs locaux et les architectures en DMZ ; pour les données à l'échelle de l'entreprise, un broker cloud joignable depuis chaque site est plus simple. ConnectMQ propose cette solution sous forme de broker MQTT managé avec MQTT 3.1.1 et 5.0, TLS sur le port 8883, et des options allant des plans Serverless mutualisés aux clusters Dedicated et aux déploiements BYOC dans votre propre compte cloud. La vue des équipements du portail comprend les topics ISA-95 et Sparkplug B : les données issues des clients natifs des automates, des passerelles et du SCADA arrivent dans une seule hiérarchie navigable.

Checklist de décision

1. Combien d'automates, de combien de constructeurs, sont concernés cette année ?
2. Les programmes automates peuvent-ils être modifiés et chargés, et qui l'approuve ?
3. Le SCADA interroge-t-il déjà les actifs dont vous avez besoin ?
4. Quelle latence de données est requise : secondes, minutes ou heures ?
5. Que deviennent les données pendant une coupure WAN, et pendant combien de temps ?
6. Quelle zone peut initier des connexions sortantes, et sur quels ports ?
7. Qui sera responsable des mises à jour de la passerelle, des certificats et de la supervision ?
8. Un chemin d'écriture du cloud vers l'automate est-il nécessaire, et a-t-il fait l'objet d'une analyse de risques ?

Si les réponses indiquent de nombreux constructeurs, aucune modification des automates et de longues coupures, commencez par une passerelle edge. Pour l'architecture de bout en bout, poursuivez avec le guide de l'IoT industriel avec MQTT.

Lancez votre projet automate vers le cloud avec ConnectMQ

Quelle que soit l'architecture choisie, il lui faut un broker MQTT cloud fiable à l'autre bout. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et connectez dès aujourd'hui votre premier automate ou votre première passerelle en TLS.

Questions fréquentes

Quelle est la façon la plus sûre de connecter un automate au cloud ?

Gardez l'automate dans sa zone de contrôle, laissez une passerelle ou un broker en DMZ établir uniquement des connexions TLS sortantes, donnez à chaque publieur ses propres identifiants et gardez le chemin des données en lecture seule.

Ai-je besoin d'une passerelle edge pour connecter un automate au cloud ?

Pas toujours. Certains automates peuvent publier nativement en MQTT, mais les passerelles sont généralement préférables pour les parcs multi-constructeurs, la mise en tampon pendant les coupures et pour laisser les programmes automates inchangés.

OPC UA ou MQTT : lequel est le meilleur pour connecter un automate au cloud ?

OPC UA excelle dans l'accès local et structuré aux données de l'automate, tandis que MQTT est meilleur pour distribuer des événements à de nombreux consommateurs cloud. De nombreuses architectures lisent via OPC UA à l'edge et publient via MQTT.

Les données d'automate doivent-elles aller dans le cloud en temps réel ?

La plupart des cas d'usage cloud requièrent des secondes à des minutes, pas des millisecondes. Gardez la régulation en boucle fermée en local et envoyez vers l'amont des données en report by exception.