Séance 1 : PCA/PRA, RTO/RPO et analyse BIA

Introduction (10 min)

En décembre 2022, l'Hôpital de Versailles (CHSF) a subi un ransomware qui a contraint les équipes à une reprise manuelle des services sur papier pendant trois semaines. Le PRA n'avait pas été testé depuis plus de deux ans : dossiers patients inaccessibles, opérations déprogrammées, coût estimé ~10 M€. Cette accroche illustre pourquoi une stratégie de continuité et de reprise correctement priorisée, documentée et testée est vitale.

À l'issue de cette séance, vous serez capable de :

• Expliquer la différence opérationnelle entre PCA et PRA et décider quel dispositif appliquer selon le service.
• Calculer et fixer des RTO et RPO pertinents, et chiffrer le coût d'une interruption (formule CA/heure × durée).
• Mener une BIA (Business Impact Analysis) simple : identifier services critiques, dépendances, impacts et prioriser la reprise.

1. PCA vs PRA : distinction essentielle (60 min)

Le Plan de Continuité d'Activité (PCA) a pour objectif de maintenir les fonctions critiques PENDANT un incident avec une dégradation acceptable. Autrement dit, le PCA définit comment garder un service en fonctionnement, même de manière limitée (ex : bascule sur une instance de secours, mise en mode dégradé, file d'attente des tâches).

Le Plan de Reprise d'Activité (PRA) vise à RESTAURER les services APRÈS un sinistre majeur qui a laissé l'infrastructure arrêtée (ex : incendie, perte data center, corruption massive). Le PRA décrit la procédure pour revenir à un état opérationnel depuis des sauvegardes ou des copies hors site.

Exemple concret : si le contrôleur de domaine win-srv01 est inaccessible, un PCA peut consister à activer un DC secondaire hébergé en warm-standby pour préserver l'authentification, alors que le PRA décrit la restauration complète du DC principal depuis sauvegarde si tous les contrôleurs sont perdus.

Dans la pratique : PCA = maintenir, PRA = restaurer. Les deux sont complémentaires et doivent être alignés sur les objectifs métier (SLA métier).

2. RTO — Recovery Time Objective (30 min)

Le RTO est la durée maximale d'interruption tolérée par le métier pour un service donné. C'est un paramètre métier, pas uniquement technique : le service propriétaire décide du RTO en fonction des pertes acceptables.

Exemples pratiques pour InnovatTech (illustration pédagogique) :

• AD (win-srv01) : RTO cible = 4 h — les comptes et authentifications doivent être rétablis rapidement pour permettre le travail des postes.
• Messagerie (debian-srv02) : RTO cible = 8 h — les boîtes peuvent être dégradées, mais la reprise doit être faite dans la journée.
• Site web public : RTO cible = 2 h — impact commercial direct et visibilité.

Le RTO influe sur le choix de la technique de reprise : pour un RTO en minutes on privilégie du hot-standby / réplication synchrone ; pour des RTO en heures on accepte warm-standby ou restauration depuis sauvegarde rapide.

3. RPO — Recovery Point Objective (30 min)

Le RPO désigne la perte de données maximale tolérée, exprimée en temps. Un RPO de 1 h signifie qu'une heure de données au maximum peut être perdue.

Exemple : AD → RPO = 1 h signifie que les sauvegardes ou la réplication doivent garantir qu'au pire les données AD sont celles d'il y a 1 heure. Pour la messagerie, un RPO de 4 h peut être acceptable.

Conséquence technique : un RPO court impose des sauvegardes fréquentes (incrémentales horaires) ou une réplication quasi temps-réel (block-level/DRBD, SAN replication).

4. BIA — Business Impact Analysis (40 min)

La BIA identifie et classe les services critiques en évaluant :

• Impact financier (perte de CA, pénalités),
• Impact opérationnel (arrêt des tâches métiers),
• Impact réputationnel (clients, conformité).

Méthode simple : pour chaque service, estimer l'impact par heure (ou par jour), puis multiplier par la durée d'indisponibilité pour obtenir la perte financière probable.

Formule de calcul

Perte financière directe = CA/heure × durée d'arrêt (h)

Exemple chiffré :
  CA = 3 000 €/h
  Site web indisponible 2 h → perte = 3 000 × 2 = 6 000 €
  AD indisponible 4 h      → perte = 3 000 × 4 = 12 000 €
  (+ coûts indirects : astreinte, image, pénalités SLA)

Dépendances techniques

Cartographier les dépendances techniques est essentiel. Si AD tombe → l'authentification échoue → la messagerie et le site web peuvent aussi devenir inaccessibles. La BIA doit représenter ces enchaînements pour éviter de restaurer un service isolé qui reste non fonctionnel faute de dépendance restaurée.

Schéma de dépendances InnovatTech :

  win-srv01 (AD/DNS)
       │
       ├──► debian-srv02 (messagerie) — dépend LDAP auth
       ├──► Site web (DMZ)            — dépend DNS interne
       ├──► nas01 (partages)          — dépend DFS/AD
       └──► proxmox01 (VMs)           — héberge win-srv01 !

Si proxmox01 tombe → win-srv01 inaccessible → cascade AD

5. Niveaux de résilience et stratégies (20 min)

Niveaux standards

• Hot standby : bascule quasi instantanée, RTO = minutes (ex : doublement synchrone, cluster active/active).
• Warm standby : réplique des données avec délai, RTO = heures (ex : VM standby sur hébergeur différent).
• Cold standby : restauration depuis sauvegarde complète, RTO = jours.

Stratégies de sauvegarde (compromis)

Règle étendue recommandée : 3-2-1-1-0

┌──────────────────────────────────────────────────────┐
│              RÈGLE 3-2-1-1-0                        │
├──────────────────────────────────────────────────────┤
│  3️⃣  Copies des données (original + 2 sauvegardes) │
│  2️⃣  Supports différents (disque, bande, cloud)    │
│  1️⃣  Copie hors site (datacenter distant, cloud)   │
│  1️⃣  Copie immuable (WORM) — résiste aux ransomwares│
│  0️⃣  Zéro erreur de restauration (tests réguliers) │
└──────────────────────────────────────────────────────┘

Travaux Pratiques — TP S1 : Réaliser la BIA complète d'InnovatTech SARL (70–80 min)

Contexte : Vous êtes technicien chez InnovatTech SARL (35 salariés). L'infrastructure contient : win-srv01 (AD/DNS), debian-srv02 (messagerie), site web (DMZ), nas01 (partages), proxmox01 (VMs).

Objectif : produire une BIA complète, définir RTO/RPO cibles par service, calculer le coût d'interruption en prenant CA = 3 000 €/h, et fournir un tableau de priorisation P1/P2/P3.

Prérequis techniques

• Accès à la fiche d'exploitation d'InnovatTech (inventaire services/hôtes).
• Tableur (LibreOffice Calc / Excel) ou Markdown pour le tableau final.

Étapes

1. Lister les 5 services critiques : AD/DNS (win-srv01), Messagerie (debian-srv02), Site web (DMZ), NAS partages (nas01), Hyperviseur/VMs (proxmox01).
2. Pour chaque service, interviewer le responsable métier (ou utiliser hypothèses pédagogiques) et estimer l'impact financier/opérationnel/réputationnel par heure.
3. Attribuer une valeur d'impact financier par heure (CA/h = 3 000 € réparti selon service si applicable).
4. Proposer un RTO cible (minutes/heures/jours) et un RPO cible (minutes/heures) pour chaque service, avec justification métier.
5. Calculer la perte financière pour scénarios d'interruption type : 1 h, 4 h, 24 h.
6. Identifier dépendances techniques (ex : si win-srv01 indisponible ⇒ messagerie et site web impactés).
7. Produire un tableau récapitulatif : Service | RTO cible | RPO cible | Impact €/h | Perte(4h) | Priorité (P1/P2/P3) | Justification.
8. Classer en priorités P1 = reprise immédiate (≤ RTO), P2 = reprise sous 24 h, P3 = reprise sous 72 h.
9. Rédiger 1 page de synthèse expliquant vos choix.

Livrable attendu

• Un fichier Markdown ou tableur contenant la BIA complète et le tableau de priorisation.
• Une synthèse d'une page justifiant RTO/RPO et priorités.

Critères de réussite

• Toutes les 5 entrées renseignées avec RTO/RPO justificatifs.
• Calculs financiers cohérents avec CA = 3 000 €/h.
• Tableau de priorisation clair et défendable.

Synthèse (10 min)

Cette séance a posé les fondements : PCA = maintenir, PRA = restaurer ; RTO/RPO sont des décisions métier qui déterminent les choix techniques ; la BIA est l'outil qui relie métier et technique en identifiant priorités et dépendances. Sans BIA on applique des moyens coûteux au mauvais endroit.

Question de vérification : En une phrase, expliquez pourquoi un RPO strict implique souvent une réplication plutôt qu'une sauvegarde horaire.

Séance suivante : Architectures résilientes, runbooks de reprise, tests PRA et post-mortem.