PRA

01 — DéfinitionQu'est-ce qu'un PRA ?

Le PRA (Plan de reprise d'activité) est un document opérationnel qui décrit l'ensemble des procédures techniques et organisationnelles à exécuter pour redémarrer les systèmes d'information critiques après un incident majeur. L'incident peut être de nature très variée :

• Panne matérielle catastrophique (défaillance d'un datacenter, d'un SAN).
• Sinistre physique (incendie — cf. OVH Strasbourg en 2021, inondation, attentat).
• Attaque cyber massive (ransomware, destruction de données, wiper).
• Perte de service cloud d'un fournisseur critique.
• Erreur humaine majeure (suppression accidentelle massive, mauvais déploiement).

Le PRA est le volet informatique d'une démarche de continuité d'activité plus large. Il répond à une question simple mais difficile : comment reconstruire nos systèmes IT, avec quelles données, dans quels délais, avec quelles priorités ?

Un bon PRA n'est pas une simple stratégie de sauvegarde. C'est l'ensemble coordonné qui comprend : identification des systèmes critiques, objectifs de reprise quantifiés, architecture de secours, procédures détaillées, équipes mobilisées, plan de communication, critères de déclenchement, tests réguliers.

Un PRA non testé n'est qu'un document de conformité qui échouera au premier vrai incident. Les organisations matures testent leur PRA plusieurs fois par an, incluant des bascules complètes.

02 — DistinctionPCA vs PRA

Le PCA — vision globale

Le PCA (Plan de continuité d'activité) couvre la continuité globale de l'organisation face à un incident majeur. Il inclut des dimensions qui dépassent largement l'IT :

• Maintien des opérations métier (produire, vendre, servir les clients).
• Gestion des ressources humaines (télétravail, repli sur un autre site, équipes critiques).
• Communication interne et externe (clients, partenaires, médias, autorités).
• Logistique (fournisseurs, stocks, transports).
• Aspects juridiques, financiers, assurantiels.
• Sites de repli physique avec infrastructure de base.

Le PRA — composante IT du PCA

Le PRA est le volet technique et informatique du PCA. Il est centré sur la restauration des systèmes, applications et données. Le PRA permet au PCA de fonctionner : sans IT, la plupart des processus métier s'arrêtent.

Articulation

Les deux plans doivent être cohérents et articulés :

• Le PCA identifie les processus métier critiques et leurs délais d'arrêt tolérables.
• Le PRA décline ces délais en objectifs techniques de reprise pour chaque application associée.
• Les tests doivent être coordonnés : un exercice PCA teste la capacité métier, un exercice PRA teste la capacité technique.
• Le retour d'expérience de chacun nourrit l'autre.

Cas particulier — PSI et continuité opérationnelle

Certaines organisations parlent de PSI (Plan de secours informatique) pour désigner ce qui relève strictement de la reprise technique minimale. D'autres distinguent PRA (reprise complète après sinistre grave) et plan de continuité opérationnelle IT (maintien avec capacités réduites pendant un incident plus léger). La terminologie varie selon les référentiels et les organisations — l'important est la cohérence et la couverture.

03 — IndicateursRTO et RPO

RTO — Recovery Time Objective

Le RTO est le délai maximal acceptable pour remettre un système en service après un incident. Mesuré en temps (minutes, heures, jours). Répond à la question : combien de temps pouvons-nous tenir sans cette application ?

Exemples typiques :

• Application de paiement d'une grande banque : RTO < 15 minutes.
• ERP d'une entreprise industrielle : RTO de 4 à 24 heures.
• Outil de gestion RH non critique : RTO de plusieurs jours.
• Système d'archivage historique : RTO de plusieurs semaines acceptable.

RPO — Recovery Point Objective

Le RPO est la perte maximale de données acceptable, mesurée en temps. Répond à la question : combien de minutes/heures de données pouvons-nous tolérer de perdre ?

Exemples :

• Système de transactions financières : RPO = 0 (pas de perte tolérée).
• Base clients d'une e-commerce : RPO d'environ 15 minutes à 1 heure.
• Système de reporting : RPO de 24 heures possible.
• Archives historiques : RPO de plusieurs jours acceptable.

Impact technique

RTO et RPO guident le choix d'architecture et de technologie :

• RPO = 0 + RTO très court : réplication synchrone entre datacenters, basculement automatique, actif-actif. Coût élevé.
• RPO court + RTO quelques heures : réplication asynchrone, basculement semi-automatique, site de secours « chaud ».
• RPO 1 heure + RTO 24 heures : sauvegardes régulières, site de secours « tiède » prêt en quelques heures.
• RPO 24h + RTO plusieurs jours : sauvegardes classiques quotidiennes, site de secours « froid » à provisionner.

Analyse d'impact métier (BIA)

La définition des RTO/RPO passe par une BIA (Business Impact Analysis) : entretiens avec les métiers pour quantifier l'impact d'une indisponibilité ou d'une perte de données (financier, réglementaire, contractuel, image). La BIA est un prérequis indispensable — sans elle, les objectifs techniques ne sont pas alignés avec la valeur métier.

04 — ComposantsLes briques d'un PRA solide

Cartographie des systèmes critiques

Inventaire exhaustif des applications, infrastructures, bases de données, dépendances et flux. Classement par criticité avec RTO/RPO associés. La cartographie doit couvrir l'on-premise, le cloud, le SaaS, et les interdépendances entre les trois.

Architecture de secours

Infrastructure technique qui héberge les systèmes de secours :

• Site secondaire physique : datacenter distant, géographiquement séparé (typiquement > 50-100 km) du site principal.
• DRaaS (Disaster Recovery as a Service) : service cloud qui réplique et provisionne les systèmes à la demande. Acteurs typiques : Zerto, Veeam, Azure Site Recovery, Druva.
• Architecture cloud multi-région : pour les organisations cloud-native, réplication entre régions (eu-west-1 / eu-central-1 par exemple).
• Architecture multi-cloud : pour les fonctions les plus critiques, certains acteurs choisissent de distribuer entre plusieurs fournisseurs cloud pour réduire le risque d'indisponibilité fournisseur.

Stratégie de sauvegarde

Règle d'or actualisée pour le cyber : 3-2-1-1-0.

• 3 copies des données (production + 2 sauvegardes).
• 2 supports différents.
• 1 copie hors site.
• 1 copie immuable ou air-gapped (déconnectée du réseau production, inatteignable par un ransomware).
• 0 erreur lors des tests de restauration (tests réguliers indispensables).

Procédures détaillées (runbooks)

Documentation opérationnelle pas à pas pour chaque scénario :

• Conditions de déclenchement du PRA (qui décide, sur quels critères).
• Séquencement des opérations par ordre de priorité et de dépendance.
• Commandes exactes à exécuter (scripts, procédures console).
• Points de validation intermédiaires.
• Procédures de rollback si nécessaire.
• Procédures de retour à la normale après incident.

Organisation de crise

Dimension humaine cruciale :

• Équipes de crise identifiées avec rôles et responsabilités clairs.
• Chaînes d'astreinte et contacts d'urgence à jour (numéros personnels, adresses mail alternatives).
• Plan de communication interne et externe.
• Coordination avec les prestataires critiques.
• Interface avec les autorités et régulateurs (CNIL, ANSSI, ACPR selon les cas).

Infrastructure as Code et automation

Les organisations modernes automatisent massivement la reconstruction via :

• Terraform, CloudFormation, ARM templates pour l'infrastructure.
• Ansible, Chef, Puppet pour la configuration.
• GitOps pour les applications containerisées.
• Scripts d'orchestration pour la séquence de redémarrage complète.

Cette approche réduit considérablement le RTO en cas de reconstruction complète — quelques heures au lieu de plusieurs jours.

05 — RansomwareAdapter le PRA aux cyberattaques modernes

Les PRA traditionnels conçus pour des sinistres physiques (incendie, inondation) sont souvent inefficaces face aux ransomwares modernes. Les attaquants savent désormais cibler les sauvegardes elles-mêmes pour maximiser la pression de rançon.

Limites des PRA classiques

• Sauvegardes connectées au réseau production, accessibles depuis les serveurs compromis → chiffrées elles aussi.
• Réplication synchrone qui propage la corruption avant détection.
• Comptes administrateurs uniques partagés entre production et secours → compromission universelle.
• Absence de copie déconnectée physiquement.
• Tests limités à des scénarios de panne matérielle.

Adaptations nécessaires

Sauvegardes immuables

Technologies qui garantissent qu'une sauvegarde ne peut pas être modifiée ou supprimée, même par un administrateur compromis, pendant une durée définie. Offres courantes : AWS S3 Object Lock, Azure Immutable Blob Storage, Veeam Hardened Repository, Rubrik, Cohesity, Wasabi, Commvault Immutable Plane.

Sauvegardes air-gapped

Copies conservées physiquement déconnectées du réseau production : bandes sorties en coffre, serveurs isolés activés périodiquement, supports extraits après sauvegarde. Plus coûteux en opération mais niveau de protection maximal.

Séparation des domaines d'identité

L'infrastructure de sauvegarde et de secours ne doit pas partager les mêmes comptes administrateurs que la production. Idéalement, elle utilise un annuaire distinct, avec des comptes dédiés protégés par FIDO2, pour qu'une compromission de l'Active Directory production ne s'étende pas au domaine de secours.

Scénarios de test incluant le ransomware

Les tests PRA doivent désormais couvrir :

• Reconstruction complète à partir de zéro (bare metal reconstruction).
• Vérification d'intégrité des sauvegardes avant restauration.
• Restauration à une date antérieure au début de la compromission (parfois plusieurs semaines avant détection).
• Reconstruction de l'environnement Active Directory / Entra ID.
• Remise en service dans un environnement réputé sain (nouveau réseau, nouveaux certificats).

Plan d'investigation préalable à la restauration

Spécificité post-ransomware : on ne peut pas restaurer aveuglément sans avoir identifié et contenu la menace. Le PRA doit intégrer une phase d'investigation forensique pour déterminer jusqu'où remonter dans les sauvegardes (point avant compromission) et pour s'assurer que l'environnement de restauration est sain.

Retour d'expérience — Kaseya, NotPetya, MGM Resorts

Les cas majeurs récents (NotPetya 2017, Kaseya 2021, MGM Resorts 2023, Clorox 2023) ont tous démontré l'insuffisance des PRA classiques. Les entreprises qui s'en sont le mieux tirées avaient toutes : sauvegardes immuables, scénarios de tests récents couvrant le ransomware, et une capacité à reconstruire rapidement leur infrastructure d'identité.

06 — ConstructionMettre en place un PRA

07 — TestsMaintenir le PRA vivant

Typologie des tests

• Test sur table (tabletop exercise) : simulation verbale d'un scénario avec les équipes autour d'une table. Peu coûteux, utile pour valider les procédures et les rôles. Fréquence : trimestrielle à semestrielle.
• Test de restauration unitaire : restauration d'une application ou d'une base de données depuis les sauvegardes, en environnement isolé. Fréquence : mensuelle idéalement.
• Test de bascule partielle : basculement d'un sous-ensemble de systèmes sur le site de secours, production maintenue ailleurs. Fréquence : semestrielle.
• Test de bascule complète : basculement total avec production effective sur le site de secours pendant plusieurs heures ou plusieurs jours. Fréquence : annuelle pour les organisations matures.
• Exercice de crise cyber : simulation d'un incident cyber majeur avec déroulé réaliste, mobilisant les équipes métier, IT, sécurité, juridique et communication. Fréquence : au moins annuelle.

Règles pour des tests utiles

• Des scénarios réalistes et variés — ne pas tester toujours le même cas.
• Inclure des situations stressantes : certaines ressources clés indisponibles, communications dégradées, pression temporelle.
• Documenter systématiquement les écarts : RTO effectif vs cible, points bloquants, procédures incorrectes, compétences manquantes.
• Plan d'actions correctives suivi jusqu'à la résolution, pas oublié dans un tiroir.
• Rotation des équipes pour éviter que les tests dépendent de quelques personnes clés.

Coûts et bénéfices

Les tests représentent un coût réel (temps, infrastructure, parfois impact limité sur la production). Mais l'alternative — découvrir en condition réelle que son PRA ne fonctionne pas — coûte infiniment plus cher. La plupart des organisations victimes d'incidents majeurs témoignent a posteriori qu'elles auraient dû tester plus souvent et dans des conditions plus proches du réel.

Obligations réglementaires

Plusieurs textes imposent des tests documentés :

• DORA : tests réguliers documentés, TLPT tous les 3 ans pour les entités significatives.
• NIS2 : tests de résilience intégrés au dispositif global.
• RGPD article 32 : « procédure visant à tester, analyser et évaluer régulièrement » les mesures de sécurité.
• PCI DSS : tests annuels obligatoires des plans de continuité.
• ISO 22301 (spécifique continuité) : norme complète avec exigences de tests.

08 — FAQQuestions fréquentes

Combien coûte un PRA ?

Très variable selon le niveau d'exigence. Pour une PME avec un niveau de base (sauvegardes 3-2-1, site de secours tiède, tests annuels), compter quelques dizaines de milliers d'euros annuels. Pour une ETI avec DRaaS et site chaud : 100 000 à 500 000 €/an. Pour une grande entreprise avec exigences DORA ou NIS2 : plusieurs millions d'euros. Le bon dimensionnement résulte de l'arbitrage RTO/RPO vs budget.

DRaaS ou infrastructure propre ?

DRaaS recommandé pour la majorité des organisations de taille moyenne : pas d'infrastructure à maintenir en permanence, capacité à payer uniquement en cas d'activation, acteurs matures sur le marché. Infrastructure propre pertinente pour les très grandes organisations avec des exigences de souveraineté, des systèmes très spécifiques, ou une économie d'échelle justifiant l'investissement.

Un PRA couvre-t-il les SaaS ?

Partiellement et c'est un angle mort classique. Les SaaS (Microsoft 365, Salesforce, Google Workspace) ont leur propre résilience d'infrastructure, mais ne protègent pas contre la perte de données de votre côté (suppression accidentelle, ransomware, malveillance d'utilisateur). Un PRA moderne inclut des solutions de sauvegarde tierces pour les SaaS critiques (Veeam Backup for M365, Druva, Spanning, AvePoint).

Le cloud rend-il le PRA obsolète ?

Non, il le transforme. Le cloud facilite certaines briques (réplication multi-région, provisioning rapide) mais introduit de nouveaux risques : erreurs de configuration, compromission de comptes cloud, indisponibilité régionale, verrouillage fournisseur. Un PRA cloud-native reste indispensable, simplement avec des outils et patterns différents de l'approche datacenter traditionnelle.

Qui doit porter le PRA dans l'organisation ?

Responsabilité partagée. La direction générale valide et finance. La DSI porte la construction technique. Le RSSI intègre les aspects cyber. Les métiers définissent les priorités via la BIA. Un responsable PRA ou responsable continuité d'activité est souvent désigné pour la coordination — poste à temps partiel en PME, à temps plein en grande entreprise. DORA et NIS2 exigent un engagement explicite de la direction au plus haut niveau.