La prévention reste indispensable, mais aucune architecture de cybersécurité ne peut garantir l’absence totale d’incident. Une erreur d’administration, une panne électrique, un sinistre physique, la compromission d’un prestataire ou un rançongiciel peuvent rendre simultanément plusieurs services indisponibles. La question stratégique devient alors très concrète : combien de temps l’entreprise peut-elle continuer à fonctionner sans ses systèmes numériques essentiels ? Cette réflexion dépasse largement la DSI. Lorsque les commandes ne peuvent plus être enregistrées, que les paiements sont interrompus ou que les collaborateurs perdent l’accès aux outils de travail, la continuité informatique devient une question de continuité économique. Le Plan de Continuité d’Activité organise le fonctionnement pendant la crise, tandis que le Plan de Reprise d’Activité prépare la reconstruction. Leur efficacité dépend d’objectifs définis avec les métiers et régulièrement testés.
Identifier les activités réellement critiques
La première étape consiste à réaliser une Business Impact Analysis. L’objectif n’est pas de considérer toutes les applications comme prioritaires, mais d’identifier celles dont l’indisponibilité provoquerait rapidement une perte financière, une rupture opérationnelle, un risque réglementaire ou une dégradation majeure de la relation client. Cette analyse permet de définir deux indicateurs structurants. Le RTO, Recovery Time Objective, correspond à la durée maximale acceptable avant la restauration d’un service. Le RPO, Recovery Point Objective, détermine la quantité de données que l’entreprise accepte éventuellement de perdre. Une application pouvant tolérer vingt-quatre heures d’interruption n’exige évidemment pas la même architecture qu’un système dont l’arrêt devient critique après trente minutes.
Ces objectifs doivent être négociés avec les métiers. Exiger un RTO proche de zéro pour chaque application ferait exploser les coûts d’infrastructure sans nécessairement créer de valeur supplémentaire.
Protéger réellement les sauvegardes
Disposer de sauvegardes ne garantit plus une reprise rapide. Les rançongiciels modernes cherchent précisément à compromettre ou supprimer les backups avant de chiffrer les environnements de production. Une stratégie de résilience doit donc empêcher qu’un même accès administrateur permette de détruire simultanément les données opérationnelles et leurs copies. La règle 3-2-1-1-0 constitue un cadre utile : conserver trois copies des données sur deux types de supports, avec une copie hors site et une copie hors ligne ou immuable. Le dernier zéro rappelle un principe essentiel : une sauvegarde n’a de valeur que si sa restauration a été testée sans erreur. L’infrastructure de sauvegarde doit également bénéficier d’une administration fortement séparée. Comptes dédiés, authentification forte et segmentation réduisent le risque qu’une compromission du système principal atteigne directement les mécanismes de reprise.
Distinguer continuité et reconstruction
Le PCA répond à la question : comment continuer à fonctionner lorsque le système d’information habituel n’est plus disponible ? Certains processus critiques doivent pouvoir basculer temporairement vers des procédures alternatives, des outils isolés ou des modes dégradés définis à l’avance.
Le PRA intervient dans un second temps. Après une cyberattaque, restaurer immédiatement toutes les sauvegardes peut réintroduire la compromission dans l’environnement reconstruit. La reprise doit suivre une séquence maîtrisée : sécurisation des identités et du réseau, validation de l’infrastructure, restauration des applications prioritaires, contrôle des données puis réouverture progressive des accès. Cette hiérarchisation permet d’éviter une reconstruction désordonnée sous la pression des équipes métiers.
Préparer la cellule de crise
Une crise cyber majeure ne peut pas être gérée uniquement par le RSSI. Direction générale, DSI, juridique, communication, ressources humaines et responsables métiers doivent connaître à l’avance leur rôle et leurs responsabilités. La cellule doit notamment déterminer comment communiquer avec les salariés, clients, partenaires, assureurs et autorités compétentes. Les obligations de notification doivent être analysées selon la nature de l’incident, les données concernées et le statut réglementaire de l’organisation, notamment au regard de la CNDP et des dispositifs nationaux de cybersécurité.
Tester avant la véritable attaque
Un PCA jamais exercé reste une hypothèse. Les entreprises doivent tester concrètement la restauration de leurs systèmes et confronter leurs dirigeants à des simulations de crise : indisponibilité totale du SI, compromission des sauvegardes, exfiltration de données ou demande de rançon. Ces exercices révèlent les dépendances invisibles, les procédures obsolètes et les décisions qui n’ont jamais été réellement arbitrées. La résilience cyber ne se mesure finalement pas au nombre de documents produits, mais à la capacité de l’organisation à continuer son activité, restaurer ses systèmes et prendre rapidement les bonnes décisions lorsque ses outils habituels ne répondent plus.
