Les zones de disponibilité partagent le même backbone réseau régional. En décembre 2021, un incident AWS us-east-1 a mis hors service des services théoriquement "multi-AZ" parce que le plan de contrôle (le service qui orchestre le failover) était lui-même centralisé et affecté. Le multi-AZ protège contre la panne d'un datacenter physique. Il ne protège pas contre les pannes du plan de contrôle, du réseau régional, ou des services de gestion communs.

De plus, le multi-AZ coûte. Chaque ressource dupliquée est facturée. Le trafic entre AZ est facturé. Un RDS Multi-AZ coûte environ 2x un RDS Single-AZ. Une architecture multi-AZ complète peut coûter 1,5x à 2x l'infrastructure primaire — sans compter les egress fees de réplication.

La réplication multi-region est réelle mais complexe. Elle exige de résoudre le problème de cohérence des données : en mode synchrone (zéro perte de données), la latence entre régions dégrade les performances. En mode asynchrone (RPO non nul), il faut accepter une fenêtre de perte de données. Ce choix architectural n'est pas trivial — il dépend de la nature des données, du métier, des exigences réglementaires.

La mise en œuvre exige la maîtrise de Route 53 (DNS failover avec health checks), Aurora Global Database ou DynamoDB Global Tables, S3 Cross-Region Replication, CloudFront, WAF, ACM (certificats dans chaque région), et des dizaines d'autres services — chacun avec ses subtilités, ses modes de défaillance, ses coûts cachés. Un PCA multi-region AWS bien fait coûte entre 2x et 5x le coût de l'infrastructure primaire.

Tester un failover multi-region en production est une opération de haute chirurgie. Elle requiert une fenêtre de maintenance, une coordination entre les équipes, un plan de rollback. Elle est coûteuse — le trafic de test est facturé comme du trafic de production. Et elle fait peur — une erreur de configuration peut aggraver l'incident au lieu de le résoudre.

Résultat : dans la majorité des organisations, le PCA multi-region n'est testé qu'en environnement de staging — qui n'est jamais identique à la production. Quand l'incident réel arrive à 3h du matin, les DevOps découvrent que le Terraform du site de secours n'a pas été mis à jour depuis la dernière migration de base de données. Que le certificat du load balancer de la région secondaire a expiré. Que le DNS TTL est encore à 3600 secondes.

La bascule infogéreur commence au niveau physique — là où le PCA hyperscaler commence au niveau logiciel. Quand le datacenter A perd son alimentation principale, l'onduleur prend le relais (quelques millisecondes), puis le groupe électrogène démarre (30 à 60 secondes). Pendant ce temps, les flux réseau sont reroutés vers le datacenter B via la fibre dédiée — pas via le backbone Internet, dont la disponibilité est hors de contrôle de l'infogéreur.

Cette maîtrise de la couche physique est ce que le cloud ne peut pas offrir. Quand le problème est un câble transoceanique coupé, un incident BGP majeur, un backbone régional saturé — le PCA logiciel du cloud ne fait rien. L'infogéreur qui contrôle sa fibre dédiée a une résilience orthogonale aux incidents d'infrastructure Internet.

L'infogéreur ne propose pas un catalogue de services PCA — il conçoit une architecture de continuité adaptée aux besoins réels du client. Cette conversation commence par les questions fondamentales :

RPO (Recovery Point Objective) : combien de données peut-on perdre ? La base de facturation : RPO zéro (synchrone, pas de perte). Les logs applicatifs : RPO 4h acceptable (asynchrone). Les sessions utilisateurs : RPO 15 minutes (semi-synchrone).

RTO (Recovery Time Objective) : en combien de temps doit-on être opérationnel ? Le site web : RTO 5 minutes (basculement DNS + HAProxy). Le back-office : RTO 30 minutes. Les traitements batch : RTO 4h.

Ces nuances, un infogéreur les implémente en scripts, en configurations HAProxy sur mesure, en règles de réplication MySQL ou PostgreSQL spécifiques. Chaque service a son propre mécanisme de continuité, adapté à son niveau de criticité métier.

L'équipe de l'infogéreur a un Runbook de bascule pour chaque type d'incident. Ce Runbook n'est pas un document bureaucratique — c'est un guide opérationnel testé et mis à jour à chaque incident réel ou simulé. Il dit exactement : qui fait quoi, dans quel ordre, avec quelle commande, avec quel critère de succès. Et il mentionne les pièges : le service X prend toujours 3 minutes de plus que prévu, le service Y nécessite un redémarrage manuel si la bascule a duré plus de 10 minutes.

Dans la plupart des organisations cloud, le test de PCA suit ce scénario :

Mois 1 : l'équipe décide de tester le failover. Elle réalise que l'environnement de staging n'est pas à jour.
Mois 2 : mise à jour de staging. Test en staging. Ça fonctionne partiellement — 3 services sur 12 ne basculent pas correctement.
Mois 3 : corrections. Re-test en staging. Mieux, mais pas parfait.
Mois 4 : décision de ne pas tester en production cette année — "trop risqué avant les fêtes".
Mois 12 : incident réel. Le Terraform de production diverge du staging depuis 4 mois. La base de données secondaire a un retard de réplication de 6 heures. Le certificat SSL de la région secondaire a expiré depuis 3 semaines. RTO réel : 4 heures au lieu des 15 minutes promis.

Un infogéreur qui se respecte intègre le test de PCA dans le cycle de vie contractuel du client. Pas comme un projet ponctuel — comme un événement récurrent, planifié, avec un COPIL dédié.

Déroulé type d'un test de bascule infogéreur :
J-30 : communication au client de la date et de la fenêtre de maintenance. Vérification que tous les services cibles sont documentés et que le Runbook est à jour.
J-7 : revue technique — quels services basculent dans quel ordre, quels sont les critères de succès, quelle est la procédure de rollback.
Jour J, fenêtre de maintenance : bascule réelle sur production. Le client est présent (en salle ou en visio). Il observe. Il valide. Il mesure le RTO réel.
Après la bascule : COPIL de retour d'expérience. Quels services ont mis plus de temps que prévu ? Pourquoi ? Qu'est-ce qu'on modifie dans le Runbook ? Le Runbook est mis à jour avant la fin de la semaine.

Le client rentre chez lui avec une conviction : son PCA fonctionne. Pas avec un schéma d'architecture.

Progressif : la bascule se fait service par service, dans l'ordre des dépendances. D'abord la base de données (source de vérité), puis les APIs qui la consomment, puis le frontend. Chaque étape est validée avant de passer à la suivante. Il n'y a pas de "tout bascule en même temps" — parce que "tout bascule en même temps" crée des problèmes de timing imprévisibles.

Réversible : chaque étape de la bascule a une procédure de rollback documentée. Si le service Y ne démarre pas correctement sur le site B, on sait exactement comment revenir au site A sans aggraver la situation. Cette réversibilité est testée — pas supposée.

Observé : la bascule est observée en temps réel par les équipes de l'infogéreur et du client. Les métriques clés sont monitorées (latence, taux d'erreur, connexions actives). Les décisions "on continue" ou "on rollback" sont prises sur des données réelles, pas sur des suppositions.

Le PCA Doux est la déclinaison de continuité d'activité de deux thèses du corpus. "La Sortie Douce" propose une migration progressive sans rupture — le PCA Doux applique le même principe à la bascule d'urgence. "L'Exodus Accompagné" propose un infogéreur comme guide de migration — le PCA Doux fait du même infogéreur le guide de la continuité.

L'organisation qui a migré vers l'infogéreur via l'Exodus Accompagné a, en bonus, un PCA Doux — parce que l'infogéreur connaît l'infrastructure qu'il a lui-même migrée, a rédigé le DAT, et a intégré le PCA dans la conception initiale plutôt qu'en ajout ultérieur.