Plan de reprise d’activité : le guide complet pour construire un PRA qui tient

1 366 incidents de sécurité traités par l’ANSSI dans son rapport 2025, dont 128 attaques par rançongiciel. Derrière ces chiffres, une constante : les organisations qui redémarrent vite ne sont pas les plus grandes, ce sont celles qui avaient préparé leur reprise.

Un plan de reprise d’activité (PRA) décrit comment votre organisation restaure son système d’information après un incident majeur : cyberattaque, panne, sinistre, erreur humaine. Pas en théorie : avec des rôles, des délais et des procédures testées.

Ce guide donne une méthode en cinq étapes pour construire un PRA informatique qui tient, avec les questions à trancher à chaque étape.

Plan de reprise d’activité : définition

Le PRA (en anglais DRP, Disaster Recovery Plan) est l’ensemble documenté et testé des procédures qui permettent de reconstruire le système d’information après un sinistre : restaurer les données, remonter les services, revenir à un fonctionnement normal. Il se distingue du PCA, le plan de continuité d’activité, qui vise à maintenir l’activité pendant l’incident. Le PCA organise la survie, le PRA organise le redémarrage. La distinction et le rôle de la sauvegarde dans les deux dispositifs sont détaillés dans PRA et PCA : le socle technique sans lequel rien ne tient.

Une conviction guide ce guide : un PRA sans sauvegarde fiable, isolée et testée n’est pas un PRA, c’est un document. Toutes les étapes qui suivent servent à éviter ce piège.

Étape 1 : inventorier et hiérarchiser

On ne protège bien que ce qu’on connaît. Commencez par un inventaire : applications, serveurs, données, dépendances (annuaire Active Directory, DNS, sauvegarde de la configuration réseau), prestataires et contrats. Pour chaque service, identifiez qui l’utilise et ce qui s’arrête s’il tombe.

Puis hiérarchisez par impact métier : quels services bloquent l’activité ou créent une obligation légale s’ils sont indisponibles ? Pour une entreprise, la production et la facturation. Pour une collectivité, la paie des agents, l’état civil, les services sociaux. Cette analyse d’impact n’a pas besoin d’être un rapport de 100 pages : un tableau honnête vaut mieux qu’une étude parfaite jamais finie.

Étape 2 : fixer vos RTO et RPO

Pour chaque service critique, deux chiffres : le RPO, la perte de données maximale admissible, et le RTO, le délai maximal de remise en service. Deux chiffres par application, jamais un chiffre global. Ils déterminent toute la suite : fréquence des sauvegardes, architecture de restauration, budget. La méthode complète est détaillée dans notre article RTO et RPO : comprendre et fixer vos objectifs de reprise.

Étape 3 : bâtir la stratégie de sauvegarde

La règle 3-2-1 comme plancher. Trois copies de vos données, sur deux supports différents, dont une hors site. C’est le minimum, plus une garantie suffisante à elle seule : une copie hors site accessible depuis le domaine compromis sera chiffrée avec le reste.

L’extension 3-2-1-1-0 comme cible. Une copie supplémentaire immuable ou hors ligne, inaccessible depuis le système d’information de production, et zéro erreur au test de restauration. Les deux ajouts comptent : l’immuabilité protège la copie, le test prouve qu’elle sert à quelque chose.

Le scénario dimensionnant est le rançongiciel. Les attaquants ciblent les sauvegardes en premier pour interdire toute reprise sans paiement. Votre stratégie doit donc garantir qu’au moins une copie complète survit à la compromission totale du domaine : c’est le rôle d’une sauvegarde immuable et d’une sauvegarde externalisée qui ne dépend pas d’un tiers unique.

C’est précisément la fonction du coffre de sauvegarde distribué DATIS. Il se raccorde comme cible de stockage sous votre logiciel de sauvegarde existant (Veeam, Commvault, NetBackup, solutions compatibles S3/SMB/NFS) : il ne remplace pas votre orchestrateur, il le sécurise. Les données sont chiffrées avant de quitter votre site, stockées localement sur un système de fichiers ZFS immuable, puis fragmentées et distribuées sur plusieurs sites distants. Pas de datacenter central, pas de tiers qui détient vos données : vous reprenez le contrôle. La technologie, issue de brevets CNRS et Université Côte d’Azur (laboratoire I3S), est labellisée France Cybersecurity, et protège aujourd’hui plus de 100 clients.

Étape 4 : écrire les procédures

Le jour de l’incident, personne ne doit improviser. Le PRA écrit répond à quatre questions : qui décide (le déclenchement du plan est une décision de direction), qui restaure quoi et dans quel ordre (l’annuaire et le réseau avant les applications, les services critiques avant le confort), qui communique (en interne, vers les usagers ou clients, vers l’assureur et les autorités), et comment joindre tout le monde si la messagerie est à terre.

Détail qui change tout : le PRA lui-même doit être accessible hors du système d’information, en copie imprimée ou sur un support indépendant. Un plan stocké uniquement sur le serveur chiffré par l’attaquant a une utilité nulle.

Étape 5 : tester, mesurer, réviser

Un PRA jamais testé est une hypothèse. Trois niveaux de test, du moins cher au plus complet : la restauration régulière d’échantillons (un fichier, une machine virtuelle) pour vérifier l’intégrité des sauvegardes, la restauration complète chronométrée d’un service critique pour confronter le RTO réel au RTO affiché, et l’exercice de crise annuel sur scénario (rançongiciel un vendredi soir) pour tester la chaîne de décision autant que la technique.

Chaque test alimente la révision : nouveaux serveurs, nouvelles applications, départs et arrivées dans l’équipe. Un PRA se révise à chaque changement majeur du système d’information, et au moins une fois par an.

PRA et conformité : NIS2, DORA, RGPD

La directive NIS2 impose aux entités essentielles et importantes de documenter et de tester leur continuité et leur reprise d’activité ; elle concerne notamment les collectivités territoriales et de nombreuses entreprises de secteurs critiques. Le règlement DORA impose des exigences équivalentes au secteur financier. Le RGPD (article 32) exige de pouvoir rétablir la disponibilité des données personnelles dans des délais appropriés. À quoi s’ajoutent les assureurs cyber et les donneurs d’ordre, qui conditionnent de plus en plus garanties et contrats à l’existence d’un PRA testé.

Le PRA en collectivité territoriale

Les collectivités sont en première ligne : services publics impossibles à interrompre, données sensibles, équipes informatiques réduites. Trois retours de terrain montrent ce qu’un socle de reprise solide change concrètement.

Fontenay-sous-Bois (53 000 hab.) : le DSI Christophe Beuvière avait constaté que 50% des bandes de sauvegarde en place étaient défaillantes. Il cherchait une solution indestructible par construction pour fonder sa capacité de reprise.
Lire l’étude de cas ->

Habitat de la Vienne (12 000 logements) : après un audit ANSSI révélant une vulnérabilité sur l’Active Directory, le DSI Denis Poirier a déployé une couche de protection indépendante du domaine, tolérant la perte de 30% des nœuds sans interruption, avec une rétention supérieure à 90 jours.
Lire l’étude de cas ->

Vanves (28 000 hab.) : le DSI Thierry Kaloustian a éliminé la dépendance à une seule personne sur la sauvegarde. Depuis : moins de 10 minutes de supervision hebdomadaire et une restauration validée en conditions réelles.
Lire l’étude de cas ->

Questions fréquentes sur le PRA

En 30 minutes, nous analysons votre architecture de sauvegarde existante et identifions les points de fragilité de votre capacité de reprise face aux scénarios d’attaque les plus fréquents.