Points clés
- La continuité d'activité autour des systèmes sensibles ne peut pas être assumée : elle doit être construite, testée et validée.
- Un plan de continuité non testé est un plan fictif qui ne résistera pas au premier incident réel.
- L'incendie du datacenter OVH à Strasbourg en 2021 a révélé que des milliers d'organisations n'avaient pas de plan de continuité activable pour leurs systèmes hébergés en cloud.
- NatWest a subi une panne informatique majeure en 2012 privant des millions de clients d'accès à leurs comptes, révélant l'absence de plan de bascule opérationnel testé.
- ISO 22301 définit le cycle complet de gestion de la continuité incluant l'analyse d'impact, les stratégies de continuité, les plans et les tests.
La continuité d'activité des systèmes critiques est l'un des domaines où l'écart entre la documentation et la réalité opérationnelle est le plus marqué. Les organisations disposent généralement de plans de reprise d'activité (PRA) et de plans de continuité d'activité (PCA). Ce que révèlent les incidents majeurs, c'est que ces plans sont souvent obsolètes, non testés, ou basés sur des hypothèses qui ne correspondent pas à la situation réelle d'une crise.
Pour la direction, l'enjeu n'est pas d'avoir un document de continuité mais de disposer d'une capacité de continuité réelle, régulièrement vérifiée. Cette distinction — entre le plan documenté et la capacité opérationnelle testée — est au cœur des exigences de DORA et ISO 22301.
Les éléments d'un dispositif de continuité crédible
Un dispositif de continuité crédible pour les systèmes critiques repose sur cinq piliers. Le premier est l'analyse d'impact formalisée (BIA) avec des RTO et RPO validés par la direction. Le deuxième est une stratégie de continuité documentée pour chaque système critique : basculement sur infrastructure redondante, mode dégradé défini, procédures manuelles de substitution. Le troisième est la documentation des procédures d'activation, accessible sans dépendance aux systèmes compromis. Le quatrième est le test régulier — au minimum annuel pour les systèmes de plus haute criticité. Le cinquième est la revue post-test avec identification des lacunes et suivi de leur traitement.
ISO 22301 structure ce cycle en quatre phases : Plan, Do, Check, Act. DORA ajoute une exigence de remontée vers la direction des résultats de tests avec un suivi formel des plans de remédiation.
L'OVH Strasbourg comme révélateur
L'incendie du datacenter OVH SBG2 de Strasbourg, survenu en mars 2021, a détruit l'infrastructure de plusieurs milliers de clients. Cet incident a révélé une lacune systémique : de nombreuses organisations avaient placé leurs systèmes critiques dans ce datacenter sans souscrire aux offres de sauvegarde ou de réplication OVH, et sans plan de continuité externalisant les backups. Lorsque l'infrastructure a brûlé, leurs données l'ont suivie.
Cet incident a également mis en évidence une incompréhension fréquente du modèle de responsabilité partagée en cloud (shared responsibility model) : le prestataire cloud protège l'infrastructure physique, mais c'est le client qui est responsable de la résilience des données et applications qu'il héberge.
Les tests de continuité comme obligation réglementaire
DORA impose aux entités financières de tester leurs plans de continuité ICT au minimum une fois par an pour les scénarios considérés les plus impactants. Les résultats de ces tests doivent être documentés, présentés à la direction et aux organes de surveillance, et les lacunes identifiées doivent faire l'objet d'un plan d'action traçable. La Banque Centrale Européenne peut demander à consulter ces documents lors de ses inspections.
CNA Financial, l'une des plus grandes compagnies d'assurance américaines, a été frappée par Phoenix CryptoLocker, un ransomware qui a chiffré 15 000 appareils dont ceux d'employés en télétravail. CNA a payé 40 millions de dollars de rançon. L'investigation a révélé que les sauvegardes de plusieurs systèmes critiques avaient également été chiffrées, en raison d'une architecture de sauvegarde non segmentée. Le plan de continuité n'avait pas anticipé l'indisponibilité simultanée des systèmes et de leurs sauvegardes.
Une mise à jour défectueuse du logiciel CA-7 a bloqué les traitements de nuit de NatWest, empêchant 6,5 millions de clients d'accéder à leurs comptes pendant plusieurs jours et bloquant des millions de paiements. La FSA (Financial Services Authority) a infligé à Royal Bank of Scotland Group (dont NatWest fait partie) une amende de 56 millions de livres sterling. L'enquête a établi que le plan de reprise n'avait pas été testé dans le scénario de défaillance qui s'est produit, et que les procédures manuelles de substitution n'étaient pas opérationnelles.
La catastrophe de Fukushima Daiichi a exposé les lacunes des plans de continuité pour les infrastructures critiques face à des scénarios de cascade : tremblement de terre, tsunami, et défaillance des systèmes de refroidissement de secours. Les générateurs diesel de secours, censés assurer la continuité des systèmes de contrôle, se trouvaient dans des zones inondables non identifiées dans les plans de risque. Cet incident a conduit à une refonte mondiale des exigences de résilience des infrastructures critiques, intégrée dans les révisions IAEA INSAG et NIST SP 800-82.