Qu'est-ce qu'un plan de reprise d'activité (PRA) ?
En bref
Un plan de reprise d'activité (PRA) est l'ensemble documenté des moyens et des procédures qui permettent de redémarrer les systèmes informatiques après un sinistre majeur : panne, incendie, rançongiciel ou erreur grave. Il fixe deux objectifs, la durée d'interruption acceptable et la perte de données acceptable, puis décrit qui fait quoi, et dans quel ordre, pour revenir à un fonctionnement normal.
Un plan de reprise d'activité répond à une question simple : si vos serveurs, vos fichiers ou vos applications deviennent inaccessibles demain matin, comment repartez-vous, et en combien de temps ? Le PRA ne se limite pas aux sauvegardes. Il réunit les moyens techniques, les décisions à prendre et les personnes à mobiliser.
PRA et PCA : quelle différence ?
| Plan de continuité d'activité (PCA) | Plan de reprise d'activité (PRA) | |
|---|---|---|
| Objectif | Continuer à fonctionner pendant l'incident | Redémarrer après une interruption |
| Moyens typiques | Équipements redondants, bascule automatique, mode dégradé | Sauvegardes, infrastructure de remplacement, procédures de restauration |
| Interruption | Évitée ou très réduite | Acceptée, mais limitée et maîtrisée |
Les deux se complètent. Le PCA coûte généralement plus cher, car il suppose de doubler certains équipements. Beaucoup d'organisations réservent la continuité aux systèmes les plus critiques et couvrent le reste par un PRA.
Quels objectifs fixer ?
Deux indicateurs structurent tout le plan :
- La durée maximale d'interruption admissible, souvent appelée RTO (recovery time objective) : combien de temps l'activité peut-elle se passer d'un système ?
- La perte de données maximale admissible, ou RPO (recovery point objective) : jusqu'à quel moment dans le passé acceptez-vous de revenir ?
Ces objectifs se fixent système par système, avec la direction, et non par le seul service informatique. Ils doivent rester cohérents avec les moyens : si vos données sont sauvegardées une fois par jour, la perte peut atteindre une journée de travail, quel que soit l'objectif écrit.
Comment construire un PRA, étape par étape ?
- Recenser les activités critiques et les systèmes dont elles dépendent : messagerie, logiciel métier, site, fichiers partagés, téléphonie, mais aussi accès Internet, DNS et comptes d'administration.
- Identifier les scénarios : panne d'un serveur, perte d'un centre de données, rançongiciel, compte administrateur compromis, suppression accidentelle, défaillance d'un prestataire.
- Fixer les objectifs de durée d'interruption et de perte de données pour chaque système.
- Choisir les moyens techniques : sauvegardes externalisées dont une copie déconnectée, infrastructure de secours, contrats de remplacement de matériel.
- Rédiger les procédures : qui déclenche le plan, dans quel ordre redémarrer les systèmes, avec quels accès.
- Tester : exercice sur table, restauration réelle d'un système, simulation complète.
- Mettre à jour le plan après chaque changement notable de l'informatique ou de l'organisation.
Que doit contenir le document ?
- Le périmètre couvert et les objectifs retenus.
- Les critères de déclenchement et la personne qui décide.
- Un annuaire de crise : responsables internes, prestataires, assureur, contacts utiles.
- L'inventaire des systèmes et un schéma de leurs dépendances.
- Les procédures de restauration, pas à pas.
- L'emplacement des sauvegardes et la manière d'obtenir les accès d'urgence.
- Les obligations à respecter, comme la notification à la CNIL d'une violation de données personnelles dans les conditions prévues par le RGPD.
- Un modèle de journal de crise pour tracer décisions et actions.
Pourquoi un PRA échoue-t-il le jour de l'incident ?
- Le document est stocké sur le serveur qui vient de tomber. Gardez-en une copie accessible hors du système d'information.
- Les sauvegardes étaient connectées en permanence et ont été chiffrées avec le reste.
- Le plan n'a jamais été testé, et la restauration prend bien plus longtemps que prévu.
- Les contacts ou les mots de passe d'urgence sont obsolètes.
- Une dépendance a été oubliée : nom de domaine, licence, téléphone portant la double authentification.
Qui doit participer au PRA ?
Un PRA rédigé par le seul service informatique reste incomplet. La direction fixe les priorités et valide les objectifs. Les responsables métier indiquent quelles activités doivent repartir en premier et comment travailler en mode dégradé. Les prestataires, hébergeur ou infogérant, précisent leurs propres délais d'intervention et leurs procédures. Chacun doit connaître son rôle avant l'incident, pas le découvrir pendant.
La restauration elle-même repose sur des sauvegardes solides : relisez les principes de la sauvegarde 3-2-1.
Pour mettre en place des sauvegardes externalisées et surveillées qui servent de socle à votre PRA, voyez sauvegardes et surveillance.
Questions fréquentes
Le PRA est-il obligatoire ?
Pas de manière générale. Certains secteurs réglementés imposent des exigences de continuité, et des clients ou assureurs peuvent en demander un. Il reste recommandé dès que l'activité dépend de l'informatique.
Quelle différence entre RTO et RPO ?
Le RTO est la durée d'interruption acceptable avant le redémarrage. Le RPO est la quantité de données, exprimée en temps, que l'on accepte de perdre.
À quelle fréquence tester un PRA ?
Régulièrement, selon un calendrier défini, et après chaque changement important de l'infrastructure. Un plan jamais testé ne peut pas être considéré comme fiable.
Un PRA protège-t-il contre un rançongiciel ?
Il permet de redémarrer, à condition que les sauvegardes soient hors d'atteinte de l'attaque, par exemple déconnectées ou non modifiables, et que la cause de l'intrusion soit traitée avant la remise en service.
Sources
Service lié
Articles liés
Rédigé par l'équipe NexSecure. Responsable de la publication : Yohann Toumine. Dernière mise à jour le 11 septembre 2026.
Une question sur votre situation ? Parler de votre projet