Plan de reprise d'activité (PRA) informatique

Qu'est-ce qu'un PRA informatique ?

Le plan de reprise d'activité (PRA) est l'ensemble documenté des procédures, moyens techniques et responsabilités qui permettent de reconstruire le système d'information après un sinistre majeur : destruction physique (incendie, inondation), attaque par ransomware, panne matérielle grave, erreur humaine massive. Il répond à une question simple : si demain matin vos serveurs sont inutilisables, qui fait quoi, dans quel ordre, avec quels moyens, et en combien de temps l'entreprise retravaille-t-elle ?

Le PRA se distingue du plan de continuité d'activité (PCA) : le PCA vise à maintenir l'activité pendant la crise (fonctionnement dégradé, solutions de contournement), le PRA organise la reprise après interruption. Les deux se complètent ; une PME commence généralement par le PRA.

RTO et RPO : les deux chiffres qui dimensionnent tout

Deux indicateurs déterminent l'ambition — et le coût — de votre PRA :

• Le RTO (Recovery Time Objective) : la durée maximale d'interruption acceptable. Combien de temps l'entreprise peut-elle fonctionner sans son informatique ? 4 heures ? 24 heures ? 3 jours ?
• Le RPO (Recovery Point Objective) : la perte de données maximale acceptable. Si vous sauvegardez chaque nuit, votre RPO est de 24 heures : vous acceptez de perdre jusqu'à une journée de travail.

Ces objectifs se définissent métier par métier, pas globalement : la messagerie peut exiger un RTO de 4 heures quand l'archivage tolère une semaine. Plus le RTO et le RPO sont courts, plus l'infrastructure de secours coûte cher — l'arbitrage appartient à la direction, pas à la technique.

Les solutions de secours, du plus simple au plus exigeant

Solution	RTO typique	Principe	Pour qui
Sauvegarde externalisée + rachat de matériel	Plusieurs jours	On restaure sur du matériel neuf ou loué	Petites structures, activité peu dépendante de l'IT
Site de secours froid	24–72 h	Infrastructure minimale à démarrer et restaurer	PME avec tolérance de quelques jours
Site tiède / reprise dans le cloud	4–24 h	Serveurs répliqués régulièrement, démarrés à la demande	PME dépendantes de leur SI
Site chaud / réplication continue	Minutes à heures	Infrastructure doublée et synchronisée en permanence	Activités critiques (santé, e-commerce, production)

La virtualisation a changé la donne : des serveurs virtualisés se répliquent facilement vers un cloud de secours et redémarrent sur n'importe quel matériel. C'est ce qui rend le « PRA dans le cloud » (DRaaS) accessible aux PME, en s'appuyant sur des sauvegardes conformes à la règle 3-2-1.

Construire son PRA : la méthode en 6 étapes

1. Inventoriez et classez. Applications, serveurs, données, dépendances (liens entre la paie et le serveur de fichiers, par exemple). Un audit informatique fournit cette cartographie.
2. Analysez les impacts. Pour chaque activité métier : coût d'une heure, d'un jour, d'une semaine d'arrêt. C'est ce qui justifie (ou non) les investissements.
3. Fixez RTO et RPO par application, validés par la direction.
4. Choisissez et déployez les moyens : sauvegarde externalisée, réplication, site de secours cloud, postes de repli, accès distants de secours.
5. Rédigez les procédures. Qui déclenche le PRA et sur quels critères ? Ordre de redémarrage des systèmes, contacts (prestataire, assureur, opérateur), communication interne. Le document doit être accessible hors du SI — un PRA stocké uniquement sur le serveur sinistré ne sert à rien.
6. Testez, puis maintenez. Sans test, un PRA est une hypothèse. Testez la restauration complète d'un serveur au moins une fois par an, chronométrez, comparez au RTO promis, corrigez. Mettez le plan à jour à chaque évolution du SI.

Les erreurs qui condamnent un PRA

• Confondre sauvegarde et PRA. Avoir les données ne dit pas en combien de temps on reconstruit serveurs, réseau et accès. La sauvegarde est une brique, pas le plan.
• Ne jamais tester. La moitié des mauvaises surprises (mot de passe manquant, dépendance oubliée, restauration trois fois plus lente que prévu) ne se découvrent qu'en test.
• Un plan obsolète. Un PRA écrit il y a trois ans décrit un SI qui n'existe plus.
• Tout faire reposer sur une personne. Si le seul détenteur des procédures est en vacances le jour du sinistre, le RTO explose. C'est un argument pour adosser le PRA à un contrat d'infogérance avec engagement écrit.

Ce que le contrat doit dire du PRA

Beaucoup de contrats d'infogérance mentionnent « la sauvegarde et le PRA » sans rien chiffrer. Avant de signer, faites préciser par écrit :

1. Le RTO et le RPO par système, et ce qui se passe s'ils ne sont pas tenus (pénalités, voir le guide du SLA informatique).
2. Où se trouvent les copies et l'environnement de secours : pays, hébergeur, isolement vis-à-vis de votre réseau et des comptes du prestataire.
3. Qui déclenche le PRA, selon quels critères, et qui supporte le coût de la reprise (heures d'intervention, matériel de remplacement, capacité cloud temporaire).
4. La fréquence et le format des tests : au minimum une restauration complète par an, avec un rapport chronométré.
5. La réversibilité : en fin de contrat, récupération des sauvegardes, des procédures et des accès dans un format exploitable par un autre prestataire.

Si le sinistre est d'origine cyber (ransomware, intrusion), la reprise passe d'abord par l'identification du point d'entrée : le guide se protéger des ransomwares détaille l'ordre des opérations, et cybermalveillance.gouv.fr (dispositif 17Cyber) oriente les victimes vers une assistance. Les guides de gestion de crise de l'ANSSI, sur cyber.gouv.fr, aident à préparer le volet organisationnel.