Un incendie de datacenter, un ransomware, une simple erreur humaine… et toute l’activité s’arrête. La question n’est plus « si », mais « quand ». Un Plan de Reprise (PRA) et un Plan de Continuité (PCA) transforment une catastrophe potentielle en interruption maîtrisée. Encore faut-il les bâtir sur les bonnes bases — et les tester.
Beaucoup d’organisations pensent en avoir un… jusqu’au jour où il faut s’en servir. Voici comment poser un plan réellement fiable, en commençant par les deux chiffres qui structurent tout : le RTO et le RPO.
1. PRA, PCA : de quoi parle-t-on ?
Le PCA (Plan de Continuité d’Activité) vise à maintenir l’activité, même en mode dégradé, pendant l’incident — c’est la vue métier. Le PRA (Plan de Reprise d’Activité) vise à remettre le SI en service après un sinistre — c’est la vue technique.
À retenir
Le PCA répond à « comment continuer à travailler ? », le PRA à « comment remettre le SI debout ? ». Les deux se complètent : l’un pour l’activité, l’autre pour l’informatique.
2. Les 2 chiffres qui structurent tout : RTO et RPO
Avant toute solution technique, deux objectifs à fixer par service : combien de temps peut-on rester sans lui, et combien de données peut-on se permettre de perdre.
RPO (Recovery Point Objective) : la quantité de données que l’on accepte de perdre — pilotée par la fréquence des sauvegardes. RTO (Recovery Time Objective) : le délai maximal pour rétablir le service — piloté par la stratégie de reprise.
3. Par où commencer : la méthode en 5 étapes
1 · Analyse d’impact (BIA)
Identifier les activités critiques et leurs dépendances, puis en déduire un RTO et un RPO pour chaque service.
2 · Définir la stratégie de reprise
Sauvegardes, réplication, site de secours : le bon niveau selon les RTO/RPO visés et le budget disponible.
3 · Documenter le plan
Procédures pas à pas, rôles et contacts, ordre de redémarrage des applications et de leurs dépendances.
4 · Tester régulièrement
Un plan non testé est une fiction. Exercices planifiés, puis inopinés, pour révéler les angles morts.
5 · Maintenir à jour
Le SI évolue, le plan aussi : revue après chaque changement majeur d’architecture ou d’application.
4. La stratégie dépend du RTO visé
Plus le RTO est court, plus la solution est sophistiquée — et coûteuse. On dimensionne donc par criticité : les services vitaux d’abord.
5. Sauvegardes : la base non négociable
- Règle 3-2-1 : 3 copies, 2 supports, 1 hors site / hors ligne.
- Immuabilité : des copies que ni un attaquant ni une erreur ne peuvent modifier.
- Isolation : la sauvegarde n’est pas accessible avec les identifiants du SI courant.
- Tests de restauration réguliers : une sauvegarde jamais restaurée n’existe pas vraiment.
6. Les idées reçues
« On a des sauvegardes, donc un PRA »
Une sauvegarde n’est pas un plan. Sans procédure, site cible ni test de restauration, la reprise s’improvise dans l’urgence.
« Le cloud nous rend résilients »
Le cloud offre des briques, mais la résilience se conçoit : redondance, sauvegardes isolées, RTO/RPO définis.
« Un plan écrit une fois suffit »
Un plan non testé et non maintenu échoue le jour J. Il vit avec le SI et se répète.
« C’est trop cher pour nous »
On dimensionne par criticité : tout n’a pas le même RTO. Les services vitaux d’abord, le reste ensuite.
7. Votre checklist PRA / PCA
Cadrer
- Activités critiques et dépendances identifiées (BIA)
- RTO et RPO définis par service
- Rôles et cellule de crise désignés
Mettre en œuvre
- Sauvegardes immuables 3-2-1 testées
- Réplication / site de secours dimensionné selon les RTO
- Procédures de reprise documentées (ordre de redémarrage)
Vérifier
- Exercices de reprise planifiés (au moins annuels)
- Plan revu après chaque changement majeur
- Contacts et accès de secours à jour
8. Questions fréquentes
Quelle différence entre une sauvegarde et un PRA ?
La sauvegarde protège les données ; le PRA organise la remise en service — procédures, site cible, ordre de redémarrage. L’un ne remplace pas l’autre.
À quelle fréquence tester le plan ?
Au moins une fois par an, idéalement par service critique, et après tout changement majeur. Un test révèle toujours des surprises qu’il vaut mieux découvrir à froid.
Faut-il forcément un second site ?
Cela dépend du RTO. Un RTO court impose de la réplication et un site de secours ; un RTO plus large peut se contenter de sauvegardes externalisées et testées.
Comment se protéger du ransomware dans le PRA ?
Par des sauvegardes immuables et isolées : si le SI est chiffré, on restaure depuis une copie que l’attaquant ne peut pas atteindre — sans payer.
Votre plan de reprise tiendrait-il le jour J ?
ZENISEC conçoit, teste et industrialise vos PRA/PCA — de l’analyse d’impact au site de secours.
Bâtir mon plan de reprise →
Découvrir notre expertise Infrastructure →
Cas concret : Migration de datacenter & rebuild du S.I d’un groupe mutualiste →
Les commentaires sont fermés