- SolarWinds (2020) : 18 000 organisations affectées par une compromission de leur outil de gestion IT — aucune n\'avait de plan de continuité pour le scénario où l\'outil de supervision lui-même est le vecteur d\'attaque.
- La première erreur : des RTO et RPO définis sans validation technique réelle — les délais de reprise affichés dans les plans ne sont pas atteints lors des tests et encore moins lors des incidents réels.
- La deuxième erreur : une liste de responsables de la gestion de crise qui n\'ont jamais été entraînés à ce rôle et qui ne se connaissent pas suffisamment pour fonctionner efficacement sous pression.
- La troisième erreur : des plans qui ne couvrent que les scénarios les plus probables, omettant les scénarios à faible probabilité mais à fort impact — précisément ceux qui causent les crises majeures.
- La quatrième erreur : des plans stockés uniquement dans des systèmes informatiques — inaccessibles lors d\'une panne ou d\'une cyberattaque qui est précisément le contexte dans lequel on en a besoin.
- La cinquième erreur : l\'absence de mise à jour lors des évolutions de l\'organisation — fusions, nouvelles activités, nouvelles dépendances — qui rend progressivement les plans inadaptés à la réalité.
Les plans de continuité d\'activité (PCA) et de reprise d\'activité (PRA) sont des documents qui satisfont les exigences des auditeurs et des assureurs, et qui sont ensuite rangés dans un dossier où ils restent jusqu\'à ce qu\'une crise les mette à l\'épreuve. C\'est souvent lors de cette mise à l\'épreuve que les erreurs de conception et de maintenance deviennent visibles — au moment le moins opportun.
L\'analyse des crises majeures des dernières années révèle un ensemble d\'erreurs récurrentes qui invalident les plans de continuité lors des incidents réels. Ces erreurs ne sont pas des accidents — elles résultent de processus de planification qui optimisent pour la conformité formelle plutôt que pour l\'efficacité opérationnelle réelle.
Les erreurs de conception initiale
La définition des RTO et RPO sans validation technique est l\'erreur de conception la plus fréquente. Les objectifs de temps de reprise (RTO) et de point de reprise (RPO) sont souvent définis par les équipes métier sur la base de ce qu\'elles souhaiteraient plutôt que de ce que les systèmes techniques peuvent effectivement garantir. Sans validation par les équipes IT de la faisabilité technique de ces objectifs — et sans test pour confirmer qu\'ils sont atteints — ces chiffres sont des aspirations, pas des engagements réalisables.
La couverture partielle des scénarios est une autre erreur de conception systémique. Les plans couvrent généralement les scénarios les plus fréquents — panne serveur, perte d\'accès à un local, interruption d\'un service spécifique. Ils omettent les scénarios à faible probabilité mais à fort impact : destruction simultanée de tous les systèmes, compromission de l\'infrastructure de backup, défaillance d\'un prestataire critique, crise simultanée dans plusieurs localisations.
La violation de données Cathay Pacific de 2018 (9,4 millions de passagers) a mis à l\'épreuve les plans de réponse aux incidents de la compagnie aérienne. L\'équipe de réponse n\'avait pas été formée aux scénarios de violation de données à grande échelle, et les procédures de notification aux clients n\'avaient pas été testées à cette échelle. Le délai de notification aux personnes affectées — plusieurs mois après la découverte — résultait en partie de l\'absence de procédures pré-établies pour ce type d\'incident. Cathay Pacific a également découvert que les systèmes de communication de crise n\'avaient pas été conçus pour gérer simultanément une notification à plusieurs millions de personnes dans des juridictions aux exigences légales différentes — une lacune de conception qui a allongé le délai de reprise.
Les erreurs de maintenance et d\'actualisation
Les plans qui ne sont pas mis à jour lors des changements organisationnels deviennent progressivement inadaptés. Une fusion, une acquisition, le lancement d\'une nouvelle activité, un changement d\'infrastructure IT majeur — chacun de ces événements rend potentiellement obsolètes certaines parties du plan de continuité. Sans processus de déclenchement de révision du plan lors de ces événements, les plans accumulent des sections qui décrivent une organisation qui n\'existe plus.
L\'évolution des personnes clés est une source d\'obsolescence particulièrement problématique. Les plans de continuité désignent généralement des responsables par leur nom ou leur titre. Lorsque ces personnes changent de poste ou quittent l\'organisation, sans transfert des connaissances et sans mise à jour du plan, les successeurs se retrouvent dans des rôles de crise pour lesquels ils n\'ont pas été formés.
Les erreurs de mise en oeuvre opérationnelle
Les plans stockés uniquement dans des systèmes informatiques sont inaccessibles lors des incidents qui affectent précisément ces systèmes. C\'est l\'une des ironies les plus cruelles des plans de continuité : le document qui décrit comment continuer à fonctionner lors d\'une panne informatique est lui-même stocké dans les systèmes informatiques qui sont en panne. Des copies physiques ou des stockages hors ligne, dont l\'emplacement est connu des personnes clés, sont une exigence élémentaire.
La violation Target de 2013 (40 millions de cartes bancaires via les credentials d\'un prestataire) a mis en évidence une erreur fréquente dans les plans de réponse aux incidents : les alertes de sécurité avaient bien été générées par les outils de détection de Target, mais les procédures de traitement de ces alertes n\'étaient pas suffisamment précises pour déclencher une réponse adéquate. Les équipes opérationnelles avaient reçu des notifications mais ne disposaient pas de procédures claires pour évaluer leur gravité et escalader aux décideurs. L\'erreur n\'était pas dans l\'absence d\'outils de détection — ils existaient — mais dans l\'absence de procédures de réponse aux alertes adaptées à l\'organisation réelle de Target.
L\'impact de WannaCry sur Renault en 2017 — arrêt de plusieurs lignes de production — a révélé une erreur classique dans les plans de continuité industriels : l\'hypothèse que les systèmes de contrôle industriel (OT — Operational Technology) étaient isolés du réseau d\'entreprise (IT). En réalité, des connexions non documentées entre les réseaux IT et OT existaient, permettant à WannaCry de se propager des postes de travail bureautiques vers les systèmes de pilotage des chaînes de production. Les plans de continuité de production n\'avaient pas intégré ce scénario, laissant les équipes de production sans procédures adaptées lorsque les automates ont commencé à tomber en panne.
La violation Air India via le prestataire SITA en 2021 (4,5 millions de passagers) a illustré une erreur fréquente dans la gestion de la continuité face aux défaillances de prestataires : Air India n\'avait pas de procédure pré-établie pour gérer une violation affectant des données traitées par un prestataire tiers. Le plan de continuité ne couvrait que les incidents affectant directement les systèmes d\'Air India, pas les incidents dans la chaîne de sous-traitance. La découverte que les données des passagers avaient été exposées via SITA — une organisation que les passagers ne connaissent pas — a créé une complexité de communication additionnelle que le plan ne permettait pas de gérer. Air India a dû improviser l\'essentiel de la réponse à l\'incident.