Modèle de plan de reprise d'activité gratuit

Présentation

Le plan de reprise d'activité (PRA) décrit les procédures techniques et organisationnelles permettant de restaurer les systèmes d'information, infrastructures et données d'une organisation après un sinistre majeur (panne matérielle grave, cyberattaque destructrice, incendie, inondation d'un centre de données), afin de revenir à un fonctionnement normal. Contrairement au plan de continuité d'activité (PCA), qui vise à maintenir un niveau de service minimal pendant l'incident, le PRA vise le redémarrage complet des systèmes après le sinistre. Quand l'utiliser : toute organisation dont l'activité dépend de systèmes d'information (applications métier, bases de données, infrastructures réseau) a intérêt à formaliser un PRA. Ce document est particulièrement structurant lorsque l'organisation traite des données sensibles ou opère dans un secteur où la disponibilité des systèmes conditionne directement la capacité à honorer des engagements contractuels ou réglementaires. Contenu : le PRA identifie les systèmes et données critiques, fixe pour chacun un objectif de délai de reprise (RTO — Recovery Time Objective, délai maximal avant le redémarrage) et un objectif de perte de données maximale tolérée (RPO — Recovery Point Objective, ancienneté maximale des données restaurées), décrit les procédures techniques de restauration (sauvegardes, site de secours, bascule vers une infrastructure alternative), la chaîne de décision pour déclencher le plan, les rôles et responsabilités de l'équipe de reprise, et les modalités de test. Erreurs à éviter : fixer des objectifs de RTO/RPO théoriques sans jamais vérifier qu'ils sont réellement atteignables (seul un test grandeur réelle permet de le confirmer), négliger la vérification effective de l'intégrité des sauvegardes (une sauvegarde qui ne se restaure pas est inutile), omettre les dépendances externes (prestataires cloud, connectivité réseau, licences logicielles nécessaires à la restauration), et laisser le plan obsolète après une évolution significative du système d'information. Ce modèle propose une trame structurante ; son contenu technique doit être précisé et vérifié par les équipes IT et sécurité de l'organisation.

Informations à personnaliser

• Nom de l'organisation

• Nom du responsable du PRA

• Fonction du responsable du PRA

• Systèmes et données identifiés comme critiques

• Objectif de délai de reprise (RTO) par système critique

  Délai maximal admissible avant redémarrage du système.

• Objectif de perte de données maximale tolérée (RPO)

  Ancienneté maximale des données restaurées, ex. : dernière sauvegarde de moins de 24h.

• Stratégie de sauvegarde et de site de secours

• Composition et rôles de l'équipe de reprise

• Chaîne de décision pour déclencher le plan

• Fréquence de test du plan

• Date de dernière mise à jour du plan

Personnalisez votre modèle

Questions fréquentes

Quelle est la différence entre PRA et PCA ?

Le PRA (plan de reprise d'activité) organise le redémarrage complet des systèmes et infrastructures après un sinistre. Le PCA (plan de continuité d'activité) organise le maintien d'un niveau de service minimal pendant l'incident, avant même ce redémarrage complet. Les deux plans se complètent : le PCA gère l'immédiat, le PRA gère le retour à la normale.

Que signifient RTO et RPO ?

Le RTO (Recovery Time Objective) est le délai maximal admissible avant que le système ne soit à nouveau opérationnel. Le RPO (Recovery Point Objective) est l'ancienneté maximale tolérée des données restaurées par rapport au moment du sinistre (ex. : perte maximale admise = les 24 dernières heures de données).

Une sauvegarde régulière suffit-elle à garantir la reprise d'activité ?

Non. Une sauvegarde qui existe mais dont la restauration n'a jamais été testée peut se révéler inutilisable au moment critique (corruption, incompatibilité, procédure de restauration mal documentée). Seul un test de restauration réel permet de vérifier la fiabilité effective du dispositif.

Faut-il un site de secours physique pour avoir un PRA valable ?

Pas nécessairement : la stratégie de reprise dépend de l'infrastructure de l'organisation (sur site, cloud, hybride). Ce qui compte est que la stratégie retenue soit documentée, testée, et cohérente avec les objectifs de RTO/RPO fixés.

À quelle fréquence tester le PRA ?

Une fréquence au moins annuelle est une pratique courante, à ajuster selon la criticité des systèmes concernés et la fréquence des évolutions du système d'information. Chaque changement significatif d'infrastructure devrait également déclencher une revue du plan.

Qui doit avoir accès au PRA dans l'organisation ?

Le plan doit être accessible aux membres de l'équipe de reprise et à leurs suppléants, y compris en cas d'indisponibilité des systèmes habituels d'accès à la documentation (prévoir une copie accessible hors des systèmes eux-mêmes). Les éléments techniques sensibles (identifiants, accès) doivent être diffusés de façon restreinte.

Modèles associés