Nous utilisons des cookies pour améliorer votre expérience sur notre site. Les cookies strictement nécessaires au fonctionnement du service sont toujours actifs. En savoir plus sur notre politique cookies
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.
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
Délai maximal admissible avant redémarrage du système.
Ancienneté maximale des données restaurées, ex. : dernière sauvegarde de moins de 24h.