Reprise d'activité
Sélection de site DR
Un site de reprise d'activité doit être suffisamment éloigné pour ne pas partager un sinistre, et suffisamment proche pour le mode de réplication dont vous avez besoin. Ces deux contraintes — plus les installations qui existent réellement sur le marché candidat — déterminent la liste restreinte avant toute discussion avec un fournisseur. L'outil ci-dessous teste ces trois critères contre des données réelles : les temps d'aller-retour mesurés entre 14 marchés, et le catalogue de 1629 centres de données.
Chercheur de paires DR
Choisissez votre marché principal. Les candidats sont classés par temps d'aller-retour, avec le mode de réplication que chaque distance supporte.
| Candidat DR | RTT | Réplication supportée | Centres de données |
|---|
Les chiffres de RTT sont des mesures inter-régions cloud publiées (Azure, cloudping.co) — sources sur la matrice de latence. Les trajets de fibre entre installations de colocation suivent des chemins similaires ; vérifiez la paire exacte auprès des opérateurs avant de fixer un RPO à cette paire.
Le mode de réplication est défini par la physique
La lumière dans la fibre parcourt environ 100 km par milliseconde d'aller-retour. Ce seul chiffre détermine l'architecture : la réplication synchrone nécessite l'aller-retour dans le budget d'écriture de l'application, ce qui limite la distance à environ 100 km — et tout ce qui est plus loin est asynchrone, quelles que soient les promesses de la couche de stockage.
| Mode | Budget RTT | RPO | Ce que cela signifie |
|---|---|---|---|
| Synchrone | ≤ ~10 ms | Zéro | Chaque écriture est confirmée sur les deux sites avant de continuer. La latence transactionnelle inclut l'aller-retour, donc la distance impose un surcoût à l'application. |
| Quasi-synchrone | ~10–25 ms | Secondes | Les écritures s'écoulent continuellement sans attendre l'accusé de réception complet. Le choix pratique pour les paires métropolitaines voisines comme Francfort–Amsterdam ou Singapour–Kuala Lumpur. |
| Asynchrone | Quelconque | Minutes | Le site DR accuse un retard égal à l'intervalle de réplication. La seule option sur les longues distances — et la bonne pour la plupart des charges de travail. |
Quatre modèles DR, tarifs transparents
Le coût s'exprime en pourcentage du coût d'exploitation du site primaire. Le modèle détermine le RTO ; le mode de réplication détermine le RPO ; la combinaison détermine le budget. La plupart des parcs exécutent différents modèles selon la criticité des charges — actif-actif pour les charges critiques, sauvegarde-restauration pour tout ce qui peut attendre un jour.
| Modèle | RPO | RTO | Coût vs primaire | Fonctionnement |
|---|---|---|---|---|
| Sauvegarde et restauration | Heures–jour | Jours | ~5% | Sauvegardes répliquées hors site, infrastructure construite seulement quand le sinistre se produit. Peu cher, lent, et la restauration est ce que personne n'a jamais testé. |
| Lampe pilote | Minutes–heures | Heures | ~10–20% | Données critiques répliquées sur une base minimale qui évolue en basculement. Quelques baies au site de reprise hébergeant les bases de données ; les ressources informatiques arrivent selon les besoins. |
| Secours chaud | Secondes–minutes | Minutes–heure | ~30–50% | Une copie réduite de la production s'exécutant continuellement. Le basculement est une promotion, non une construction. |
| Actif-actif | ≈ Zéro | ≈ Zéro | 100%+ | Les deux sites servent le trafic ; la perte de l'un est un événement de capacité, non une panne. Nécessite que l'application soit construite pour cela — l'adapter après coup revient à la réécrire. |
Modélisez le coût de la base de secours avec le calculateur de coûts de colocation au tarif Index du marché cible.
Ce qui échoue réellement
La planification de reprise de sinistre tend à imaginer des tremblements de terre. Le journal des incidents indique que les menaces réelles sont plus proches du compteur : perturbations du réseau électrique, incendies de batteries UPS, défaillances de refroidissement et pannes d'équipements réseau. Un site de reprise sur le même réseau, dans la même plaine inondable, derrière le même central de porteurs ne protège contre presque rien de cela. Entrées récentes :
- 2026-09-01Google Cloud: network degradation in us-central1-b takes down 15 products for up to 4h08mus-central1-b (Council Bluffs, Iowa)
- 2026-08-31Microsoft 365: authentication-configuration fault disrupts Exchange Online, Teams, SharePoint and Defender XDR for multiple daysGlobal (Microsoft 365 cloud services)
- 2026-08-27Proton: total cooling failure at Frankfurt datacenter takes down Mail, VPN, Drive and Pass for 2h18mFrankfurt, Germany (Proton-operated datacenter)
- 2026-08-20Google Cloud us-west1 (Oregon) region: multi-service degradation for about 3h40mus-west1 region (The Dalles, Oregon)
- 2026-08-17GitHub outage: retry storm and Central US datacenter network saturation cause 7h47m disruption to Issues, PRs, Actions and CopilotCentral US datacenter region, with failover traffic routed to Northern Virginia
Journal complet des incidents →
Liste de vérification du site de reprise
- Réseau électrique différent du principal — vérifier la sous-station réelle, pas l'affirmation marketing
- En dehors de la plaine inondable et de la zone sismique du principal
- Chemins de fibre diversifiés : les deux sites ne doivent pas partager un central de porteurs ou un point d'atterrissage de câble
- RTT mesuré, non estimé — et à l'intérieur du budget de votre mode de réplication choisi
- Centre de données certifié au niveau de conformité attendu — consultez le répertoire des certifications
- Capacité extensible contractuellement : un site DR que vous ne pouvez pas redimensionner lors d'un véritable sinistre n'est qu'une décoration
- Intervention à distance avec délais de réponse contractuels — lors d'un événement régional, vous n'aurez pas à vous déplacer
- Basculement d'urgence testé de bout en bout avant la mise en production, puis annuellement — un plan n'est pas une capacité
Questions fréquentes
Quelle distance doit séparer les centres de données primaire et DR ?
Suffisamment pour ne pas partager un sinistre, assez proches pour votre mode de réplication. Le minimum absolu : réseaux électriques distincts, zones d'inondation distinctes et cheminements d'opérateurs distincts — en pratique 50 km ou plus. La réplication synchrone plafonne la distance à environ 100 km (soit environ 10 ms aller-retour) ; la réplication asynchrone supprime complètement cette limite. De nombreux régulateurs en Asie-Pacifique exigent un DR hors du pays, ce qui force la réplication asynchrone.
Quelle est la différence entre RPO et RTO ?
RPO (recovery point objective) est la quantité de données que vous pouvez vous permettre de perdre, déterminée par le mode de réplication. RTO (recovery time objective) est la durée pendant laquelle vous pouvez vous permettre d'être indisponible, déterminée par le modèle DR — backup-restore récupère en jours, active-active en secondes. Le coût évolue avec les deux : resserrer l'un ou l'autre d'un ordre de grandeur environ double le budget DR.
La réplication synchrone peut-elle fonctionner entre pays ?
Seulement entre pays limitrophes. Singapore–Kuala Lumpur à ~8 ms RTT le permet ; Frankfurt–Amsterdam à ~11 ms est à la limite. Au-delà de ~25 ms, c'est le domaine asynchrone, peu importe ce que dit la fiche technique du fournisseur de stockage — chaque écriture porterait le coût de l'aller-retour, et l'équipe applicative le sentira avant l'équipe DR.
Qu'est-ce qui met réellement les centres de données hors service ?
Notre journal des incidents est dominé par les événements électriques (perturbations du réseau et défaillances d'UPS), les incendies (les salles de batterie lithium-ion y figurent régulièrement), les défaillances de refroidissement et les pannes matériel réseau — non par les catastrophes naturelles régionales. Implication pratique : un site DR dans la même zone métropolitaine sur le même réseau protège contre presque aucun des incidents qui se produisent réellement au niveau des installations, tandis qu'un site dans un autre pays protège contre presque tous.
Le cloud public est-il un site DR valide pour les charges de colocation ?
Pour les modèles backup-restore et pilot-light, souvent oui — vous payez la capacité de secours seulement quand elle fonctionne, ce qui correspond exactement au modèle de tarification cloud. Le hic concerne les frais de sortie au retour et l'écart opérationnel : récupérer une infrastructure de colocation sur le cloud signifie maintenir deux cibles de déploiement en permanence. Testez la restauration complète, pas la réplication.
À quelle fréquence faut-il tester la DR ?
Un basculement complet au moins annuellement, des restaurations de composants trimestriellement, et après chaque modification matérielle d'infrastructure. Un plan DR non testé est un document, pas une capacité — et le journal des incidents montre que les défaillances se regroupent exactement dans les mécanismes (basculement d'alimentation, redémarrage du refroidissement) que seul un vrai test met à l'épreuve.
Présélectionner un marché DR ?
Indiquez-nous le site primaire, le RPO dont vous avez besoin et le régime de conformité. Nous vous proposerons des installations dans les marchés DR viables, une tarification de référence et les questions à poser à chaque opérateur.