La cybersécurité s’est longtemps concentrée sur l’informatique de gestion : serveurs, postes de travail, messagerie, applications métier. Pendant ce temps, un autre système d’information fonctionnait en silence dans les usines, les stations d’épuration, les réseaux électriques et les entrepôts : celui qui pilote la matière. Ces systèmes, regroupés sous les sigles OT (Operational Technology) et ICS (Industrial Control Systems), ont longtemps été considérés comme hors de portée des attaquants parce qu’isolés. Cette hypothèse ne tient plus.
La convergence entre IT et OT, la connexion croissante des équipements industriels à Internet, la maintenance à distance et l’arrivée de la réglementation NIS2 ont fait entrer l’OT dans le champ de la cybersécurité d’entreprise. Le guide de référence de l’ANSSI sur la cybersécurité des systèmes industriels [1] et la publication NIST SP 800-82 révision 3 [2] cadrent le sujet. Cet article en propose une lecture opérationnelle pour un DSI ou un RSSI qui découvre ce périmètre : ce qu’est réellement l’OT, en quoi il diffère de l’IT, et quelle doctrine appliquer.
Qu’est-ce que l’OT et l’ICS
L’OT désigne l’ensemble des matériels et logiciels qui détectent ou modifient un processus physique par surveillance et commande directes d’équipements. L’ICS en est le sous-ensemble le plus connu : les systèmes de contrôle industriel.
Concrètement, un environnement OT regroupe plusieurs familles d’équipements. Les capteurs et actionneurs mesurent (température, pression, débit) et agissent (ouvrir une vanne, démarrer un moteur). Les automates programmables industriels, appelés API en français ou PLC en anglais, exécutent la logique de commande en temps réel. Les systèmes SCADA (Supervisory Control And Data Acquisition) supervisent et pilotent à distance des sites étendus. Les systèmes numériques de contrôle-commande (SNCC, ou DCS) orchestrent des procédés continus comme une raffinerie. Les interfaces homme-machine (IHM) permettent aux opérateurs d’interagir avec le procédé.
Ces équipements ont trois caractéristiques qui les distinguent radicalement de l’IT. Leur durée de vie se compte en décennies, pas en années : un automate installé il y a vingt ans peut encore piloter une ligne critique. Leur disponibilité est prioritaire au point que l’on hésite à les redémarrer. Et beaucoup ont été conçus à une époque où la sécurité réseau n’était pas une préoccupation : protocoles sans authentification ni chiffrement, mots de passe par défaut, absence de journalisation.
Pourquoi l’OT change la donne de la sécurité
La réponse directe : parce qu’une compromission OT ne menace pas d’abord la donnée, mais la disponibilité du procédé et, dans certains cas, la sécurité physique des personnes et de l’environnement.
En IT, on protège la triade confidentialité, intégrité, disponibilité, souvent dans cet ordre. En OT, l’ordre s’inverse. La disponibilité du procédé passe en premier : arrêter une ligne de production, un réseau de distribution d’eau ou une sous-station électrique a des conséquences immédiates et coûteuses. L’intégrité vient ensuite : une commande falsifiée qui modifie un dosage chimique, une consigne de pression ou une vitesse de rotation peut endommager des équipements ou créer un danger. La confidentialité arrive en dernier, non pas qu’elle soit négligeable, mais parce que le vol d’une consigne de température a rarement le même impact qu’un arrêt de production.
Cette inversion des priorités a des conséquences pratiques. On ne peut pas appliquer les recettes IT telles quelles. Une analyse antivirus intensive peut perturber un automate au timing serré. Un scan de vulnérabilités trop agressif peut faire tomber un équipement industriel fragile. Une coupure réseau de sécurité, réflexe naturel en IT, peut au contraire aggraver la situation en OT si elle prive les opérateurs de la supervision d’un procédé dangereux. La prudence et la connaissance du procédé priment sur l’automatisme des réponses.
Le paysage de la menace industrielle
Les systèmes industriels ne sont plus des cibles théoriques. L’ENISA, dans son panorama annuel des menaces [3], documente une pression croissante sur les secteurs qui exploitent de l’OT, en particulier l’énergie, l’eau, le transport et la production manufacturière. Les motivations vont de l’appât du gain (ransomware qui paralyse la production) à la déstabilisation géopolitique visant des infrastructures critiques.
Trois grandes catégories de menaces se dessinent. La première, et de loin la plus fréquente, est le ransomware qui touche l’OT par ricochet : l’attaque démarre sur l’IT, se propage, et l’exploitant arrête volontairement sa production OT par précaution, faute de pouvoir garantir l’intégrité des commandes. Le procédé n’est même pas directement compromis, mais l’usine s’arrête quand même. La deuxième catégorie regroupe les attaques ciblées sur l’OT lui-même, plus rares mais plus graves, qui manipulent directement automates et systèmes de sécurité. La troisième tient aux erreurs et négligences : une clé USB infectée branchée sur une IHM, un accès de maintenance à distance mal sécurisé, un intégrateur dont le poste est compromis.
Pour structurer l’analyse de ces attaques, MITRE publie une matrice ATT&CK dédiée aux systèmes industriels [4]. Elle décrit les tactiques et techniques propres à l’OT : accès initial par les canaux de maintenance, découverte des équipements industriels, manipulation du procédé, inhibition des fonctions de sécurité. Cette matrice est le pendant OT de la matrice ATT&CK entreprise bien connue des équipes de détection, et sert de langage commun pour cartographier les scénarios d’attaque industriels.
À jour au juillet 2026, la CISA américaine maintient un flux d’alertes de sécurité spécifiquement dédié aux produits ICS [5], qui recense en continu les vulnérabilités des équipements des grands fabricants d’automates et de SCADA. Ce volume d’avis, publié plusieurs fois par semaine, illustre à lui seul que la surface d’exposition industrielle est vaste et activement scrutée.
Cartographier avant de sécuriser
On ne protège pas ce que l’on ne connaît pas, et l’inventaire OT est souvent le point le plus faible. Beaucoup d’exploitants découvrent, en démarrant une démarche de sécurité industrielle, qu’ils ignorent une partie des équipements connectés à leur réseau : automates oubliés, passerelles installées par un intégrateur, objets connectés ajoutés au fil des projets.
La cartographie OT poursuit trois objectifs. Recenser les actifs : quels équipements, quelles versions de firmware, quels protocoles, quelles interconnexions. Identifier les flux : qui communique avec qui, dans quel sens, pour quel usage légitime. Évaluer l’exposition : quels équipements sont joignables depuis l’IT, depuis Internet, depuis un accès de maintenance distant.
La difficulté tient à la fragilité des équipements. Un scan actif classique, tel qu’on le pratique en IT, peut perturber un automate. On privilégie donc des méthodes de découverte passives, qui observent le trafic réseau sans interroger directement les équipements, complétées par un travail documentaire avec les équipes automatisme et les intégrateurs. Cette approche rejoint la logique des outils de détection réseau : là où l’IT déploie des agents sur les postes, l’OT s’observe surtout par le réseau, comme le fait un NDR sur les équipements sans agent. Voir à ce sujet le guide NDR (Network Detection and Response) : /cybersecurite/ndr-network-detection-response-entreprise/.
Segmenter selon Purdue et IEC 62443
Une fois la cartographie établie, la segmentation est la mesure structurante. La réponse directe : isoler l’OT de l’IT, et isoler les niveaux OT entre eux, de manière à ce qu’une compromission d’un niveau ne se propage pas aux niveaux inférieurs plus critiques.
Le cadre de référence est le modèle Purdue, une architecture qui découpe l’environnement industriel en niveaux. Au plus bas, le procédé physique et ses capteurs et actionneurs. Au-dessus, les automates et systèmes de commande. Puis la supervision SCADA et le contrôle de site. Enfin, au sommet, l’informatique de gestion et les systèmes IT. Entre les niveaux OT et l’IT, une zone tampon, souvent appelée DMZ industrielle, filtre les échanges : aucun flux direct entre le poste bureautique d’un opérateur et l’automate qui pilote une turbine.
La norme IEC 62443 formalise cette logique avec les notions de zones et de conduits. Une zone regroupe des actifs de même niveau de confiance. Un conduit est un flux autorisé et contrôlé entre deux zones. Tout ce qui n’est pas explicitement autorisé est interdit. La norme définit aussi des niveaux de sécurité, du plus basique au plus exigeant, et répartit les responsabilités entre l’exploitant, l’intégrateur qui assemble le système et le fabricant qui conçoit les composants [6]. C’est aujourd’hui le référentiel international de facto pour la cybersécurité industrielle.
En pratique, la segmentation OT combine plusieurs mécanismes. Des pare-feu industriels entre les zones, capables de comprendre les protocoles OT. Une DMZ industrielle qui héberge les serveurs d’échange (historian, serveurs de patch) pour éviter tout flux direct IT vers OT. Des diodes réseau, ou passerelles unidirectionnelles, quand on veut remonter des données du procédé vers l’IT sans jamais permettre de commande en sens inverse. Cette approche de séparation stricte prolonge la logique de segmentation réseau que l’on retrouve dans les architectures modernes de type SASE : /infrastructure/sase-sd-wan-reseau-entreprise/.
Gérer les vulnérabilités et les correctifs autrement
La gestion des correctifs en OT ne ressemble pas à celle de l’IT. La réponse directe : on priorise par la criticité du procédé et l’exposition réelle, pas par la seule note CVSS, et l’on applique des mesures compensatoires quand le correctif est impossible.
Plusieurs contraintes expliquent cette différence. Un automate ne se redémarre pas sans arrêter la production, ce qui impose de planifier les mises à jour lors de fenêtres d’arrêt qui peuvent n’arriver qu’une fois par an. Certains équipements ne reçoivent plus de correctifs du fabricant, faute de support. D’autres ne peuvent être mis à jour qu’avec l’accord de l’intégrateur, sous peine de perdre la garantie ou la certification de sûreté du procédé.
La méthode consiste donc à qualifier chaque vulnérabilité dans son contexte. Une CVE critique sur un équipement non exposé, enfoui au cœur d’une zone segmentée, ne présente pas le même risque que la même CVE sur une passerelle joignable depuis l’IT. On croise donc la gravité technique, l’exposition réelle et la criticité du procédé pour décider. Cette logique de priorisation par le risque plutôt que par la seule note prolonge celle décrite pour l’IT : voir la gestion des vulnérabilités du CVE au patch en entreprise : /cybersecurite/gestion-vulnerabilites-cve-cvss-entreprise/.
Quand le correctif n’est pas applicable, on ne reste pas sans rien faire. Les mesures compensatoires réduisent l’exposition à défaut de corriger la faille : renforcer la segmentation autour de l’équipement vulnérable, restreindre et surveiller ses accès, appliquer un filtrage réseau qui bloque l’exploitation de la faille (virtual patching), désactiver les services inutiles. Le principe reste constant : à défaut de supprimer la vulnérabilité, on rend son exploitation impossible ou détectable.
Surveiller un environnement à trafic stable
La détection en OT présente un avantage inattendu par rapport à l’IT : le trafic industriel est largement prévisible. Un automate parle aux mêmes équipements, avec les mêmes protocoles, à des fréquences régulières, pour exécuter un procédé qui ne varie guère. Cette stabilité rend les écarts d’autant plus visibles.
La surveillance OT s’appuie donc principalement sur la modélisation du comportement normal. On établit une base de référence des communications légitimes, puis on alerte sur les écarts : une nouvelle connexion vers un équipement jamais contacté, un protocole inhabituel, un ordre de commande émis par une source inattendue, un scan interne. Ces signaux, noyés dans le bruit d’un réseau IT, ressortent nettement dans le calme relatif d’un réseau industriel.
Les journaux et alertes OT doivent remonter vers la supervision de sécurité de l’entreprise pour être corrélés avec le reste. C’est le rôle d’un SIEM, qui centralise les événements de toutes les sources pour détecter les scénarios d’attaque qui traversent la frontière IT-OT. Une compromission qui démarre sur l’IT et cherche à atteindre l’OT laisse des traces des deux côtés : c’est la corrélation qui révèle le mouvement. Sur la centralisation des journaux, voir le guide SIEM et journalisation : /cybersecurite/siem-journalisation-detection-logs-entreprise/. La surveillance ne se limite d’ailleurs pas au réseau : les accès physiques aux armoires d’automates, les branchements de supports amovibles sur les IHM et les connexions de maintenance à distance méritent une attention particulière, car ils constituent des vecteurs d’entrée fréquents dans un environnement autrement isolé.
Sécuriser les accès de maintenance à distance
La maintenance à distance est à la fois indispensable et dangereuse. Les fabricants et intégrateurs interviennent souvent à distance pour diagnostiquer, mettre à jour ou dépanner. Ces accès, s’ils sont mal maîtrisés, deviennent la porte d’entrée idéale : un tiers dont le poste est compromis ouvre un chemin direct vers le cœur du procédé.
La doctrine tient en quelques règles. Aucun accès de maintenance permanent : les connexions distantes ne sont ouvertes qu’à la demande, pour une intervention identifiée, et refermées ensuite. Une authentification forte systématique, avec traçabilité de qui se connecte, quand et pour quoi. Un passage par un point de contrôle unique, souvent un bastion, qui enregistre les sessions et applique le moindre privilège. Et une supervision des interventions elles-mêmes : un accès de maintenance qui exécute des commandes inattendues doit déclencher une alerte. Ces principes rejoignent la gestion des accès à privilèges décrite pour l’IT, transposée à un contexte où le tiers intervenant n’est pas un salarié mais un fournisseur.
Préparer une réponse à incident spécifique
La réponse à incident OT ne se décalque pas de l’IT. La réponse directe : on ne peut pas tout éteindre ni tout isoler sans risquer d’aggraver la situation, et la décision doit associer les équipes automatisme et sûreté de fonctionnement, pas seulement la sécurité informatique.
En IT, isoler une machine compromise est un réflexe sans danger. En OT, couper brutalement un équipement peut interrompre un procédé en cours de manière dangereuse : arrêter une pompe au mauvais moment, figer une vanne, priver les opérateurs de la supervision d’un système sous pression. Chaque décision de confinement doit être arbitrée en fonction de l’état du procédé et de ses conséquences physiques. Cela suppose un plan de réponse écrit spécifiquement pour l’OT, connu des équipes d’exploitation, et testé par des exercices qui associent automaticiens, responsables sûreté et RSSI.
Cette préparation s’inscrit dans la continuité du plan de gestion de crise cyber de l’entreprise, mais avec des scénarios propres : arrêt d’urgence maîtrisé, bascule en mode dégradé manuel, restauration d’automates depuis des configurations de référence conservées hors ligne. Sur la logique générale de préparation, voir la gestion de crise cyber, PCA et PRA en entreprise : /cybersecurite/gestion-crise-cyber-pca-pra-entreprise/. La conservation de sauvegardes des configurations d’automates et des programmes, testées et stockées hors ligne, est l’équivalent OT des sauvegardes immuables en IT : sans elles, la reconstruction d’un procédé compromis peut prendre des semaines.
Ce que NIS2 impose au monde industriel
La réglementation a rattrapé l’OT. La directive européenne NIS2 [7] étend les obligations de cybersécurité à de nombreux secteurs qui exploitent des systèmes industriels : énergie, eau potable et assainissement, transports, production et distribution alimentaire, fabrication de produits critiques, gestion des déchets, entre autres.
Pour ces entités, les attentes deviennent explicites. Une gestion des risques qui couvre l’ensemble des systèmes, OT compris. Une cartographie des actifs et des dépendances. Des mesures de sécurité proportionnées au risque : segmentation, contrôle des accès, détection, sauvegarde, gestion des correctifs. Une capacité à notifier les incidents significatifs dans des délais courts. Et une implication de la direction, qui devient responsable de la conformité. Ce qui relevait hier de la bonne pratique devient une obligation, adossée à un régime de sanctions.
Concrètement, un exploitant industriel concerné par NIS2 ne peut plus traiter l’OT comme un angle mort. La démarche décrite dans cet article, cartographier, segmenter, surveiller, gérer les vulnérabilités et préparer la réponse, correspond précisément aux attentes réglementaires. Sur le périmètre et les obligations générales de la directive, voir le guide complet NIS2 pour l’entreprise : /cybersecurite/nis2-entreprise-guide-2026/.
À retenir
La sécurité OT et ICS protège les systèmes qui pilotent le monde physique : automates, SCADA, capteurs et actionneurs. Contrairement à l’IT, un incident n’y menace pas d’abord la donnée mais la disponibilité de la production et parfois la sécurité des personnes, ce qui inverse les priorités et interdit de transposer les recettes IT telles quelles. La doctrine, cadrée par l’ANSSI, le NIST SP 800-82 et la norme IEC 62443, tient en quelques piliers : cartographier des actifs souvent mal connus, segmenter selon le modèle Purdue par des zones et conduits, gérer les vulnérabilités par la criticité du procédé plutôt que la seule CVSS, surveiller un trafic dont la stabilité facilite la détection, sécuriser strictement les accès de maintenance et préparer une réponse à incident où l’on ne peut pas tout éteindre. Avec NIS2, cette discipline n’est plus optionnelle pour les exploitants industriels : l’OT est entré dans le champ réglementaire de la cybersécurité.
Sources
[1] ANSSI, La cybersécurité des systèmes industriels. https://cyber.gouv.fr/publications/la-cybersecurite-des-systemes-industriels [2] NIST, SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security. https://csrc.nist.gov/pubs/sp/800/82/r3/final [3] ENISA, Threat Landscape. https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024 [4] MITRE, ATT&CK for ICS Matrix. https://attack.mitre.org/matrices/ics/ [5] CISA, Cybersecurity Advisories (ICS). https://www.cisa.gov/news-events/cybersecurity-advisories [6] IEC, Understanding IEC 62443. https://www.iec.ch/blog/understanding-iec-62443 [7] Union européenne, Directive (UE) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj