Le plan de reprise d’activite (PRA) est le dispositif qui permet a une organisation de restaurer ses systemes d’information et de reprendre son fonctionnement nominal apres un sinistre majeur. Si le plan de continuite d’activite (PCA) vise a maintenir les activites critiques pendant la crise, le PRA se concentre sur la phase de reconstruction : comment repartir de zero – ou presque – lorsque les systemes ont ete detruits, corrompus ou rendus inaccessibles. Ce guide analyse les obligations juridiques applicables au PRA, les strategies techniques disponibles et les etapes de sa mise en oeuvre.

I. Fondements juridiques du PRA

A. L’article 32 du RGPD : restauration des donnees

L’article 32, paragraphe 1, point c) du RGPD impose explicitement la mise en place de “moyens permettant de retablir la disponibilite des donnees a caractere personnel et l’acces a celles-ci dans des delais appropries en cas d’incident physique ou technique”. Cette formulation correspond exactement a l’objet du PRA.

La notion de “delais appropries” est centrale. La CNIL ne fixe pas de duree universelle mais attend une justification documentee du delai de reprise retenu, fondee sur une analyse de risques prealable. Un delai de reprise de 72 heures peut etre “approprie” pour un systeme secondaire mais totalement inadequat pour un systeme hospitalier traitant des donnees de sante. Les obligations de l’article 32 doivent etre lues a la lumiere de la sensibilite des donnees traitees.

B. NIS2 : reprise d’activite et gestion des sauvegardes

L’article 21 de la directive NIS2 mentionne explicitement la “reprise des activites” et la “gestion des sauvegardes” parmi les mesures de gestion des risques obligatoires. Le PRA n’est donc plus une bonne pratique : c’est une obligation legale pour les entites concernees.

NIS2 va au-dela de la simple existence d’un PRA. L’article 21 impose egalement des “politiques et procedures visant a evaluer l’efficacite des mesures de gestion des risques”, ce qui implique que le PRA doit etre teste regulierement. La checklist de conformite NIS2 integre le PRA et ses tests parmi les controles obligatoires.

C. Normes de reference

L’ISO 27031 fournit des lignes directrices specifiques pour la preparation des TIC a la continuite d’activite, couvrant la strategie de reprise, les solutions techniques et les tests. L’ISO 22301 traite plus largement de la continuite d’activite, dont la reprise est une composante. L’ISO 27001 integre la continuite dans son Annexe A et exige que le PRA soit aligne avec les objectifs de securite du SMSI.

II. Concepts techniques fondamentaux

A. RTO et RPO : les deux metriques essentielles

Le PRA est dimensionne par deux metriques issues du Business Impact Analysis (BIA) :

Le RTO (Recovery Time Objective) definit le delai maximal acceptable pour restaurer un systeme apres un sinistre. Un RTO de 4 heures signifie que le systeme doit etre operationnel dans les 4 heures suivant la declaration du sinistre. Le RTO conditionne l’architecture de reprise : plus le RTO est court, plus la solution technique est couteuse.

Le RPO (Recovery Point Objective) definit la perte de donnees maximale acceptable, exprimee en duree. Un RPO de 1 heure signifie que les donnees produites dans la derniere heure avant le sinistre peuvent etre perdues. Le RPO conditionne directement la frequence des sauvegardes et la technologie de replication.

B. Les niveaux de reprise (Tiers)

L’industrie a formalise une echelle de niveaux de reprise, souvent appelee “Tiers” :

Tier 1 – Sauvegarde sur site distant. Les donnees sont sauvegardees et transportees (physiquement ou electroniquement) vers un site distant. Le RTO se mesure en jours. C’est la solution la moins couteuse mais la plus lente.

Tier 2 – Site de secours froid (cold standby). Un site secondaire dispose des infrastructures de base (electricite, reseau, climatisation) mais les serveurs doivent etre installes et configures. RTO de 24 a 72 heures.

Tier 3 – Site de secours tiede (warm standby). Le site secondaire dispose de serveurs preconfigures. Les donnees sont restaurees a partir des sauvegardes. RTO de 4 a 24 heures.

Tier 4 – Site de secours chaud (hot standby). Le site secondaire est une replique quasi-complete du site primaire, avec replication asynchrone des donnees. RTO de 1 a 4 heures.

Tier 5 – Replication synchrone avec basculement automatique. Les donnees sont repliquees en temps reel entre les deux sites. Le basculement est automatique en cas de defaillance. RTO proche de zero, RPO zero. C’est la solution la plus couteuse.

C. Strategie de sauvegarde

La strategie de sauvegarde est le fondement technique du PRA. La regle 3-2-1-1 est aujourd’hui le standard recommande par l’ANSSI : 3 copies des donnees, sur 2 types de supports differents, dont 1 copie hors site et 1 copie immuable ou deconnectee.

Les types de sauvegarde se declinent en trois categories : la sauvegarde complete (copie integrale des donnees), la sauvegarde differentielle (copie des modifications depuis la derniere sauvegarde complete) et la sauvegarde incrementale (copie des modifications depuis la derniere sauvegarde, quelle qu’elle soit). Une strategie typique combine une sauvegarde complete hebdomadaire avec des incrementales quotidiennes.

Le chiffrement des sauvegardes est une obligation de fait sous le RGPD : des sauvegardes non chiffrees constituent un risque de fuite de donnees en cas de perte ou de vol du support.

III. Elaboration du PRA : methode structuree

A. Phase 1 : cadrage et inventaire

Le PRA commence par un inventaire exhaustif des systemes d’information : serveurs, applications, bases de donnees, equipements reseau, services cloud, interconnexions avec les partenaires. Chaque composant est classifie selon sa criticite (definie par le BIA) et ses dependances techniques (un serveur d’application depend de sa base de donnees, qui depend du stockage, qui depend du reseau).

La cartographie des dependances est un exercice technique exigeant mais indispensable. Sans elle, l’ordre de restauration des systemes ne peut etre defini, ce qui conduit a des tentatives de reprise chaotiques ou des systemes sont restaures avant leurs prerequis. La politique de securite doit imposer le maintien a jour de cette cartographie.

B. Phase 2 : definition de la strategie de reprise

Pour chaque systeme ou groupe de systemes, la strategie de reprise est definie en fonction du RTO et du RPO assignes. Cette phase est un exercice d’arbitrage entre les exigences metier (RTO/RPO courts) et les contraintes techniques et budgetaires (solutions couteuses).

Les solutions modernes offrent une palette elargie : replication vers le cloud public (Azure Site Recovery, AWS Disaster Recovery), solutions de DRaaS (Disaster Recovery as a Service), virtualisation des environnements de secours, conteneurisation facilitant le redeploiement rapide. Le choix entre solutions on-premise et cloud doit integrer les contraintes de localisation des donnees imposees par le RGPD.

C. Phase 3 : procedures de reprise

Chaque scenario de sinistre doit faire l’objet de procedures de reprise detaillees. Un PRA efficace contient :

• Les procedures de declaration de sinistre : qui decide d’activer le PRA, sur quels criteres, selon quel processus d’escalade.
• Les procedures de basculement : etapes techniques pour activer le site de secours, basculer les flux reseau, restaurer les donnees.
• L’ordre de restauration : sequence dans laquelle les systemes doivent etre restaures, en respectant les dependances techniques.
• Les procedures de verification : comment s’assurer que les systemes restaures fonctionnent correctement et que les donnees sont integres.
• Les procedures de retour : comment revenir sur le site primaire une fois celui-ci retabli.

D. Phase 4 : tests

Les tests du PRA sont une obligation, pas une option. L’ANSSI recommande une approche progressive :

Tests unitaires (trimestriels) : restauration d’une sauvegarde individuelle, verification de l’integrite des donnees, test de basculement d’un composant isole.

Tests integres (semestriels) : restauration d’une chaine applicative complete (application + base de donnees + middleware), verification du fonctionnement de bout en bout.

Test global (annuel) : simulation d’un sinistre majeur avec activation complete du PRA sur un perimetre etendu. Cet exercice implique les equipes techniques, les metiers et la direction.

Chaque test doit produire un rapport documentant le scenario teste, les resultats obtenus (RTO et RPO effectifs vs cibles), les anomalies constatees et le plan d’action correctif. Un audit de securite doit systematiquement verifier la realisation et les resultats des tests du PRA.

IV. Le PRA face aux rancongiciels : adaptations necessaires

A. Le scenario de destruction totale

Les attaques par rancongiciel ont fondamentalement change la nature des sinistres auxquels le PRA doit repondre. Un rancongiciel moderne ne se contente pas de chiffrer les postes de travail : il cible les serveurs, les bases de donnees, les sauvegardes en ligne et les systemes de virtualisation. Le scenario de reference n’est plus la perte d’un site physique mais la destruction logique de l’ensemble du systeme d’information.

Cette realite impose des adaptations du PRA. Les sauvegardes doivent etre protegees contre le chiffrement malveillant par l’immutabilite ou la deconnexion. Le PRA doit prevoir la reconstruction a partir d’une infrastructure saine, ce qui suppose de disposer des supports d’installation des systemes d’exploitation et des applications, des fichiers de configuration documentes et versionnes, et de sauvegardes dont l’integrite a ete verifiee.

B. Le delai de reconstruction

L’experience des cyberattaques majeures montre que la reconstruction d’un systeme d’information completement compromis prend en general plusieurs semaines, voire plusieurs mois pour un retour complet a la normale. Les RTO definis en heures pour des scenarios de panne technique sont rarement tenables face a un rancongiciel generalise. Le PRA doit integrer ce scenario avec des RTO realistes et des procedures de fonctionnement en mode degrade prolonge.

C. La question de l’investigation

Apres une cyberattaque, il existe une tension entre la rapidite de la reprise et la necessite de l’investigation numerique (forensics). Restaurer trop vite peut detruire les preuves necessaires a la comprehension de l’attaque et a la prevention d’une recidive. Le PRA doit prevoir une phase d’investigation avant la restauration, en coordination avec la procedure de gestion de fuite de donnees si des donnees personnelles sont impactees.

V. PRA et cloud : opportunites et risques

L’adoption du cloud a transforme les strategies de reprise. Les fournisseurs cloud offrent des mecanismes de redondance, de replication et de basculement natifs qui simplifient considerablement la mise en oeuvre d’un PRA. Mais le cloud ne dispense pas d’un PRA : il en modifie les modalites.

Les risques specifiques au cloud incluent la dependance a un fournisseur unique (risque de lock-in), l’indisponibilite de la region cloud (panne AWS us-east-1 en 2017 qui a impacte des milliers d’entreprises), les modifications unilaterales des conditions de service et les risques de perte de donnees lies a une erreur de configuration.

Le PRA cloud doit prevoir des sauvegardes independantes du fournisseur (multi-cloud ou hybride), des procedures de migration d’urgence et des mecanismes de portabilite des donnees. Le role du RSSI est de s’assurer que la strategie cloud ne cree pas un point unique de defaillance.

La reglementation europeenne est accessible sur EUR-Lex et les guides techniques de l’ANSSI fournissent des recommandations detaillees par secteur.

FAQ

Quelle est la difference entre PCA et PRA ?

Le PCA (plan de continuite d’activite) maintient les activites critiques pendant un sinistre, potentiellement en mode degrade. Le PRA (plan de reprise d’activite) restaure les systemes d’information a leur etat nominal apres le sinistre. Le PCA couvre la phase de survie, le PRA couvre la phase de reconstruction. Les deux sont complementaires et generalement elabores conjointement dans le cadre d’une strategie globale de resilience.

Le PRA est-il juridiquement obligatoire ?

Oui, sous plusieurs textes. L’article 32 du RGPD exige la capacite de retablir la disponibilite des donnees en cas d’incident. L’article 21 de NIS2 impose explicitement la reprise d’activite et la gestion des sauvegardes. Les secteurs reglementes (banque, assurance, sante) ont des obligations supplementaires. L’absence de PRA constitue un manquement susceptible de sanctions.

A quelle frequence faut-il tester le PRA ?

Un test global annuel est le minimum. Les bonnes pratiques recommandent des tests unitaires trimestriels (restauration de sauvegardes, test de composants isoles) et des tests integres semestriels (restauration d’une chaine applicative complete). Chaque test doit etre documente et les ecarts entre les objectifs (RTO/RPO cibles) et les resultats effectifs doivent faire l’objet d’un plan d’action correctif. NIS2 impose une evaluation reguliere de l’efficacite des mesures.

Comment dimensionner le budget du PRA ?

Le budget du PRA depend directement des RTO et RPO exiges par les metiers. Un RTO de quelques heures avec un RPO proche de zero necessite une replication synchrone et un site de secours chaud, dont le cout annuel peut representer 30 a 50% du budget d’infrastructure SI. Un RTO de 48 heures avec un RPO de 24 heures peut etre atteint avec des sauvegardes quotidiennes et un site froid, pour un cout nettement inferieur. L’arbitrage se fait lors du BIA, en confrontant le cout de la solution technique au cout de l’interruption d’activite.