Entretien éditorial. Quand une PME industrielle connecte ses machines pour la première fois, elle découvre souvent en même temps une surface d'attaque qu'elle ignorait avoir. Nous avons interrogé un RSSI spécialisé dans la convergence IT/OT sur les vulnérabilités les plus fréquentes des environnements industriels français, la méthode pour sécuriser un projet IoT dès sa conception, et ce que change concrètement la nouvelle obligation de signalement CERT-FR qui entre en vigueur en septembre 2026.
Sommaire
Une PME industrielle sans expertise cyber interne peut sécuriser un projet IoT en appliquant quatre priorités : inventorier les équipements, séparer strictement les réseaux IT et OT, encadrer les accès distants et imposer des exigences de sécurité au fournisseur. Le premier investissement ne doit donc pas être un SOC coûteux, mais une architecture limitant les chemins d'attaque et un dispositif simple de réaction aux incidents.
Dans cet entretien éditorial, « le RSSI » désigne un profil générique spécialisé dans la convergence IT/OT au sein de PME manufacturières françaises. Son approche : réduire le risque opérationnel sans bloquer la production ni transformer chaque projet connecté en chantier interminable.
Les PME industrielles sont-elles réellement ciblées ?
Les chiffres disponibles reflètent-ils une menace concrète pour les PME industrielles françaises ?
Le RSSI : Le risque n'est plus théorique. Orange Cyberdefense rapporte que, selon l'ANSSI, 37 % des victimes de ransomwares en France en 2024 étaient des PME industrielles. SysDream indique de son côté que près de 70 % des entreprises industrielles ont subi une cyberattaque OT et qu'une organisation sur quatre a dû interrompre ses opérations après une attaque. Ces données ne signifient pas que toutes les usines seront paralysées, mais elles confirment la pression exercée sur le secteur.
Une PME est attractive parce qu'elle combine continuité de production, dépendance à quelques machines critiques et moyens cyber limités. L'attaquant n'a d'ailleurs pas toujours besoin de comprendre l'automate : il peut chiffrer le serveur de supervision, compromettre le poste de maintenance ou couper les échanges avec l'ERP. Pour le dirigeant, la bonne question n'est donc plus « sommes-nous une cible ? », mais « combien d'heures pouvons-nous produire sans informatique, supervision ou accès fournisseur ? ». Le guide de la cybersécurité permet ensuite de replacer ce risque industriel dans la stratégie globale de l'entreprise.
Pourquoi les automates anciens restent-ils vulnérables ?
Qu'est-ce qui rend les PLC, SCADA et postes de supervision plus difficiles à protéger ?
Le RSSI : Beaucoup d'automates ont été conçus à une époque où le réseau industriel était supposé isolé. L'authentification forte, le chiffrement des communications, la journalisation détaillée ou la signature des mises à jour n'étaient pas des fonctions standard. BetterLink estime que 60 % des usines françaises présentent encore des vulnérabilités majeures dans leurs environnements OT et rappelle que de nombreux PLC et systèmes SCADA datent de plusieurs décennies.
Le problème ne se résout pas simplement par l'installation d'un antivirus. Un système ancien peut dépendre d'une version obsolète de Windows, d'un protocole industriel non chiffré ou d'un logiciel fournisseur incompatible avec les correctifs récents. Le redémarrer peut aussi nécessiter un arrêt de ligne planifié.
Il faut alors compenser : filtrage réseau, suppression des services inutiles, sauvegarde des configurations, contrôle des supports USB et accès de maintenance via un bastion. Avant tout remplacement, la PME doit vérifier si elle possède les programmes sources, les paramètres de l'automate et une procédure de restauration testée. Une sauvegarde jamais restaurée reste une hypothèse, pas une protection.
Quelle segmentation IT/OT appliquer avant de connecter des capteurs ?
Quelle règle d'architecture devrait précéder tout projet IoT industriel ?
Le RSSI : Aucun capteur, automate ou équipement IoT ne devrait créer un passage direct entre l'atelier, le système d'information et Internet. C'est la règle de départ. IT Pro souligne que la convergence IT/OT expose des systèmes historiquement isolés à des menaces structurées, notamment avec la multiplication des machines connectées. La segmentation doit donc exister avant la connexion à une plateforme cloud, pas après l'incident.
Je recommande quatre étapes :
- séparer physiquement ou logiquement le réseau bureautique, l'OT et les équipements IoT ;
- placer les échanges nécessaires dans une DMZ industrielle contrôlée par des pare-feu ;
- appliquer un filtrage « refus par défaut », limité aux adresses, ports et flux documentés ;
- faire passer toute télémaintenance par un bastion avec MFA, comptes nominatifs et autorisation temporaire.
Un automate ne doit pas dialoguer directement avec Internet. Une passerelle collecte les données nécessaires et les transmet vers la plateforme, sans ouvrir un chemin retour permanent vers la production. Cette architecture doit être intégrée dès le choix de la plateforme IoT industrielle, car certains produits imposent des flux sortants ou des services cloud difficiles à maîtriser après l'achat.
Que faut-il exiger du fournisseur IoT ?
Comment évaluer une solution lorsque l'entreprise ne possède pas d'expert sécurité interne ?
Le RSSI : Il faut transformer la sécurité en critères d'achat vérifiables. Un fournisseur qui répond uniquement « notre cloud est sécurisé » n'apporte aucune information exploitable. La PME doit connaître la durée de support, la procédure de mise à jour, l'emplacement des données, les dépendances cloud et les conditions de télémaintenance.
Les exigences minimales sont concrètes :
- comptes nominatifs et MFA pour l'administration ;
- correctifs signés, documentés et déployables sans perte de configuration ;
- export des journaux et notification des événements sensibles ;
- procédure de suppression des accès fournisseur en fin de contrat ;
- engagement sur le traitement et la communication des vulnérabilités.
Il faut aussi tester le fonctionnement en mode dégradé. La ligne s'arrête-t-elle si la connexion Internet tombe ? Les données sont-elles stockées localement ? L'équipement continue-t-il à assurer sa fonction principale si l'abonnement cloud expire ? Pour un projet relevant de l'industrie 4.0 et de l'IoT, ces réponses ont autant de valeur que les performances du capteur. Elles doivent apparaître dans le contrat, avec un responsable identifié chez le fournisseur.
| Point de contrôle | Preuve à demander | Blocage avant production |
|---|---|---|
| Inventaire | Liste des équipements, versions et propriétaires | Actif inconnu ou non administrable |
| Flux réseau | Schéma des communications et ports | Accès Internet direct depuis l'OT |
| Mises à jour | Politique de support et procédure de retour arrière | Correctifs non signés ou support non défini |
| Télémaintenance | MFA, bastion et journal des connexions | Compte partagé ou accès permanent |
| Continuité | Test hors ligne et sauvegarde restaurable | Arrêt de production en cas de panne cloud |
Que change le Cyber Resilience Act en septembre 2026 ?
L'obligation de signalement au CERT-FR concerne-t-elle toutes les PME industrielles ?
Le RSSI : À partir du 11 septembre 2026, les fabricants concernés par le Cyber Resilience Act devront signaler au CERT-FR les vulnérabilités activement exploitées et les incidents graves affectant leurs produits. BYCYB rappelle cette échéance dans son analyse consacrée à l'IIoT, au CRA et à l'IEC 62443. Il faut toutefois distinguer l'exploitant d'une usine du fabricant qui met un produit comportant des éléments numériques sur le marché européen.
Une PME qui conçoit une machine connectée, une passerelle industrielle ou un équipement IoT peut donc être directement concernée. Une entreprise uniquement utilisatrice devra malgré tout organiser la remontée d'information vers ses fabricants et intégrateurs. Sans inventaire, version logicielle, traces techniques et interlocuteur désigné, elle perdra un temps précieux.
La préparation opérationnelle tient sur une page : qui qualifie l'événement, qui contacte le fournisseur, qui conserve les journaux, qui décide d'arrêter une machine et qui pilote la communication. Cette organisation doit être coordonnée avec les autres obligations applicables, notamment celles présentées dans le guide NIS2 pour les PME. Le CRA ne doit pas être traité comme un simple formulaire réglementaire.
Peut-on se protéger sans financer un SOC dédié ?
Quelle démarche réaliste recommandez-vous à une PME disposant d'un budget limité ?
Le RSSI : Oui, à condition de ne pas chercher à reproduire le dispositif d'un grand groupe. L'IEC 62443 fournit un référentiel utile pour structurer la sécurité industrielle autour des zones, des conduits de communication, des niveaux de risque et des responsabilités. Une PME peut s'en inspirer sans engager immédiatement une certification complète.
Le premier budget doit financer un inventaire fiable, la segmentation, les sauvegardes de configurations et la sécurisation des accès distants. La surveillance peut ensuite s'appuyer sur quelques sources prioritaires : pare-feu entre IT et OT, bastion, annuaire, antivirus ou EDR des postes de supervision compatibles et journaux de la plateforme IoT. Il vaut mieux dix alertes compréhensibles qu'un outil collectant tout sans personne pour l'exploiter.
La supervision peut être confiée à un prestataire, mais le pouvoir de décision doit rester en interne. Un responsable de production et un référent informatique doivent savoir isoler une zone, suspendre une télémaintenance et appeler les bons contacts. Le rôle du RSSI, même externalisé ou à temps partagé, consiste surtout à organiser ces arbitrages. Cet équilibre est également abordé dans notre entretien sur le RSSI en PME.
Que révèle généralement un incident après coup ?
Quel écart constate-t-on le plus souvent entre la sécurité perçue et la sécurité réelle ?
Le RSSI : Après un incident, on découvre fréquemment un chemin d'accès oublié : routeur 4G installé par un mainteneur, ancien VPN toujours actif, compte générique jamais supprimé, modem intégré à une machine ou poste à double connexion entre le Wi-Fi bureautique et l'atelier. Sur le schéma officiel, les réseaux étaient séparés. Dans la réalité, une exception temporaire était devenue permanente.
L'autre surprise concerne les responsabilités. L'informatique pense que le fournisseur administre l'équipement ; le fournisseur considère que le client protège le réseau ; la production suppose que les sauvegardes sont automatiques. Lorsque l'incident survient, personne ne sait immédiatement qui peut couper l'accès sans endommager la ligne.
Un exercice annuel très simple révèle ces écarts. On choisit une machine critique et l'on vérifie ses connexions, ses comptes, ses sauvegardes, ses contrats et son redémarrage hors ligne. Puis on simule la compromission du poste de maintenance. Si l'équipe ne peut pas identifier rapidement les flux à bloquer et la personne habilitée à décider, la sécurité réelle est inférieure à la sécurité déclarée. C'est précisément ce décalage qu'un projet IoT doit traiter avant sa mise en production.