La vision de Cyber Academy
Le disaster recovery est le sous-ensemble du BCM centré sur l'IT : restaurer les infrastructures, les applications et les données après une interruption. Le RPO, le RTO et les runbooks y trouvent leur place. Un plan de DR qui n'a jamais été testé de bout en bout est une fiction. ISO 24762 le couvrait autrefois ; la pratique actuelle renvoie à ISO 22301 complété par les runbooks opérationnels.
Où se situe la reprise après sinistre au sein de la continuité
La reprise après sinistre est la salle des machines technique de la continuité d'activité. Le management de la continuité d'activité pose la question de savoir comment l'organisation continue à délivrer ses activités critiques pendant une perturbation, en couvrant les personnes, les locaux, les fournisseurs et les processus. La reprise après sinistre répond à une question plus étroite : comment remettre l'informatique en route. Serveurs, réseaux, applications, bases de données et les données elles-mêmes. Lorsqu'un centre de données est inondé, qu'une souche de rançongiciel chiffre la production ou qu'une région cloud s'éteint, le plan de reprise est le document et la mémoire musculaire qui remettent les systèmes en marche dans un ordre connu, jusqu'à un point dans le temps connu.
Cette distinction compte parce que les deux sont souvent confondues. Un plan de continuité peut décrire des contournements manuels qui maintiennent un service en vie pendant que l'informatique est hors service. Un plan de reprise n'a pas ce luxe. Il se juge uniquement sur le fait que les systèmes reviennent, à quelle vitesse et combien de données ont été perdues. Traiter la reprise comme un sous-ensemble de la continuité plutôt que comme un synonyme garde le périmètre honnête et empêche les équipes de supposer qu'un serveur rétabli signifie un service métier rétabli.
RTO, RPO et le runbook
Deux chiffres gouvernent chaque décision de reprise. L'objectif de temps de reprise (RTO) est la durée maximale tolérable pendant laquelle un système peut être indisponible avant que l'impact ne devienne inacceptable. L'objectif de point de reprise (RPO) est la quantité maximale tolérable de perte de données, exprimée sous forme de fenêtre temporelle, ce qui dicte en pratique la fréquence à laquelle vous répliquez ou sauvegardez. Un RTO de quatre heures avec un RPO de quinze minutes constitue une architecture très différente, et un budget très différent, d'un RTO au jour ouvré suivant avec une sauvegarde quotidienne. Ces objectifs doivent provenir d'une analyse d'impact sur l'activité, et non du niveau de confort de l'équipe d'infrastructure.
- Le RTO pilote l'architecture de reprise : redondance à chaud et réplication pour les cibles serrées, restauration depuis sauvegarde pour les cibles plus souples.
- Le RPO pilote la stratégie de protection des données : réplication synchrone, instantanés, ou sauvegardes périodiques.
- Le runbook transforme ces objectifs en une procédure de reprise testée, étape par étape, que quelqu'un sous pression peut réellement suivre.
Normes, menaces et pratique actuelle
Le paysage normatif a évolué. ISO/IEC 24762 fournissait autrefois des recommandations dédiées sur les services de reprise après sinistre des TIC, mais elle a été retirée, et la pratique actuelle renvoie à ISO 22301 pour le système de management de la continuité d'activité, ISO/IEC 27031 couvrant la préparation des TIC à la continuité d'activité.
Dans ce modèle, la reprise n'est pas une discipline autonome ; c'est la couche opérationnelle qui réalise la stratégie de continuité, gouvernée par le même système de management et le même appétit pour le risque. Les secteurs réglementés ajoutent leur propre pression : le régime de résilience du secteur financier de l'UE, par exemple, attend des entreprises qu'elles démontrent que la reprise et la continuité des fonctions critiques sont testées, et pas seulement documentées.
La reprise moderne est également façonnée par les menaces qu'elle doit absorber. Le rançongiciel en particulier a réécrit le scénario, car si vos sauvegardes sont accessibles et inscriptibles depuis l'environnement de production, un attaquant les chiffre elles aussi. Les praticiens privilégient désormais des sauvegardes immuables et isolées, des environnements de reprise segmentés et des reconstructions en salle blanche afin que la restauration ne réinfecte pas tout simplement.
Le cloud et l'infrastructure-as-code ont rendu certaines reprises plus rapides à automatiser, mais ils introduisent leurs propres points de défaillance uniques aux couches région, compte et identité. La discipline reste la même qu'elle a toujours été : connaissez vos objectifs, protégez vos données pour qu'elles survivent au sinistre, écrivez un runbook que quelqu'un peut suivre, et prouvez qu'il fonctionne avant d'en avoir besoin.
Frequently asked questions
01Quelle est la différence entre reprise après sinistre et continuité d'activité ?
La continuité d'activité est la discipline large consistant à maintenir les activités métier critiques en fonctionnement pendant une perturbation, en couvrant les personnes, les processus, les locaux et les fournisseurs. La reprise après sinistre est le sous-ensemble centré sur l'informatique : restaurer l'infrastructure, les applications et les données. La reprise délivre la partie technique de la stratégie de continuité.
02Quelle est la différence entre RTO et RPO ?
Le RTO indique combien de temps un système peut être indisponible avant que l'impact ne soit inacceptable ; il pilote donc la vitesse de reprise. Le RPO indique la quantité de données que vous pouvez vous permettre de perdre, mesurée comme une fenêtre temporelle ; il pilote donc la fréquence à laquelle vous répliquez ou sauvegardez.
03ISO 24762 est-elle encore la référence pour la reprise après sinistre ?
Non. ISO/IEC 24762 a été retirée. La pratique actuelle ancre la reprise dans ISO 22301 pour le système de management de la continuité et ISO/IEC 27031 pour la préparation des TIC, la reprise se situant comme la couche opérationnelle sous-jacente.
04À quelle fréquence un plan de reprise doit-il être testé ?
Testez à un rythme régulier et après tout changement significatif des systèmes ou de l'architecture. Combinez des exercices de reprise complets avec des exercices sur table du flux de décision, et documentez les écarts que chaque test révèle afin que le plan continue de s'améliorer.
05Pourquoi les attaques par rançongiciel changent-elles la reprise après sinistre ?
Parce que les sauvegardes accessibles depuis la production peuvent être chiffrées en même temps qu'elle, mettant en échec la reprise. La reprise face au rançongiciel repose sur des sauvegardes immuables et isolées et sur des environnements de reprise propres afin que la restauration ne réintroduise pas le maliciel.