Préparer un PRA sans cabinet de conseil : la BIA simplifiée

1. Partez des activités, pas des serveurs

Le réflexe est de commencer par la technique : serveurs, sauvegardes, réseau. C’est l’entrée la moins utile. Un plan de reprise protège des activités — vendre, produire, facturer, payer les salaires, répondre aux clients — et c’est leur interruption qui coûte, pas celle d’une machine. Commencez donc par lister ce que fait l’entreprise, service par service.

Réunissez les responsables et listez sans hiérarchiser — prise de commande, production, facturation, encaissement, paie, support client, accueil téléphonique, expéditions — puis notez les dépendances de chaque activité : applications, fichiers partagés, messagerie, téléphonie, accès Internet, matériel spécifique. Pour une TPE-PME, une réunion préparée suffit généralement ; l’exhaustivité prime sur la finesse.

Cette cartographie sommaire fait remonter les dépendances oubliées — le lien Internet unique, le poste « qui a le logiciel », l’accès distant d’un prestataire. Ce sont souvent elles qui allongent une reprise.

2. Faites estimer l’impact par ceux qui font le travail

C’est le cœur de la méthode, et la raison pour laquelle un cabinet n’est pas indispensable à ce stade : personne ne connaît mieux les conséquences d’un arrêt de la facturation que la personne qui facture. Posez à chaque responsable la même question : que se passe-t-il si cette activité s’arrête quelques heures ? Une journée ? Une semaine ?

Consignez les réponses par écrit, avec leur auteur. Ce sont des jugements métier assumés, pas des vérités comptables : quand la direction arbitrera, elle s’appuiera sur l’estimation de la personne qui vit l’activité, pas sur une moyenne abstraite.

Pas besoin de chiffrer en euros. Une échelle qualitative — négligeable, gênant, grave, inacceptable — suffit, à condition d’examiner l’impact sous plusieurs angles :

• Chiffre d’affaires : encaissements décalés, commandes perdues, pénalités contractuelles éventuelles
• Clients : engagements non tenus, confiance entamée, risque de départ vers un concurrent
• Obligations : échéances légales, sociales ou fiscales qui ne peuvent pas attendre
• Fonctionnement interne : équipes à l’arrêt, ressaisies, rattrapage après la reprise

3. Traduisez les tolérances en RTO et RPO cibles

Deux notions transforment ces tolérances en objectifs. Le RTO (Recovery Time Objective) est la durée d’interruption maximale visée pour une activité : au-delà, l’impact décrit devient inacceptable. Le RPO (Recovery Point Objective) est l’ancienneté maximale acceptable des données restaurées — le travail que vous acceptez de ressaisir.

Déduisez-les des paliers de l’étape 2, activité par activité. Pour le RTO : à partir de quand l’arrêt devient-il intenable ? Pour le RPO : en repartant de la dernière sauvegarde, que faudrait-il refaire, et est-ce supportable ? Les objectifs n’ont aucune raison d’être identiques partout : facturation et archivage ne se valent pas.

À ce stade, ce sont des cibles, pas des engagements. Plus les objectifs sont courts, plus les dispositifs nécessaires sont conséquents — réplication, environnement de secours, copies hors site ; des objectifs plus longs peuvent s’appuyer sur de bonnes sauvegardes. Cet arbitrage entre impact et coût revient à la direction : c’est une décision de gestion, pas une question technique.

4. Priorisez l’ordre de reprise et confrontez-le à l’existant

Classez les activités par RTO croissant : vous obtenez l’ordre de reprise. Complétez-le avec les dépendances relevées à l’étape 1 : une application ne repart pas avant son serveur, ni le serveur avant le réseau et les accès. Cet ordre écrit évite l’improvisation du jour J, où chaque hésitation prolonge l’arrêt.

Vient ensuite le test de vérité : que permettent vos moyens actuels ? À quelle fréquence vos sauvegardes s’exécutent-elles vraiment ? C’est votre RPO effectif. Combien de temps prend une restauration complète, constatée et non supposée ? C’est une grande part de votre RTO effectif. Si personne ne sait répondre, l’enseignement est déjà là.

L’écart entre cibles et réalité devient votre plan d’action : ajuster la fréquence des sauvegardes, ajouter une copie hors site et isolée du réseau — la règle 3-2-1 : trois copies, deux supports, une hors site —, prévoir un mode dégradé pour les activités les plus sensibles. Certains écarts se corrigent par la seule organisation.

5. Documentez court, et hors du système d’information

Un PRA utile en TPE-PME est un document court et actionnable, pas un classeur. Il contient les activités priorisées avec leurs RTO et RPO validés, l’ordre de redémarrage, les procédures de restauration pas à pas, l’annuaire de crise — contacts internes, prestataires, opérateurs — et l’organisation de la décision : qui constate, qui déclenche, qui exécute, qui communique.

Conservez une copie accessible quand le système d’information est à terre : version imprimée, copie hors ligne. Un plan stocké uniquement sur le serveur qu’il est censé restaurer ne servira pas le jour venu.

Désignez un responsable du document et des suppléants : un plan « dans une seule tête » reste un point de fragilité. Si un prestataire vous aide à le rédiger, le document appartient à votre entreprise — exigez-le.

6. Exercez le plan, puis tenez-le à jour

Un plan qui n’est pas exercé perd sa valeur : les exercices révèlent les écarts avant qu’un incident réel ne s’en charge. Deux formats se complètent. Le test de restauration : restaurer un serveur ou un jeu de fichiers depuis la sauvegarde et mesurer la durée effective. L’exercice sur table : dérouler un scénario — ransomware, panne du serveur principal, site inaccessible — chacun décrivant ce qu’il ferait, document sous les yeux.

Chaque exercice produit un compte rendu : ce qui a fonctionné, ce qui a manqué, qui corrige quoi, pour quand. C’est ce cycle qui transforme un document en capacité de reprise. Sur les sauvegardes que nous opérons, nous pratiquons des tests de restauration trimestriels ; l’essentiel est qu’un rythme soit fixé, puis tenu.

Enfin, tenez le plan à jour : à chaque évolution significative du système d’information — nouvelle application critique, déménagement, changement de prestataire — et lors d’une revue au moins annuelle. Une BIA a une date ; passé un certain temps, elle décrit une entreprise qui n’existe plus.