- Equifax (2017) : un patch disponible depuis des mois pour la vulnérabilité Apache Struts n\'avait pas été appliqué — l\'organisation avait un processus de gestion des vulnérabilités sur le papier mais pas de mécanisme d\'exécution testé régulièrement.
- La première raison pour laquelle les plans ne sont pas testés : la peur des résultats — un test qui révèle des lacunes crée un problème à gérer, et les organisations préfèrent souvent ne pas savoir.
- La deuxième raison : les tests réalistes sont disruptifs — ils perturbent les opérations normales, mobilisent des ressources et créent de l\'incertitude opérationnelle pendant leur durée.
- Les tests partiels — qui ne mettent pas réellement le plan à l\'épreuve — sont une forme de conformité de façade qui satisfait les auditeurs sans développer la résilience réelle.
- La fréquence de test recommandée par les standards industriels (annuelle minimum, idéalement semestrielle) est rarement atteinte dans les organisations qui traitent la continuité comme une contrainte plutôt que comme un investissement.
- Les audits d\'assurance cyber incluent de plus en plus des exigences de preuve des tests — les organisations qui ne peuvent pas produire des rapports de test récents voient leurs primes augmenter ou leur couverture réduite.
La quasi-totalité des organisations qui disposent de plans de continuité d\'activité les testent insuffisamment. Cette réalité est bien documentée dans les études du secteur et confirmée par les post-mortems des incidents majeurs : les plans qui n\'ont jamais été testés en conditions réalistes échouent lors des crises réelles de manière prévisible, pour des raisons qui auraient pu être identifiées lors d\'un test.
Les raisons pour lesquelles les plans ne sont pas testés sont multiples, mais elles convergent vers une réalité organisationnelle inconfortable : tester vraiment un plan de continuité en conditions réalistes, c\'est accepter de découvrir qu\'il ne fonctionne pas comme prévu. Cette découverte crée du travail, des responsabilités à assumer et des investissements à justifier — des conséquences que beaucoup d\'organisations préfèrent différer.
Les obstacles organisationnels aux tests réalistes
Le premier obstacle est la disruption opérationnelle. Un test réaliste de continuité interrompt les opérations normales — même temporairement et partiellement. Dans des organisations où la pression opérationnelle est forte et où les marges sont serrées, il est difficile de justifier une interruption délibérée, même brève et maîtrisée. Cet argument est compréhensible, mais il ignore le coût de la découverte de l\'incapacité à reprendre lors d\'une crise réelle.
Le deuxième obstacle est la peur des résultats. Un test qui révèle des lacunes crée un problème à gérer — des écarts à corriger, des investissements à réaliser, des responsabilités à assumer. Dans les organisations où la culture est orientée vers la démonstration des succès plutôt que vers l\'identification des faiblesses, les tests sont naturellement conçus pour réussir plutôt que pour révéler les lacunes. Cette culture de l\'évitement du problème est exactement ce qui laisse les lacunes en place jusqu\'à la prochaine crise réelle.
La violation Citibank de 2011 (360 000 comptes exposés via traversal d\'API) résultait d\'une vulnérabilité dans le portail client web qui n\'avait pas été identifiée lors des audits de sécurité périodiques. Les tests de sécurité réalisés étaient suffisamment ciblés pour satisfaire les auditeurs mais insuffisamment exhaustifs pour identifier des vecteurs d\'attaque comme le traversal d\'API. Cette distinction — entre un test qui satisfait les auditeurs et un test qui révèle les vrais risques — est caractéristique du problème des tests de conformité qui ne sont pas des tests de résilience réelle. Citibank a révisé ses procédures de test de sécurité après l\'incident, en élargissant la surface des tests pour inclure des vecteurs d\'attaque moins conventionnels.
Les types de tests et leur valeur relative
Les tests de continuité se déclinent en plusieurs niveaux de réalisme et d\'exigence. Les tests documentaires — révision des plans sans simulation opérationnelle — sont les plus courants et les moins révélateurs. Les tests de notification — vérification que les contacts clés sont joignables et connaissent leur rôle — sont un niveau supérieur mais restent insuffisants pour révéler les lacunes opérationnelles. Les tests de basculement technique — activation effective des systèmes de reprise — révèlent les problèmes techniques mais pas les lacunes de processus métier. Les simulations complètes — exercices impliquant direction et équipes opérationnelles dans des scénarios réalistes, avec des contraintes de communication et de ressources — sont les seuls tests qui révèlent les lacunes systémiques.
La valeur d\'un test est proportionnelle à son niveau de réalisme et d\'exigence. Un test conçu pour réussir ne révèle pas les lacunes du plan. Un test conçu pour challenger le plan révèle les hypothèses invalides, les dépendances non documentées et les lacunes de procédure — et crée les conditions pour les corriger avant la prochaine crise réelle.
Les exigences des assureurs et des régulateurs
Les exigences des assureurs cyber en matière de tests de continuité ont significativement augmenté dans les dernières années. Les organisations qui ne peuvent pas produire de rapports de tests récents voient leurs primes augmenter ou leur couverture conditionnée à la réalisation de tests. Cette pression externe est devenue un levier efficace pour les directions IT et les DPO qui cherchent à justifier les investissements dans les tests de continuité auprès de directions générales réticentes.
L\'affaire Morgan Stanley des serveurs revendus sans effacement (amende de 35 millions de dollars avec la SEC, 2022) illustre le problème des tests partiels. Morgan Stanley avait des politiques d\'effacement des données sur les équipements en fin de vie — des politiques qui étaient théoriquement testées et validées. En pratique, la procédure avait été contournée lors de la revente de serveurs de data centers, sans que les contrôles existants ne détectent la déviation. Les tests de la politique d\'effacement n\'incluaient pas de vérification de son application lors des cessions d\'actifs — un angle mort caractéristique des tests partiels qui valident la procédure nominale sans vérifier les cas limites.
La publication de 9,5 Go de données internes de Thales par LockBit en 2022 a révélé des lacunes dans les procédures de contrôle des accès aux systèmes collaboratifs. Les procédures existantes n\'avaient pas été testées dans des scénarios incluant des prestataires extérieurs avec des droits d\'accès larges — un angle mort des tests de sécurité. Dans un groupe comme Thales, qui travaille avec de nombreux sous-traitants et prestataires sur des projets sensibles, la surface des tests doit inclure les accès accordés aux tiers et leur niveau de contrôle. L\'incident a conduit Thales à réviser son programme de tests de sécurité pour inclure des scénarios de compromission via des accès tiers.
L\'incident SoftBank de 2023 (employés partageant des informations confidentielles avec ChatGPT) a révélé une lacune dans les tests des politiques de sécurité de l\'information : les procédures existantes n\'avaient pas été testées dans des scénarios incluant l\'utilisation d\'outils d\'IA générative — des outils qui n\'étaient pas dans le périmètre des politiques au moment de leur rédaction. Les tests de continuité et de sécurité doivent être mis à jour pour refléter l\'évolution du paysage technologique, pas seulement pour valider les politiques existantes. SoftBank a dû rapidement mettre en place des restrictions sur l\'utilisation des outils d\'IA générative et former ses équipes aux risques associés.