Un plan de reprise d’activité (PRA) désigne le document opérationnel qui organise le redémarrage des systèmes informatiques après un incident majeur. Panne de serveur, cyberattaque, sinistre physique dans un datacenter : le PRA fixe les procédures, les délais et les responsabilités pour remettre l’entreprise en ordre de marche. Sans ce cadre, la réponse à une crise repose sur l’improvisation, avec des conséquences financières souvent disproportionnées par rapport au coût du dispositif lui-même.
A lire également : Comment sécuriser votre entreprise ?
Recovery Time Objective et Recovery Point Objective : les deux métriques qui structurent un PRA
Avant de parler d’infrastructure ou de prestataire, un PRA repose sur deux indicateurs techniques que chaque direction doit arbitrer.
Le Recovery Time Objective (RTO) fixe la durée maximale d’interruption acceptable pour un système donné. Une plateforme de paiement en ligne tolère quelques minutes d’arrêt, là où un outil de reporting interne peut rester indisponible plusieurs heures sans paralyser l’activité.
A voir aussi : Sécuriser son entreprise en adoptant un stockage fiable des produits dangereux
Le Recovery Point Objective (RPO) définit la quantité de données que l’entreprise accepte de perdre. Un RPO de quatre heures signifie que les sauvegardes doivent être espacées de quatre heures au maximum. Plus le RPO est court, plus la fréquence de réplication augmente, et plus le budget grimpe.
Ces deux valeurs ne se décrètent pas uniformément pour toute l’entreprise. Elles se négocient service par service, application par application. La base clients et le système de facturation n’ont pas les mêmes exigences qu’un intranet documentaire. Confondre les deux conduit soit à un PRA surdimensionné et coûteux, soit à un dispositif qui protège mal les fonctions vitales.
Élaborer un PRA informatique : l’audit du parc avant toute rédaction
La première étape concrète consiste à inventorier l’ensemble du parc informatique. Serveurs physiques et virtuels, équipements réseau, applications métier, bases de données, solutions de sauvegarde existantes : rien ne doit manquer à ce recensement.
Ce travail d’audit permet ensuite de classer chaque composant selon son niveau de criticité. Un PRA informatique efficace ne cherche pas à tout protéger de la même manière. Il concentre les ressources sur les systèmes dont l’arrêt bloque directement le chiffre d’affaires ou expose l’entreprise à un risque réglementaire.
Dans les secteurs régulés comme la finance, l’Autorité des marchés financiers impose aux entreprises agréées de disposer d’un PRA opérationnel. La conformité n’est pas optionnelle, et l’audit initial sert aussi à documenter cette obligation.
Nommer un responsable et cartographier les dépendances
Un PRA sans pilote identifié reste un document théorique. Le responsable, souvent rattaché à la direction des systèmes d’information, coordonne l’audit, valide les RTO et RPO avec les métiers, et supervise les tests.
La cartographie des dépendances entre applications est un point que beaucoup d’entreprises sous-estiment. Une application métier peut dépendre d’un annuaire d’authentification, lui-même hébergé sur un serveur distinct. Restaurer une application sans ses dépendances ne sert à rien. Le PRA doit documenter ces chaînes pour que l’ordre de redémarrage soit cohérent.
Site miroir, sauvegarde externalisée ou DRaaS : choisir la bonne architecture de secours
Le choix de l’infrastructure de secours dépend directement des RTO et RPO définis en amont, et du budget disponible.
- Le site miroir réplique en temps réel l’ensemble des systèmes critiques sur un second datacenter. Le basculement est quasi instantané, mais le coût de maintien de deux environnements parallèles est élevé.
- La sauvegarde externalisée (sur bandes, sur un NAS distant ou dans un coffre-fort numérique) offre un RPO plus large. Elle convient aux entreprises dont l’activité tolère quelques heures de perte de données et un délai de restauration plus long.
- Le DRaaS (Disaster Recovery as a Service) externalise l’infrastructure de reprise chez un prestataire cloud. Cette approche supprime l’investissement matériel initial et permet de moduler les ressources selon les besoins, mais elle introduit une dépendance vis-à-vis du fournisseur et de la qualité de la liaison réseau.
Aucune de ces trois options n’est universellement supérieure. Le bon choix est celui qui aligne le coût du dispositif sur la perte financière réelle d’une interruption. Une entreprise dont chaque heure d’arrêt coûte plusieurs dizaines de milliers d’euros justifie un site miroir. Pour une PME avec des contraintes budgétaires fortes, une sauvegarde externalisée combinée à un DRaaS partiel couvre souvent le besoin.
Tester le PRA : la seule garantie qu’il fonctionne le jour J
Un PRA qui n’a jamais été testé est un PRA qui ne marche pas. La simulation grandeur nature reste le seul moyen de valider que les procédures documentées produisent le résultat attendu dans les délais prévus.
Les tests révèlent systématiquement des écarts entre la théorie et la réalité. Un mot de passe de compte de service expiré, une bande de sauvegarde illisible, un ordre de redémarrage qui provoque un conflit d’adresses IP : ces détails ne se découvrent que lors d’un exercice réel.
- Planifier au minimum un test complet par an, et un test partiel (restauration d’une application critique) chaque trimestre.
- Documenter chaque anomalie constatée et mettre à jour le PRA dans la foulée.
- Impliquer les équipes métier dans le test, pas uniquement l’équipe informatique, pour vérifier que les utilisateurs savent basculer sur l’environnement de secours.
Un PRA se dégrade naturellement avec le temps si personne ne le maintient. Chaque changement d’infrastructure (nouveau serveur, migration d’application, changement de prestataire d’hébergement) doit déclencher une mise à jour du document.
PRA et plan de continuité d’activité : deux dispositifs distincts
La confusion entre PRA et PCA (plan de continuité d’activité) reste fréquente. Le PCA vise à maintenir un niveau de service minimal pendant la crise, en anticipant les scénarios de dégradation. Le PRA intervient après l’interruption pour restaurer le fonctionnement nominal.
Les deux dispositifs se complètent mais ne se substituent pas. Une entreprise peut disposer d’un PCA qui prévoit le basculement de la messagerie vers un webmail de secours, et d’un PRA qui organise la restauration complète du serveur Exchange dans les 24 heures suivantes. Le PCA gère le pendant, le PRA gère l’après.
Construire un PRA solide demande du temps, un budget calibré et une rigueur de mise à jour permanente. Le dispositif ne protège réellement l’entreprise que s’il reflète l’état actuel de son infrastructure et que ses procédures ont été éprouvées par des tests réguliers. Un plan rédigé une fois puis oublié dans un dossier partagé offre exactement le même niveau de protection qu’une absence totale de plan.
