Comment connecter un automate Siemens S7 au cloud en 2025 ?

· 14 minutes de lecture
14 min read
Lucas Moreau
Lucas Moreau
Ingénieur Réseau OT/IT

Les automates Siemens S7 équipent des dizaines de milliers d'installations industrielles en France — lignes de production, stations de traitement, infrastructures énergétiques. Pendant des années, ces automates vivaient en vase clos, communiquant uniquement avec un superviseur SCADA local. Aujourd'hui, la pression est forte pour les connecter au cloud : supervision à distance, maintenance prédictive, centralisation des données de production, accès des équipes maintenance depuis n'importe où.

Mais connecter un S7 au cloud ne s'improvise pas. Les protocoles disponibles varient selon la génération d'automate, la configuration réseau du site peut interdire certaines approches, et la sécurité de l'accès distant à un automate de production est un sujet à part entière.

Ce guide détaille trois méthodes éprouvées pour connecter un automate Siemens S7 au cloud en 2025, avec leurs avantages, leurs limites et des exemples de configuration concrets.

Pourquoi connecter un S7 au cloud ?​

Avant d'entrer dans le technique, posons les bases du ROI. Les industriels qui franchissent le pas citent systématiquement trois bénéfices principaux :

Supervision à distance. Accéder aux valeurs de process, aux alarmes et à l'état de la ligne depuis un ordinateur ou un smartphone — sans VPN complexe configuré par le service IT, sans avoir à appeler le chef d'équipe sur place. Pour un constructeur de machines, c'est la capacité à voir en temps réel l'état de chaque installation chez ses clients.

Maintenance prédictive. Historiser les données de l'automate dans une base de données temporelle (InfluxDB, TimescaleDB, Azure Time Series Insights) permet de détecter des dérives avant qu'elles ne causent un arrêt. Un moteur dont la consommation augmente progressivement sur 3 semaines est détectable bien avant la panne.

Réduction des déplacements. Un diagnostic à distance évite un déplacement sur site. Pour une installation à 500 km du bureau technique, c'est une économie directe et immédiate.

Les protocoles disponibles sur un automate Siemens S7​

La première étape est de connaître ce que votre automate supporte nativement. La réponse dépend fortement de la génération.

ProtocoleS7-300 / S7-400S7-1200 (FW ≥ 4.x)S7-1500
S7COMM (protocole natif)Oui (port 102/TCP)OuiOui
Modbus TCPVia CP ou FB tiersOui (FB natif)Oui (FB natif)
OPC-UA serveurNon natifNon (client uniquement FW 4.x)Oui (serveur natif)
PUT/GETOuiOui (à activer)Oui (à activer)
MQTTNonNon natif (via passerelle)Via LHTTP ou passerelle

S7COMM : le protocole natif Siemens​

S7COMM est le protocole propriétaire utilisé par TIA Portal pour la communication entre le PC de programmation et l'automate. Il fonctionne sur TCP port 102 et peut être utilisé par des clients tiers (libnodave, python-snap7) pour lire et écrire des variables. Cependant, ce protocole n'est pas recommandé pour une exposition cloud : il ne supporte pas l'authentification, et exposer le port 102 à Internet est une faute de sécurité grave.

PUT/GET : lecture directe depuis un tiers​

La fonction PUT/GET permet à un client externe de lire ou écrire des blocs de données dans l'automate. Elle est désactivée par défaut sur les S7-1200 et S7-1500 et doit être explicitement autorisée dans les propriétés de la CPU dans TIA Portal. Même raisonnement côté sécurité : à utiliser uniquement derrière un VPN, jamais exposé directement.

OPC-UA et Modbus TCP : les deux protocoles recommandés​

Pour une intégration cloud sécurisée, les deux approches recommandées sont OPC-UA (sur S7-1500) et Modbus TCP (S7-1200 et S7-1500). Ce sont les protocoles pour lesquels il existe des bibliothèques, des connecteurs cloud et des solutions de passerelle éprouvées.

Méthode 1 — Via OPC-UA (S7-1500)​

OPC-UA est le protocole de référence pour l'interopérabilité industrielle. Depuis la version V2.0 du firmware S7-1500, le serveur OPC-UA est intégré nativement dans la CPU. C'est la méthode la plus propre et la plus pérenne pour les nouvelles installations ou les automates S7-1500.

Activation du serveur OPC-UA dans TIA Portal​

Étape 1 — Ouvrir les propriétés de la CPU. Dans le projet TIA Portal, sélectionner la CPU S7-1500, aller dans Propriétés > OPC UA > Serveur.

Étape 2 — Activer le serveur. Cocher Activer le serveur OPC UA. Laisser le port par défaut (4840). Vous pouvez définir un port personnalisé si votre infrastructure réseau l'exige.

Étape 3 — Configurer la sécurité. Sélectionner au minimum le mode de sécurité SignAndEncrypt avec Basic256Sha256. Ne jamais utiliser None en production — cela équivaut à exposer les variables de l'automate sans authentification.

Étape 4 — Créer les nœuds OPC-UA. Dans le bloc de données (DB), cocher les variables à exposer via OPC-UA (Accessible depuis OPC UA). Les variables non cochées ne sont pas visibles depuis l'extérieur — c'est un premier niveau de filtrage.

Étape 5 — Déployer et tester. Télécharger le projet dans la CPU. Tester avec un client OPC-UA comme UaExpert (gratuit) depuis le réseau local avant de configurer la passerelle cloud.

Passerelle OPC-UA → Cloud​

Le serveur OPC-UA du S7-1500 attend des connexions entrantes. Pour l'envoyer vers le cloud sans ouvrir de port entrant (recommandation de sécurité), une passerelle IoT locale se connecte au serveur OPC-UA en tant que client et relaie les données via une connexion sortante HTTPS/MQTT vers le cloud.

# Exemple de configuration passerelle Eziwan — source OPC-UA
sources:
  - type: opcua
    endpoint: opc.tcp://192.168.1.10:4840
    security_mode: SignAndEncrypt
    security_policy: Basic256Sha256
    certificate: /etc/eziwan/opcua_client.pem
    polling_interval: 5s
    nodes:
      - node_id: "ns=3;s=DB1.temperature_process"
        name: temperature_process
        unit: °C
      - node_id: "ns=3;s=DB1.pression_bar"
        name: pression_bar
        unit: bar
      - node_id: "ns=3;s=DB1.etat_ligne"
        name: etat_ligne

destinations:
  - type: mqtt
    broker: mqtt.eziwan.cloud:8883
    tls: true
    topic_prefix: "usine/ligne1"

Méthode 2 — Via Modbus TCP (S7-1200 / S7-1500)​

Modbus TCP est supporté nativement sur le S7-1200 (firmware 4.x et supérieur) et le S7-1500 via des blocs fonctionnels (FB) intégrés à TIA Portal. C'est l'approche à privilégier lorsque votre passerelle IoT ou votre SCADA parle Modbus TCP, ou lorsque vous devez vous intégrer à un système existant qui supporte déjà ce protocole.

Configuration du serveur Modbus TCP sur S7-1200​

Étape 1 — Créer un bloc de données pour les registres. Créer un DB Modbus_Holding_Registers avec un tableau de WORD de la taille souhaitée (ex. 100 registres). Ce tableau sera accessible en lecture/écriture par le client Modbus.

Étape 2 — Instancier le FB MB_SERVER. Dans le bloc OB1 ou dans une tâche cyclique, instancier le FB MB_SERVER (disponible dans la bibliothèque TIA Portal).

// Exemple d'instanciation MB_SERVER en SCL
#MB_SERVER_Instance(
    EN_R_JMP    := TRUE,
    DISCONNECT  := FALSE,
    MB_HOLD_REG := "Modbus_Holding_Registers".data,
    NDR         := #NDR,
    DR          := #DR,
    ERROR       := #ERROR,
    STATUS      := #STATUS,
    CONNECT     := #TCON_Param
);

Étape 3 — Configurer les paramètres de connexion. Dans le bloc de données TCON_Param, spécifier :

  • InterfaceId : ID de l'interface Ethernet de la CPU (généralement 64)
  • ID : identifiant de connexion (ex. 1)
  • ActiveEstablished : FALSE (le S7 attend les connexions)
  • RemotePort : 0 (accepte tous les clients)
  • LocalPort : 502 (port Modbus standard)

Étape 4 — Mapper les variables dans le DB de registres. Écrire les valeurs process dans le tableau de registres depuis le programme automate. La passerelle IoT lit ces registres en Modbus TCP et les transmet au cloud.

Paramètres de configuration importants​

ParamètreValeur recommandéeRemarque
Port502Standard Modbus TCP
Connexions simultanées3 maximumValeur par défaut S7-1200
Timeout connexion30 sÀ ajuster selon le réseau
RegistresDB structuréÉviter les accès à la mémoire M
Mise à jour registresCyclique (100 ms)Adapter à la dynamique du process

Méthode 3 — Via passerelle IoT RS-485 (tous automates)​

Cette méthode s'applique lorsque l'automate S7 n'est pas directement accessible depuis le réseau IP (pas d'interface Ethernet disponible, réseau OT isolé, S7-300 ancien sans CP Ethernet) ou lorsque vous avez déjà un bus RS-485 Modbus RTU sur lequel l'automate est accessible en tant qu'esclave ou maître.

Architecture​

Dans ce schéma, une passerelle IoT (Eziwan Gateway, par exemple) se connecte physiquement au port RS-485 de l'automate ou du réseau de terrain et dialogue en Modbus RTU. La passerelle convertit les données Modbus RTU en MQTT ou HTTP et les transmet au cloud via sa connectivité 4G ou Ethernet.

Configuration Modbus RTU sur S7-300​

Sur un S7-300 avec module de communication CP 340 ou CP 341, la communication RS-485 Modbus RTU est configurée via le logiciel de paramétrage Siemens (protocole USS ou Modbus RTU selon le module). Les registres à exposer sont définis dans le DB de communication du CP.

Cette méthode présente un avantage majeur : elle ne nécessite aucune modification du programme automate existant si celui-ci est déjà configuré en Modbus RTU maître ou esclave. La passerelle IoT est transparente pour l'automate.

Sécuriser l'accès à distance au S7​

La sécurisation de l'accès à un automate de production est un sujet critique. Une mauvaise configuration peut exposer le process industriel à des accès non autorisés, voire à des attaques (cf. incidents documentés sur des installations industrielles).

Principe : zéro port exposé vers Internet​

Ne jamais exposer directement le port de l'automate (TCP 102, TCP 502, TCP 4840) vers Internet, même derrière un NAT. L'approche correcte est le tunnel VPN sortant.

La passerelle IoT établit une connexion sortante chiffrée vers un concentrateur VPN cloud. L'automate, lui, ne voit que le réseau local. Depuis l'extérieur, l'accès se fait via le concentrateur VPN, qui authentifie et autorise chaque connexion.

Configuration VPN OpenVPN​

OpenVPN est le protocole VPN recommandé pour les déploiements industriels IoT : il traverse les pare-feux via TCP 443, se re-connecte rapidement après une coupure réseau (critique sur 4G), et s'authentifie par certificat X.509. IPSec (IKEv2) reste disponible pour les environnements régulés.

# Configuration OpenVPN côté passerelle terrain (profil .ovpn)
client
dev tun
proto udp
remote vpn.eziwan.cloud 1194
remote-cert-tls server
cipher AES-256-GCM
auth SHA256
keepalive 10 60
persist-tun
# routes terrain poussées par le serveur : 10.10.1.0/24
# certificat client X.509 injecté automatiquement par le Zero-Touch Provisioning

Avec cette configuration, la passerelle maintient un tunnel permanent vers le cloud. L'automate S7 reste sur le réseau local 192.168.x.x, jamais exposé directement. L'ingénieur de maintenance se connecte au concentrateur VPN cloud et accède à l'automate via le tunnel.

Segmentation réseau​

Séparer le réseau OT (automates) du réseau IT (bureautique, cloud) par un pare-feu industriel ou un VLAN dédié. La passerelle IoT est l'unique pont autorisé entre les deux zones, avec des règles de flux strictes (uniquement les protocoles et les destinations nécessaires).

Exemple de déploiement complet​

Contexte : une ligne de production équipée d'un S7-1500, avec une centaine de variables process à superviser depuis le siège (à 300 km) et à historiser pour l'analyse de performance.

Architecture déployée :

  1. S7-1500 sur la ligne — serveur OPC-UA activé, 87 variables exposées dans 3 blocs de données. Sécurité OPC-UA en mode SignAndEncrypt.

  2. Passerelle Eziwan Gateway dans l'armoire de la ligne — connectée en Ethernet local au S7-1500. Client OPC-UA qui poll les variables toutes les 5 secondes. VPN OpenVPN/IPSec permanent vers le cloud Eziwan. Failover dual SIM si l'Ethernet de l'usine tombe.

  3. Cloud Eziwan — réception MQTT des données, stockage en base de données temporelle, agrégation horaire/quotidienne. API REST disponible pour les systèmes tiers.

  4. Dashboard Grafana au siège — connexion à l'API cloud Eziwan, affichage des KPIs de production (TRS, cadence, OEE), alertes e-mail et SMS sur dépassement de seuils.

  5. Accès maintenance à distance — les ingénieurs maintenance se connectent au VPN Eziwan depuis leur poste. Ils voient le S7-1500 comme si ils étaient sur le réseau local de l'usine, avec TIA Portal en accès direct pour le diagnostic.

Résultat : mise en service en 4 heures. Aucune modification du programme automate existant. Aucun port ouvert sur le pare-feu du client.

Erreurs fréquentes​

  1. Activer PUT/GET sans VPN. La fonction PUT/GET ouvre un accès direct aux DB de l'automate. Sans VPN, quiconque peut atteindre le réseau OT peut lire et écrire les variables de production. C'est la configuration la plus dangereuse rencontrée sur le terrain.

  2. Utiliser S7COMM depuis le cloud. Le protocole natif Siemens (port 102) n'est pas conçu pour une exposition externe. Les bibliothèques tierces qui l'implémentent ne supportent pas les mécanismes de sécurité modernes.

  3. Négliger le flux de retour. Une supervision cloud qui envoie des commandes vers l'automate (setpoints, commandes de démarrage) nécessite une analyse de sécurité renforcée. Définir clairement les variables en lecture seule et celles en lecture/écriture dans le serveur OPC-UA ou le mapping Modbus.

  4. Ignorer la version du firmware S7. Le serveur OPC-UA intégré n'est disponible que depuis une certaine version firmware selon le modèle. Sur S7-1500, vérifier que le firmware est ≥ V2.0 avant de planifier une intégration OPC-UA.

  5. Sous-dimensionner la passerelle. Une passerelle qui poll 500 variables OPC-UA toutes les secondes tout en maintenant un tunnel VPN et en gérant une connexion 4G a besoin de ressources CPU et mémoire suffisantes. Valider les performances avec un test de charge avant le déploiement production.

FAQ​

Mon S7-300 avec CP Ethernet peut-il être connecté au cloud ? Oui, mais les options sont plus limitées. Le S7-300 ne supporte pas OPC-UA nativement. Les approches possibles sont : Modbus TCP via FB tiers ou CP dédié, S7COMM via bibliothèque tierce (à utiliser uniquement derrière VPN), ou RS-485 Modbus RTU avec passerelle IoT (méthode 3).

Peut-on connecter un S7 au cloud sans modifier le programme automate ? Souvent oui, notamment via la méthode RS-485/passerelle (si l'automate a déjà un port RS-485 Modbus) ou via OPC-UA en lecture seule (les variables existantes sont exposées sans modification du programme). La méthode Modbus TCP serveur nécessite des modifications limitées (ajout du FB MB_SERVER et d'un DB de registres).

Quelle est la latence entre une valeur process et son affichage sur le dashboard cloud ? Avec un polling OPC-UA à 5 secondes, une transmission MQTT et un rafraîchissement dashboard à 5 secondes, la latence totale est de 5 à 15 secondes dans des conditions normales. Ce n'est pas adapté à la régulation temps réel (qui reste le rôle de l'automate), mais c'est parfaitement suffisant pour la supervision et la maintenance.

L'accès distant via VPN nécessite-t-il TIA Portal sur le PC de l'ingénieur ? Oui pour accéder en modification au programme automate (ce qui requiert TIA Portal). Non pour la supervision des variables, qui peut se faire via le dashboard cloud sans aucun logiciel Siemens installé.

Pour aller plus loin​

Vous souhaitez connecter vos automates Siemens S7 au cloud sans ouvrir de ports ni modifier votre programme ? Contactez notre équipe — diagnostic de compatibilité gratuit en 48h.

Ressources complémentaires​