Une attaque cyber majeure ne se gère pas comme un incident technique ordinaire. Lorsqu’un rançongiciel chiffre l’Active Directory d’une entité, la messagerie tombe, les sauvegardes deviennent suspectes, et la direction découvre souvent en quelques heures que son organisation ne sait pas fonctionner sans système d’information. Le moment de la crise n’est pas le moment de la préparation. C’est le moment où l’on découvre, parfois brutalement, ce qui a été préparé et ce qui ne l’a pas été.
La gestion de crise cyber repose sur un principe simple et exigeant : tout ce qui peut être décidé à froid doit l’être avant l’incident. Le jour de l’attaque, l’organisation ne dispose ni du temps, ni de la sérénité, ni parfois des outils de communication habituels pour improviser des arbitrages. Cet article décrit la construction du dispositif complet : le plan de continuité d’activité (PCA), le plan de reprise d’activité (PRA), le dispositif de gestion de crise, et la discipline d’exercice sans laquelle l’ensemble reste une fiction de papier. Le cadre suit la doctrine de l’ANSSI [1] et la norme internationale ISO 22301 [3].
Trois objets qu’il ne faut pas confondre
La première erreur consiste à employer les sigles PCA et PRA comme synonymes. Ils désignent des objets distincts, articulés mais non interchangeables.
Le PCA, plan de continuité d’activité, est un objet métier. Il répond à la question : comment l’organisation continue-t-elle à remplir ses fonctions essentielles pendant que les systèmes sont indisponibles. Un PCA peut prévoir des procédures manuelles, des modes dégradés, des sites de repli, des circuits de décision alternatifs. Il s’intéresse à l’activité, pas à la technique. Une clinique doit pouvoir admettre et soigner des patients même quand son dossier patient informatisé est hors service ; un industriel doit pouvoir expédier des commandes même quand son ERP est arrêté. Le PCA décrit comment.
Le PRA, plan de reprise d’activité, est un objet technique. Il répond à la question : comment restaurer les systèmes d’information dans un état opérationnel après le sinistre. Le PRA décrit les procédures de restauration des sauvegardes, l’ordre de redémarrage des services, la reconstruction de l’annuaire, la bascule vers une infrastructure de secours. Le PRA est, en réalité, un sous-ensemble du PCA : il sert la continuité métier en restaurant les moyens techniques.
Le dispositif de gestion de crise est un objet humain et organisationnel. Il ne s’agit ni de maintenir l’activité ni de restaurer les systèmes, mais d’organiser la décision sous pression. Qui décide d’isoler le réseau ? Qui communique vers les clients, les autorités, la presse ? Qui arbitre entre restaurer vite et restaurer proprement ? Le dispositif de gestion de crise structure ces choix avant qu’ils ne se posent.
Une organisation peut posséder un PRA technique impeccable et se révéler incapable de gérer une crise, faute de chaîne de décision claire. À l’inverse, une cellule de crise bien rodée sans sauvegardes restaurables ne pourra que constater les dégâts. Les trois objets sont nécessaires et complémentaires.
RTO et RPO : les deux paramètres fondateurs
Avant toute architecture, deux paramètres doivent être définis, fonction par fonction. Ils conditionnent l’ensemble des choix techniques et budgétaires.
Le RTO (Recovery Time Objective) est la durée maximale d’interruption acceptable avant que l’impact ne devienne critique pour l’organisation. Un RTO de quatre heures sur la prise de commande signifie que l’entreprise estime pouvoir survivre à quatre heures d’arrêt de cette fonction, pas davantage.
Le RPO (Recovery Point Objective) est la quantité maximale de données que l’organisation accepte de perdre, exprimée en temps. Un RPO d’une heure impose des sauvegardes au moins horaires : en cas de sinistre, on restaure l’état d’il y a au plus une heure, et l’heure de données plus récente est perdue.
Ces deux paramètres ne se décrètent pas par défaut sur l’ensemble du système. Ils se définissent fonction par fonction, à l’issue d’une analyse d’impact sur l’activité (Business Impact Analysis, BIA). Cette analyse identifie les processus essentiels, mesure les conséquences de leur interruption dans le temps, et hiérarchise les priorités de reprise. La méthode NIST SP 800-34 [4] détaille cette démarche dans le contexte des plans de contingence des systèmes d’information.
L’enjeu est économique autant que technique. Plus le RTO et le RPO sont courts, plus l’architecture de redondance et de sauvegarde devient coûteuse. Un RPO proche de zéro suppose une réplication synchrone permanente ; un RTO de quelques minutes suppose une infrastructure de secours active en permanence. À l’inverse, des objectifs trop laxistes exposent l’organisation à des pertes que son activité ne supporte pas. Le dimensionnement juste résulte d’un arbitrage explicite entre le coût de la protection et le coût de l’interruption, arbitrage qui relève de la direction et non de la seule DSI.
Cette analyse rejoint directement la démarche d’appréciation des risques décrite dans notre guide de la méthode EBIOS Risk Manager : les événements redoutés identifiés lors de l’analyse de risque deviennent les scénarios que le PCA doit traiter.
Construire le plan de continuité d’activité
Le PCA se construit en partant des fonctions essentielles identifiées par la BIA, et non de l’inventaire technique. Cette inversion de perspective est fondamentale : on ne protège pas des serveurs, on protège la capacité de l’organisation à remplir sa mission.
Pour chaque fonction essentielle, le plan décrit le mode de fonctionnement dégradé. Comment l’activité continue-t-elle quand le système nominal est indisponible ? La réponse passe souvent par des procédures manuelles temporaires : bons de commande papier, registres tenus à la main, validation par téléphone. Ces procédures dégradées doivent être documentées, et surtout praticables, ce qui suppose que les équipes en aient connaissance avant la crise.
Le plan définit ensuite les ressources minimales nécessaires au maintien de chaque fonction : personnel clé, locaux de repli, moyens de communication alternatifs, fournisseurs critiques. La dépendance à des prestataires externes mérite une attention particulière, car la crise d’un fournisseur peut devenir la crise de l’organisation. La question de la souveraineté et de la maîtrise des dépendances rejoint ici les enjeux abordés dans notre analyse du cloud souverain et de la qualification SecNumCloud.
Le PCA précise enfin les conditions de bascule : quels critères déclenchent le passage en mode dégradé, qui prend la décision, et comment l’organisation revient au mode nominal une fois le système restauré. Le retour à la normale est une phase souvent négligée, alors qu’elle comporte ses propres risques : réintégrer dans le système restauré les données saisies manuellement pendant la crise est une opération délicate, source d’erreurs et d’incohérences.
Le plan de reprise technique
Le PRA décrit, étape par étape, la restauration des systèmes. Sa qualité se mesure à une seule aune : la capacité à restaurer effectivement, dans les délais du RTO, à partir des sauvegardes disponibles.
La première condition est la disponibilité de sauvegardes restaurables et protégées. Dans le contexte du rançongiciel, les sauvegardes en ligne, accessibles depuis le système de production, sont systématiquement ciblées par les attaquants avant le déclenchement du chiffrement. La doctrine actuelle impose des sauvegardes immuables, déconnectées ou conservées hors d’atteinte des comptes du domaine, selon la règle 3-2-1 que nous détaillons dans notre guide de la stratégie de sauvegarde cloud 3-2-1. Une sauvegarde chiffrée par l’attaquant n’est pas une sauvegarde.
Le PRA documente ensuite l’ordre de reconstruction. Dans un environnement Windows, la reconstruction de l’Active Directory précède la plupart des autres services, car l’authentification en dépend. Les dépendances entre applications imposent une séquence : restaurer une application métier avant sa base de données ne sert à rien. Cette cartographie des dépendances doit être maintenue à jour, ce qui suppose une connaissance précise de l’architecture, souvent perdue ou incomplète dans les organisations qui n’ont jamais exécuté leur plan.
Un point crucial, et trop souvent ignoré, concerne la reconstruction en environnement sain. Après une compromission, restaurer les systèmes dans l’infrastructure attaquée revient à reconstruire sur un terrain potentiellement encore contaminé. Les attaquants laissent fréquemment des accès persistants, des comptes dormants, des portes dérobées. La reconstruction propre suppose une investigation préalable pour comprendre le périmètre de la compromission, opération qui mobilise souvent un prestataire spécialisé de réponse à incident. Cette articulation entre reprise et investigation est l’une des raisons pour lesquelles disposer d’un contrat de détection et réponse externalisées avec un MSSP ou un service SOC accélère considérablement la sortie de crise.
Organiser le dispositif de gestion de crise
Le dispositif de gestion de crise est la dimension humaine qui orchestre l’ensemble. L’ANSSI a publié un guide opérationnel et stratégique dédié [1], complété par un guide consacré à l’organisation des exercices [2].
Au cœur du dispositif se trouve la cellule de crise, qui réunit deux niveaux.
La cellule décisionnelle (ou stratégique) associe la direction générale, la communication, la direction juridique et les directions métier concernées. Elle prend les décisions à fort enjeu : faut-il arrêter une partie de l’activité, communiquer publiquement, notifier les autorités, mobiliser l’assurance. Elle porte la responsabilité des choix qui engagent l’organisation.
La cellule opérationnelle (ou technique) réunit le RSSI, la DSI, les équipes techniques et, le cas échéant, le prestataire de réponse à incident. Elle conduit l’investigation, l’endiguement, et la reprise. Elle alimente la cellule décisionnelle en éléments factuels et en options techniques.
Un coordinateur de crise assure le lien entre les deux niveaux, anime les points de situation réguliers, et tient la main courante, ce journal horodaté de toutes les décisions et actions qui se révélera indispensable lors du retour d’expérience et, parfois, lors des suites judiciaires ou assurantielles.
Trois conditions matérielles conditionnent l’efficacité du dispositif.
Des moyens de communication hors système d’information. Si la messagerie et la téléphonie sur IP sont compromises ou coupées, la cellule de crise doit disposer de canaux alternatifs préétablis : messagerie de secours sur un domaine distinct, application de messagerie sur terminaux personnels, numéros de téléphone mobiles. Communiquer la gestion de la crise via le système attaqué expose en outre l’organisation à ce que l’attaquant lise ses échanges.
Des coordonnées et procédures consultables hors ligne. L’annuaire de crise, les fiches réflexes, les procédures de bascule doivent exister sur un support accessible même réseau coupé : copies papier, support chiffré hors domaine. Un plan stocké uniquement sur le partage réseau chiffré par le rançongiciel est un plan perdu au pire moment.
Des rôles définis et des suppléants désignés. La crise peut survenir un week-end, pendant les congés, lors d’un déplacement. Chaque rôle clé doit disposer d’un suppléant identifié. La désignation des responsables le jour de la crise est une perte de temps et une source de confusion.
La déclaration aux autorités et la dimension réglementaire
La gestion de crise comporte un volet réglementaire que la cellule décisionnelle doit anticiper. Plusieurs obligations de notification peuvent se déclencher simultanément, avec des délais courts et des destinataires distincts.
En cas de violation de données à caractère personnel, le RGPD impose une notification à la CNIL dans les soixante-douze heures. Pour les entités assujetties à NIS2, des obligations de notification d’incident significatif s’imposent vers l’autorité nationale compétente, selon un calendrier en plusieurs temps. Le secteur financier, soumis à DORA, relève d’exigences propres de signalement des incidents majeurs. Ces dispositifs sont décrits dans nos guides du règlement NIS2 en entreprise et du règlement DORA pour le secteur financier.
S’ajoute, en France, le dépôt de plainte, condition préalable à certaines indemnisations. La loi d’orientation et de programmation du ministère de l’Intérieur conditionne le versement d’une indemnité au titre d’une cyber-rançon au dépôt d’une plainte dans les soixante-douze heures suivant la connaissance de l’atteinte. Cette articulation entre gestion de crise, déclaration et assurance est traitée dans notre dossier sur l’assurance cyber en entreprise. La cellule de crise doit connaître ces délais à l’avance, car les engager tardivement peut fermer des droits.
L’exercice de crise : la pierre angulaire
Un plan jamais testé est un plan qui échouera. Cette affirmation n’est pas rhétorique : elle décrit une régularité observée par tous les acteurs de la réponse à incident. Les plans non exercés comportent invariablement des hypothèses fausses, des dépendances non documentées, des procédures obsolètes. L’exercice est le seul moyen de les révéler avant la crise réelle.
L’ANSSI distingue plusieurs formats d’exercices, de complexité croissante [2].
L’exercice sur table réunit les membres de la cellule de crise autour d’un scénario présenté par un animateur. Les participants décrivent les actions qu’ils entreprendraient, sans manipulation technique réelle. Ce format, peu coûteux, permet de valider la chaîne de décision, la connaissance des rôles, et la cohérence des procédures. Il constitue le point d’entrée recommandé pour une organisation qui débute.
L’exercice de simulation introduit une dynamique temporelle et des injections successives : nouvelles informations, rebondissements, pression médiatique simulée. Il teste la capacité de la cellule à fonctionner dans la durée, à gérer l’incertitude et l’information incomplète.
Le test technique de restauration vérifie concrètement la capacité du PRA : restaurer effectivement un système à partir des sauvegardes, mesurer le temps réel de reprise, le confronter au RTO théorique. Ces tests révèlent fréquemment des écarts considérables entre le délai espéré et le délai constaté.
Quel que soit le format, l’exercice ne vaut que par son retour d’expérience. À l’issue de chaque exercice, un compte rendu identifie les dysfonctionnements, les hypothèses invalidées, les écarts entre le plan et la réalité. Ce retour alimente un plan d’amélioration assorti d’échéances et de responsables. Sans cette boucle d’amélioration, l’exercice devient un rituel sans effet.
La fréquence recommandée comprend au minimum un exercice de gestion de crise annuel, complété par des tests techniques de restauration plus rapprochés. Tout changement majeur du système d’information, toute évolution organisationnelle, justifie une révision et un nouveau test. Un plan dont le dernier exercice remonte à plus de douze mois doit être considéré comme non fiable.
Continuité et résilience : une obligation, plus une option
La continuité d’activité et la gestion de crise ont longtemps relevé de la bonne pratique, laissée à l’appréciation de chaque organisation. La directive NIS2 [5] change cette donne pour les entités essentielles et importantes : son article 21 impose explicitement des mesures de continuité d’activité, de gestion des sauvegardes et de gestion de crise au titre des obligations de sécurité. Le secteur financier, soumis à DORA, relève d’exigences détaillées de résilience opérationnelle, incluant un programme de tests structuré.
Au-delà de la contrainte réglementaire, la logique économique est claire. Le rançongiciel demeure la première cause d’arrêt d’activité, et la durée d’indisponibilité, davantage que la rançon, détermine le coût total d’un incident. Les retours d’expérience publics montrent des remédiations s’étalant de quelques semaines à plusieurs mois. Dans ce contexte, la préparation à la crise n’est pas une dépense de précaution facultative : elle est le déterminant principal du temps de sortie de crise, et donc du coût final. Cette préparation s’inscrit dans la défense en profondeur dont le plan de défense contre les rançongiciels constitue le volet préventif.
La résilience cyber ne se résume pas à empêcher l’attaque. Elle suppose d’admettre qu’une attaque réussie finira par survenir, et d’organiser, à froid, la capacité de l’organisation à tenir et à se reconstruire. C’est l’objet du dispositif de continuité et de gestion de crise. C’est aussi, parce qu’il mobilise la direction, les métiers et la technique ensemble, l’un des projets cyber qui ancre le plus durablement la sécurité dans la culture de l’organisation.
Références
[1] ANSSI, « Crise d’origine cyber, les clés d’une gestion opérationnelle et stratégique ». [2] ANSSI, « Organiser un exercice de gestion de crise cyber ». [3] ISO 22301:2019, « Sécurité et résilience, Systèmes de management de la continuité d’activité, Exigences ». [4] NIST, SP 800-34 Rev. 1, « Contingency Planning Guide for Federal Information Systems ». [5] Directive (UE) 2022/2555 (NIS2), article 21, mesures de gestion des risques de cybersécurité.