À quoi sert un DRP
Le Disaster Recovery Plan (DRP) est l'ensemble documenté des procédures, infrastructures et responsabilités qui permet à une organisation de reprendre ses activités IT après un sinistre majeur : perte d'un datacenter, attaque ransomware paralysant l'infrastructure, corruption massive de données, indisponibilité durable d'un fournisseur cloud. Le DRP ne couvre pas les incidents ordinaires (un serveur qui plante, un service qui crashe) ; il s'active uniquement quand la production normale est inopérante au-delà d'un seuil prédéfini.
Un DRP réussi répond à quatre questions concrètes : qui décide d'activer le plan, quelles infrastructures de secours sont disponibles, comment restaurer chaque application critique dans l'ordre, et comment communiquer aux clients et collaborateurs pendant la crise.
Les composants d'un DRP solide
Analyse d'impact business (BIA). Cartographie des applications critiques, valeur business par heure d'arrêt, RTO et RPO cibles par périmètre. C'est la fondation : sans BIA, le DRP s'aligne sur des intuitions plutôt que sur des priorités business.
Site de secours. Selon le RTO visé, le site secondaire est froid (infrastructure dormante à activer manuellement), tiède (infrastructure préinstallée mais sans données récentes) ou chaud (réplication temps-réel, bascule automatique). Le coût varie typiquement de 1 (site froid) à 5 (site chaud actif-actif) en multiple du coût de l'infrastructure principale.
Procédures de restauration. Runbooks détaillés par application : ordre de démarrage des services, dépendances entre composants, validations fonctionnelles avant déclaration de service rétabli. Les runbooks doivent être lisibles sous stress, par une personne qui n'a pas forcément conçu le système.
Plan de communication. Qui prévient les clients, sous quels canaux, dans quel délai. Les obligations RGPD imposent une notification dans les 72 heures en cas de fuite de données. La FINMA exige une notification immédiate pour les institutions financières.
Tests réguliers. Un DRP non testé est une fiction. La cadence minimum recommandée : un test complet de bascule annuel, un test partiel trimestriel, une validation théorique mensuelle.
DRP et conformité suisse
Plusieurs cadres réglementaires imposent un DRP en Suisse :
- FINMA RS 2018/3 (gestion des risques opérationnels) : DRP documenté et testé annuellement pour les banques et entreprises d'investissement.
- nLPD (loi sur la protection des données) : mesures de sécurité adéquates incluant la disponibilité, donc un DRP proportionné à la sensibilité des données.
- ISO 27001 annexe A.17 : politique formalisée de continuité de la sécurité de l'information, plans testés et révisés.
- Secteur santé : RA-ASA, eHealth Suisse imposent des plans de reprise pour les systèmes EPD.
Pour les clients soumis à ces cadres, le DRP devient un livrable d'audit, pas un document interne facultatif.
Erreurs courantes observées
Sur nos missions de conseil Hidora, les défaillances de DRP suivent des patterns récurrents :
-
Sauvegardes non testées : la politique existe, les sauvegardes tournent, mais aucune restauration n'a été validée depuis 2 ans. Découverte typique : un format de sauvegarde devient incompatible après une montée de version.
-
Dépendances oubliées : le DRP couvre les applications mais pas les services tiers (DNS externe, authentification SaaS, fournisseur de mail). En sinistre réel, ces dépendances rendent la procédure inopérante.
-
Documentation à jour mais runbooks périmés : la cartographie reflète l'état idéal, les commandes opérationnelles datent d'il y a 18 mois. À 3 heures du matin, l'écart fait perdre 2 heures de RTO.
Services Hidora associés
- Consulting : audit BIA, conception du DRP, rédaction des runbooks, organisation des tests trimestriels.
- Managed Services : exécution opérationnelle du DRP avec rapports mensuels et tests semestriels.
- SLA Expert : intervention en astreinte H24 lors de l'activation du plan.
- RTO, RPO, Cloud souverain : indicateurs et briques associées.