Plan de reprise d'activité (PRA) : guide complet 2026

Un plan de reprise d'activité (PRA) est le dispositif documenté qui permet de redémarrer le système d'information après un sinistre majeur (incendie, panne d'infrastructure, cyberattaque) dans des délais et avec une perte de données fixés à l'avance par les métiers : le RTO et le RPO. Il précise quoi restaurer, dans quel ordre, par qui, depuis quelles sauvegardes et vers quelle infrastructure.

Beaucoup de PRA ont été écrits pour l'incendie de la salle serveur. Le scénario dominant est aujourd'hui un rançongiciel qui chiffre la production, vise les sauvegardes et compromet l'annuaire. Ce guide montre comment construire, tester et prouver un PRA qui tienne dans les deux cas.

L'essentiel en 30 secondes

• Le PRA redémarre le SI ; le PCA maintient l'activité. Le PRA est une composante du PCA.
• Les objectifs de reprise viennent de la BIA : chaque système hérite du RTO le plus exigeant des processus qui en dépendent.
• L'ordre de reprise compte autant que la vitesse : annuaire, DNS et sauvegarde passent avant les applications métier.
• Face à un rançongiciel, seule une copie hors ligne ou immuable, restaurée dans un environnement sain, offre un point de départ fiable.
• DORA impose de tester les plans de rétablissement au moins une fois par an ; NIS2 cite la gestion des sauvegardes et la reprise des activités.

Qu'est-ce qu'un PRA, et en quoi diffère-t-il d'un PCA ?

Le PRA, souvent appelé PRA informatique ou plan de reprise après sinistre, couvre la dimension technique de la continuité : infrastructures, applications, données, réseaux, identités. Il part d'une hypothèse : le service s'est arrêté. Son objet est de revenir dans les délais convenus, avec une perte de données acceptable, sans réintroduire la cause du sinistre.

Le PCA est le chapeau ; PRA et PCI en sont les briques techniques. Un PRA sans PCA laisse les métiers sans consigne pendant la restauration ; un PCA sans PRA promet une reprise que personne ne sait exécuter. La méthode d'ensemble est détaillée dans notre guide du plan de continuité d'activité.

Que contient un plan de reprise d'activité ?

Un PRA informatique utile se lit sous stress et s'exécute par des suppléants. Six rubriques suffisent.

1. Périmètre et scénarios

Sites, plateformes (centre de données, cloud, SaaS) et scénarios : perte d'un site, d'une région cloud, de l'annuaire, chiffrement des données, défaillance d'un prestataire.

2. Inventaire classé par niveau de criticité

Chaque système hérite du RTO et du RPO les plus exigeants des processus qui en dépendent, tels que fixés par la BIA. Les regrouper en niveaux simplifie les arbitrages :

Ces valeurs sont illustratives : les vôtres sortent de la BIA. Le niveau 0 n'a pas de « RTO métier », mais rien ne redémarre sans lui. Pour calibrer : RTO vs RPO et le calculateur RTO/RPO.

3. Dépendances et ordre de reprise

La rubrique la plus souvent absente. L'ANSSI recommande un ordre de restauration qui tient compte des dépendances aux services d'infrastructure (DNS, NTP, annuaire), de la criticité des applications et des durées de restauration. Concrètement : un graphe de reprise où chaque système a ses prérequis et ses contrôles de bon fonctionnement.

4. Rôles et décision

Qui déclare le sinistre, qui décide de basculer, qui valide le retour en production ? Titulaires et suppléants, joignables hors du SI. Basculer fait perdre les données non encore répliquées : la décision revient à une personne désignée, sur des critères écrits.

5. Procédures techniques et communication

Une procédure par système : prérequis, étapes, emplacement des sauvegardes et des clés de chiffrement, comptes de secours, durée mesurée au dernier test, le tout accessible hors ligne. S'y ajoutent les messages aux métiers, aux clients et, si l'incident est notifiable, aux autorités (voir NIS2 : notification en 24 h, 72 h et 1 mois).

6. Retour à la normale

Revenir sur l'infrastructure principale (failback) est une seconde bascule : resynchronisation, contrôles d'intégrité et rapprochements (DORA les exige après un incident lié aux TIC), validation par les métiers, clôture formelle.

Notre modèle de plan de reprise après sinistre reprend cette structure.

Quelle stratégie de reprise choisir ?

Quatre stratégies couvrent l'essentiel des cas. Plus le RTO est court, plus la facture monte :

Deux erreurs reviennent. La première : confondre réplication et sauvegarde. La réplication copie en quelques secondes une suppression malveillante ou un chiffrement vers le site de secours ; seule une sauvegarde datée, hors de portée, permet de revenir en arrière. Même un actif-actif a besoin de sauvegardes. La seconde : choisir selon les préférences techniques plutôt que selon la BIA. Le simulateur de coût de reprise aide à objectiver l'arbitrage.

Sauvegardes : la règle 3-2-1 suffit-elle ?

Dans son guide Sauvegarde des systèmes d'information – Les fondamentaux (version 1.1, novembre 2025), l'ANSSI recommande la règle 3-2-1 : trois copies distinctes des données (la production et deux sauvegardes), sur des supports différents, dont une hors ligne. Elle juge le hors ligne indispensable, même moins fréquent. Les copies immuables (WORM) sont un compromis acceptable pour les sauvegardes fréquentes, le hors ligne restant plus robuste. Les éditeurs parlent aussi de « 3-2-1-1-0 » : une copie immuable ou hors ligne, zéro erreur aux vérifications.

Le même guide de l'ANSSI ajoute des précautions sans lesquelles la règle ne tient pas :

• Isoler l'infrastructure de sauvegarde : hors du domaine Active Directory de production, avec une authentification indépendante et des comptes dédiés.
• Sauvegarder la sauvegarde : catalogue, binaires, procédures d'import, clés de chiffrement. Sans eux, les supports sont inexploitables.
• Tester les restaurations régulièrement, selon une procédure écrite.

La géographie compte aussi. Lors de l'incendie du centre de données OVHcloud de Strasbourg, dans la nuit du 9 au 10 mars 2021, des clients ont découvert que leurs sauvegardes étaient stockées sur le même site que leurs serveurs.

Enfin, une sauvegarde jamais restaurée reste une hypothèse. Le seul indicateur qui compte est la date du dernier test de restauration réussi, avec sa durée.

Comment reprendre après un rançongiciel ?

Face à un rançongiciel (ransomware), la reprise change de nature. Selon l'ANSSI, il est fréquent qu'un attaquant tente de chiffrer, d'effacer ou de rendre indisponible l'infrastructure de sauvegarde pour ralentir la reconstruction. Le redémarrage devient alors un projet de remédiation (endiguement, éviction, éradication, reconstruction) qui peut durer des semaines, voire des mois. Le PRA doit traiter ce scénario à part.

Isoler les sauvegardes avant tout

C'est la mesure prioritaire que recommande l'ANSSI en cas d'incident de sécurité. Elle suppose un « bouton rouge » préparé à l'avance : script, déconnexion d'un commutateur.

Préserver les traces

Chaque action de remédiation détruit des traces utiles à l'investigation et à d'éventuelles poursuites. Il faut arbitrer entre vitesse de reprise et collecte de preuves, avec les équipes d'investigation. Réemployer aussitôt les serveurs touchés fait perdre des preuves ; une main courante horodatée servira face à la justice et à l'assureur.

Reconstruire le cœur de confiance en premier

L'annuaire (Active Directory, le plus souvent) et l'administration du SI forment le cœur de confiance. S'il reste compromis, tout ce qui est restauré ensuite l'est aussi ; selon l'ANSSI, l'échec de sa reconstruction mène généralement à des cycles de compromission et de remédiation qui peuvent durer des mois, voire des années. Un PRA « rançongiciel » commence donc par l'identité, pas par l'ERP.

Restaurer dans un environnement sain et isolé

Les sauvegardes peuvent contenir des implants de l'attaquant. Réinstallez les systèmes depuis des images de confiance et les applications depuis des binaires signés, contrôlez les configurations, analysez les données avant réimport. Le point de restauration doit être antérieur à la compromission, souvent bien plus ancien que la dernière sauvegarde : le RPO réel dépasse alors le RPO prévu. DORA impose d'ailleurs aux entités financières qui restaurent avec leurs propres systèmes d'utiliser des systèmes séparés physiquement et logiquement du système source.

Le guide de l'ANSSI Piloter la remédiation détaille ces étapes, y compris le matériel et l'aide externe à prévoir. Pour s'entraîner : nos 10 scénarios d'exercice de crise, qui s'ouvrent sur un rançongiciel.

PRA cloud et SaaS : qui est responsable de quoi ?

Dans le modèle de responsabilité partagée, le fournisseur répond de la résilience de son infrastructure ; configuration, données, identités et stratégie de reprise restent les vôtres.

• La perte d'une région. Plusieurs zones de disponibilité protègent contre la perte d'un bâtiment, pas d'une région. Le 20 octobre 2025, un défaut de gestion DNS de DynamoDB a perturbé la région AWS us-east-1 pendant plus de quatorze heures pour ses principaux services, selon le rapport d'AWS.
• Le compte, point de défaillance unique. Un compte d'administration compromis peut supprimer la production et les sauvegardes stockées au même endroit. Gardez des copies dans un compte séparé, verrouillées contre la suppression.
• Le SaaS. L'éditeur restaure son service, pas forcément vos données au point voulu. Vérifiez rétention, export et réversibilité, et conservez des exports réguliers des données critiques.

Autre dépendance cachée : le 19 juillet 2024, une mise à jour défectueuse de CrowdStrike a mis hors service environ 8,5 millions de postes Windows selon Microsoft ; la réparation exigeait une intervention sur chaque machine, parfois avec la clé de récupération BitLocker. Où sont ces clés, et comment y accéder sans le SI ?

Architectures détaillées : BCDR pour AWS et BCDR pour Azure.

Comment tester un PRA ?

Chaque test répond à une question précise :

Pour les entités financières (hors microentreprises), DORA exige que ces tests incluent des scénarios de cyberattaque et de basculement vers la capacité redondante.

L'écart RTO : l'indicateur qui compte

Le RTO de la BIA est une exigence ; le temps de reprise mesuré est une capacité. Leur écart est l'information la plus utile qu'un PRA puisse donner à une direction. Pour le mesurer honnêtement :

1. Chronométrer de bout en bout : de la déclaration du sinistre à la validation par le métier, pas jusqu'au démarrage de la machine virtuelle.
2. Suivre le chemin critique : un ERP restauré en 2 heures ne sert à rien si l'annuaire en demande 10.
3. Décider : réviser le RTO, investir, ou accepter formellement le risque. Laisser l'écart sans décision n'est pas une option.

Chaque constat devient une action corrective, avec un responsable et une échéance.

Le PRA est-il obligatoire ? Ce qu'exigent NIS2, DORA et le RGPD

Le mot « PRA » n'y figure pas, mais la capacité est exigée :

DORA s'applique depuis le 17 janvier 2025 (texte sur EUR-Lex) ; en France, la loi de transposition de NIS2 n'était pas définitivement adoptée à la mi-octobre 2026. L'auditeur demandera de toute façon le plan, la date et le résultat du dernier test, et le suivi des écarts. Voir notre guide DORA 2026.

Ce que fait ResiPlan, concrètement

ResiPlan est la couche de pilotage du PRA, pas un outil de sauvegarde : il n'exécute ni sauvegarde, ni bascule, ni orchestration d'infrastructure.

• PRA pré-rempli depuis la BIA : l'un des 8 types de plans ; les RTO et RPO de la BIA deviennent ses objectifs.
• Premier jet par IA, relu et validé par vos équipes.
• Écarts de reprise visibles : les liens processus ↔ services informatiques signalent quand le RTO d'un processus est plus court que la capacité de reprise des systèmes dont il dépend.
• Simulateur de dépendances : simulez la perte d'un actif ou d'un fournisseur et voyez les processus touchés.
• Tests tracés : exercices de type « test PRA technique », constats transformés en actions correctives suivies.
• Preuves : NIS2 article 21, DORA et ISO 22301 cartographiés, dossier de preuves téléchargeable.

Les données métier sont hébergées dans l'Union européenne. Un logiciel ne rend personne « conforme » et ne certifie personne : ResiPlan structure et prouve le travail de vos équipes. Essai gratuit de 7 jours, sans carte bancaire.

Checklist : votre PRA est-il prêt ?

• Chaque système a un niveau de criticité, un RTO et un RPO issus de la BIA.
• L'annuaire, le DNS, la sauvegarde et les clés ont leur propre procédure de reconstruction.
• L'ordre de reprise est écrit, avec les prérequis de chaque système.
• Au moins une copie des données critiques est hors ligne ou immuable, sur un site distinct.
• L'infrastructure de sauvegarde est hors du domaine de production ; son catalogue et les clés de chiffrement restent accessibles sans le SI.
• Le scénario rançongiciel est traité à part : isolement, traces, cœur de confiance, environnement sain.
• Les dépendances cloud et SaaS sont identifiées, exports et réversibilité vérifiés.
• Les systèmes critiques ont été restaurés avec succès dans les 12 derniers mois, durée mesurée.
• Un exercice PRA, retour à la normale compris, a eu lieu dans l'année et l'écart RTO est suivi.

FAQ

Quelle est la différence entre un PRA et un PCA ?

Le PCA maintient les activités essentielles pendant la perturbation, sur tout le périmètre de l'organisation. Le PRA redémarre le système d'information après l'arrêt : c'est une composante du PCA, qui s'appuie sur ses délais de reprise pour dimensionner les modes dégradés.

Le PRA est-il obligatoire ?

Aucun texte n'impose un document intitulé « PRA ». Mais NIS2, DORA et le RGPD exigent la capacité qu'il décrit : sauvegardes, reprise, plans de rétablissement testés, accès aux données rétabli. Sans PRA, impossible de le démontrer.

À quelle fréquence tester un PRA ?

Un exercice significatif au moins une fois par an pour le périmètre critique, minimum fixé par DORA, et après chaque changement majeur d'infrastructure. Les tests de restauration gagnent à être plus fréquents : ils coûtent peu et révèlent vite une sauvegarde défaillante.

Les sauvegardes suffisent-elles face à un rançongiciel ?

Non. Il faut une copie hors de portée de l'attaquant (hors ligne ou immuable), une infrastructure de sauvegarde isolée du domaine de production, et une restauration dans un environnement sain, après reconstruction de l'annuaire. Sinon, on restaure l'attaquant avec les données.

Le cloud dispense-t-il d'un PRA ?

Non. Le fournisseur assure la résilience de son infrastructure, pas la reprise de vos charges : configuration, données, identités, choix multi-région et sauvegardes restent à votre charge. Prévoyez au minimum la perte d'une région et celle de votre compte d'administration.

Pour aller plus loin

• Plan de continuité d'activité (PCA) : guide 2026 en 8 étapes
• RTO vs RPO : matrice et benchmarks par secteur
• BIA en 7 étapes, avec modèle gratuit
• Modèle de plan de reprise après sinistre
• Calculateur RTO/RPO

Un PRA ne vaut que par son dernier test réussi : c'est la première date qu'un auditeur, un assureur ou une direction devrait vous demander.