Modbus, SCADA, automates : la télémaintenance sans exposition

Le besoin réel : intervenir sans se déplacer

La télémaintenance n’est pas un confort : c’est ce qui sépare un arrêt de production de vingt minutes d’un arrêt de deux jours. Diagnostiquer un défaut, lire des registres, charger un correctif de programme, vérifier une recette — la plupart des interventions ne justifient pas un déplacement, à condition de pouvoir joindre la machine à distance. Trois situations reviennent constamment.

Dans les trois cas, la question n’est pas « comment accéder » — des solutions existent depuis vingt ans — mais « comment accéder sans créer une porte d’entrée permanente sur un équipement qui ne sait pas se défendre ».

Modbus et les protocoles nés sans sécurité

Modbus date d’une époque où le réseau d’automatisme était un câble série entre deux armoires. Sa déclinaison Modbus TCP, qui écoute par convention sur le port 502, a hérité du modèle : aucune authentification, aucun chiffrement, aucun contrôle d’intégrité. Toute machine capable d’établir une connexion TCP vers l’automate peut lire les entrées, écrire les sorties et modifier les registres. Ce n’est pas un défaut d’implémentation : c’est le protocole, tel qu’il a été conçu — pour un réseau supposé fermé.

Modbus n’est pas un cas isolé. Une grande partie des protocoles d’automatisme encore en production repose sur la même hypothèse d’un réseau de confiance : l’identité de l’interlocuteur n’est pas vérifiée, et les échanges circulent en clair. La sécurité de ces équipements ne vient pas du protocole : elle vient — entièrement — de qui peut atteindre le réseau où ils vivent.

Or les équipements exposés ne restent pas discrets. Des moteurs de scan publics parcourent en permanence l’espace d’adressage Internet et indexent les services qui répondent, ports industriels compris. Un automate joignable depuis Internet n’est pas « caché parce que personne ne connaît l’adresse » : il est trouvable par n’importe qui, sans effort particulier, et il répondra à quiconque lui parle son protocole.

Pourquoi les pratiques courantes font peur

Face au besoin, le terrain a improvisé. Trois pratiques dominent, chacune née d’une contrainte réelle — et chacune avec un coût de sécurité ou d’exploitation qu’on finit toujours par payer.

Le point commun de ces trois pratiques : l’accès est trop large (un réseau entier, un bureau entier) ou trop exposé (un port ouvert sur le protocole nu), et il repose sur une configuration côté site que quelqu’un doit créer, documenter et penser à retirer. À l’échelle d’un parc, c’est autant de portes d’entrée que de clients.

L'approche : une passerelle rejoint le mesh, l'automate reste chez lui

Le modèle VIGIL-MESH tient en une phrase : ce n’est pas l’automate qui rejoint le réseau privé, c’est une passerelle de site — un PC industriel, un NVIDIA Jetson, une box Linux — posée en coupure entre le réseau machine et le monde. La passerelle installe le client VIGIL et rejoint le mesh ; l’automate, lui, ne bouge pas : il reste sur son réseau machine, sans agent, sans modification, invisible depuis Internet.

• Zéro port entrant côté site — la passerelle n’établit que des connexions sortantes : un seul flux en 443 UDP, le même port que le web moderne. Rien à ouvrir sur le pare-feu du client, rien à rediriger, rien à justifier.
• Connexion immédiate, direct dès que possible — le trafic passe d’abord par un relais, puis migre sans coupure vers le chemin direct quand la traversée NAT aboutit. La session survit aux changements de réseau — utile pour un site raccordé en 4G/5G.
• Une adresse stable et un nom — la passerelle garde la même adresse sur le mesh où qu’elle soit, et un nom MagicDNS lisible. La supervision pointe vers un nom qui ne change jamais, pas vers une IP publique de site.
• Un nœud, tout l’atelier — un seul nœud connecté rend joignables, dans le réseau privé et sous contrôle des ACL, les équipements du réseau machine qu’il dessert.

ACL strictes : le moindre privilège, machine par machine, service par service

Rejoindre le mesh n’ouvre aucun droit. Les ACL de VIGIL-MESH sont en refus par défaut : tout flux qui n’est pas explicitement autorisé est refusé. Les règles sont ordonnées — la première qui correspond décide — et désignent leurs sujets par identité (machine, groupe, étiquette), jamais par adresse IP. Pour la télémaintenance, cela permet d’écrire exactement l’accès dont on a besoin : telle équipe joint telle passerelle, sur tel service, et rien d’autre.

Chaque changement de politique produit une nouvelle génération signée par le contrôleur, que le client vérifie contre la clé publique du contrôleur avant de l’appliquer, y compris hors ligne. Les actions sensibles exigent une authentification forte (MFA), et l’audit est chaîné par hachage : une intervention de télémaintenance laisse une trace vérifiable — qui a eu accès à quoi, sous quelle génération de politique.

Modbus dans un tunnel TLS 1.3 de bout en bout

Le mesh ne demande rien aux protocoles qu’il transporte — et c’est justement ce qui sauve les protocoles nus. Entre le poste du technicien et la passerelle de site, chaque session est une connexion QUIC/TLS 1.3 chiffrée de bout en bout, fondée sur des clés Ed25519 avec un établissement de clés hybride post-quantique X25519 + ML-KEM. Le flux Modbus circule à l’intérieur de ce tunnel : sur le trajet distant, il n’est jamais en clair.

• Le relais est structurellement aveugle — quand le trafic passe par une vigie, celle-ci ne détient pas les clés et ne voit jamais le contenu. Relayé ou direct, le chemin ne change rien au chiffrement.
• Vigie privée possible — si transiter par un relais partagé vous dérange, vous pouvez héberger votre propre vigie, dédiée à votre espace de travail.
• Tout l’IP en profite — Modbus TCP, OPC UA, MQTT, l’IHM web d’une machine ou un accès VNC/RDP vers le poste de supervision voyagent dans le même tunnel, chacun soumis à sa règle d’ACL.

OEM et intégrateurs : un espace, des réseaux par site, des îlots autonomes

Pour un constructeur ou un intégrateur qui suit un parc, la structure compte autant que le tunnel. Un espace de travail regroupe l’ensemble du parc ; à l’intérieur, chaque site ou chaque client a son réseau. Les ACL cloisonnent : les machines du site A n’ont aucune raison de voir celles du site B, et ne les voient pas. L’équipe SAV, elle, reçoit des droits par groupe — ajoutés et retirés sans réécrire la politique site par site.

• Un réseau par site — chaque site est un domaine propre, avec ses machines, ses noms MagicDNS et ses règles. La croissance du parc n’ajoute pas de complexité de tunnels : elle ajoute des lignes d’inventaire.
• Îlots autonomes — si le lien Internet d’un site tombe, les membres déjà vérifiés présents sur place continuent de se parler. La supervision locale survit à la coupure ; seule la visibilité distante attend le retour du lien.
• Publication contrôlée — un tableau de bord ou un historian du mesh peut être exposé proprement via les publications, sans rendre visible le reste de l’OT.
• Audit par intervention — adhésions, révocations et changements de politique sont tracés : on peut répondre à un client qui demande qui a accédé à sa machine, et quand.

Côté postes, la télémaintenance se pratique depuis Windows ou Linux au bureau, depuis Android en déplacement, et jusque dans le navigateur via le nœud WASM de la console — sans VPN à installer sur la machine de l’hôtel.

Les limites, dites franchement

VIGIL-MESH règle le problème de l’accès distant — qui peut joindre quoi, chiffré, sans exposition. Il ne prétend pas régler toute la sécurité OT, et il vaut mieux le dire avant que vous ne le découvriez.

• Ce n’est pas un pare-feu industriel — le mesh transporte les flux autorisés sans inspecter les trames : il ne filtre pas les codes fonction Modbus, ne bloque pas une écriture de registre illégitime venant d’un poste autorisé. La défense en profondeur sur le réseau machine reste nécessaire.
• Ce n’est pas une conformité clé en main — l’audit chaîné et les générations signées sont des briques utiles à une démarche de conformité, pas la démarche elle-même. L’analyse de risque et l’organisation restent à faire.
• Les protocoles non-IP sortent du périmètre — PROFINET DCP, EtherCAT natif et autres trames de niveau 2 non-IP ne traversent pas le cœur du mesh, qui est un overlay L3. Le cas échéant, ils relèvent d’un pont L2 de site optionnel sur un nœud passerelle.
• Le chemin direct n’est pas garanti — deux NAT symétriques face à face (site en 4G, technicien en 4G) imposent un relais permanent. La connexion fonctionne, chiffrée de bout en bout, simplement par un chemin plus long.

Mettre en place la télémaintenance

1. 1
   Créez un compte et un espace de travailL’espace de travail regroupera vos réseaux — par exemple un réseau par site ou par client. Gratuit pour un usage personnel.
2. 2
   Installez le client sur les machines concernéesLa passerelle de site (PC industriel, Jetson, box Linux) d’un côté ; les postes des techniciens (Windows, Linux, Android) de l’autre.
3. 3
   Enrôlez chaque machinePage Réseaux → Machines → « Ajouter une machine », avec une clé à usage unique par machine.
4. 4
   VérifiezChaque machine reçoit son adresse stable et son nom MagicDNS ; un ping vers la passerelle confirme le chemin.
5. 5
   Accédez au service comme en localPointez la supervision ou l’outil de configuration vers l’adresse ou le nom de la passerelle, exactement comme si vous étiez sur place.

Questions fréquentes