Ce chiffre révèle un changement profond : les sauvegardes, souvent considérées dernier recours, sont désormais des cibles à part entière. Face à une cyberattaque majeure, les plans de continuité traditionnels ne suffisent plus. En effet, ils ne fonctionnent pas en milieu industriel, notamment via la nature des enjeux : sécurité physique, impact environnemental, production continue, etc.

C’est pourquoi les organisations les plus avancées construisent aujourd’hui des programmes de cyber-résilience OT dédiés, conçus pour gérer la crise face à une perturbation ou un incident majeur, assurer la continuité des activités essentielles et restaurer les éléments altérés.

La Directive NIS2, notamment le référentiel RECYF de l’ANSSI, vient supporter cet effort en intégrant des obligations claires sur la cyber-résilience pour les entités essentielles et importantes.

Par où commencer, quels obstacles anticiper, et comment bâtir une résilience OT à la hauteur des exigences de NIS 2 ?

NIS 2 et la résilience industrielle : exigences et état des lieux

Ce que NIS 2 impose concrètement

L’intégration croissante de l’IT dans les processus industriels (MES, ERP connectés aux lignes, abandon progressif des processus papier) a profondément modifié la réalité opérationnelle des usines. Les dépendances sont nombreuses, souvent mal cartographiées, et une défaillance IT peut bloquer l’OT même lorsque les équipements physiques sont intacts. A ce titre, la capacité des milieux industriels à être plus résilient aux attaques cyber apparaît comme un chantier prioritaire.

La directive NIS 2, élargit significativement le périmètre des entités soumises par rapport à sa version antérieure, et vise à adresser parmi ses priorités, la cyber-résilience des entités. Deux objectifs sont particulièrement structurants en matière de résilience :

Etat des lieux sur la cyber-résilience en milieu industriel 

Si les organisations industrielles ont progressivement investi dans la sécurisation de leurs environnements OT, la maturité sur la continuité et la reprise reste insuffisante pour répondre aux exigences de NIS 2. Plusieurs lacunes sont systématiquement observées :

• Manque de connaissance formelle des assets et de leur criticité :
  • Cartographie des actifs souvent non formalisé ou incomplet
  • BIA absent ou partiellement réalisé
• Les PCA métiers existants sont conçus pour des scénarios physiques ou IT traditionnels mais pas pour des enjeux cyber OT
• Les capacités de continuité et de reprise ne sont pas testées : les organisations se limitent à des tests unitaires ou des restaurations de VM isolées, sans jamais couvrir une ligne de production complète ou un scénario bout en bout. Plusieurs facteurs expliquent cette situation :

Sans maturation sur ces sujets, un incident cyber peut se traduire par des semaines d’arrêt. 

Par où commencer pour bâtir une résilience OT à la hauteur de NIS 2 ?

Fondations et prérequis

Avant de construire un plan de reprise ou de tester quoi que ce soit, il faut établir les fondations : définir ce qu’on protège, définir comment l’activité se maintient en cas d’incident, et déterminer ce qui doit être sauvegardé. 

Quels acteurs intégrer au démarrage ? 

Un programme de cyber-résilience piloté uniquement par les équipes Cyber ou IT risque de ne pas refléter les réalités opérationnelles et de ne pas répondre aux véritables enjeux métiers : sans la participation et compréhension de l’enjeu par les opérateurs, le chantier aura du mal à avancer. Cela passe par une phase d’évangélisation : expliquer concrètement ce qu’un incident coûte à leur activité, et identifier dès le départ les bons interlocuteurs dans chaque direction.

Quels périmètres métiers prioriser ? 

L’objectif pour la cyber-résilience n’est pas de produire un inventaire exhaustif du parc industriel. Il s’agit d’identifier les actifs qui portent les processus critiques pour l’activité. Le point de départ est de créer un PCA à l’échelle de l’entreprise, puis un BIA à l’échelle des sites qui permettront de définir les DMIA et PRD par processus critique. 

La collecte s’appuie sur une approche hybride : 

• Entretiens opérationnels avec les équipes terrain 
• Exploitation des documents d’architecture et des configurations afin d’identifier les dépendances supplémentaires 

Les sondes peuvent apparaître comme un bon choix mais elles ne détectent que les assets qui émettent du trafic. Un équipement qui ne communique pas à un instant T disparaît de la cartographie. En OT, bon nombre d’équipements sont configurés une fois puis fonctionnent en autonomie, ce qui limite fortement leur visibilité réseau. De plus, certains systèmes sont totalement standalone et n’émettent aucun trafic, alors même qu’ils peuvent être critiques pour l’activité. Se reposer uniquement sur des sondes donne donc une vision partielle et parfois trompeuse de l’environnement, avec un risque réel de passer à côté d’équipements essentiels. 

Quelles données sauvegarder et comment ? 

La cartographie permet de recenser et prioriser les systèmes à protéger en fonction de leur criticité validée avec les équipes métiers. Ensuite, pour chaque asset, on définit le contenu minimum à sauvegarder et leur fréquence : 

Indépendamment de la fréquence planifiée, il est recommandé d’effectuer une sauvegarde après tout changement majeur afin de limiter la perte de configuration en cas d’incident. 

Plusieurs principes structurent ensuite la stratégie de sécurisation des sauvegardes : 

• Redondance, chiffrement, et immuabilité des sauvegardes 
• Air-gapping pour les environnements les plus sensibles 
• Politique de rétention différenciée par type d’actif
• Clauses contractuelles encadrant les obligations de sauvegarde des tiers 

Les infrastructures de sauvegarde ne sont pas de simples supports techniques : elles constituent elles-mêmes des cibles sensibles et doivent être traitées comme des systèmes critiques, avec le niveau de protection approprié. 

Comment assurer la continuité en cas d’incident ? 

La première étape du PCA consiste à identifier les scénarios de crise à adresser, car ceux-ci déterminent les interlocuteurs à impliquer, les procédures à définir et les modes de fonctionnement à adopter. Ce travail est mené conjointement avec les équipes HSE, métiers, cybersécurité, risk management. 

Pour chaque processus critique identifié, il convient ensuite de définir, avec les équipes production, maintenance, et qualité : 

Validation et reprise 

Comment valider le fonctionnement de la reprise ? 

Un PRA non testé est un PRA théorique.

Les tests peuvent être effectués, pour limiter l’impact sur la production : 

• Sur une infrastructure globale de test, mutualisée entre les différents sites, 
• Sur une ligne de test, 
• Pendant les fenêtres de maintenance, 
• En utilisant des jumeaux numériques. 

Ces tests doivent être validé au minimum une fois par an. 

La progression est graduelle :

Chaque test est documenté : DMIA et PRD réels mesurés, comparaison avec les cibles théoriques, écarts identifiés, actions correctives planifiées. 

Les objectifs de DMIA/PRD peuvent ne pas être réalistes dans le contexte d’une crise cyber majeure. Ils ne doivent donc pas constituer un facteur bloquant pour la réalisation des tests ni pour la validation des principes de cyber‑résilience au sens de NIS2. 

Comment reconstruire après un incident ? 

Le PRA définit comment redémarrer les systèmes critiques après un sinistre. Il couvre plusieurs scénarios : panne matérielle, ransomware, perte du réseau OT. 

Pour chaque scénario, il est nécessaire de : 

• Définir le séquençage de redémarrage selon les dépendances entre systèmes 
• Documenter la chaîne d’escalade et de décision 
• Définir clairement l’implication des tiers : conditions d’intervention, modalités de coordination, et exigences préalables de sécurisation (éradication du ransomware, environnement contrôlé type « salle blanche », reprise progressive avec cloisonnement) 

Deux logiques de reprise doivent être distinguées : la perte de disponibilité (bascule vers des ressources de secours) et la perte d’intégrité (reconstruction complète depuis les sauvegardes). Les procédures ne sont pas les mêmes et doivent être traitées séparément. 

De la résilience des assets à la gestion de crise 

Ce que nous avons décrit ici constitue le socle minimum pour enclencher une démarche de reprise en environnement OT. Mais NIS 2 exige d’aller plus loin : c’est l’ensemble du SI qui est concerné, et la question n’est plus seulement technique, c’est celle d’un programme structuré, piloté dans la durée, capable de prouver la conformité et la résilience des assets. 

Cela implique de déployer cette démarche de façon pragmatique, en tenant compte des risques cyber, des contraintes réglementaires et des moyens disponibles. Cela implique aussi de ne pas en faire un projet ponctuel : la cyber-résilience doit être intégrée par design, avec des chantiers suivis, des preuves documentées, et des équipes métier embarquées sur le long terme. 

Enfin, le marché propose aujourd’hui des solutions dédiées à la résilience OT. Une veille active sur ce sujet peut s’avérer précieuse pour identifier les outils adaptés. 

Par ailleurs, la résilience ne s’arrête pas à la reprise technique, elle intègre aussi la gestion de crise : Repenser sa stratégie de préparation à la gestion de crise d’origine cyber – RiskInsight

Glossaire