PRA PCA : le plan qui ne résiste pas à son premier test réel

Pourquoi le PRA PCA reste un point faible majeur

Le PRA PCA a longtemps été pensé pour des sinistres physiques, un incendie, une inondation, une panne matérielle. La cyberattaque a changé la nature du problème. Un rançongiciel ne se contente pas d’interrompre un service, il cherche activement à détruire ou chiffrer les moyens de reprise eux-mêmes, à commencer par les sauvegardes.

Le baromètre CESIN publié en 2025 indique qu’une entreprise française sur trois a subi une interruption d’activité liée à un incident cyber au cours de l’année. La durée moyenne d’arrêt après une attaque par rançongiciel atteint 23 jours. Pour une PME réalisant deux millions d’euros de chiffre d’affaires annuel, une telle interruption représente une perte directe qui se chiffre rapidement à plusieurs dizaines de milliers d’euros, sans compter les coûts de remédiation, la perte de clients et l’atteinte à la réputation.

La directive NIS 2, transposée en France par l’ordonnance du 30 avril 2024, impose aux entités essentielles et importantes de disposer d’un plan de continuité documenté, avec une obligation de signalement des incidents majeurs sous 24 heures. Le règlement DORA, applicable depuis le 17 janvier 2025 au secteur financier, impose de son côté des tests récurrents de résilience opérationnelle numérique. Mais l’obligation réglementaire ne garantit en rien l’efficacité opérationnelle du plan qu’elle impose. Un PRA PCA rédigé pour cocher une case de conformité tend à rester théorique, précisément parce que sa validation s’arrête à la relecture du document.

PRA, PCA, RTO, RPO : de quoi parle-t-on réellement

Ces sigles sont souvent confondus, alors qu’ils répondent à des questions différentes.

Le PCA, plan de continuité d’activité, couvre l’ensemble de l’organisation. Il répond à la question suivante, comment l’entreprise continue-t-elle à fonctionner, même en mode dégradé, pendant et après un sinistre majeur. Il englobe les aspects humains, organisationnels et de communication, pas seulement l’informatique.

Le PRA, plan de reprise d’activité, est un sous-ensemble du PCA centré sur le système d’information. Il décrit techniquement comment redémarrer les applications, les serveurs et les données après un incident.

Le RTO, recovery time objective, désigne la durée maximale d’interruption acceptable pour un système ou un processus donné avant que l’impact business ne devienne inacceptable. Le RPO, recovery point objective, désigne la quantité maximale de données que l’entreprise peut se permettre de perdre, mesurée en temps écoulé depuis la dernière sauvegarde exploitable. Ces deux indicateurs doivent être définis processus par processus, et non fixés arbitrairement pour l’ensemble du système d’information.

Construire un PRA PCA qui tient la route

La méthodologie de l’ANSSI structure la démarche de continuité d’activité en cinq étapes, le cadrage, l’analyse d’impact sur l’activité (BIA), l’identification des scénarios de sinistre, la définition des stratégies de reprise, puis la mise en œuvre et les tests. Voici les points à configurer concrètement.

Réaliser une analyse d’impact sur l’activité (BIA). Elle consiste à identifier, processus par processus, l’impact d’une interruption sur l’activité, et à en déduire un RTO et un RPO réalistes plutôt qu’arbitraires. Sans cette étape, les priorités de restauration se décident dans l’urgence plutôt que sur la base d’une analyse préparée en amont.

Isoler une copie de sauvegarde du réseau de production. Une copie air gap ou immuable, déconnectée du réseau de production, est la seule garantie qu’un rançongiciel ayant compromis le système d’information ne puisse pas également chiffrer ou supprimer les moyens de reprise. Une sauvegarde accessible depuis le même annuaire Active Directory que la production offre une protection largement illusoire.

Définir un ordre de priorité de restauration explicite. Redémarrer un serveur de messagerie avant l’ERP de facturation, ou l’inverse, est une décision métier qui doit avoir été prise à froid, en amont, et non négociée en pleine crise entre plusieurs directions.

Documenter un volet communication de crise séparé du volet technique. Porte-parole désignés, modèles de messages préparés à l’avance pour les clients, les partenaires et, le cas échéant, les autorités dans le cadre des obligations de notification NIS 2 ou DORA.

Tester le plan au moins une fois par an. À travers un exercice de simulation de crise ou un test de restauration réel. L’ANSSI considère qu’un PCA non testé depuis 18 mois ne peut plus être regardé comme opérationnel.

Erreurs fréquentes observées

Des sauvegardes accessibles depuis le réseau de production. Si un compte compromis peut atteindre le stockage de sauvegarde avec des droits d’écriture ou de suppression, un rançongiciel peut chiffrer ou effacer les sauvegardes avant même que l’équipe technique n’ait le temps de réagir.

Un RTO théorique très éloigné du temps de restauration réel. Sans test de restauration périodique, l’écart entre la promesse écrite et la durée réellement constatée peut se compter en jours, découvert au pire moment possible.

Un plan jamais mis à jour depuis sa rédaction initiale. L’architecture du système d’information évolue, mais le PRA PCA continue de décrire une infrastructure qui n’existe plus.

Une dépendance excessive à une seule personne. Les procédures de restauration détaillées ne sont connues que d’un administrateur en particulier, souvent absent au moment où l’incident se déclare.

Une documentation stockée uniquement sur le réseau compromis. Le classeur de procédures, les mots de passe d’urgence et les contacts des prestataires critiques deviennent eux-mêmes inaccessibles pendant l’incident.

Aucune articulation avec le volet réglementaire de notification. Les obligations de signalement sous 24 heures imposées par NIS 2 ne sont pas intégrées au plan opérationnel, ce qui ajoute une pression supplémentaire sur des équipes déjà mobilisées.

Vue pentest : ce qu’un PRA PCA "sur le papier" ne révèle pas

La robustesse d’un PRA PCA est l’un des points que nous évaluons systématiquement dans le cadre de nos audits d’infrastructure et de nos exercices de simulation d’attaque, indépendamment du contenu du document lui-même.

Un PRA PCA jamais testé en conditions réelles peut-il vraiment garantir une reprise ?

Non, et c’est précisément ce qu’un test d’intrusion permet de mettre en évidence avant qu’un attaquant ne le fasse à votre place. Un document validé en comité de direction ne dit rien de sa capacité réelle à fonctionner un dimanche soir, avec une partie du système d’information indisponible et une équipe restreinte.

Ce que nos pentesters vérifient systématiquement, au-delà de la simple existence du plan :

L’isolement réel des sauvegardes vis-à-vis du réseau de production. En tentant, dans le cadre autorisé de la mission, d’atteindre le stockage de sauvegarde depuis un poste compromis, un scénario proche de celui que nous décrivons dans notre article sur le Pass-the-Hash.

Le temps de restauration effectif d’un système critique. Comparé au RTO annoncé dans le document.

L’accessibilité de la documentation de crise elle-même. En cas d’indisponibilité totale du réseau interne, y compris de la messagerie et de l’intranet.

La cohérence entre l’ordre de priorité de restauration documenté et les dépendances techniques réelles. Souvent découvertes uniquement au moment du test, comme le révèle une cartographie complète via un pentest Active Directory.

La résistance du plan de communication de crise. À un scénario où les canaux habituels, messagerie professionnelle en tête, sont eux-mêmes hors service.

Le message à retenir : un PRA PCA rédigé et un PRA PCA éprouvé sont deux choses différentes, et seule la seconde protège réellement l’entreprise le jour où elle en a besoin. C’est exactement la différence entre avoir coché une case de conformité et avoir vérifié que cette case correspond à une capacité de reprise qui fonctionne réellement, ce qu’un audit de sécurité permet de confirmer ou d’infirmer.