La panne d’AWS du 20 octobre nous a rappelé une vérité simple : la résilience ne s’improvise pas. La haute disponibilité (HA) dans une seule région aide, mais elle ne remplace pas un plan B capable de maintenir les services quand l’élément commun dont dépendent trop de composants tombe en panne (région, plan de contrôle, DNS, files d’attente, identité, etc.).
Ce guide propose un chemin pratique pour passer de la « HA » à la continuité d’activité, avec des schémas que nous voyons fonctionner en production — et que nous mettons en œuvre chez Stackscale avec deux centres de données en actif–actif. Lorsque c’est nécessaire, ces architectures se combinent sans friction avec d’autres fournisseurs. Tout commence par l’essentiel : définir RTO/RPO et répéter la bascule (failover).
David Carrero (co-fondateur de Stackscale) : « La HA est indispensable, mais si tout dépend d’un point commun, la HA échoue. La différence entre une frayeur et une crise, c’est un plan B répété. »
1) Aligner le business et la technique : RTO/RPO et cartographie des dépendances
- RTO (Recovery Time Objective) : durée maximale d’indisponibilité admissible.
- RPO (Recovery Point Objective) : perte de données maximale acceptable (en temps) lors de la reprise.
Une fois ces objectifs validés par le métier, dressez la carte des dépendances : qu’est-ce qui casse quoi ? Où « s’ancrent » identité, DNS, files, catalogues ou tables globales ? Le livrable est la liste des services qui ne peuvent pas tomber — et de quoi ils dépendent.
2) Schémas de continuité qui fonctionnent réellement
Actif–actif entre deux centres de données (RTO=0 / RPO=0)
Pour les paiements, l’identité ou les transactions cœur :
- Réplication synchrone du stockage entre les deux DC → RTO=0 / RPO=0.
- SGBD distribués / à quorum, avec gestion de conflits (CRDTs / sagas).
- DNS/GTM avec tests de santé métier (pas seulement des pings).
- Modes dégradés définis (lecture seule, feature flags).
Chez Stackscale, nous proposons l’actif–actif entre deux DC européens avec réplication synchrone comme base « mission-critique ». Ce noyau peut être complété par des tiers (hyperscalers ou autres DC) si vous avez besoin d’une troisième voie de continuité ou d’exigences de souveraineté/localisation.
Warm standby multi-site (passif « chaud »)
Pour la plupart des charges importantes :
- Réplication asynchrone vers un second site.
- Infrastructure pré-provisionnée (templates / IaC) pour promouvoir le site B en quelques minutes.
- Bascule automatique via DNS/GTM et runbooks répétés.
Empreinte minimale chez un fournisseur alternatif (ex-« pilot-light »)
Pour réduire la concentration du risque à coût maîtrisé :
- Maintenez le minimum vital allumé en dehors du fournisseur principal (p. ex. DNS, observabilité, sauvegardes immuables, identité d’urgence, status page).
- Ne promouvez en actif–passif ou actif–actif que le vraiment critique, selon vos RTO/RPO.
Carrero : « Il ne s’agit pas d’abandonner les hyperscalers, mais d’équilibrer. L’écosystème européen — Espagne comprise — est mûr et constitue un excellent complément pour la résilience et la souveraineté. »
3) Trois couches qui changent la donne (et comment les traiter)
Données
- Transactionnel : distribution à quorum + gestion des conflits.
- Objets : versioning + réplication inter-sites, immutabilité (verrouillage WORM) et, si nécessaire, air-gap.
- Catalogues/files : évitez les services « globaux » ancrés dans une seule région externe si vos RTO/RPO ne le permettent pas.
Réseau / DNS / CDN
- Deux fournisseurs DNS et GTM avec sondes métier (une transaction de santé, pas un simple ping).
- Multi-CDN et origines alternées (A/A ou A/P) avec origin shielding.
- Connectivité privée redondée (overlay SD-WAN) entre cloud et DC.
Identité & accès
- IdP avec cache de clés (JWKS) et ré-authentification contextuelle.
- Comptes “break-glass” hors domaine de panne, protégés par MFA forte (clés matérielles).
- Gouvernance des applications pour contrer le consent phishing et les abus OAuth.
4) Observabilité, sauvegardes et exercices : sans cela, pas de plan B
- Observabilité hors du même domaine de panne : au moins un miroir métriques/logs et une status page qui ne dépendent pas du fournisseur principal.
- Sauvegardes immuables et tests de restauration chronométrés (avec succès récent).
- Gamedays trimestriels : pannes de région/IdP/DNS/files/BDD. Mesurez RTO réel, dwell time et MTTR.
5) Deux architectures de référence (et leur intégration avec Stackscale)
Continuité « tout Stackscale »
- DC A + DC B (Stackscale) en actif–actif avec réplication synchrone (RTO=0/RPO=0).
- Sauvegardes immuables dans un troisième domaine (autre DC ou object storage isolé).
- DNS/DNSSEC multi-fournisseur + GTM avec sondes métier.
- Observabilité répliquée à l’extérieur (fournisseur dédié ou second site Stackscale).
- Runbooks et gamedays réguliers avec support de proximité 24/7.
Continuité hybride (Stackscale + autre site/fournisseur)
- DC A + DC B (Stackscale) actif–actif pour le cœur.
- Empreinte minimale chez un autre fournisseur pour DNS, status, logs/SIEM et stockage objet immuable (ou l’inverse).
- Charges non critiques sur l’autre site, avec DR de retour vers Stackscale si la souveraineté ou le coût l’exigent.
- Connectivité privée et politiques portables (identité, logging, backup).
Ce qu’apporte Stackscale (sans « ton commercial ») :
- Deux DC européens à faible latence, réseaux et alimentation redondés, support 24/7 de proximité.
- Réplication synchrone pour les applications mission-critiques (RTO=0/RPO=0).
- Stockage hautes performances (bloc/objet) avec versioning et verrouillage WORM (Object Lock) pour sauvegardes immuables.
- Bare-metal et cloud privé pour consolider les charges, plus connectivité dédiée avec opérateurs et clouds publics via partenaires.
- Intégration aisée avec fournisseurs externes (DNS, CDN, observabilité, hyperscalers) pour des stratégies hybrides ou multicloud sélectives.
6) Feuille de route 30-60-90 jours (réaliste et actionnable)
Jours 1–30
- Validation RTO/RPO par service.
- Carte des dépendances et ancres globales.
- Sauvegardes immuables et premier test de restauration chronométré.
Jours 31–60
- DNS/GTM multi-fournisseur, multi-CDN et observabilité hors du même domaine de panne.
- Empreinte minimale (identité d’urgence, status, SIEM).
- Premier gameday (DNS + BDD/files).
Jours 61–90
- Déploiement actif–actif ou warm standby entre les deux DC Stackscale.
- Intégrations avec tiers (si besoin).
- Gameday de panne régionale complète et revue des métriques.
7) Indicateurs exécutifs qui comptent vraiment
- % de services avec RTO/RPO signés et tenus en test.
- Restauration OK (30 derniers jours) et temps moyen de restauration.
- Temps de bascule (gamedays) et dwell time par scénario.
- Couverture d’observabilité “hors domaine” (oui/non par périmètre).
- Dépendances “globales” avec alternative (oui/non).
Mot de la fin : résilience lucide (sans se lier les mains)
La leçon n’est pas de « fuir le cloud », mais de concevoir pour l’échec et de dés-concentrer les points uniques de rupture. La HA est indispensable, mais insuffisante : il faut une autre route complète vers le même résultat. Avec deux DC en actif–actif (RTO=0/RPO=0) comme socle et des couches de continuité — DNS, copies immuables, observabilité et identité d’urgence — hors du même domaine de panne, votre plateforme restera disponible quand un fournisseur ou une région trébuche.
Chez Stackscale, nous accompagnons cette transition au quotidien. Et lorsque les objectifs de continuité ou la réglementation l’exigent, nous combinons notre infrastructure deux DC avec d’autres fournisseurs. Ainsi, le plan B n’est plus un PDF au fond d’un tiroir : c’est un chemin déjà emprunté.