Plan de Reprise d'Activité (PRA) : guide ANSSI RTO RPO

En une phrase. Le Plan de Reprise d’Activité (PRA) est la composante technique du PCA : il décrit comment redémarrer le système d’information après un sinistre, dans des délais (RTO) et avec une perte de données (RPO) acceptables pour l’organisation. Son efficacité dépend des dépendances réellement rétablies, des décisions prises en crise et des exercices mesurés.

Un PRA ne se limite pas à un document : c’est une chaîne fonctionnelle testée (sauvegardes, sites, procédures, équipes) capable de remettre un SI en production après une interruption majeure. L’ANSSI distingue la reprise de la seule sauvegarde : sans procédure ni essai de restauration, l’organisation ne peut pas démontrer que ses données seront disponibles à temps. Ce guide détaille les composantes techniques et organisationnelles.

Pour le cadre général : PCA, sécurité du traitement et analyse de risques EBIOS.

Points clés

• RTO = délai cible de remise en service ; RPO = perte de données maximale tolérée.
• La règle 3-2-1 est une méthode de conception à adapter aux risques et aux objectifs métier.
• Une copie isolée ou protégée contre la modification réduit le risque de destruction simultanée des sauvegardes.
• La fréquence des exercices dépend du risque, des changements et des exigences applicables ; chaque exercice doit produire des preuves.
• NIS 2, DORA et le RGPD posent des obligations distinctes de continuité, de restauration et de disponibilité selon leur champ.

1. RTO et RPO : les deux indicateurs fondamentaux

Le PRA repose sur deux métriques :

• RTO (Recovery Time Objective) : délai maximum entre le sinistre et la remise en service de l’application.
• RPO (Recovery Point Objective) : ancienneté maximale des données récupérables (= perte de données acceptable).

Exemple concret : RTO 4h et RPO 15 min signifient que l’application doit être redémarrée en moins de 4 heures, avec au pire 15 minutes de transactions perdues.

Ces valeurs illustrent un arbitrage, pas un standard sectoriel. Le métier fixe d’abord la durée maximale d’interruption admissible et la perte maximale de données admissible. L’équipe technique vérifie ensuite si ces objectifs sont atteignables pour l’ensemble de la chaîne : réseau, identité, DNS, applications, données et validation fonctionnelle. Un RTO de quatre heures annoncé pour l’application n’a aucun sens si l’annuaire nécessaire à sa connexion exige huit heures.

Le plan de continuité d’activité décrit aussi le fonctionnement en mode dégradé pendant l’interruption. Le PRA peut rétablir le service informatique sans résoudre à lui seul la prise de commandes sur papier, les locaux indisponibles ou la communication aux clients.

2. La règle 3-2-1 (et ses évolutions)

Standard historique des sauvegardes :

• 3 copies de chaque donnée
• 2 supports différents (disque + bande, par exemple)
• 1 copie hors site

Évolution 3-2-1-1-0 post-ransomware :

• +1 copie immuable (WORM, S3 Object Lock)
• 0 erreur lors de la vérification de restauration

La séparation peut être physique ou logique selon l’architecture et les menaces. Une copie « immuable » n’est utile que si sa durée de rétention, ses comptes d’administration, ses clés et sa suppression sont maîtrisés. Vérifiez surtout qu’une personne autorisée peut effectivement la restaurer dans un environnement sain. Le guide de sauvegarde 3-2-1 détaille cette couche, qui reste une partie du PRA.

Pour chaque jeu de données, documentez le propriétaire, la fréquence de sauvegarde, la dernière exécution réussie, l’emplacement et la procédure de restauration. Une alerte « sauvegarde terminée » ne démontre ni l’intégrité du contenu ni la capacité à reconstruire l’application. Testez aussi les secrets, certificats, configurations et licences indispensables au redémarrage.

3. Types de sites de repli

Quatre architectures classiques :

Ne choisissez pas une solution sur la seule promesse commerciale de bascule. Examinez les zones de défaillance communes, les quotas disponibles pendant une crise, la connectivité, les sauvegardes de configuration et le temps nécessaire pour rétablir les accès. Une région cloud distincte peut partager l’identité, la facturation ou un fournisseur réseau avec la production. Faites constater ces dépendances par l’architecte et le propriétaire métier.

4. Architectures techniques de réplication

Trois grandes options existent, avec des compromis différents :

• Réplication synchrone : elle réduit la perte potentielle de transactions validées, mais dépend de la latence et peut propager une corruption.
• Réplication asynchrone : elle découple les sites, avec un retard variable à mesurer sous une charge représentative.
• Instantanés périodiques : ils offrent des points de retour, sous réserve de leur cohérence applicative et de leur protection.

Pour une base de données critique, confrontez les options à deux scénarios distincts : perte du site et compromission logique. Une réplication rapide peut propager un effacement malveillant ; une sauvegarde conservant des versions antérieures permet alors de revenir avant l’incident. Définissez qui choisit le point de reprise et comment les opérations perdues seront reconstituées.

5. Procédures de bascule documentées

Une procédure de bascule (runbook) doit contenir :

1. Critères de déclenchement (qui décide, sur quels indicateurs)
2. Séquence de bascule pas à pas (ordre des applications, dépendances)
3. Tests post-bascule (validation fonctionnelle par les métiers)
4. Communication (interne, clients, autorités)
5. Procédure de retour à la normale (souvent plus complexe que la bascule)

Le runbook doit pouvoir être exécuté par l’astreinte lorsque l’expert de l’application est indisponible. Ajoutez les prérequis vérifiables : accès d’urgence, coffre de secrets, console d’administration, contact du fournisseur, décision de la cellule de crise et critère de « retour en service ». Indiquez les étapes qui exigent une validation humaine, par exemple reconnecter une machine suspecte au réseau.

La décision de bascule doit avoir un suppléant et un journal horodaté. Notez la cause observée, les hypothèses encore ouvertes, le point de données retenu et la personne qui accepte la perte résiduelle. Après restauration, les métiers valident des transactions représentatives ; un serveur allumé ou une page d’accueil affichée ne prouvent pas que les commandes peuvent être traitées.

6. Tests du PRA : la condition de validité

Organisez des essais de portée croissante : restauration d’un échantillon choisi selon le risque, reprise applicative avec ses dépendances, exercice de crise réunissant décideurs et métiers, puis bascule réelle encadrée lorsque son risque est acceptable. Aucun calendrier unique ne vaut pour toutes les organisations.

Fixez un résultat observable avant chaque essai : durée jusqu’à validation métier, âge du dernier point restauré, étapes manuelles et écarts. Conservez journaux, captures, tickets et décisions, puis attribuez les corrections. Un exercice concluant sur une base vide ne valide pas le RPO annoncé. Si l’objectif échoue, révisez le plan ou l’architecture et recommencez sur le point en défaut. Réexaminez la périodicité après un changement d’application, de fournisseur ou d’équipe.

7. Reprise après un rançongiciel

Un rançongiciel peut toucher la production et les sauvegardes. Prévoyez une copie isolée ou protégée contre la modification, des droits d’administration distincts, la recherche d’un point antérieur à la compromission et la préservation des preuves utiles à l’enquête. Une simple bascule vers une réplique contaminée ne résout pas l’incident.

Ne déclenchez pas automatiquement la reconnexion du site de secours : l’équipe d’incident doit d’abord établir ce qui est sain. La reprise se fait dans une zone contrôlée, avec des identités renouvelées et une vérification de l’intégrité des images et des données. Prévoyez aussi la ressaisie des données du mode dégradé : responsable, ordre de traitement et contrôle des doublons.

8. Exigences réglementaires

Le RGPD article 32(1)© exige une capacité de rétablissement adaptée au risque ; il ne prescrit pas un RTO identique pour tous. La directive NIS 2 vise les entités dans son champ et cite la continuité, notamment sauvegardes, reprise et gestion de crise. DORA impose aux entités financières concernées des politiques de sauvegarde et procédures de restauration, testées périodiquement. Vérifiez toujours le champ et les règles de mise en œuvre avant de qualifier une organisation d’assujettie.

9. Spécificités sectorielles

• Santé : pour les prestations concernées, vérifier le périmètre du certificat HDS, les engagements contractuels et l’exercice de restauration.
• Finance : DORA requiert des méthodes adaptées à la criticité ; les objectifs concrets viennent de l’analyse métier et des exigences applicables.
• OIV : examiner les règles imposées au système d’information d’importance vitale concerné.
• Cloud qualifié : la qualification SecNumCloud ne dispense pas le client d’éprouver sa propre reprise applicative.

10. Coût d’un PRA

Chiffrez séparément la capacité de secours, le stockage des versions, le trafic de réplication, les licences, les connexions, les astreintes, les exercices et la remise en état après retour. Demandez un devis sur le scénario réel : une infrastructure de secours « à l’usage » peut coûter davantage lorsqu’elle fonctionne plusieurs jours. Comparez ce coût au dommage d’interruption établi avec les métiers, sans supposer qu’une architecture plus chère garantit un RTO plus court.

11. Erreurs fréquentes

• Sauvegardes non testées en restauration
• Sauvegardes sur le même réseau que la production (ransomware)
• RTO/RPO non validés par les métiers (trop ambitieux ou trop lâches)
• Dépendance à une seule personne pour la bascule
• Pas de procédure de retour à la normale documentée

12. Bonnes pratiques 2026

1. Définir la rétention selon le besoin métier et le scénario de compromission.
2. Tester régulièrement la restauration d’un échantillon représentatif.
3. Documenter la chaîne de dépendances applicatives et son ordre de démarrage.
4. Séparer les comptes de bureautique et d’administration des sauvegardes.
5. Programmer un exercice difficile et consigner les écarts constatés.

Du premier inventaire au PRA exploitable

Commencez par sélectionner deux ou trois services dont l’arrêt aurait un effet immédiat. Pour chacun, relevez le propriétaire métier, la durée d’interruption admissible, les dépendances, la dernière sauvegarde exploitable et le moyen de travailler en mode dégradé. Classez les autres services selon leur ordre de redémarrage. Cette première carte révèle souvent des dépendances communes : annuaire, messagerie, gestion des clés, accès au prestataire ou connexion entre sites.

Écrivez un scénario crédible par famille de sinistre : panne localisée, perte de site, erreur logique et compromission. Pour une panne de stockage, une réplique peut suffire ; pour une suppression volontaire propagée à tous les sites, il faut choisir un point de retour antérieur. Consignez les hypothèses : durée de coupure réseau, disponibilité du fournisseur, effectif d’astreinte et volume à transférer. Le métier valide la perte résiduelle acceptable.

Exemple hypothétique : l’ERP doit revenir en huit heures et au plus une heure de saisies peut être perdue. L’essai montre une restauration de la base en deux heures, mais l’annuaire et les certificats prennent sept heures supplémentaires. La mesure utile n’est pas « base restaurée » ; c’est « commande passée et confirmée » neuf heures après déclenchement. Le plan doit alors améliorer la dépendance ou faire accepter un délai différent par le métier. Reliez chaque écart à un propriétaire, une échéance et un nouvel essai.

Gardez la version du runbook, les coordonnées de secours et les accès d’urgence disponibles hors du SI primaire. Vérifiez-les après toute migration, modification d’identité ou changement de prestataire. Une cartographie du SI à jour et des mesures de sécurité proportionnées donnent le contexte, mais seule la restauration démontrée valide la capacité annoncée.

FAQ

Quelle est la différence entre PCA et PRA ?

Le PCA est le plan global de continuité des activités (humains, locaux, procédures). Le PRA est la composante technique IT : restauration des systèmes d’information. Toute organisation a besoin des deux, mais le PRA est inclus dans le PCA.

Quel RTO viser pour mon entreprise ?

Cela dépend du métier. L’analyse d’impact métier doit déterminer l’interruption acceptable par processus. L’objectif technique se négocie ensuite avec les responsables du service et les fournisseurs.

Une sauvegarde en cloud suffit-elle comme PRA ?

Non. Une sauvegarde n’est pas un PRA. Le PRA inclut : sauvegardes + procédures de restauration testées + infrastructure de redémarrage + équipes formées + tests réguliers. Une sauvegarde sans plan de restauration testé a peu de valeur en cas de sinistre majeur.

Comment se protéger contre le chiffrement des sauvegardes par ransomware ?

Combinez des versions de sauvegarde protégées, une séparation physique ou logique de la production et des comptes d’administration distincts. Avec S3 Object Lock, la protection dépend du mode choisi, de la rétention effectivement appliquée à chaque version d’objet et des droits de contournement : le mode governance peut être outrepassé par une identité autorisée, tandis que le mode compliance protège la version pendant sa période de rétention. Testez la restauration et vérifiez les permissions ; le nom de la fonction ne garantit pas à lui seul la disponibilité des copies.

Le PRA est-il obligatoire ?

Les textes fixent des obligations différentes selon l’entité et le service. NIS 2 mentionne la continuité, la reprise et les sauvegardes ; DORA impose aux entités financières concernées des politiques et procédures de sauvegarde et de restauration ; le RGPD exige une capacité de rétablissement proportionnée au risque. Un document intitulé « PRA » n’est pas exigé uniformément, mais un dispositif de reprise démontrable répond à leur objectif lorsque le périmètre est concerné.

Sources vérifiées le 27 septembre 2026 : mesures de résilience de l’ANSSI, directive NIS 2, article 21, règlement DORA, article 12, RGPD, article 32 et documentation AWS sur S3 Object Lock. Les rythmes d’exercice et les exemples chiffrés sont des choix à adapter, pas des seuils légaux universels.