PRA — Définition IT

Le PRA (Plan de Reprise d'Activité, en anglais DRP — Disaster Recovery Plan) est le volet technique et IT du PCA. Il décrit précisément comment restaurer le système d'information après un sinistre — cyberattaque, panne matérielle massive, incendie, inondation — en respectant deux contraintes mesurables : un RTO (délai maximal de remise en service) et un RPO (perte de données maximale acceptable).

L'enjeu est très concret : selon le Ponemon Cost of Downtime Report 2024, chaque heure d'indisponibilité IT coûte en moyenne 9 000 $ aux PME et plus de 540 000 $ aux grandes entreprises, sans compter l'impact réputationnel et réglementaire. Pour les institutions financières soumises à DORA et les opérateurs NIS2, un PRA testé est désormais une exigence réglementaire.

RTO et RPO : les deux indicateurs qui structurent le PRA

Tout PRA s'appuie sur deux indicateurs cibles, fixés par application ou par processus métier :

• •RTO (Recovery Time Objective): : « dans combien de temps maximum doit-on être revenus en service ? ». Quelques minutes pour un site e-commerce, plusieurs heures pour une application back-office, plusieurs jours pour un outil non critique.
• •RPO (Recovery Point Objective): : « combien de données peut-on accepter de perdre ? ». Quelques secondes pour une transaction financière, quelques minutes pour un CRM, plusieurs heures pour un système de reporting.

Ces deux paramètres conditionnent l'investissement technique : un RTO de 4 heures et un RPO de 1 heure coûtent dix fois moins qu'un RTO de 5 minutes et un RPO de 0 seconde.

Les niveaux de PRA

Selon les RTO/RPO visés, on distingue plusieurs architectures :

• •Cold standby: : site de secours non équipé, restauration à partir de sauvegardes. RTO de plusieurs jours, RPO de plusieurs heures.
• •Warm standby: : infrastructure pré-installée mais éteinte, réplication asynchrone. RTO de quelques heures, RPO de quelques minutes.
• •Hot standby (actif/passif): : infrastructure prête, réplication synchrone, bascule automatisée. RTO de quelques minutes, RPO de quelques secondes.
• •Active-active: : production simultanée sur plusieurs sites, RTO et RPO proches de zéro. Modèle multi-région des hyperscalers.

Les étapes d'un PRA

1. Analyse d'impact : identifier les applications critiques, leurs dépendances, leurs RTO/RPO cibles.
2. Définition de l'architecture cible : sauvegardes, réplication, sites, bascule.
3. Documentation des procédures : runbooks détaillés, scripts d'automatisation, schémas réseau, contacts.
4. Tests réguliers : restauration de sauvegarde, bascule partielle, exercice complet annuel.
5. Amélioration continue : intégration des retours d'expérience, mise à jour après chaque changement majeur.

Sauvegarde n'est pas PRA

Une confusion classique : « on a des sauvegardes, donc on a un PRA ». Faux. Une sauvegarde est une donnée. Un PRA est un processus testé qui transforme la sauvegarde en service restauré. Sans procédures documentées, sans tests, sans coordination métier, des sauvegardes ne servent à rien lors d'une crise.

La règle 3-2-1 reste un standard pour les sauvegardes :

• •3: copies des données.
• •2: supports différents.
• •1: copie hors site (idéalement air-gapped pour résister aux ransomwares).

PRA et ransomware : la nouvelle donne

L'évolution des cyberattaques a transformé le PRA. Les ransomwares ciblent désormais explicitement les sauvegardes — selon Veeam Data Protection Trends 2024, 75 % des entreprises attaquées ont vu leurs sauvegardes ciblées, et 39 % se sont retrouvées avec des sauvegardes corrompues ou chiffrées. D'où l'importance de :

• •Sauvegardes immuables: : impossibles à modifier ou supprimer pendant une fenêtre définie.
• •Air-gap logique ou physique: : sauvegardes déconnectées du réseau.
• •Tests réguliers de restauration depuis ces sauvegardes: .

Tester son PRA

Les types d'exercices :

• •Test de restauration unitaire: : une application, en environnement de pré-prod.
• •Test de bascule partielle: : un site secondaire, sans impact sur la production.
• •Test de bascule complète (Full failover): : bascule réelle sur le site de secours. À faire au moins une fois par an pour les applications critiques.
• •Game day: : simulation de crise avec injection de panne réelle, équipes en conditions opérationnelles.

PRA et cartographie applicative

Un PRA crédible exige de connaître précisément quelles applications doivent être restaurées, dans quel ordre, et avec quelles dépendances. Sans cartographie applicative à jour, l'ordre de restauration est deviné — et lors d'une crise réelle, c'est souvent ce flou qui prolonge l'indisponibilité. Kabeen fournit la carte vivante des applications, de leurs dépendances et de leurs usages métiers pour bâtir un PRA exploitable.