PRA (plan de reprise d’activité)

Un plan de reprise d’activité décrit comment remettre en service les systèmes après une interruption. Il précise les éléments à récupérer, l’ordre des opérations et les responsabilités. Il doit permettre de retrouver un fonctionnement utilisable, avec des objectifs définis par l’activité.

La reprise ne se limite pas à copier des fichiers. Une application peut dépendre d’une base, d’une configuration, d’un compte, d’une licence ou d’une connexion. Ces éléments doivent être identifiés. Un système qui démarre sans permettre le travail attendu ne constitue pas une reprise validée.

Le métier doit préciser le délai de reprise visé et la perte de données acceptable. Ces objectifs sont souvent désignés par RTO et RPO. Ils servent à concevoir les moyens et les tests. Ils ne deviennent pas des garanties simplement parce qu’ils sont écrits dans un document.

Les moyens doivent être compatibles avec les objectifs. Une copie ancienne ou un équipement de remplacement indisponible peut empêcher la reprise prévue. Vérifiez les dépendances et les délais réels avec les fournisseurs et les personnes qui interviennent.

Le PCA vise le maintien des activités essentielles pendant la perturbation. Le PRA organise le rétablissement des systèmes. La sauvegarde fournit des copies et des moyens de récupération. Les trois doivent être cohérents.

Un mode dégradé peut permettre de travailler pendant une restauration. Le PRA doit alors prévoir la reprise des informations produites durant cette période. Le retour au système normal demande un contrôle des doublons et de la cohérence, pas seulement le redémarrage des serveurs.

Imaginons une PME dont un serveur métier devient indisponible. Le plan identifie la copie à utiliser, l’environnement de récupération et les configurations nécessaires. La personne responsable vérifie la situation avant de lancer les opérations, notamment si une compromission est possible.

L’application est restaurée dans un environnement adapté. Les utilisateurs désignés contrôlent les données et les fonctions essentielles. Le résultat est comparé aux objectifs retenus : disponibilité du service et informations effectivement récupérées.

Ce scénario est illustratif. Il ne fixe pas un délai de restauration universel. Le test doit annoncer son périmètre, les ressources utilisées et les limites. Une récupération réussie dans des conditions préparées ne démontre pas tous les scénarios possibles.

Les services d’identité, le réseau et les dépendances applicatives peuvent devoir revenir avant les outils métier. L’ordre doit suivre l’architecture et les priorités. Une procédure générale sans références aux composants réels peut être difficile à exécuter.

Conservez les moyens d’accès et la documentation nécessaires dans un emplacement adapté à l’incident. Les secrets doivent rester protégés, tout en étant disponibles pour les personnes autorisées. Prévoyez un remplaçant lorsque le responsable habituel est absent.

Un essai de restauration vérifie les copies, les procédures et les applications. Il doit inclure une validation métier. Les erreurs et les étapes manquantes sont enregistrées, puis corrigées. Le plan devient plus utile lorsqu’il reflète le fonctionnement observé.

Revoyez les tests après un changement important : logiciel, infrastructure, fournisseur ou méthode de sauvegarde. Une ancienne réussite ne couvre pas automatiquement la nouvelle architecture. Les objectifs et les moyens doivent évoluer ensemble.

Après la restauration, vérifiez les accès, les versions et les informations produites pendant l’arrêt. Une reprise technique peut laisser des tâches en attente ou des données saisies dans un autre outil. Le retour à la normale doit prévoir leur rapprochement et sa validation. Conservez les réserves observées et les actions encore nécessaires. Cette étape évite de clôturer l’incident simplement parce qu’un écran est de nouveau accessible, alors que le processus métier reste incomplet.

Inventoriez les systèmes et leurs dépendances. Définissez les priorités et les objectifs avec les responsables métier. Identifiez les copies, les configurations et les ressources nécessaires à chaque service.

Rédigez une procédure exécutable et préparez un test dans un environnement adapté. Mesurez les étapes et vérifiez les fonctions utiles avec les utilisateurs concernés. Le compte rendu doit distinguer les résultats observés des objectifs souhaités.

Documentez les corrections, les responsables et les conditions de révision. Reliez la reprise au fonctionnement dégradé et au retour à la normale. Un plan utilisable doit permettre à l’équipe de retrouver les informations et les moyens nécessaires même lorsque le système habituel est indisponible.

Pour les principes de planification de reprise des systèmes, voir le guide NIST SP 800-34.

Référence consultée le 10 octobre 2026.