En une phrase. Le PRA (plan de reprise d’activité) est le dispositif technique et organisationnel — documenté et testé — qui permet de reconstruire ou de basculer le système d’information après un sinistre majeur, dans des délais mesurés par deux indicateurs : le RTO (Recovery Time Objective, durée maximale de reconstruction) et le RPO (Recovery Point Objective, quantité maximale de données perdues), fixés par le métier et non par la technique.
L’incendie du datacenter OVHcloud de Strasbourg (10 mars 2021, destruction du bâtiment SBG2, 3,6 millions de sites web affectés) a offert au marché français une leçon grandeur nature : des centaines d’entreprises ont découvert que leurs sauvegardes étaient hébergées dans le même bâtiment que leur production. Plusieurs jugements ont depuis condamné l’hébergeur à indemniser des clients — mais les tribunaux ont aussi rappelé que la responsabilité de l’architecture de secours incombe d’abord au client.
Ce guide couvre la démarche PRA de bout en bout : RTO/RPO, architectures de secours, coûts réels, tests, et le cadre juridique qui rend désormais le PRA obligatoire pour beaucoup d’organisations. Le PRA s’articule avec le PCA et s’inscrit dans la politique de sécurité des systèmes d’information (PSSI) de l’organisation.
Points clés
- RTO = durée d’interruption tolérée ; RPO = données perdues tolérées. Les deux se décident au niveau métier, via le BIA du PCA.
- Quatre grandes architectures : reconstruction depuis sauvegardes (RTO en jours), site de secours froid/tiède (heures à jours), site chaud ou actif-actif (minutes à heures), DRaaS (réplication cloud à la demande).
- Règle de sauvegarde 3-2-1 : 3 copies, 2 supports, 1 hors site — plus une copie hors ligne/immuable à l’ère des rançongiciels.
- Obligations : NIS2 (art. 21), DORA (plans de rétablissement TIC), RGPD art. 32 (rétablir la disponibilité des données).
- Un PRA non testé échoue : les tests de bascule et de restauration complète sont la seule preuve.
1. RTO et RPO : les deux curseurs qui font le prix
Tout le dimensionnement d’un PRA découle de deux chiffres par application :
- RTO (la DMIA du vocabulaire SGDSN) : en combien de temps l’application doit être de nouveau opérationnelle.
- RPO (PDMA) : combien d’heures de données on accepte de perdre — déterminé par la fréquence de sauvegarde ou de réplication.
Ces valeurs ne se décrètent pas uniformément : un ERP de production peut exiger RTO 4 h / RPO 15 min, quand l’intranet documentaire tolère RTO 5 jours / RPO 24 h. Classer les applications en 3 ou 4 tiers de criticité — à partir de la cartographie du SI — évite de payer un secours haute disponibilité pour des systèmes secondaires.
2. Les architectures de secours et leurs coûts
| Stratégie | RTO typique | RPO typique | Coût indicatif |
|---|---|---|---|
| Restauration depuis sauvegardes externalisées | 2-10 jours | 4-24 h | Faible : coût du stockage + procédures |
| Site de secours froid (matériel à provisionner) | 2-5 jours | 4-24 h | Modéré |
| Site tiède (infrastructure prête, données répliquées périodiquement) | 4-24 h | 1-4 h | 30-60 % du coût de la production |
| Site chaud / actif-passif répliqué | 1-4 h | quelques minutes | 60-100 % de la production |
| Actif-actif multi-sites | quasi nul | quasi nul | > 100 % + complexité applicative |
| DRaaS (Disaster Recovery as a Service) | 1-8 h | 15 min-4 h | À la VM/mois : quelques dizaines d’€/VM + stockage + tests |
Pour une PME de 50 VM, un DRaaS sérieux se chiffre en 1 500 à 5 000 €/mois ; un site tiède en propre commence à plusieurs dizaines de milliers d’euros par an. À comparer au coût d’un arrêt : les études de place situent le coût médian d’interruption pour une PME entre plusieurs milliers et dizaines de milliers d’euros par heure selon le secteur.
Le point non négociable : les sauvegardes
Toute stratégie repose in fine sur les sauvegardes. Standard actuel : 3-2-1-1-0 — 3 copies, 2 supports, 1 hors site, 1 copie hors ligne ou immuable (WORM/air gap), 0 erreur de restauration vérifiée. Les rançongiciels modernes chiffrent ou suppriment d’abord les sauvegardes en ligne ; sans copie immuable, votre PRA est une hypothèse — le guide « Attaques par rançongiciels » de l’ANSSI en fait sa première recommandation. Et séparez géographiquement production et sauvegardes — la leçon OVH SBG2.
3. La démarche en 6 étapes
- Tiering applicatif : criticité, RTO/RPO par application, validés par la direction (c’est un arbitrage budgétaire, pas un choix technique).
- Choix des stratégies par tier : DRaaS pour le cœur, restauration simple pour le reste — la mixité est la norme.
- Mise en œuvre : réplication, automatisation (runbooks, infrastructure as code), gestion des dépendances (annuaire, DNS, licences, accès réseau, secrets — les oubliés classiques qui font échouer les bascules).
- Documentation : procédures de bascule et de retour arrière pas à pas, accessibles hors du SI, annuaire de crise, contrats prestataires.
- Tests : restauration unitaire mensuelle par échantillonnage, test de bascule applicative semestriel sur le tier 1, exercice de reconstruction complète annuel. Mesurez les RTO/RPO réels et comparez aux objectifs — l’écart est votre plan d’action.
- Maintien : revue à chaque changement d’architecture ; un PRA a la durée de vie de la cartographie qui le sous-tend.
4. Le cadre juridique : le PRA n’est plus optionnel
- RGPD, article 32 : obligation de « rétablir la disponibilité des données à caractère personnel et l’accès à celles-ci dans des délais appropriés en cas d’incident physique ou technique » — le PRA est littéralement dans le texte (voir sécurité des traitements). Une perte définitive de données personnelles est une violation notifiable à la CNIL sous 72 h (procédure).
- NIS2, article 21(2)© : sauvegardes et reprise des activités pour toutes les entités essentielles et importantes.
- DORA, articles 11-12 : plans de réponse et de rétablissement TIC, sites de sauvegarde et exigences de tests pour le secteur financier.
- Contrats et assurance cyber : les questionnaires assureurs exigent quasi systématiquement sauvegardes hors ligne testées et PRA documenté ; leur absence fonde des refus de garantie.
FAQ
Quelle différence entre PCA et PRA ?
Le PCA maintient les activités métier pendant la crise, au besoin sans informatique (procédures dégradées) ; le PRA reconstruit le système d’information. Le PRA est le volet IT du PCA, dimensionné par le BIA. Une organisation peut survivre trois jours sans SI avec un bon PCA — pas trois semaines sans PRA.
Quel RTO/RPO viser ?
Ceux que le métier peut justifier financièrement, ni plus ni moins. Une démarche saine : partir de l’impact horaire d’indisponibilité par application, et accepter des RTO longs sur tout ce qui n’est pas critique. Le sur-dimensionnement uniforme est la première cause de PRA abandonnés pour cause de coût.
Le cloud me dispense-t-il d’un PRA ?
Non. Le cloud déplace les risques (défaillance régionale, suppression de compte, erreur humaine, rançongiciel sur vos accès) mais ne les supprime pas. Un PRA cloud existe : sauvegardes hors du fournisseur principal ou sur compte isolé, multi-zones/multi-régions pour le tier 1, procédures de reconstruction testées. L’incendie OVH de 2021 l’a démontré à grande échelle.
Combien coûte un PRA pour une PME ?
Ordre de grandeur : 10 à 30 k€ de conception et de documentation (souvent avec accompagnement), puis un coût récurrent dominé par l’architecture retenue — de quelques centaines d’euros par mois (sauvegardes externalisées immuables) à plusieurs milliers (DRaaS sur le cœur applicatif). Les tests coûtent quelques jours-homme par an et sont le meilleur investissement du lot.
Conclusion
Un PRA se résume à trois preuves : des sauvegardes immuables et hors site, des procédures de reconstruction écrites et accessibles hors du SI, et des tests datés avec RTO/RPO mesurés. Tout ce qui n’a pas ces trois preuves est une intention. La réglementation — RGPD, NIS2, DORA — a transformé cette hygiène en obligation, et les assureurs en condition de garantie. Commencez par le test le plus simple : restaurez intégralement une application critique ce mois-ci, chronomètre en main.