Les attaques sur les systèmes industriels ne sont plus l'exception réservée aux États-nations et aux infrastructures hyperprotégées. En 2026, des groupes ransomware que tout le monde connaît — Qilin, BlackCat, LockBit 4.0 — s'attaquent méthodiquement aux environnements OT parce qu'ils ont compris quelque chose que beaucoup d'opérateurs refusent encore d'admettre : la convergence IT/OT a ouvert un angle mort que personne ne surveille correctement.

Ce que "convergence IT/OT" signifie vraiment dans un contexte d'attaque

Quand on parle de convergence IT/OT dans les réunions de direction, on parle de productivité, d'efficacité opérationnelle, de maintenance prédictive alimentée par des données temps réel. Ce sont de bons arguments. Mais cette convergence a une conséquence concrète qui n'est pas toujours nommée clairement : des systèmes qui n'ont jamais été conçus pour être connectés à un réseau IP — des automates programmables datant des années 2000, des HMI sous Windows XP, des SCADA fonctionnant sur des protocoles industriels sans authentification — sont désormais accessibles depuis des réseaux qui communiquent avec Internet.

Ce n'est pas une hypothèse. Shodan indexe en permanence des milliers de systèmes SCADA, HMI et PLC exposés directement sur Internet, parfois avec des interfaces web en clair, parfois avec des credentials par défaut jamais changés. En 2025, Censys a compté 18 400 interfaces HMI industrielles directement accessibles depuis Internet aux États-Unis uniquement. En France, l'ANSSI a documenté des cas similaires dans ses rapports annuels sur la cybermenace. Ce n'est pas un risque théorique : c'est une réalité observable en quelques minutes par n'importe quel acteur malveillant.

Le problème n'est pas simplement l'exposition directe sur Internet — beaucoup d'opérateurs ont résolu ce cas évident. Le problème plus insidieux, c'est la segmentation incomplète entre les réseaux IT (bureautique, ERP, messagerie) et OT (contrôle industriel). Une segmentation qui "existait sur le papier" mais qui a été compromise au fil du temps par des exceptions nécessaires : le technicien de maintenance qui accède à distance au SCADA depuis son PC bureautique, la passerelle IoT qui envoie des données de capteurs vers le cloud, l'antivirus déployé sur les postes SCADA qui communique avec ses serveurs de mise à jour en traversant la frontière IT/OT.

Chacune de ces exceptions est raisonnable prise isolément. Leur accumulation crée un réseau OT qui n'est plus réellement isolé — mais qui est traité comme s'il l'était. C'est l'angle mort. Et c'est précisément là qu'un attaquant va chercher son chemin.

Comment les groupes ransomware ont appris à exploiter l'OT

Il y a cinq ans, cibler un environnement industriel nécessitait des compétences très spécifiques : connaissance des protocoles industriels (Modbus, DNP3, EtherNet/IP, Profinet), compréhension des logiciels SCADA (Ignition, iFIX, WinCC, AVEVA), capacité à analyser des processus physiques pour maximiser l'impact sans déclencher immédiatement des alertes. Ces compétences étaient rares et cantonnées à des acteurs étatiques ou à des groupes très spécialisés comme Sandworm (APT44) ou XENOTIME.

En 2026, la barrière à l'entrée a considérablement baissé, pour plusieurs raisons cumulatives.

Premièrement, la convergence elle-même. Dès lors qu'un réseau OT peut être atteint depuis un réseau IT compromis, un attaquant ransomware standard peut atteindre les systèmes industriels avec ses outils habituels. L'exploitation de failles IT classiques — phishing, VPN vulnérable, credentials volés via infostealer — suffit pour entrer dans le réseau IT, puis progresser vers l'OT via les passerelles mal segmentées. Pas besoin de spécialisation OT pour le mouvement latéral initial.

Deuxièmement, la documentation est publique. Les protocoles industriels sont ouverts et documentés. Les manuels des automates Siemens, Rockwell, Schneider Electric sont téléchargeables librement. Les CVE affectant les logiciels SCADA sont publiées sur NVD/NIST comme n'importe quelle autre vulnérabilité logicielle. MITRE ATT&CK for ICS documente l'ensemble des tactiques, techniques et procédures (TTP) spécifiques aux environnements industriels. Ce savoir, longtemps confiné à des cercles spécialisés, est désormais accessible à des acteurs beaucoup moins sophistiqués.

Troisièmement, les outils existent. Des scripts Nmap NSE pour les protocoles industriels permettent de cartographier des environnements OT sans expertise approfondie. Des frameworks comme PLCscan ou Redpoint automatisent la reconnaissance sur les réseaux industriels. Sur les forums cybercriminels fermés, des courtiers spécialisés proposent des "accès initiaux OT" à la vente — des accès VPN ou SCADA déjà compromis, prêts à être exploités par un groupe ransomware qui achète l'accès sans avoir eu à l'obtenir lui-même.

Quatrièmement, l'impact est maximal. Chiffrer des fichiers bureautiques est perturbant mais gérable. Bloquer une ligne de production, une station de traitement des eaux, un réseau de distribution d'énergie ou un système de contrôle ferroviaire, c'est une tout autre pression. Les opérateurs d'infrastructures critiques ont souvent peu d'alternatives au paiement quand leur production physique est à l'arrêt et que leurs marges de tolérance à l'interruption se comptent en heures. C'est précisément pourquoi ils sont des cibles de plus en plus attractives pour les acteurs ransomware raisonnant en termes de retour sur investissement criminel.

Les cinq erreurs de conception que je vois systématiquement en audit OT

En mission d'audit sur des environnements industriels, je retrouve régulièrement les mêmes patterns d'erreur. Voici les cinq plus fréquents, par ordre de criticité décroissante.

1. La segmentation "firewall only" sans inspection du trafic OT. L'opérateur a bien installé un pare-feu entre les réseaux IT et OT. Mais ce pare-feu est configuré pour autoriser le trafic de certains ports et protocoles industriels sans inspecter le contenu des échanges. Résultat : un flux Modbus TCP autorisé peut transporter des commandes de contrôle malveillantes après qu'un attaquant ait compromis un poste autorisé à traverser la frontière. La segmentation existe sur le papier, mais ne filtre pas ce qui compte vraiment dans un contexte d'attaque.

2. Les comptes de service partagés aux mots de passe figés. C'est une constante dans les environnements industriels : un compte de service "scada_svc" ou "admin_plc" avec un mot de passe défini lors de l'installation il y a dix ans, connu de l'ensemble des techniciens qui ont travaillé sur le site, utilisé par quinze applications différentes. Ce compte est souvent membre du groupe Domain Admins parce que "ça ne marchait pas autrement à l'époque". Compromettre ce seul compte, c'est compromettre la totalité de l'environnement sans aucune élévation de privilège supplémentaire.

3. Les systèmes d'exploitation hors support sur les HMI et postes SCADA. Selon l'enquête annuelle de Dragos sur la sécurité OT publiée au premier semestre 2026, 34 % des postes SCADA et HMI audités fonctionnent encore sous Windows 7 ou Windows Server 2008 R2, pour lesquels Microsoft ne publie plus de correctifs de sécurité depuis 2020. Ces postes ne peuvent souvent pas être mis à jour sans requalification des logiciels SCADA qui tournent dessus — un processus coûteux, long (six à douze mois en moyenne) et qui est systématiquement repoussé au budget suivant. Pendant ce temps, chaque nouvelle CVE Windows s'applique à ces systèmes sans aucun correctif disponible.

4. L'absence totale de surveillance réseau OT. Dans la grande majorité des environnements que j'audite, il n'existe aucune solution de détection d'intrusion ou d'anomalie sur le réseau industriel. Les équipes de sécurité surveillent leurs SIEM alimentés par les logs Windows, les proxies et les EDR — mais les communications réseau OT sont un angle mort complet. Une exfiltration de données via Modbus, une manipulation de PLC via EtherNet/IP, un scan de reconnaissance sur le réseau industriel : tout cela passe sans laisser la moindre trace dans les outils IT classiques. On pourrait avoir une attaque en cours depuis plusieurs semaines sans le voir.

5. Le shadow OT non documenté. Au fil des années, des équipements s'accumulent sur le réseau OT sans être documentés : un routeur 4G installé par un prestataire pour une télémaintenance "temporaire" qui dure depuis trois ans, un PC de programmation connecté au réseau OT pour "dépanner" qui n'a jamais été retiré, un capteur IoT tiers qui envoie des données vers le cloud du fabricant en traversant le réseau industriel. Ces équipements ne figurent pas dans l'inventaire, ne sont pas monitorés, et créent des accès non contrôlés qui constituent autant de vecteurs d'entrée potentiels.

Ce que font concrètement les attaquants une fois dans l'OT

Pour savoir quoi défendre, il faut comprendre ce que font les attaquants une fois qu'ils ont pied dans un environnement industriel. L'analyse des incidents documentés — notamment par Dragos, Claroty, Mandiant et les publications CISA — permet d'identifier plusieurs patterns récurrents selon le niveau de sophistication de l'acteur.

Acteurs ransomware standards (niveau intermédiaire) : l'approche est pragmatique et rapide. Après le mouvement latéral depuis le réseau IT, ils chiffrent les postes SCADA et HMI, effacent les backups de configuration des PLC accessibles depuis le réseau, et posent leur note de rançon. L'impact physique est indirect : l'opérateur ne voit plus rien et ne peut plus contrôler ses équipements, mais les PLC eux-mêmes continuent de fonctionner sur leur logique précédemment chargée. La pression vient de la perte de visibilité et de contrôle, pas d'une modification du processus physique.

Acteurs intermédiaires avec connaissance OT partielle : ils vont plus loin — reconnaissance active du réseau OT (scan Modbus, EtherNet/IP), identification des équipements présents, parfois accès aux logiciels de programmation pour lire la logique d'automate. Leur objectif peut être le sabotage ciblé (arrêt d'une ligne de production spécifique) ou l'exfiltration de données de processus (secrets de fabrication, plans d'équipements). Ces acteurs sont moins nombreux mais leur impact potentiel est bien supérieur.

Acteurs étatiques sophistiqués (APT) : c'est la catégorie documentée dans l'advisory CISA AA26-097A sur les APT iraniens. Ils modifient directement la logique des PLC — ajout de ladder logic qui override les paramètres de sécurité tout en maintenant l'apparence de fonctionnement normal aux opérateurs humains. Ce type d'attaque peut rester indétecté pendant des semaines ou des mois, et son impact peut être physique et potentiellement dangereux pour les personnes présentes sur site ou pour les populations desservies par l'infrastructure compromise.

La frontière entre ces trois niveaux s'estompe progressivement. Des groupes cybercriminels qui opéraient jusqu'ici au niveau intermédiaire intègrent des connaissances OT de plus en plus spécialisées, notamment via le recrutement d'anciens ingénieurs système industriel ou via des collaborations avec des acteurs étatiques dans le cadre de partenariats tacites documentés par des agences de renseignement occidentales.

Que faire concrètement — sans langue de bois

Je vais être direct : la plupart des recommandations génériques sur la sécurité OT que vous lisez dans les guides officiels sont correctes mais trop abstraites pour être actionnables immédiatement. Voici ce que je ferais concrètement, dans l'ordre, si j'arrivais demain matin sur un site industriel sans historique de sécurité OT.

Jour 1 — cartographier ce qui existe réellement. Pas ce qui devrait exister selon les plans réseau datant de 2015. Ce qui existe réellement maintenant. Un scan passif du réseau OT avec un outil comme Claroty, Nozomi Networks ou Dragos Platform donne une image de l'inventaire réel en quelques heures. Invariablement, on découvre des équipements non documentés. Parmi eux, certains sont des vecteurs d'entrée directs vers des réseaux qui se croyaient isolés.

Semaine 1 — identifier et fermer les chemins IT/OT non nécessaires. Lister tous les flux autorisés à traverser la frontière IT/OT, les justifier fonctionnellement, et fermer tout ce qui ne peut pas l'être. Pour chaque flux conservé, implémenter une inspection de contenu (Deep Packet Inspection pour les protocoles industriels) plutôt qu'un simple filtrage par port. Un pare-feu qui laisse passer Modbus TCP sur le port 502 sans inspecter les function codes autorisés n'est pas une segmentation — c'est une illusion de segmentation.

Mois 1 — éliminer les comptes partagés et les credentials par défaut. Inventaire exhaustif de tous les comptes de service OT, rotation des mots de passe, mise en place d'un coffre-fort de secrets (PAM — Privileged Access Management) avec rotation automatique. Pour les équipements anciens qui ne supportent pas le changement de mot de passe ou l'intégration PAM, les isoler dans des segments réseau strictement contrôlés avec des compensations manuelles documentées.

Trimestre 1 — déployer de la visibilité réseau OT. Sans capteurs réseau passifs sur le réseau industriel, vous opérez en aveugle. Les solutions de surveillance OT passives (Nozomi Networks, Claroty, Dragos Platform) fonctionnent par écoute passive du trafic réseau — aucun impact sur les équipements temps-réel, aucune interruption de production possible. Le SOC doit recevoir et traiter les alertes OT avec les mêmes procédures que les alertes IT, ce qui implique de former les analystes aux spécificités des protocoles et comportements industriels.

Sur le moyen terme (six à dix-huit mois), le sujet incontournable est la gestion des systèmes d'exploitation hors support. Il n'existe pas de solution magique : soit on finance la requalification du logiciel SCADA pour le faire fonctionner sur un OS supporté (coûteux, long, mais la seule vraie solution à terme), soit on compense par des contrôles compensatoires stricts — isolation réseau maximale, surveillance renforcée, interdiction d'accès distant, gestion rigoureuse des supports amovibles. La seconde option est un pis-aller acceptable temporairement, pas une stratégie durable.

Le cadre réglementaire force la main — et c'est une bonne chose

NIS2, transposée en droit français depuis octobre 2024, étend les obligations de cybersécurité à un périmètre bien plus large que l'ancienne directive NIS1. Les entités essentielles et importantes des secteurs eau, énergie, transports, santé et industrie manufacturière critique ont désormais des obligations formelles de gestion des risques cyber qui incluent explicitement les environnements OT.

Les obligations NIS2 qui s'appliquent directement aux environnements OT comprennent notamment la gestion des incidents (notification sous 24h pour l'alerte initiale, 72h pour la notification complète, un mois pour le rapport final), la continuité d'activité avec des plans testés, la sécurité de la chaîne d'approvisionnement incluant les fournisseurs d'équipements industriels, et la gestion des vulnérabilités avec des processus formalisés de patch management. Ces exigences sont soumises à contrôle et à des sanctions allant jusqu'à 2 % du chiffre d'affaires mondial pour les entités essentielles — un levier interne considérable pour les RSSI qui peinent à obtenir des budgets OT.

DORA, applicable depuis janvier 2025 pour le secteur financier, inclut des dispositions similaires pour les systèmes opérationnels critiques, y compris les composants OT des plateformes de trading haute fréquence ou des centres de traitement de données financières. Et au niveau américain, les règles de la SEC sur la divulgation des incidents cyber (en vigueur depuis 2024) imposent une transparence accrue sur les incidents OT affectant les infrastructures matérielles des entreprises cotées.

Ces cadres réglementaires sont utiles non pas principalement parce qu'ils sanctionnent les manquements, mais parce qu'ils donnent aux RSSI et aux responsables OT un levier interne pour obtenir les budgets et les arbitrages nécessaires. "Nous sommes en non-conformité NIS2 sur ces points précis et nous nous exposons à une sanction de X euros" est un argument qui passe en comité de direction là où "nous avons un risque cyber sur l'OT" peut rester dans le vague et être systématiquement repoussé.

Les six à douze prochains mois vont être déterminants

Plusieurs signaux convergent pour indiquer que la pression sur les environnements OT va s'intensifier dans les prochains mois. L'incident du Minnesota sur les systèmes d'eau (juillet 2026), les APT iraniens documentés ciblant des PLC d'infrastructures critiques (advisory CISA AA26-097A d'avril 2026), les capacités OT croissantes des groupes ransomware affiliés à des États — tous ces éléments dessinent un paysage de menace en escalation rapide.

En parallèle, deux tendances technologiques amplifient la surface d'attaque. D'abord, la généralisation des capteurs IIoT (Industrial Internet of Things) qui connectent des équipements de terrain au cloud pour la maintenance prédictive ou la supervision distante — chaque capteur IIoT est potentiellement un point d'entrée dans le réseau OT. Ensuite, l'intégration d'agents IA dans les systèmes de supervision industrielle, qui crée de nouvelles interfaces de programmation et de nouveaux vecteurs d'attaque encore mal compris par les équipes de sécurité OT.

Les opérateurs qui agissent maintenant — inventaire, segmentation effective, visibilité réseau, gestion des identités — auront un avantage défensif significatif sur ceux qui attendent. L'expérience des incidents OT documentés montre que les attaquants n'ont pas besoin de sophistication exceptionnelle quand les défenses de base ne sont pas en place. Les mesures fondamentales bien implémentées éliminent la grande majorité des vecteurs d'attaque observés dans les incidents réels.

Mon avis d'expert

Ce qui me frappe dans les incidents OT que j'analyse, c'est à quel point la plupart auraient pu être évités avec des mesures basiques correctement implémentées — pas avec des technologies de pointe à six chiffres. L'attaque sur les systèmes d'eau du Minnesota, les PLC ciblés par des APT dans l'advisory CISA, les ransomwares dans des usines automobiles européennes : dans la grande majorité des cas, le vecteur d'entrée initial n'est pas une zero-day sophistiquée. C'est un VPN avec des credentials par défaut, un poste SCADA connecté au réseau bureautique, un compte de service avec des droits excessifs et un mot de passe figé depuis dix ans. La convergence IT/OT crée un risque réel — mais c'est l'absence de mesures fondamentales qui le rend catastrophique. Inventaire, segmentation réelle (pas sur le papier), gestion des identités, visibilité réseau : ces quatre piliers, correctement implémentés, éliminent 80 % de la surface d'attaque que j'observe en audit. Commencez par là avant de chercher la solution technologique miracle.

Conclusion

La convergence IT/OT est irréversible — les bénéfices opérationnels sont trop importants pour que les organisations y renoncent. Mais cette convergence impose de revisiter entièrement la posture de sécurité des environnements industriels avec la même rigueur qu'on appliquerait à un environnement IT critique exposé sur Internet. L'époque où "nos automates ne sont pas connectés à Internet" était une défense suffisante est révolue depuis plusieurs années. En 2026, après les incidents documentés aux États-Unis et les alertes CISA et ANSSI répétées, continuer à traiter la sécurité industrielle comme un problème secondaire est une prise de risque assumée — dont les conséquences peuvent dépasser largement le cadre d'une coupure de production et affecter directement des personnes ou des populations.

Besoin d'un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique — périmètre OT, architecture réseau, conformité NIS2 ou posture globale de sécurité industrielle.

Prendre contact