Résilience cloud : HA, Disaster Recovery et continuité d'activité

Votre application cloud tombe en panne : combien de temps pouvez-vous rester indisponible avant de perdre des clients ? Combien de données pouvez-vous vous permettre de perdre ? Ce guide vous explique comment concevoir des architectures cloud résilientes avec haute disponibilité (HA), disaster recovery (DR), et stratégies de sauvegarde adaptées à vos objectifs métier (RTO/RPO).

Ce que vous allez apprendre

• La différence entre HA (Haute Disponibilité) et DR (Disaster Recovery)
• Comment définir RTO (Recovery Time Objective) et RPO (Recovery Point Objective)
• Concevoir une architecture multi-zone tolérante aux pannes
• Mettre en place une stratégie de backup et restore efficace
• Les patterns cloud-native pour la résilience

Prérequis : Connaître les bases du cloud et les zones de disponibilité. Si besoin, voir Régions et zones cloud.

HA vs DR : deux concepts complémentaires

Haute Disponibilité (HA) : éviter l’interruption

Objectif : Garantir que votre application reste accessible même si un composant tombe en panne (serveur, datacenter, réseau).

Principe : Redondance + basculement automatique (failover).

Exemple concret :

Vous avez un site e-commerce. Pour garantir la HA :

• Déployer l’application dans 2 zones de disponibilité (AZ) différentes
• Placer un load balancer devant les serveurs
• Si une AZ tombe, le load balancer redirige automatiquement vers l’autre

SLA typique : 99.9% à 99.99% de disponibilité (8h à 52 min d’indisponibilité/an max)

Disaster Recovery (DR) : se remettre du pire

Objectif : Récupérer après un événement catastrophique (incendie datacenter, cyberattaque, corruption de données, erreur humaine massive).

Principe : Sauvegardes + réplication + plan de reprise testé régulièrement.

Exemple concret :

Un ransomware chiffre toute votre base de données production. Sans DR :

• ❌ Vos données sont perdues
• ❌ Vous payez la rançon (sans garantie de récupération)

Avec DR :

• ✅ Vous restaurez la base depuis le backup de la veille
• ✅ Perte maximale : 24h de données (RPO = 24h)

Comparaison HA vs DR

Critère	Haute Disponibilité (HA)	Disaster Recovery (DR)
Objectif	Éviter l’interruption	Se remettre de l’interruption
Échelle temps	Secondes à minutes	Minutes à heures
Événement	Panne technique (serveur, zone)	Catastrophe (incendie, cyber, corruption)
Solution	Redondance + failover auto	Backups + réplication + runbook
Coût	Moyen (x2 à x3 ressources)	Variable (stockage backups + test DR)
Test	Automatique (load balancer)	Manuel régulier (drill DR)

Glissez pour voir

HA ET DR, pas HA OU DR

Les deux sont complémentaires, pas alternatifs :

• HA protège contre les pannes courantes (serveur qui crash, mise à jour ratée)
• DR protège contre les événements catastrophiques rares (datacenter détruit, ransomware, erreur humaine massive)

Une architecture mature a les deux.

RTO et RPO : vos contraintes métier

Avant de concevoir une architecture résiliente, définissez deux métriques clés avec le métier :

RPO (Recovery Point Objective)

Question : Combien de données pouvez-vous perdre maximum ?

Définition : Ancienneté maximale acceptable de la dernière sauvegarde avant l’incident.

Exemples :

Cas d’usage	RPO acceptable	Stratégie backup
Blog personnel	1 semaine	Backup hebdomadaire manuel
Site e-commerce	1 heure	Backup horaire automatisé
Transactions bancaires	0 minute (zéro perte)	Réplication synchrone continue

Glissez pour voir

Concrètement :

• RPO = 24h → Backup quotidien à 3h du matin. Si incident à 14h, vous perdez 11h de données.
• RPO = 1h → Backup toutes les heures. Si incident à 14h32, vous perdez max 32 min de données.
• RPO = 0 → Réplication synchrone (chaque transaction écrite dans 2 datacenters).

RTO (Recovery Time Objective)

Question : Combien de temps d’indisponibilité pouvez-vous tolérer ?

Définition : Délai maximal acceptable entre l’incident et le retour à la normale.

Exemples :

Cas d’usage	RTO acceptable	Architecture nécessaire
Site vitrine corporate	4 heures	Backup + restore manuel
SaaS B2B (clients professionnels)	15 minutes	HA multi-zone + failover auto
Plateforme financière	0 minute (zéro downtime)	Active-Active multi-région

Glissez pour voir

Concrètement :

• RTO = 4h → Vous avez 4h pour restaurer le backup et redémarrer l’app (acceptable pour un intranet interne)
• RTO = 15 min → Failover automatique vers zone secondaire (e-commerce, SaaS)
• RTO = 0 → Architecture active-active, pas de failover (banque, bourse)

Matrice RTO/RPO

RTO	RPO	Coût	Architecture type
Élevé (4h+)	Élevé (24h+)	€	Backup quotidien + restore manuel
Moyen (1h)	Moyen (1h)	€€	HA multi-zone + backup horaire
Faible (5min)	Faible (5min)	€€€	HA multi-zone + réplication async
Zéro	Zéro	€€€€	Active-active multi-région + sync

Glissez pour voir

Le coût de la résilience

RTO/RPO faibles = architecture complexe et coûteuse.

Ne visez zéro downtime que si le métier le justifie réellement. Un site vitrine peut tolérer 1h d’indisponibilité par an. Une plateforme de trading ne peut pas tolérer 1 seconde.

Règle d’or : Définir RTO/RPO avec le métier AVANT de concevoir l’architecture, pas après.

Architecture HA multi-zone

La haute disponibilité repose sur la redondance géographique : déployer votre application dans plusieurs zones de disponibilité (AZ) indépendantes.

Zones de disponibilité (AZ)

Une zone de disponibilité est un datacenter (ou groupe de datacenters) isolé au sein d’une même région cloud :

• Alimentation électrique séparée
• Refroidissement indépendant
• Réseau dédié avec interconnexion très faible latence (< 2ms)

Exemple Outscale eu-west-2 (France) :

• eu-west-2a, eu-west-2b, eu-west-2c : 3 sous-régions indépendantes
• Si eu-west-2a perd l’électricité, eu-west-2b et eu-west-2c continuent de fonctionner

Architecture HA type

Composants :

1. Load Balancer : Répartit le trafic entre les 3 AZ, health checks automatiques
2. App Servers : Déployés dans chaque AZ (minimum 2 AZ, idéal 3)
3. Database : RDS Multi-AZ avec réplication synchrone automatique

Scénario de panne :

1. AZ-A perd l’électricité → tous ses serveurs tombent
2. Load balancer détecte que AZ-A ne répond plus (health check fail)
3. Trafic automatiquement redirigé vers AZ-B et AZ-C
4. Utilisateurs ne voient aucune interruption

Checklist architecture HA

• Application déployée dans au moins 2 AZ (idéal : 3)
• Load balancer avec health checks actifs
• Base de données en mode Multi-AZ ou réplication synchrone
• Stockage répliqué (S3 automatic replication, EBS snapshots multi-AZ)
• Sessions externalisées (Redis, DynamoDB) pour rendre les serveurs stateless
• Autoscaling configuré pour remplacer automatiquement les instances défaillantes

Stateless vs Stateful

Pour que le failover fonctionne, vos serveurs applicatifs doivent être stateless : pas de données locales critiques. Les sessions utilisateurs doivent être stockées dans un cache partagé (Redis, Memcached) ou une base de données.

Si un serveur crash, un autre peut prendre le relais instantanément car il n’y a pas d’état local à reconstruire.

Stratégie de backup et restore

Même avec HA, les backups restent essentiels pour protéger contre :

• Corruption de données
• Ransomware / cyberattaque
• Erreur humaine (DELETE FROM users WHERE 1=1;)
• Bug applicatif qui détruit les données

Règle 3-2-1 des sauvegardes

3 copies de vos données :

• 1 copie principale (production)
• 2 sauvegardes

2 supports différents :

• 1 local (snapshot disque, backup région primaire)
• 1 distant (backup région secondaire ou autre cloud)

1 copie offline ou immuable :

• Protection contre ransomware (backup verrouillé, non supprimable pendant X jours)

Types de backups cloud

Type	Fréquence	RPO	Cas d’usage
Snapshot disque	Horaire	1h	Récupération rapide, même région
Backup automatisé RDS	Quotidien	24h	Base de données production
Réplication cross-region	Continue	< 1 min	DR multi-région
Backup immuable	Hebdomadaire	1 semaine	Protection ransomware
Archive Glacier	Mensuel	1 mois	Conformité légale (7 ans)

Glissez pour voir

Exemple de stratégie backup complète

1. Snapshot automatique toutes les heures (rétention 24h) → RPO 1h
2. Backup quotidien à 3h du matin (rétention 30 jours) → Récupération erreur humaine
3. Backup hebdomadaire immuable (rétention 1 an) → Protection ransomware
4. Réplication cross-region en continu → DR régional

Coût estimé (base de données 100 GB) :

• Snapshots horaires : ~50 €/mois
• Backups quotidiens : ~20 €/mois
• Réplication cross-region : ~100 €/mois
• Archive Glacier : ~10 €/mois

Total : ~180 €/mois pour une protection complète

Testez vos backups

Un backup non testé est un backup qui ne fonctionne pas.

Planifiez des drills (exercices de restauration) réguliers :

• Tous les 3 mois : Restore de base de données en environnement de test
• Tous les 6 mois : DR drill complet (simule destruction datacenter primaire)

Mesurez le temps de restore réel pour vérifier que vous tenez votre RTO.

Disaster Recovery : stratégies

Selon votre RTO/RPO, choisissez un pattern DR adapté :

1. Backup & Restore (RTO 4h+, RPO 24h)

Principe : Backups réguliers, restore manuel en cas de disaster.

Coût : € (stockage backups uniquement)

Scénario :

1. Disaster détecté → équipe alertée
2. Provision manuelle infrastructure région secondaire (Terraform)
3. Restore du backup le plus récent
4. Redirection DNS vers nouvelle région
5. Tests et mise en prod

Pour qui : Applications non critiques, intranets, environnements dev/test

2. Pilot Light (RTO 1h, RPO 15min)

Principe : Infrastructure minimale toujours active en région secondaire (base de données répliquée), reste à provisionner en cas de disaster.

Coût : €€ (base de données secondaire + stockage)

Scénario :

1. Disaster détecté
2. Scale up infra secondaire (autoscaling rapide)
3. Basculement DNS
4. Perte de données limitée au delta de réplication

Pour qui : SaaS B2B, e-commerce moyenne taille

3. Warm Standby (RTO 15min, RPO 5min)

Principe : Environnement secondaire actif mais sous-dimensionné, peut scaler rapidement.

Coût : €€€ (infra secondaire + réplication continue)

Scénario :

1. Disaster détecté
2. Autoscaling immédiat région secondaire
3. Basculement load balancer global
4. Perte minimale de données

Pour qui : Plateformes SaaS critiques, fintech

4. Active-Active (RTO 0, RPO 0)

Principe : Deux régions actives en parallèle, trafic réparti 50/50, réplication synchrone.

Coût : €€€€ (double infra + réplication sync + orchestration complexe)

Scénario :

1. Disaster région A → détection automatique (health check)
2. Trafic immédiatement redirigé vers région B
3. Zéro perte de données (sync réplication)
4. Utilisateurs ne voient rien

Pour qui : Banques, bourses, services critiques gouvernementaux

Patterns cloud-native pour la résilience

Pattern #1 : Circuit Breaker

Problème : Un service dépendant tombe, votre app continue d’envoyer des requêtes qui échouent, cascade de timeouts.

Solution : Détecter le service défaillant et “ouvrir le circuit” → retourner une erreur immédiate sans tenter l’appel.

from circuitbreaker import circuit

@circuit(failure_threshold=5, recovery_timeout=60)
def call_external_service():
    return requests.get("https://api.external.com/data")

Si 5 échecs consécutifs → circuit ouvert pendant 60 secondes (pas d’appel), puis réessai.

Pattern #2 : Retry with Exponential Backoff

Problème : Erreur temporaire (réseau instable), mais vous abandonnez immédiatement.

Solution : Réessayer automatiquement avec délai croissant (1s, 2s, 4s, 8s…).

import time

def retry_with_backoff(func, max_retries=5):
    for i in range(max_retries):
        try:
            return func()
        except Exception as e:
            if i == max_retries - 1:
                raise
            time.sleep(2 ** i)  # 1s, 2s, 4s, 8s, 16s

Pattern #3 : Bulkhead

Problème : Un service lent monopolise toutes vos ressources, autres services impactés.

Solution : Isoler les ressources (pool de connexions séparé par service).

# Pool dédié pour service critique
critical_pool = ThreadPoolExecutor(max_workers=10)

# Pool dédié pour service non critique
non_critical_pool = ThreadPoolExecutor(max_workers=5)

Si le service non-critique sature, le critique continue de fonctionner.

Pattern #4 : Graceful Degradation

Problème : Service recommandations produit tombe → tout le site e-commerce tombe.

Solution : Afficher le site sans recommandations plutôt que planter.

try:
    recommendations = get_recommendations(user_id)
except Exception:
    recommendations = []  # Dégradation gracieuse

Le site fonctionne, juste sans cette feature non critique.

À retenir

La résilience cloud repose sur plusieurs piliers complémentaires :

1. HA (Haute Disponibilité) : Redondance multi-zone + failover automatique
2. DR (Disaster Recovery) : Backups testés + plan de reprise documenté
3. RTO/RPO : Définir avec le métier AVANT de concevoir l’architecture
4. Stratégie backup : Règle 3-2-1, snapshots + réplication + immutabilité
5. Patterns résilience : Circuit breaker, retry, bulkhead, graceful degradation

Règle d’or : Ne sur-engineerez pas. Adaptez RTO/RPO aux besoins métier réels, pas à “zéro downtime” systématique.

Prochaines étapes

Régions et zones de disponibilité

Comprenez comment choisir vos régions et AZ cloud

Régions et zones cloud

Limites et compromis du cloud

Découvrez les contraintes réelles du cloud (coûts, latence, lock-in)

Limites et compromis

Modèles de déploiement

Choisissez entre cloud public, privé, hybride ou multi-cloud

Modèles de déploiement

×

📖 Voir la documentation →