Il y a deux catégories d’entreprises : celles qui ont un Plan de Continuité d’Activité (PCA) de 140 pages soigneusement rangé dans un dossier SharePoint, et celles qui ont déjà essayé d’éteindre un serveur critique sans prévenir personne un mardi matin.
Les premières ont bonne conscience jusqu’au premier vrai incident. Les secondes savent exactement où ça coince.
Le problème de la sécurité et de la continuité opérationnelle n’a jamais été un manque d’outils ou de modèles documentaires. Le point de rupture est presque toujours humain et organisationnel : le jour où la panne arrive, le cerveau humain bascule en mode panique, la mémoire vive des équipes s’évapore, et personne ne retrouve le mot de passe du compte d’urgence.
Installer une culture de la résilience, ce n’est pas faire signer une charte informatique. C’est créer des automatismes à travers trois étapes concrètes : la formation, la simulation et le retour d’expérience.
1. La formation : tuer le QCM obligatoire
La plupart des formations à la cybersécurité ressemblent à une corvée administrative. Un module e-learning de quarante minutes avec une vidéo en 240p, trois questions évidentes pour valider le badge, et un collaborateur qui clique sur « Suivant » en faisant autre chose.
Résultat opérationnel : zéro.
Acculturer des équipes à la résilience, ce n’est pas leur apprendre la différence théorique entre un ver et un cheval de Troie. C’est leur donner le contexte de leur propre métier :
- Expliquer à l’équipe financière ce qui se passe techniquement quand leur outil de facturation SaaS tombe, et comment fonctionne le mode dégradé (le vrai, avec des feuilles de calcul prêtes à l’emploi).
- Montrer aux développeurs ce que produit réellement une dépendance non maîtrisée quand l’API externe répond avec des codes 504.
- Désamorcer la honte : le premier réflexe d’un collaborateur qui clique sur un lien douteux ne doit pas être d’éteindre discrètement son écran en espérant que personne n’ait vu, mais de lever la main tout de suite.
La formation ne sert pas à fabriquer des experts en cyber, elle sert à donner le droit d’alerter tôt.
2. La simulation : le crash-test sans filet
Un exercice d’évacuation incendie dont la date et l’heure sont affichées dans l’ascenseur depuis deux semaines n’apprend rien à personne. C’est juste une pause café dehors avec un gilet jaune.
En informatique, c’est pareil. Tester un Plan de Reprise d’Activité en prévenant les administrateurs trois jours à l’avance pour qu’ils préparent les scripts, ce n’est pas un test. C’est du théâtre.
La simulation d’incident doit être progressive, mais elle doit piquer un peu :
- L’exercice sur table (tabletop) : on enferme pendant deux heures la direction, les opérations et la technique dans une pièce. Le scénario tombe : « Il est 11 h, les sauvegardes locales sont chiffrées, la messagerie est inaccessible. Qui appelle qui ? Avec quel téléphone ? Où sont les contacts d’urgence si le carnet d’adresses est dans le cloud compromis ? » C’est souvent là qu’on découvre que le numéro de l’hébergeur était noté sur un post-it… sur l’écran du bureau verrouillé.
- Le test technique à blanc : couper l’accès à une base de données répliquée ou simuler la perte d’un prestataire réseau. Observer comment les applications réagissent (dégradation gracieuse ou plantage sec) et mesurer le temps réel qu’il faut aux équipes pour reprendre la main sans improviser.
On ne simule pas pour vérifier que tout marche bien. On simule précisément pour trouver ce qui ne marche pas, au moment où cela ne coûte rien.
3. Le retour d’expérience : l’art du post-mortem sans tribunal
L’incident est passé — ou la simulation s’est terminée dans un désordre relatif. C’est ici que tout se joue.
Dans les organisations fragiles, la première question qui fuse est : « C’est la faute de qui ? » Dans une organisation résiliente, la question est : « Pourquoi le système a-t-il permis que cette action ait un tel impact ? »
Le post-mortem (ou RETEX) doit être impitoyablement sincère, mais rigoureusement sans blâme (blameless) :
- Si un collaborateur a fait une fausse manipulation en prod, le problème n’est pas le collaborateur, c’est l’absence de garde-fous sur l’environnement de prod.
- Si la communication de crise a patiné pendant trois heures, ce n’est pas un manque de volonté, c’est que la chaîne d’escalade n’était pas claire.
Chaque retour d’expérience doit accoucher de décisions directes : une modification de configuration, un script automatisé, une procédure simplifiée de moitié. Si le RETEX produit simplement un compte-rendu de réunion classé sans suite, l’incident se reproduira à l’identique au trimestre suivant.
En pratique : s’inspirer de l’aéronautique
Dans l’aviation commerciale, les audits de sécurité en ligne (LOSA) montrent qu’un équipage gère en moyenne entre 4 et 6 menaces et erreurs par vol régulier : un changement de trajectoire imprévu par la tour de contrôle, une météo qui se dégrade, un chiffre mal sélectionné sur le pilote automatique. Pourtant, c’est le mode de transport le plus sûr au monde.
Pourquoi ? Parce que l’aéronautique n’a pas cherché à fabriquer des humains parfaits. Elle a appris, souvent dans la douleur, à construire un cockpit résilient qui piège l’erreur avant qu’elle ne fasse boule de neige.
Dans le numérique, nous continuons trop souvent d’espérer que rien ne casse et que personne ne se trompe. C’est un vœu pieux. La résilience est une mécanique musculaire : elle s’atrophie si on ne s’en sert pas. La résilience commence quand on accepte les secousses et qu’on s’entraîne à les absorber.
Commencez petit. Inutile de simuler une attaque étatique dès demain. Réunissez trois personnes autour d’un café, coupez mentalement l’accès à votre outil de travail principal pendant une matinée, et regardez ce qui se passe. Le plan d’action s’écrira tout seul.
Prêt à éprouver vos défenses ? Contactez-nous pour organiser une simulation de crise.