Plan de Reprise d'Activité (PRA) et Plan de Continuité d'Activité (PCA)

Plan de Reprise d'Activité (PRA) et Plan de Continuité d'Activité (PCA)

Définitions

PCA (Plan de Continuité d'Activité) : Ensemble des mesures visant à assurer la continuité des fonctions critiques de l'entreprise pendant et après un incident majeur.

PRA (Plan de Reprise d'Activité) : Procédures permettant de remettre en service les systèmes informatiques après un sinistre, dans un délai prédéfini.

Différence clé : Le PCA maintient l'activité pendant la crise, le PRA rétablit les systèmes après la crise.

Indicateurs critiques

RTO (Recovery Time Objective) : Durée maximale d'interruption acceptable - Site e-commerce : RTO = 1h (perte de CA critique) - Application interne : RTO = 24h (impact limité)

RPO (Recovery Point Objective) : Perte de données maximale acceptable - Base clients : RPO = 0 (réplication en temps réel) - Logs d'accès : RPO = 24h (sauvegarde quotidienne)

Exemple concret : Site e-commerce

Scénario : Datacenter principal hors service (incendie, inondation)

PCA - Maintien de l'activité

# Bascule automatique vers datacenter secondaire
Architecture:
  - Site A (Principal): Paris
  - Site B (Secours): Strasbourg
  - Load balancer avec healthcheck

Bascule automatique:
  - Healthcheck échoue → 3 tentatives en 30s
  - Si échec confirmé → Redirection DNS vers Site B
  - Durée d'interruption : ~5 minutes

Actions immédiates : 1. Monitoring détecte l'incident (Nagios/Prometheus) 2. Alerte automatique équipe IT 3. Bascule DNS automatique (TTL=60s) 4. Vérification du site B (checklist 15 min) 5. Communication clients via bandeau "Mode dégradé"

PRA - Remise en service

Après extinction du sinistre :

# Phase 1 : Évaluation (J+0)
- État infrastructure physique
- Inventaire matériel récupérable
- Estimation délais réparation

# Phase 2 : Reconstruction (J+1 à J+7)
- Commande nouveau matériel si nécessaire
- Réinstallation OS et applicatifs
- Restauration données depuis sauvegardes

# Phase 3 : Tests (J+7 à J+10)
- Tests fonctionnels complets
- Tests de charge
- Validation sécurité

# Phase 4 : Retour production (J+10)
- Bascule DNS progressive (10% → 50% → 100%)
- Monitoring intensif 48h

Exemple 2 : Cyberattaque ransomware

Scénario : Chiffrement des serveurs de fichiers

PCA

Immédiat (H+0 à H+2) :

# Isolation réseau
iptables -A INPUT -s 0.0.0.0/0 -j DROP  # Couper serveurs infectés
# Vérification périmètre infection
for host in $(cat inventory); do
  ssh $host "test -f /tmp/ransom_note.txt && echo INFECTED || echo OK"
done

# Bascule sur serveurs de secours
# Restauration depuis snapshots immuables (J-1)

Communication : - IT : Alerte générale, interdiction d'allumer postes - Direction : État des lieux, coût estimé - Clients : Email "Maintenance exceptionnelle"

PRA

# Procédure de restauration
étapes = {
    1: "Analyse forensique (déterminer vecteur d'attaque)",
    2: "Reconstruction serveurs from scratch",
    3: "Restauration données depuis backup offline J-1",
    4: "Mise à jour sécurité (patch vulnérabilité exploitée)",
    5: "Durcissement sécurité (2FA obligatoire, segmentation réseau)",
    6: "Tests intrusion avant remise en prod"
}

# Délai total : 3-5 jours

Exemple 3 : Panne humaine (suppression base de données)

Scénario : DROP DATABASE production; exécuté par erreur

PCA

-- Immédiat : Basculer sur réplica secondaire (lecture seule)
-- Durée : 30 secondes

-- Communication transparente pour utilisateurs
-- Mode dégradé : consultation OK, modifications bloquées

PRA

# Restauration base depuis backup
# 1. Arrêt application (mode maintenance)
docker service scale api=0

# 2. Restauration backup J-0 4h00
pg_restore -d production /backups/prod_04h00.dump

# 3. Rejouer les logs transactionnels 4h00 → incident
pg_waldump /wal/archive/*.wal | psql production

# 4. Vérification intégrité
psql -c "SELECT COUNT(*) FROM users;"  # Comparer avec métriques

# 5. Remise en service progressive
docker service scale api=2  # Test
# Si OK après 10 min
docker service scale api=10  # Full capacity

# Durée totale : 45 minutes
# Perte de données : ~10 minutes (RPO respecté)

Matrice de criticité

Tests obligatoires

Fréquence recommandée : - Test PCA : Trimestriel (bascule réelle vers site de secours) - Test PRA : Semestriel (restauration complète environnement) - Test partiel : Mensuel (restauration d'une VM)

Exemple de test :

# Test PRA - Un samedi matin
1. Snapshot production → environnement test
2. Simuler perte complète (arrêt brutal VM)
3. Chronomètre : démarrer
4. Exécuter procédure PRA
5. Valider : site accessible, données cohérentes
6. Chronomètre : arrêter
7. Comparer au RTO prévu
8. Documenter écarts et corriger procédure

Budget PCA/PRA réaliste

PME (50 personnes) : - Site de secours mutualisé : 500€/mois - Sauvegardes externalisées : 200€/mois - Tests semestriels : 2 jours homme - Total : ~10k€/an

Grande entreprise : - Datacenter secondaire : 50k€/mois - Équipe dédiée (3 personnes) : 180k€/an - Infrastructure redondée : 200k€ capex - Total : ~800k€/an

Le coût d'un PCA/PRA doit être comparé au coût d'une interruption d'activité. Si 1h d'arrêt coûte 100k€, investir 50k€/an dans un PCA avec RTO=15min est rentable dès le premier incident évité.