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.