Le PRA, plan de reprise d'activité, décrit comment remettre votre informatique en état de marche après un sinistre ; le PCA, plan de continuité d'activité, décrit comment continuer à travailler pendant l'interruption. Contrairement à une idée reçue, construire un PRA crédible ne demande pas un budget de grand compte : avec le cloud, une stratégie de sauvegarde 3-2-1 et des procédures écrites puis testées, c'est avant tout une affaire de méthode.
PRA, PCA : quelle différence, concrètement ?
Le PCA répond à la question « comment continue-t-on à servir nos clients pendant la crise ? » : téléphonie de secours, procédures manuelles temporaires, connexion 4G/5G de repli, travail depuis un autre site. Le PRA répond à « comment remet-on le système d'information sur pied, dans quel ordre et en combien de temps ? » : restauration des serveurs, des données et des accès. Pour la plupart des PME, l'objectif raisonnable est un PRA solide, complété de quelques mesures de continuité ciblées sur les processus vitaux — pas le dispositif complet d'un opérateur bancaire.
RTO et RPO : les deux chiffres qui pilotent tout
Le RTO (Recovery Time Objective) est la durée d'interruption maximale que vous acceptez : un RTO de 4 heures sur la facturation signifie que l'outil doit être restauré en moins de 4 heures. Le RPO (Recovery Point Objective) est la quantité de données que vous acceptez de perdre : une sauvegarde chaque nuit donne un RPO de 24 heures — tout ce qui a été saisi depuis la dernière sauvegarde peut disparaître.
Concrètement : une messagerie hébergée en SaaS vise un RTO de quelques heures et un RPO quasi nul ; un serveur de fichiers supporte souvent un RTO de 8 heures et un RPO de 24 heures ; un site marchand exige un RTO d'une heure et un RPO de quelques minutes sur les commandes. Retenez surtout que chaque réduction de RTO ou de RPO a un coût croissant : ce sont des curseurs économiques à arbitrer, pas des prouesses techniques à empiler.
La démarche pragmatique en 5 étapes
1. Inventorier ce qui est vraiment critique
Listez applications, données, matériels, accès et prestataires, puis posez trois questions pour chacun : qui l'utilise, quel processus s'arrête sans lui, quels RTO et RPO sont acceptables. Dans une PME, la liste des éléments réellement critiques dépasse rarement une dizaine de lignes — c'est elle qui doit concentrer l'effort.
2. Écrire les scénarios de sinistre
Quatre ou cinq scénarios couvrent l'essentiel : panne matérielle du serveur principal, ransomware, incendie ou dégât des eaux dans les locaux, défaillance d'un prestataire cloud, indisponibilité prolongée de la personne clé. Pour chaque scénario, décrivez l'impact, le mode de détection et la réponse prévue.
3. Mettre en place la sauvegarde 3-2-1
Trois copies de vos données, sur deux supports différents, dont une hors site — et idéalement hors ligne ou immuable, pour résister à un ransomware qui chiffrerait aussi les sauvegardes connectées. Le stockage objet dans le cloud a rendu ce standard accessible : pour des volumes de PME, on parle généralement de quelques dizaines d'euros par mois.
4. Rédiger des procédures actionnables
Un PRA utile n'est pas un classeur de 80 pages : c'est une série de fiches réflexes. Qui appeler et dans quel ordre, où se trouvent les mots de passe (dans un coffre-fort chiffré accessible même si le SI est à terre), comment lancer une restauration, quoi dire aux clients. Chaque fiche doit pouvoir être exécutée à 3 heures du matin par quelqu'un de stressé, éventuellement sans l'expert habituel.
5. Tester régulièrement
Une restauration de sauvegarde testée chaque trimestre, un exercice de scénario complet chaque année. Chronométrez, notez ce qui a coincé, mettez à jour les fiches. C'est ce cycle qui transforme un document en capacité réelle.
Les options économiques qui changent la donne
- Le cloud comme site de secours : plus besoin de financer une seconde salle serveur ; des images de machines prêtes à démarrer ne coûtent presque rien tant qu'elles ne tournent pas.
- La réplication ciblée : répliquer uniquement les données et services critiques identifiés à l'étape 1, pas l'intégralité du SI.
- Le SaaS bien choisi : messagerie et outils collaboratifs chez un éditeur sérieux déplacent une partie du risque vers un acteur dont c'est le métier — à condition de sauvegarder aussi ces données, qui restent votre responsabilité.
- La documentation : elle ne coûte que du temps, et c'est presque toujours elle qui manque le jour du sinistre.
L'erreur fatale : le PRA jamais testé
Un PRA non testé n'est pas un plan, c'est une hypothèse. Les mauvaises surprises classiques découvertes le jour J : des sauvegardes silencieusement corrompues ou incomplètes depuis des mois, le mot de passe du coffre connu du seul collaborateur en congé, une procédure qui référence un serveur décommissionné, une restauration qui prend 30 heures là où le RTO en prévoyait 4. Chacun de ces problèmes se détecte en une demi-journée d'exercice. Rapporté au coût d'un arrêt d'activité de plusieurs jours, c'est probablement l'assurance la moins chère qui existe.
La bonne nouvelle, c'est qu'un premier PRA crédible se construit en quelques jours de travail structuré, pas en plusieurs mois. Le plus efficace est souvent de se faire accompagner sur l'inventaire initial et le premier test de restauration : un partenaire technique qui a déjà vécu des reprises réelles saura repérer les angles morts que l'on ne voit pas de l'intérieur.