- Maersk (2017) : l\'attaque NotPetya a paralysé l\'organisation en quelques heures malgré l\'existence de plans de continuité — ces plans n\'avaient pas anticipé une destruction simultanée de l\'ensemble des systèmes, révélant leur caractère partiel.
- Un plan de continuité qui n\'a jamais été testé en conditions réelles est une hypothèse, pas une garantie — les organisations découvrent lors des crises que leurs plans supposent des ressources ou des communications qui ne sont pas disponibles.
- La continuité d\'activité théorique se caractérise par des délais de reprise irréalistes, des dépendances non cartographiées et des responsabilités qui ne sont pas exercées hors des conditions nominales.
- Les RTO (Recovery Time Objective) et RPO (Recovery Point Objective) affichés dans les plans sont rarement atteints lors des tests réels — l\'écart moyen est de deux à cinq fois le délai planifié.
- Le budget alloué à la continuité d\'activité est souvent insuffisant pour couvrir les scénarios les plus sévères — ceux que le plan mentionne mais pour lesquels les ressources de reprise n\'ont pas été provisionnées.
- La dépendance non documentée aux systèmes IT est la première source d\'écart entre le plan et la réalité — des processus supposés manualisables se révèlent entièrement dépendants de systèmes lors d\'un incident réel.
Presque toutes les organisations d\'une certaine taille disposent d\'un plan de continuité d\'activité (PCA) ou d\'un plan de reprise d\'activité (PRA). Ces documents existent, ils sont archivés quelque part, et ils satisfont généralement les exigences des auditeurs et des assureurs. Ce qu\'ils ne garantissent pas, c\'est la capacité réelle de l\'organisation à fonctionner lors d\'une crise majeure.
L\'écart entre la continuité d\'activité documentée et la résilience opérationnelle réelle est l\'une des vulnérabilités organisationnelles les plus difficiles à voir en temps normal — et les plus coûteuses à découvrir lors d\'un incident. Cet écart résulte de processus qui n\'ont pas été réellement testés, de dépendances qui n\'ont pas été cartographiées et de ressources qui ont été provisionnées sur le papier mais pas réservées dans la réalité.
Les raisons structurelles du caractère théorique des plans
La première raison est la nature même du processus de planification. Les plans de continuité sont rédigés par des équipes qui connaissent les processus en conditions normales. Ces équipes ont naturellement tendance à supposer que les ressources disponibles en conditions normales seront également disponibles lors d\'une crise — des hypothèses qui sont systématiquement invalidées lors des incidents réels.
La deuxième raison est l\'absence de test régulier en conditions réalistes. Les tests de continuité organisés dans les organisations qui en font sont souvent des exercices partiels — on teste la reprise d\'un système mais pas l\'impact sur les processus métier qui en dépendent, on simule une crise sans restreindre réellement les communications, on exerce les procédures mais sans la pression temporelle d\'une situation réelle. Ces tests validés permettent de cocher une case mais ne révèlent pas les vrais angles morts du plan.
L\'attaque ransomware contre Colonial Pipeline en 2021 a conduit à l\'arrêt du pipeline pendant cinq jours, créant des pénuries de carburant sur la côte est américaine. Colonial Pipeline disposait de plans de continuité, mais ces plans n\'avaient pas anticipé la décision de couper préventivement le pipeline par mesure de précaution — une décision opérationnelle prise en urgence qui a amplifié l\'impact de l\'incident. La reprise a pris beaucoup plus de temps que les RTO initialement documentés, notamment en raison de l\'incertitude sur l\'étendue de la compromission. L\'organisation a payé une rançon de 4,4 millions de dollars, dont une grande partie a pu être récupérée ultérieurement par le FBI, mais le coût de l\'interruption d\'activité et de la gestion de crise a largement dépassé ce montant.
Les hypothèses qui invalident les plans
Les plans de continuité reposent généralement sur un ensemble d\'hypothèses implicites qui ne sont pas valides lors des incidents les plus sévères. L\'hypothèse de disponibilité des ressources humaines clés est la première : lors d\'une crise majeure, les personnes désignées comme responsables dans le plan peuvent être elles-mêmes affectées, indisponibles ou dépassées. L\'hypothèse de disponibilité des systèmes de communication est la deuxième : lors d\'une cyberattaque, les systèmes de messagerie et de communication peuvent être parmi les premiers affectés, rendant impossible la coordination via les canaux habituels.
L\'hypothèse de manualisabilité des processus est peut-être la plus fréquemment invalidée. Beaucoup de plans supposent que, en cas d\'indisponibilité des systèmes IT, les processus peuvent être réalisés manuellement. En pratique, des processus qui étaient réalisés manuellement il y a dix ans sont désormais entièrement automatisés et les collaborateurs qui sauraient les réaliser manuellement ont quitté l\'organisation ou ne sont plus formés à ces procédures.
Les conditions d\'une continuité d\'activité réelle
La transition de la continuité théorique à la résilience réelle passe par des tests réguliers et progressivement plus exigeants. Un programme de test de continuité mature commence par des tests techniques (reprise d\'un système), passe par des tests de processus (simulation d\'une interruption d\'un service avec les équipes métiers concernées) et progresse vers des exercices de crise complets (simulation d\'un scénario majeur avec la direction). Chaque niveau de test révèle des lacunes que le niveau précédent ne permettait pas de voir.
La compromission SolarWinds de 2020, qui a affecté 18 000 organisations via une mise à jour logicielle infectée, a révélé que la continuité d\'activité de beaucoup d\'organisations ne couvrait pas le scénario d\'une compromission profonde de l\'infrastructure de gestion IT. Les plans existants supposaient que les outils de gestion des systèmes resteraient disponibles et fiables — SolarWinds Orion était précisément l\'un de ces outils. Lorsqu\'il est devenu lui-même le vecteur d\'attaque, les organisations ne disposaient pas de plans alternatifs pour gérer leurs infrastructures sans lui. Ce scénario — l\'outil de gestion de crise lui-même compromis — est caractéristique des plans de continuité qui ne couvrent pas les scénarios les plus adverses.
L\'impact de NotPetya sur Maersk en 2017 (300 millions de dollars de pertes) a été le test réel le plus documenté d\'un plan de continuité d\'activité d\'une grande organisation. Maersk a perdu l\'accès à 45 000 PC, 4 000 serveurs et 2 500 applications en quelques heures. Les plans de continuité existants n\'avaient pas anticipé ce niveau de destruction simultanée. La reconstitution de l\'infrastructure en dix jours — un exploit opérationnel remarquable — a nécessité l\'activation de ressources qui n\'étaient pas dans les plans : des équipes venues d\'autres entités du groupe, du matériel commandé en urgence dans le monde entier, des solutions temporaires basées sur des outils grand public. L\'expérience de Maersk a redéfini le standard de ce que doit couvrir un plan de continuité d\'activité dans le secteur.
La violation SingHealth de 2018 (1,5 million de patients) a révélé que les plans de continuité du système de santé singapourien n\'avaient pas suffisamment anticipé les scénarios de compromission des systèmes de gestion des données patients. La réponse à l\'incident — isolement des systèmes, reprise en mode dégradé, communication aux patients — a nécessité des décisions qui n\'étaient pas toutes documentées dans les plans existants. Le rapport du Committee of Inquiry a formulé des recommandations précises sur l\'amélioration des plans de continuité, notamment sur la définition des procédures d\'escalade et la préparation de modes dégradés pour les systèmes de santé critiques.