5.2Plan de sauvegarde & reprise d'activité
L'essentiel en 30 secondes
- Sauvegarder ne suffit pas : le PRA décrit comment repartir après un sinistre, le PCA comment maintenir l'activité pendant l'incident.
- RTO = délai maximal de reprise ; RPO = perte de données tolérable — ces deux repères dimensionnent le plan et justifient le budget.
- Un plan non testé n'est pas un plan : exercices de restauration et documentation à jour rendent la reprise réelle, pas théorique.
Mini-cas filé — Sofiane esquisse le PRA de la paie
Sofiane, technicien support dans une PME de distribution à Alger, constate que l'entreprise a des sauvegardes mais aucun plan de reprise. Il esquisse un PRA minimal pour le service de paie, critique en fin de mois. Il raisonne en principes : ce service tolère très peu de perte de données, donc des sauvegardes rapprochées et un délai de reprise court — sans fixer de durée chiffrée, il retient surtout que ces objectifs se décident avec la direction selon les contraintes du métier. Il liste ce qu'il faut restaurer et dans quel ordre, note qui fait quoi, puis planifie un exercice de restauration. Il transforme « on a des sauvegardes » en « on sait redémarrer ».
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 5.2.
1. De la sauvegarde au plan
Sauvegarder est nécessaire mais insuffisant. Un plan de reprise d'activité (PRA) décrit comment repartir après un sinistre (panne majeure, incendie, rançongiciel) : quoi restaurer, dans quel ordre, par qui, avec quelles ressources. Le plan de continuité (PCA) vise, lui, à maintenir l'activité pendant l'incident. Sofiane retient la phrase simple : on passe de « on a des sauvegardes » à « on sait redémarrer ».
2. RTO et RPO, les deux repères
Deux objectifs structurent le plan. Le RTO (Recovery Time Objective) : en combien de temps doit-on être reparti ? Le RPO (Recovery Point Objective) : quelle quantité de données peut-on accepter de perdre ? Un RPO serré impose des sauvegardes rapprochées ; un RTO serré impose une procédure rapide et des ressources prêtes. Ces repères dictent l'investissement — Sofiane les fait valider avec la direction, service par service, sans imposer de valeur toute faite.
3. Un plan non testé n'est pas un plan
Comme pour les sauvegardes, un PRA se teste : exercices de restauration, simulations de sinistre, mise à jour de la documentation. Un plan écrit une fois puis oublié échoue le jour J (contacts périmés, procédure incomplète, ressources indisponibles). Sofiane planifie donc des exercices réguliers pour que le plan reste réel, pas théorique.
🔎 Exemple concret — 🔎 Exemple concret — Raisonner RTO et RPO pour la paie
Sofiane raisonne en principes sur un service critique, sans imposer de valeur chiffrée toute faite :
RPO serré → sauvegardes plus fréquentes (moins de données perdues)
RTO serré → procédure rapide + ressources prêtes (reprise plus vite)
→ ces repères se décident avec la direction, service par serviceLecture : le RPO pilote la fréquence des sauvegardes ; le RTO pilote la rapidité de la reprise.
Leçon : sans repères définis avec le métier, impossible de dimensionner (ni de justifier) le plan.
Vocabulaire de la section
- PRA
- Plan de reprise d'activité : comment repartir après un sinistre.
Exemple simple : Sofiane esquisse le PRA du service de paie.
Ce que ce n'est pas : croire que les sauvegardes suffisent.
Réflexe : PRA = comment repartir.
- PCA
- Plan de continuité d'activité : maintenir l'activité pendant l'incident.
Exemple simple : Sofiane prévoit comment la paie tourne en mode dégradé.
Ce que ce n'est pas : confondre maintien (PCA) et reprise (PRA).
Réflexe : PCA = continuer pendant.
- RTO
- Durée maximale acceptable pour être de nouveau opérationnel.
Exemple simple : Sofiane le fixe avec la direction pour chaque service.
Ce que ce n'est pas : un délai choisi sans lien avec le métier.
Réflexe : RTO = délai de reprise.
- RPO
- Quantité de données maximale qu'on accepte de perdre.
Exemple simple : Un RPO serré pousse à des sauvegardes rapprochées.
Ce que ce n'est pas : l'oublier et découvrir la perte le jour J.
Réflexe : RPO = perte de données tolérable.
- Exercice de reprise
- Test réel qui vérifie que le plan fonctionne.
Exemple simple : Sofiane planifie un exercice de restauration de la paie.
Ce que ce n'est pas : un PRA écrit puis jamais testé.
Réflexe : tester le plan régulièrement.
En pratique — En pratique — Esquisser un PRA minimal
- Choisissez un service critique (comme la paie chez Sofiane) et déterminez avec le métier ses repères : délai de reprise (RTO) et perte de données tolérable (RPO).
- Listez ce qu'il faut restaurer et dans quel ordre pour le remettre en route (dépendances d'abord).
- Notez qui fait quoi et quelles ressources sont nécessaires pendant la reprise.
- Planifiez un exercice de restauration pour valider le plan sur le terrain.
Script pas-à-pas — esquisser son plan comme Sofiane (8 min)
1) Nommez un service critique et fixez avec le métier ses repères RTO et RPO. 2) Listez les éléments à restaurer et leur ordre, en respectant les dépendances. 3) Écrivez qui fait quoi et les ressources requises. 4) Datez un premier exercice de restauration. 5) Notez où sont stockées les sauvegardes et comment y accéder sans le système principal. 6) Relisez le plan comme s'il devait servir par une personne absente.
Un plan utile tient sur une page par service : clair, ordonné, et surtout testé régulièrement.
Modèle copier-coller — ma fiche PRA (un service)
Service : ___ (ex. paie de la PME de Sofiane)
Repères : RTO = ___ (délai de reprise) · RPO = ___ (perte tolérée)
À restaurer (dans l'ordre) : ___
Qui fait quoi : ___
Ressources : ___
Date du dernier exercice : ___
Règle : un plan non testé n'est pas un plan.Un plan pour la paie
Sofiane cible d'abord le service de paie, critique en fin de mois, avec des repères serrés.
Un plan pour les fichiers
Sofiane couvre le partage de documents des commerciaux, utile au quotidien.
Maintenir pendant (PCA)
Sofiane prévoit un mode dégradé pour que la distribution continue pendant l'incident.
Tester, encore tester
Sofiane planifie des exercices de restauration réguliers plutôt qu'un plan écrit une seule fois.
✓ Bonnes pratiques
- Définir RTO et RPO avec le métier, service par service, pas dans l'abstrait.
- Ordonner les restaurations selon les dépendances (l'essentiel d'abord).
- Tester le plan par des exercices réguliers : sinon il n'existe pas.
✗ Pièges fréquents
- Confondre « avoir des sauvegardes » et « savoir repartir ».
- Écrire un PRA puis ne jamais le tester.
- Oublier les dépendances et restaurer dans le désordre.
Points clés à retenir
- Le PRA décrit comment repartir ; le PCA, comment continuer pendant l'incident.
- RTO = délai de reprise ; RPO = perte de données tolérable.
- Ces repères dictent la fréquence des sauvegardes et l'investissement.
- Un plan non testé échoue : exercices réguliers obligatoires.
Défi 48h — appliquez demain
Comme Sofiane, esquissez le PRA d'UN service critique : notez ses repères RTO et RPO avec le métier, la liste ordonnée de ce qu'il faut restaurer, qui fait quoi, puis datez un premier exercice de restauration. Écrivez en une phrase ce que la PME gagnerait à savoir redémarrer.
- Je distingue sauvegarde, PRA et PCA.
- Je sais lire RTO (délai de reprise) et RPO (perte tolérable).
- Je sais pourquoi un plan doit être testé régulièrement.
Questions fréquentes
Quelle différence entre PRA et PCA ?
Le PCA vise à maintenir l'activité pendant l'incident (solutions de secours, mode dégradé) ; le PRA vise à reconstruire et repartir après. Les deux se complètent : continuer autant que possible, puis restaurer complètement.
Comment justifier le budget d'un PRA à la direction ?
En chiffrant le coût d'une interruption (heures perdues, données, réputation) face au coût du plan, et en traduisant les besoins en RTO et RPO. Ces repères rendent l'investissement concret plutôt que théorique — sans imposer de valeurs toutes faites.
Que mesure le RPO d'un plan de reprise d'activité ?