Plan de reprise d'activité (PRA) : stratégie, obligations légales et mise en oeuvre technique

Le plan de reprise d’activité (PRA) est le dispositif qui permet à une organisation de restaurer ses systèmes d’information et de reprendre son fonctionnement nominal après un sinistre majeur. Si le plan de continuité d’activité (PCA) vise à maintenir les activités critiques pendant la crise, le PRA se concentre sur la phase de reconstruction : comment répartir de zéro – ou presque – lorsque les systèmes ont été détruits, corrompus ou rendus inaccessibles. Ce guide analyse les obligations juridiques applicables au PRA, les stratégies techniques disponibles et les étapes de sa mise en oeuvre.

I. Fondements juridiques du PRA

A. L’article 32 du RGPD : restauration des données

L’article 32, paragraphe 1, point c) du RGPD impose explicitement la mise en place de “moyens permettant de rétablir la disponibilité des données à caractère personnel et l’accès a celles-ci dans des délais appropriés en cas d’incident physique ou technique”. Cette formulation correspond exactement à l’objet du PRA.

La notion de “délais appropriés” est centrale. La CNIL ne fixe pas de durée universelle mais attend une justification documentée du délai de reprise retenu, fondée sur une analyse de risques préalable. Un délai de reprise de 72 heures peut être “approprié” pour un système secondaire mais totalement inadéquat pour un système hospitalier traitant des données de santé. Les obligations de l’article 32 doivent être lues à la lumière de la sensibilité des données traitées.

B. NIS2 : reprise d’activité et gestion des sauvegardes

L’article 21 de la directive NIS2 mentionné explicitement la “reprise des activités” 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 légale pour les entités concernées.

NIS2 va au-delà de la simple existence d’un PRA. L’article 21 impose également des “politiques et procédures visant à évaluer l’efficacité des mesures de gestion des risques”, ce qui implique que le PRA doit être testé régulièrement. La checklist de conformité NIS2 intègre le PRA et ses tests parmi les contrôles obligatoires.

C. Normes de référence

L’ISO 27031 fournit des lignes directrices spécifiques pour la préparation des TIC à la continuité d’activité, couvrant la stratégie de reprise, les solutions techniques et les tests. L’ISO 22301 traité plus largement de la continuité d’activité, dont la reprise est une composante. L’ISO 27001 intègre la continuité dans son Annexe A et exigé que le PRA soit aligné avec les objectifs de sécurité du SMSI.

II. Concepts techniques fondamentaux

A. RTO et RPO : les deux métriques essentielles

Le PRA est dimensionne par deux métriques issues du Business Impact Analysis (BIA) :

Le RTO (Recovery Time Objective) définit le délai maximal acceptable pour restaurer un système après un sinistre. Un RTO de 4 heures signifie que le système doit être opérationnel dans les 4 heures suivant la déclaration du sinistre. Le RTO conditionné l’architecture de reprise : plus le RTO est court, plus la solution technique est coûteuse.

Le RPO (Recovery Point Objective) définit la perte de données maximale acceptable, exprimée en durée. Un RPO de 1 heure signifie que les données produites dans la dernière heure avant le sinistre peuvent être perdues. Le RPO conditionné directement la fréquence des sauvegardes et la technologie de réplication.

B. Les niveaux de reprise (Tiers)

L’industrie a formalisé une échelle de niveaux de reprise, souvent appelee “Tiers” :

Tier 1 – Sauvegarde sur site distant. Les données sont sauvegardées et transportees (physiquement ou électroniquement) vers un site distant. Le RTO se mesure en jours. C’est la solution la moins coûteuse mais la plus lente.

Tier 2 – Site de secours froid (cold standby). Un site secondaire dispose des infrastructures de base (électricité, réseau, climatisation) mais les serveurs doivent être installés et configurés. RTO de 24 à 72 heures.

Tier 3 – Site de secours tiède (warm standby). Le site secondaire dispose de serveurs préconfigurés. Les données sont restaurées à partir des sauvegardes. RTO de 4 à 24 heures.

Tier 4 – Site de secours chaud (hot standby). Le site secondaire est une réplique quasi-complète du site primaire, avec réplication asynchrone des données. RTO de 1 à 4 heures.

Tier 5 – Replication synchrone avec basculement automatique. Les données sont répliquées en temps réel entre les deux sites. Le basculement est automatique en cas de défaillance. RTO proche de zéro, RPO zéro. C’est la solution la plus coûteuse.

C. Strategie de sauvegarde

La stratégie de sauvegarde est le fondement technique du PRA. La règle 3-2-1-1 est aujourd’hui le standard recommandé par l’ANSSI : 3 copies des données, sur 2 types de supports différents, dont 1 copie hors site et 1 copie immuable ou déconnectée.

Les types de sauvegarde se déclinent en trois catégories : la sauvegarde complète (copie intégrale des données), la sauvegarde différentielle (copie des modifications depuis la dernière sauvegarde complète) et la sauvegarde incrémentale (copie des modifications depuis la dernière sauvegarde, quelle qu’elle soit). Une stratégie typique combiné une sauvegarde complète hebdomadaire avec des incrémentales quotidiennes.

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

III. Élaboration du PRA : méthode structurée

A. Phase 1 : cadrage et inventaire

Le PRA commencé par un inventaire exhaustif des systèmes d’information : serveurs, applications, bases de données, équipements réseau, services cloud, interconnexions avec les partenaires. Chaque composant est classifié selon sa criticité (définie par le BIA) et ses dépendances techniques (un serveur d’application dépend de sa base de données, qui dépend du stockage, qui dépend du réseau).

La cartographie des dépendances est un exercice technique exigeant mais indispensable. Sans elle, l’ordre de restauration des systèmes ne peut être défini, ce qui conduit à des tentatives de reprise chaotiques ou des systèmes sont restaures avant leurs prérequis. La politique de sécurité doit imposer le maintien à jour de cette cartographie.

B. Phase 2 : définition de la stratégie de reprise

Pour chaque système ou groupe de systèmes, la stratégie de reprise est définie en fonction du RTO et du RPO assignes. Cette phase est un exercice d’arbitrage entre les exigences métier (RTO/RPO courts) et les contraintes techniques et budgétaires (solutions coûteuses).

Les solutions modernes offrent une palette élargie : réplication 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 intégrer les contraintes de localisation des données imposées par le RGPD.

C. Phase 3 : procédures de reprise

Chaque scénario de sinistre doit faire l’objet de procédures de reprise détaillées. Un PRA efficace contient :

• Les procédures de déclaration de sinistre : qui décide d’activer le PRA, sur quels critères, selon quel processus d’escalade.
• Les procédures de basculement : étapes techniques pour activer le site de secours, basculer les flux réseau, restaurer les données.
• L’ordre de restauration : séquence dans laquelle les systèmes doivent être restaures, en respectant les dépendances techniques.
• Les procédures de vérification : comment s’assurer que les systèmes restaures fonctionnent correctement et que les données sont intégrés.
• Les procédures de retour : comment revenir sur le site primaire une fois celui-ci rétabli.

D. Phase 4 : tests

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

Tests unitaires (trimestriels) : restauration d’une sauvegarde individuelle, vérification de l’intégrité des données, test de basculement d’un composant isolé.

Tests intégrés (semestriels) : restauration d’une chaîne applicative complète (application + base de données + middleware), vérification du fonctionnement de bout en bout.

Test global (annuel) : simulation d’un sinistre majeur avec activation complète du PRA sur un périmètre étendu. Cet exercice implique les équipes techniques, les métiers et la direction.

Chaque test doit produire un rapport documentant le scénario testé, les résultats obtenus (RTO et RPO effectifs vs ciblés), les anomalies constatées et le plan d’action correctif. Un audit de sécurité doit systématiquement vérifier la réalisation et les résultats des tests du PRA.

IV. Le PRA face aux rançongiciels : adaptations nécessaires

A. Le scénario de destruction totale

Les attaques par rançongiciel ont fondamentalement changé la nature des sinistres auxquels le PRA doit répondre. Un rançongiciel moderne ne se contente pas de chiffrer les postes de travail : il cible les serveurs, les bases de données, les sauvegardes en ligne et les systèmes de virtualisation. Le scénario de référence n’est plus la perte d’un site physique mais la destruction logique de l’ensemble du système d’information.

Cette réalité impose des adaptations du PRA. Les sauvegardes doivent être protégées contre le chiffrement malveillant par l’immutabilite ou la déconnexion. Le PRA doit prévoir la reconstruction à partir d’une infrastructure saine, ce qui suppose de disposer des supports d’installation des systèmes d’exploitation et des applications, des fichiers de configuration documentés et versionnés, et de sauvegardes dont l’intégrité a été vérifiée.

B. Le délai de reconstruction

L’expérience des cyberattaques majeures montré que la reconstruction d’un système d’information complètement compromis prend en général plusieurs semaines, voire plusieurs mois pour un retour complet à la normale. Les RTO définis en heures pour des scénarios de panne technique sont rarement tenables face à un rançongiciel généralise. Le PRA doit intégrer ce scénario avec des RTO réalistes et des procédures de fonctionnement en mode dégradé prolongé.

C. La question de l’investigation

Après une cyberattaque, il existe une tension entre la rapidité de la reprise et la nécessité de l’investigation numérique (forensics). Restaurer trop vite peut détruire les preuves nécessaires à la compréhension de l’attaque et à la prévention d’une récidive. Le PRA doit prévoir une phase d’investigation avant la restauration, en coordination avec la procédure de gestion de fuite de données si des données personnelles sont impactées.

V. PRA et cloud : opportunités et risques

L’adoption du cloud a transformé les stratégies de reprise. Les fournisseurs cloud offrent des mécanismes de redondance, de réplication et de basculement natifs qui simplifient considérablement la mise en oeuvre d’un PRA. Mais le cloud ne dispense pas d’un PRA : il en modifie les modalités.

Les risques spécifiques au cloud incluent la dépendance à un fournisseur unique (risque de lock-in), l’indisponibilite de la région 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 données lies à une erreur de configuration.

Le PRA cloud doit prévoir des sauvegardes indépendantes du fournisseur (multi-cloud ou hybride), des procédures de migration d’urgence et des mécanismes de portabilité des données. Le rôle du RSSI est de s’assurer que la stratégie cloud ne créé pas un point unique de défaillance.

La réglementation européenne est accessible sur EUR-Lex et les guides techniques de l’ANSSI fournissent des recommandations détaillées par secteur.

FAQ

Quelle est la différence entre PCA et PRA ?

Le PCA (plan de continuité d’activité) maintient les activités critiques pendant un sinistre, potentiellement en mode dégradé. Le PRA (plan de reprise d’activité) restaure les systèmes d’information à leur état nominal après le sinistre. Le PCA couvre la phase de survie, le PRA couvre la phase de reconstruction. Les deux sont complémentaires et généralement élaborés conjointement dans le cadre d’une stratégie globale de résilience.

Le PRA est-il juridiquement obligatoire ?

Oui, sous plusieurs textes. L’article 32 du RGPD exige la capacité de rétablir la disponibilité des données en cas d’incident. L’article 21 de NIS2 impose explicitement la reprise d’activité et la gestion des sauvegardes. Les secteurs réglementés (banque, assurance, santé) ont des obligations supplémentaires. L’absence de PRA constitue un manquement susceptible de sanctions.

À quelle fréquence 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 intégrés semestriels (restauration d’une chaîne applicative complète). Chaque test doit être documenté et les écarts entre les objectifs (RTO/RPO ciblés) et les résultats effectifs doivent faire l’objet d’un plan d’action correctif. NIS2 impose une évaluation régulière de l’efficacité des mesures.

Comment dimensionner le budget du PRA ?

Le budget du PRA dépend directement des RTO et RPO exigés par les métiers. Un RTO de quelques heures avec un RPO proche de zéro nécessité une réplication synchrone et un site de secours chaud, dont le coût annuel peut représenter 30 à 50% du budget d’infrastructure SI. Un RTO de 48 heures avec un RPO de 24 heures peut être atteint avec des sauvegardes quotidiennes et un site froid, pour un coût nettement inférieur. L’arbitrage se fait lors du BIA, en confrontant le coût de la solution technique au coût de l’interruption d’activité.