Plan de reprise d'activité : concevoir un PRA infrastructure efficace

Toute infrastructure échouera un jour ou l'autre. Ce n'est pas une question de si, mais de quand et de combien de temps vous pourrez survivre sans elle. C'est à cet endroit qu'intervient le Plan de Reprise d'Activité (PRA) : une stratégie multidimensionnelle pour minimiser les pertes de données et restaurer vos services dans les meilleurs délais.

Ce guide explore les éléments fondamentaux du PRA moderne, des métriques critiques (RPO, RTO) aux tests réguliers et à l'automatisation, en passant par les pièges courants que rencontrent les organisations de toutes tailles.

1. PRA vs PCA : définitions et périmètre
2. RPO et RTO : les métriques clés à maîtriser
3. Stratégies de réplication : synchrone, asynchrone et hybrides
4. Architecture multi-site : active-active vs active-passive
5. Sauvegardes : le socle du PRA (règle 3-2-1)
6. Tests de bascule : du tabletop à la production
7. Documentation du PRA : modèle et templates
8. Automatiser la reprise : Ansible, health checks, DNS
9. Retour d'expérience : amélioration continue post-incident
10. Perspectives complémentaires : ressources et architectures avancées

Le Plan de Reprise d'Activité (PRA) ou Disaster Recovery Plan (DRP) cible spécifiquement la restauration technique des systèmes informatiques après une défaillance : bases de données, serveurs d'application, stockage.

Le Plan de Continuité d'Activité (PCA) ou Business Continuity Plan (BCP) est plus large : il englobe le PRA mais ajoute les processus métier, les communications, les ressources humaines et la gestion des enjeux légaux.

Quand s'applique chacun ?

• Une défaillance disque dans un datacenter → le PRA redémarre les VMs sur un autre hyperviseur en heures
• Un tremblement de terre affectant un site entier → le PCA active une seconde usine en jours

En pratique, tout CTO doit maîtriser le PRA pour que le PCA soit viable.

Deux chiffres dominent la conception d'un PRA efficace.

RTO (Recovery Time Objective)

Le RTO est le délai maximum acceptable entre la détection d'une panne et la restauration complète du service.

• RTO = 1 heure : redémarrage depuis sauvegarde, simple
• RTO = 15 minutes : basculement vers une réplique chaude, infrastructure dupliquée
• RTO = 0 minute : active-active, basculement transparent

Exemple : Une base de données métier critique ne peut pas être hors ligne plus de 2 heures, donc RTO = 2h.

RPO (Recovery Point Objective)

Le RPO est la quantité maximale de données perdues acceptable lors d'un sinistre.

• RPO = 24 heures : sauvegardes quotidiennes
• RPO = 1 heure : réplication asynchrone toutes les heures
• RPO = 0 : réplication synchrone (aucune donnée perdue, mais latence plus haute)

Exemple : Un panier e-commerce peut perdre 10 minutes de transactions, donc RPO = 10 min.

Tableau RPO/RTO par service

Service                  RTO       RPO       Complexité
────────────────────────────────────────────────────────
Base critique            30 min    5 min     Haute
API métier               1h        30 min    Moyen
Site web public          4h        2h        Basse
Archivage légal          24h       0         (sauvegarde immuable)

Piège courant : confondre RTO et RPO. Une réplication avec RPO = 0 n'implique pas RTO = 0 si la détection ou le basculement prend du temps.

Réplication synchrone vs asynchrone

Synchrone (RPO = 0)

Écriture sur site A
  ↓
Attendre confirmation site B
  ↓
Retourner ACK client

Avantages :

• Zéro perte de données
• Cohérence garantie

Inconvénients :

• Latence réseau visible (minimum 10–50 ms)
• Overhead réseau important (doublage du trafic)
• Impact sur les perf applicatives

Asynchrone (RPO > 0)

Écriture sur site A
  ↓
Retourner ACK client immédiatement
  ↓
(Quelques ms/secondes plus tard) Répliquer vers site B

Avantages :

• Zéro impact sur la latence
• Bande passante optimisée

Inconvénients :

• Risque de perte de transactions en vol
• RPO dépend de la latence de réplication

Cold, Warm, Hot Standby

Cold : Juste les sauvegardes, aucun serveur secondaire actif.

Warm : Répliques régulièrement mises à jour, mais l'infrastructure secondaire est arrêtée. Au moment du sinistre, démarrer les serveurs prend 15–30 minutes.

Hot : Répliques constamment synchronisées, prêtes à prendre le trafic en secondes.

Active-Passive

┌─────────────┐                 ┌─────────────┐
│ Site A      │ ─ Réplication →  │ Site B      │
│ (ACTIF)     │ ← Monitoring  ←  │ (PASSIF)    │
│ Trafic 100% │                 │ Trafic 0%   │
└─────────────┘                 └─────────────┘
     ↑
  DNS / Load Balancer

À la détection d'une panne sur A, le DNS (ou la sonde de load balancer) bascule vers B.

Avantages : Simple, coûts réduits (un seul site reçoit du trafic) Inconvénients : Temps de détection + basculement, ressources passives inutilisées

Active-Active

    ┌──────────────────────┐
    │     DNS Round-Robin   │
    └──────────────────────┘
           ↙ 50%        ↖ 50%
    ┌─────────────┐    ┌─────────────┐
    │ Site A      │    │ Site B      │
    │ (ACTIF)     │    │ (ACTIF)     │
    │ Trafic 50%  │    │ Trafic 50%  │
    └─────────────┘    └─────────────┘
           ↓ Réplication bidirectionnelle ↑

Chaque site reçoit du trafic et réplique vers l'autre en permanence.

Avantages : RTO quasi-nul, utilisation maximale des ressources Inconvénients : Complexité (split-brain, cohérence), coûts doublés, latence réseau croissante

Défis de cohérence dans les architectures multi-site

La réplication asynchrone entre deux sites pose des questions :

• Split-brain : si le lien réseau se casse, comment les deux sites savent-ils qui est leader ?
• Conflits d'écriture : deux clients écrivent sur deux données différentes en même temps, puis les changements se répliquent (résolvable par last-write-wins ou custom logic)
• Lag réplication : les données lues sur B peuvent être plus anciennes que sur A

Solution pratique : leader-leader avec quorum ou consensus (Pacemaker, etcd, Consul) pour éviter le split-brain.

La réplication n'est pas une sauvegarde. Une corruption logicielle qui se réplique aussi vers le site de secours vous tue tout autant.

Règle 3-2-1

3 copies des données
2 supports différents (disque + bande magnétique)
1 copie hors site (distant, géographiquement séparé)

Exemple concret

Donnée originale
  ├─ Copie 1 : Sauvegarde disque local, quotidienne (Proxmox VE, Veeam)
  ├─ Copie 2 : Sauvegarde sur bande magnétique, hebdomadaire (LTO-9)
  └─ Copie 3 : Sauvegarde disque hors site, chiffrée en S3/Object Storage distant

Sauvegardes immuables

Un backup immuable ne peut pas être modifié ou supprimé après sa création, même par l'administrateur. Cela protège contre :

• Les ransomwares qui tentent de supprimer les sauvegardes
• Les erreurs d'administration (rm -rf accidentel sur une sauvegarde)
• Les acteurs malveillants avec droits root compromis

# Exemple : Object Storage immuable (S3 Glacier avec Object Lock)
aws s3api put-object-retention \
  --bucket my-backups \
  --key backup-2026-03-22.tar.gz \
  --retention '{"Mode":"GOVERNANCE","RetainUntilDate":"2027-03-22T00:00:00Z"}'

Restaurations testées

Une sauvegarde qui ne s'est jamais restaurée n'est pas une sauvegarde, c'est un mensonge tranquille.

• Cycle d'audit : au moins une restauration complète par trimestre
• Alertes de succès : recevoir un mail si la sauvegarde réussit (pas juste en cas d'erreur)
• Documentez chaque restauration : durée réelle, données récupérées, problèmes rencontrés

Tabletop Exercise (Exercise sur table)

Réunir les parties prenantes (DSI, ops, direction) dans une salle avec un scénario fictif. Parcourir manuellement le PRA sans toucher aux systèmes.

Animateur : "Nous sommes le 22 mars 2026, 14h30. Le site de Toulouse est en feu.
            Qu'est-ce qu'on fait ?"
DSI :       "On détecte automatiquement en 3 min et escalade à la direction."
Ops :       "J'active le basculement DNS vers Bordeaux."
Direction : "Quelle perte de données ? Combien pour revenir ?"

Durée : 2–3 heures Fréquence : 2 fois par an minimum

Partial Failover Test

Basculer un seul service (ex: une base de données non critique) vers le site de secours, avec trafic réel.

• Détecte les bugs de réplication spécifiques à votre app
• Moins de risque qu'un full test
• Idéal pour la validation en continu

Full DR Test

Basculement complet d'une application en production vers le site de secours. Tous les services, trafic réel.

Préparation :

1. Annoncer 2 semaines avant
2. Planifier une fenêtre de maintenance
3. Préparer un backout plan (retour en arrière en 30 min)
4. Avoir un on-call renforcé

Pendant le test :

• Monitorer chaque métrique (CPU, I/O, latence, erreurs)
• Garder les équipes en contact constant
• Documenter chaque écart vs plan

Après le test :

• Post-mortem : qu'est-ce qui a dysfonctionné ?
• Mettre à jour le PRA avec les apprentissages

Fréquence : 1 fois par an minimum, mieux : 2 fois par an pour les systèmes critiques

Chaos Engineering

Injecter des pannes aléatoires dans la production ou un environnement de staging. Exemples :

# Éteindre une VM aléatoire toutes les heures
chaosmonkey --interval 1h --targets vm --mode kill

# Ajouter 500ms de latence sur 10% du trafic réseau
tc qdisc add dev eth0 root netem delay 500ms

# Tuer le process MySQL aléatoirement
(crontab) */15 * * * * pkill -9 -f mysqld

Permet de découvrir les soucis d'architecture avant une vraie panne.

Un PRA qui ne tient que dans la tête du CTO n'existe pas. Quand ce CTO part en vacances et que la panne arrive, c'est le chaos.

Template minimal

# Plan de Reprise d'Activité — ACME Corp

## 1. Équipe d'intervention

| Rôle               | Nom     | Téléphone         | Email             |
| ------------------ | ------- | ----------------- | ----------------- |
| Incident Commander | Alice   | +33 6 XX XX XX XX | alice@acme.corp   |
| DSI                | Bob     | +33 6 YY YY YY YY | bob@acme.corp     |
| DBA                | Charlie | +33 6 ZZ ZZ ZZ ZZ | charlie@acme.corp |

## 2. RTO/RPO par service

| Service      | RTO    | RPO   | Site Secondaire |
| ------------ | ------ | ----- | --------------- |
| API métier   | 30 min | 5 min | Bordeaux        |
| Base données | 15 min | 1 min | Bordeaux        |
| Site web     | 2h     | 1h    | Lyon            |

## 3. Procédure de basculement

### Phase 1 : Détection (0–5 min)

- Alerte probe défaillante → on-call notifié
- Vérifier que la panne est réelle (pas un faux positif)
- Escalader à Incident Commander

### Phase 2 : Décision (5–15 min)

- Conférence bridge : tous les on-call
- Décider : basculement partiel ou complet ?
- Informer la direction

### Phase 3 : Basculement (15–45 min)

- DBA valide réplication lag = 0 sur Bordeaux
- Ops bascule le DNS via terraform
- Equipe test vérifie trafic arrive sur Bordeaux

### Phase 4 : Retour en arrière (si nécessaire)

- Identifier la cause racine sur Toulouse
- Basculer DNS vers Toulouse
- Vérifier cohérence réplication inverse

## 4. Points de contact externes

| Service      | Contact           | Urgence            |
| ------------ | ----------------- | ------------------ |
| ISP          | Numéro SAV Orange | Perte connectivité |
| Hébergeur    | Support SHPV      | VM, stockage       |
| DNS provider | CloudFlare        | Basculement DNS    |

## 5. Communication de crise

- **Client externe** : mail dans les 15 min, maj toutes les 30 min
- **Équipe interne** : Slack #incident-responders (live updates)
- **Direction** : call toutes les heures
- **Presse** (si critique) : après accord direction

## 6. Runbook spécifique

[Lier vers documentation technique détaillée : basculement DNS, scripts Ansible, etc.]

Emplacement et accessibilité

• Fichier principal : Wiki interne, accessible 24/24
• Version papier : imprimer 2 exemplaires, coffre-fort de l'entreprise
• Synchroniser avec les sites : télécharger offline dans chaque DC, au cas où

La réaction humaine est lente et sujette aux erreurs sous stress. L'automatisation accélère et fiabilise.

Health Checks distribués

# health_check.py
import requests
import json
from datetime import datetime

ENDPOINTS = [
    ("https://api.company.com/health", "API"),
    ("https://db-master.toulouse.local:5432", "DB-Toulouse"),
    ("https://db-slave.bordeaux.local:5432", "DB-Bordeaux"),
]

def check_all():
    results = []
    for url, name in ENDPOINTS:
        try:
            resp = requests.get(url, timeout=5)
            status = "UP" if resp.status_code == 200 else "DOWN"
        except Exception as e:
            status = "DOWN"

        results.append({"service": name, "status": status, "ts": datetime.utcnow()})

    return results

if __name__ == "__main__":
    health = check_all()

    # Alerter si 3 probes DOWN en moins de 2 min
    down_count = len([x for x in health if x["status"] == "DOWN"])
    if down_count >= 3:
        # POST vers Pagerduty, Opsgenie, etc.
        trigger_incident()

    print(json.dumps(health))

Basculement DNS automatisé

# terraform/dns.tf
resource "aws_route53_record" "api" {
zone_id = aws_route53_zone.example.zone_id
name    = "api.example.com"
type    = "A"

set_identifier = "primary-toulouse"
failover_routing_policy {
type = "PRIMARY"
}

alias {
name                   = "api-toulouse.example.com"
zone_id                = aws_route53_zone.toulouse.zone_id
evaluate_target_health = true
}
}

resource "aws_route53_record" "api_secondary" {
zone_id = aws_route53_zone.example.zone_id
name    = "api.example.com"
type    = "A"

set_identifier = "secondary-bordeaux"
failover_routing_policy {
type = "SECONDARY"
}

alias {
name                   = "api-bordeaux.example.com"
zone_id                = aws_route53_zone.bordeaux.zone_id
evaluate_target_health = true
}
}

Route 53 bascule automatiquement vers SECONDARY si PRIMARY échoue les health checks.

Playbook Ansible pour orchestration

# failover.yml
---
- name: "Disaster Recovery Failover - Toulouse to Bordeaux"
  hosts: localhost
  vars:
    primary_site: toulouse
    secondary_site: bordeaux

  tasks:
    - name: "Check replication lag on Bordeaux"
      mysql_query:
        login_host: "db-bordeaux.local"
        query: "SHOW SLAVE STATUS\G"
      register: slave_status

    - name: "Fail if replication lag > 10 seconds"
      fail:
        msg: "Replication lag too high: {{ slave_status.query_result[0].Seconds_Behind_Master }}"
      when: slave_status.query_result[0].Seconds_Behind_Master > 10

    - name: "Promote Bordeaux as master"
      mysql_query:
        login_host: "db-bordeaux.local"
        query: "STOP SLAVE; RESET MASTER;"

    - name: "Update DNS via Route 53 (or local DNS server)"
      route53:
        zone: "example.com"
        record: "db-master.example.com"
        value: "db-bordeaux.local"
        type: "CNAME"
        state: "present"

    - name: "Notify Slack"
      slack:
        token: "{{ slack_token }}"
        channel: "#incidents"
        msg: "Failover completed: API now on Bordeaux"

    - name: "Create incident ticket in Jira"
      jira:
        uri: "https://jira.example.com"
        username: "bot"
        password: "{{ jira_token }}"
        project: "OPS"
        issue_type: "Incident"
        summary: "Automatic failover: Toulouse → Bordeaux"

Avec evaluate_target_health = true dans Terraform, ce playbook s'exécute automatiquement via un Lambda/webhook dès qu'une sonde échoue.

Un PRA qui ne change jamais devient obsolète. Chaque incident (réel ou simulé) doit générer des learnings.

Post-Incident Review (PIR)

Réunion sans culpabilisation dans les 48–72h après un incident DR (réel ou test).

Facilitateur : "Qu'est-ce qui s'est bien passé ?"
Ops1 :         "La détection a fonctionné en 3 min, c'était bon."
Ops2 :         "Mais le basculement DNS a pris 20 min à cause d'un oubli dans le runbook."

Facilitateur : "Action ? Comment éviter la prochaine fois ?"
Ops2 :         "Automatis DNS failover via Terraform, code review hebdo du runbook."

Registre des incidents DR

Tenir un registre vivant :

Incident | Date | Cause | RTO actuel | RTO cible | Action |
----------|------|-------|-----------|-----------|--------|
Défaillance disque Toulouse | 2025-11-15 | Secteur défaillant | 2h 30min | 30min | Passer en architecture active-active |
Test DR complet Q2 2026 | 2026-04-10 | Test | 1h 15min | 30min | Améliorer démarrage VMs secondaires |

Mise à jour cyclique

• Trimestriel : revérifier les contacts (départs, changements de tél)
• Semestriel : table-top exercise avec nouveaux scénarios
• Annuel : full failover test
• Lors d'un changement d'architecture : revalider RPO/RTO

Vos besoins spécifiques peuvent nécessiter des architectures plus poussées :

• Pacemaker + Corosync : Clustering haute disponibilité pour Linux (heartbeat, fencing, STONITH)
• Kubernetes HA : Étendre le PRA aux conteneurs (etcd backups, node affinity, pod disruption budgets)
• Velero pour backup Kubernetes : Automatiser sauvegarde et restauration de clusters K8s
• Stratégie 3-2-1 dans AWS : Appliquer 3-2-1 avec S3, Glacier et EBS snapshots
• HAProxy en cluster : Load balancing résilient en multiples datacenters

Pour une infrastructure très critique (banking, healthcare), investiguer aussi :

• Synchronisation de temps précise (NTP, GPS) entre sites
• Séparation complète des canaux de communication (plusieurs FAI, fibres distinctes)
• Retour d'expérience régulier avec l'assureur et audit tierce partie (ISO 27001, SOC 2)

• NIST Cybersecurity Framework — Disaster Recovery : définitions et bonnes pratiques de DR aux USA
• AWS Well-Architected Framework — Disaster Recovery : patterns et coûts de réplication multi-région
• Gartner Magic Quadrant for Disaster Recovery as a Service : panorama des solutions DR
• Veeam Backup & Replication Docs : outils populaires pour sauvegarde/réplication VMware et Hyper-V
• Red Hat Pacemaker Cluster Suite : opensource HA pour infrastructure Linux
• Kubernetes Disaster Recovery Best Practices : guides DR natifs K8s
• RTO vs RPO Explainer — Druva : blog technique clair sur les métriques clés

Un Plan de Reprise d'Activité solide n'est pas un document figé : c'est un processus vivant d'amélioration continue, d'automatisation et de tests réguliers.

À chaque panne (ou simulation), vous apprenez :

• Quel RTO/RPO est réaliste pour votre infrastructure
• Où sont les goulots d'étranglement : détection ? DNS ? orchestration ?
• Quels outils et procédures fonctionnent vraiment sous stress

SHPV opère dans trois datacenters français (Toulouse/Fullsave, Bordeaux/TDF, Lyon/Nexeren) interconnectés via un backbone AS41652 de 150 Gbps. Cette architecture multi-site offre la résilience géographique aux clients critiques, mais elle impose aussi une discipline rigoureuse : réplication testée, sauvegardes immuables, failover automatisé. La même rigueur s'applique à votre PRA interne.

La vraie résilience, c'est celle qu'on a testée.