5.2Plan de sauvegarde & reprise d'activité (PRA/PCA)
La sauvegarde (niveau 3) protège les données ; le plan de reprise va plus loin : il prépare l'organisation à continuer ou reprendre son activité après un incident majeur (panne grave, sinistre, cyberattaque, perte de données). On distingue deux notions complémentaires. Le PRA (Plan de Reprise d'Activité) : comment redémarrer les systèmes informatiques après un sinistre (restaurer les serveurs, les données, les services). Le PCA (Plan de Continuité d'Activité) : comment maintenir l'activité essentielle pendant l'incident (solutions de secours, procédures dégradées) — vision plus large, qui dépasse l'IT. En clair : le PCA vise à ne pas s'arrêter, le PRA à repartir vite quand on s'est arrêté.
Deux indicateurs structurent tout plan de reprise, et il faut les comprendre. Le RPO (Recovery Point Objective) : quelle quantité de données peut-on se permettre de perdre ? Il détermine la fréquence des sauvegardes (un RPO d'une heure impose de sauvegarder au moins toutes les heures ; un RPO d'un jour tolère une sauvegarde quotidienne). Le RTO (Recovery Time Objective) : en combien de temps doit-on avoir tout remis en marche ? Il détermine les moyens de restauration (un RTO de quelques heures exige une infrastructure de reprise bien plus réactive qu'un RTO de plusieurs jours). Ces objectifs se fixent selon la criticité de chaque activité : tout n'a pas le même niveau d'exigence. Concrètement, bâtir un plan de reprise suppose : identifier les activités et données critiques, définir RPO/RTO pour chacune, mettre en place les sauvegardes et moyens de reprise correspondants, documenter les procédures (qui fait quoi, dans quel ordre — section 5.4), et surtout tester régulièrement. Car c'est le prolongement direct de la leçon du niveau 3 : un plan de reprise jamais testé ne vaut rien. On teste les restaurations, on simule des scénarios de sinistre, on vérifie que les procédures fonctionnent et que les délais sont tenables. Trop d'organisations découvrent, le jour de la crise, que leur « plan » n'était qu'un document théorique. Deux réalités à intégrer. D'abord, le plan de reprise n'est pas qu'affaire de technique : il implique l'organisation, les responsabilités, la communication de crise. Ensuite, à l'ère des rançongiciels, la capacité à restaurer à partir de sauvegardes saines (et déconnectées, pour qu'elles ne soient pas chiffrées elles aussi) est devenue la meilleure assurance-vie d'une organisation — beaucoup d'entreprises paralysées par une attaque ne s'en sont sorties que grâce à des sauvegardes testées et un plan de reprise éprouvé.
Vocabulaire de la section
- PRA (Plan de Reprise d'Activité)
- Plan pour redémarrer les systèmes informatiques après un sinistre (restaurer serveurs, données, services).
- PCA (Plan de Continuité d'Activité)
- Plan pour maintenir l'activité essentielle PENDANT l'incident (solutions de secours, mode dégradé) ; dépasse l'IT.
- RPO (Recovery Point Objective)
- Quantité de données qu'on accepte de perdre ; détermine la fréquence des sauvegardes.
- RTO (Recovery Time Objective)
- Temps maximal pour tout remettre en marche ; détermine les moyens de restauration.
- Test de plan
- Simulation régulière de sinistre et de restauration ; un plan de reprise jamais testé ne vaut rien.
Que distingue le RPO du RTO dans un plan de reprise ?
En pratique — Ébaucher un plan de reprise
- Identifiez les activités et données CRITIQUES à protéger en priorité.
- Pour chacune, définissez le RPO (données tolérables à perdre) et le RTO (temps de reprise acceptable) selon la criticité.
- Mettez en place les sauvegardes et moyens de reprise correspondants, avec des sauvegardes saines et déconnectées (anti-rançongiciel).
- Documentez les procédures (qui fait quoi) et TESTEZ régulièrement (restaurations, scénarios de sinistre).
Points clés à retenir
- PRA = redémarrer l'informatique après un sinistre ; PCA = maintenir l'activité pendant l'incident (plus large que l'IT).
- RPO = données qu'on accepte de perdre (→ fréquence de sauvegarde) ; RTO = temps de reprise acceptable (→ moyens de restauration).
- Fixer RPO/RTO selon la criticité de chaque activité ; documenter les procédures et TESTER régulièrement (un plan non testé ne vaut rien).
- Face aux rançongiciels, restaurer depuis des sauvegardes saines et DÉCONNECTÉES est la meilleure assurance-vie.
Questions fréquentes
Un plan de reprise, n'est-ce pas surdimensionné pour une petite structure ?
La forme doit être proportionnée à la taille, mais le principe est vital à toute échelle — et croire que « c'est pour les grandes entreprises » est une erreur qui coûte cher aux petites structures, souvent les plus vulnérables. Nuançons. Ce qu'on imagine en entendant « plan de reprise » — un document épais, des infrastructures de secours coûteuses, des procédures élaborées — correspond effectivement à de grandes organisations avec des enjeux considérables. Une petite structure n'a pas besoin de cela, et vouloir copier ces dispositifs serait disproportionné et irréaliste. Mais le besoin sous-jacent est universel : que se passe-t-il si vous perdez vos données ou vos systèmes ? Une petite entreprise qui perd sa comptabilité, ses fichiers clients, ses documents de travail à cause d'un rançongiciel ou d'une panne peut tout simplement ne pas s'en remettre — les statistiques sur les petites structures victimes de sinistres informatiques graves sans plan de reprise sont sévères. Paradoxalement, les petites structures sont souvent plus fragiles : moins de redondance, pas d'équipe IT dédiée, une dépendance totale à quelques outils. Un incident qui ne serait qu'un contretemps pour une grande entreprise résiliente peut être fatal pour une petite. Le plan de reprise n'est donc pas un luxe de grande entreprise, c'est une assurance de survie proportionnée à ses moyens. Concrètement, pour une petite structure, un plan de reprise « à sa mesure » peut être simple et peu coûteux, mais il doit exister et être réel. L'essentiel tient en quelques points : des sauvegardes fiables et testées (le cœur de tout, selon la règle 3-2-1 du niveau 3), avec au moins une copie hors site et déconnectée ; l'identification de ce qui est vraiment critique (quelles données, quels outils sont indispensables à l'activité ?) et une idée claire du RPO/RTO acceptable (combien de données peut-on perdre, en combien de temps faut-il repartir ?) ; une procédure documentée, même simple, décrivant comment restaurer et qui contacter (le prestataire, par exemple) ; et un test occasionnel pour vérifier que la restauration fonctionne vraiment. Cela ne demande pas de gros budget — surtout avec le cloud, qui rend la sauvegarde hors site et la reprise beaucoup plus accessibles qu'avant. Le principal investissement est, là encore, la rigueur : réfléchir en amont, à froid, à « que ferais-je si tout disparaissait demain ? », plutôt que de découvrir la réponse dans la panique le jour de la crise. En résumé : une petite structure n'a pas besoin d'un dispositif de grande entreprise, mais elle a absolument besoin de savoir qu'elle peut récupérer ses données et repartir après un incident. Adapter l'échelle, oui ; négliger le principe, jamais. Un plan de reprise simple mais réel et testé est l'une des meilleures protections qu'une petite structure puisse se donner.
Quelle différence pratique entre le RPO et le RTO ? Comment les fixer ?
Ces deux indicateurs sont au cœur de tout plan de reprise, et bien les comprendre évite de se tromper dans le dimensionnement des sauvegardes et des moyens de reprise. Ils répondent à deux questions différentes, qu'il ne faut pas confondre. Le RPO (Recovery Point Objective) répond à : « combien de données puis-je me permettre de perdre ? ». C'est un point dans le passé : si un sinistre survient maintenant, jusqu'à quel moment antérieur puis-je remonter ? Un RPO d'une heure signifie que je ne veux pas perdre plus d'une heure de travail ; un RPO d'un jour signifie que perdre une journée est tolérable. Le RPO détermine directement la fréquence des sauvegardes : pour un RPO d'une heure, il faut sauvegarder au moins toutes les heures (sinon on risque de perdre plus qu'une heure) ; pour un RPO d'un jour, une sauvegarde quotidienne suffit. Plus le RPO est court (moins on accepte de perdre), plus les sauvegardes doivent être fréquentes — donc plus le dispositif est coûteux. Le RTO (Recovery Time Objective) répond à une tout autre question : « en combien de temps dois-je avoir tout remis en marche ? ». C'est une durée : après le sinistre, combien de temps l'activité peut-elle rester à l'arrêt avant que ce soit inacceptable ? Un RTO de deux heures signifie qu'il faut avoir tout restauré et redémarré en deux heures ; un RTO de deux jours laisse plus de marge. Le RTO détermine les moyens de restauration : un RTO très court exige une infrastructure de reprise réactive (systèmes de secours prêts, restauration rapide, éventuellement redondance en temps réel), coûteuse ; un RTO long tolère une restauration plus artisanale et moins chère. Une image pour distinguer : imaginez un sinistre à midi. Le RPO dit « je récupère les données jusqu'à 11h » (j'ai perdu une heure = RPO d'une heure). Le RTO dit « je serai de nouveau opérationnel à 14h » (deux heures d'interruption = RTO de deux heures). L'un mesure la perte de données (en remontant dans le passé), l'autre la durée d'indisponibilité (en avançant vers la reprise). Comment les fixer ? Selon la criticité de chaque activité, car tout n'a pas le même niveau d'exigence — et c'est le point clé. Pour une activité vitale (une production qui coûte très cher à chaque heure d'arrêt, des données qu'on ne peut pas se permettre de perdre), on fixe des RPO et RTO courts, en acceptant le coût des moyens correspondants. Pour une activité secondaire, on tolère des RPO/RTO plus longs, ce qui coûte bien moins cher. Fixer ces objectifs est donc un arbitrage économique : plus on exige (RPO/RTO courts), plus on paie ; il faut trouver, pour chaque activité, le juste équilibre entre le coût de la protection et le coût de la perte/interruption. La démarche pratique consiste à lister les activités et données, à évaluer pour chacune l'impact d'une perte de données et d'une interruption (financier, opérationnel, réputationnel), et à en déduire des RPO/RTO réalistes. Une erreur fréquente est de vouloir un RPO/RTO très court pour tout « par sécurité » : c'est ruineux et inutile. La bonne approche différencie selon les enjeux. Une fois ces objectifs fixés, ils pilotent concrètement tout le dispositif : la fréquence des sauvegardes (RPO) et les moyens de reprise (RTO) — c'est pourquoi les définir est la première étape d'un plan de reprise sérieux.