# Une architecture de bascule DNS et applicative testée en conditions réelles chaque trimestre

> Description d'un exercice de bascule DNS et applicative périodique, conçu pour vérifier une continuité de service éprouvée plutôt que simplement documentée.

- Auteur : Clément Hadrot
- Publié le : 2026-04-04
- Mis à jour le : 2026-04-04
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/architecture-bascule-dns-applicative-testee-trimestre/

## L’essentiel

- Un plan de reprise non testé reste une hypothèse, pas une garantie
- La bascule DNS et la bascule applicative doivent être exercées ensemble
- Chaque exercice trimestriel produit un rapport qui sert de preuve de fiabilité

Une documentation de plan de reprise d'activité rédigée une fois, archivée, et jamais rejouée vaut-elle mieux qu'aucune documentation du tout ? La question mérite d'être posée sérieusement, car un plan jamais testé donne une fausse impression de sécurité, souvent plus dangereuse qu'une absence assumée de préparation. Ce billet ne traite pas du choix initial du registrar de domaine, un sujet distinct déjà couvert ailleurs, mais de l'architecture et du rituel qui permettent de vérifier, quatre fois par an, qu'une bascule DNS et applicative fonctionne réellement en conditions proches du réel.

L'architecture décrite ici sert un site WordPress dont l'indisponibilité prolongée aurait un coût opérationnel et d'image jugé inacceptable par l'organisation qui l'exploite. Plutôt que de se contenter d'un schéma d'architecture théorique, la décision a été prise de matérialiser un exercice de bascule complet, exécuté en conditions réelles, chaque trimestre.

## Architecture générale

```
zone-dns-primaire (registrar A)
├── enregistrement A → serveur-principal (TTL 300 s)
└── enregistrement A secondaire → serveur-secours (désactivé par défaut)

serveur-principal/
├── nginx + php-fpm (application WordPress)
├── mariadb (source d'écriture)
└── agent de synchronisation (médias + configuration)

serveur-secours/
├── nginx + php-fpm (image identique, veille chaude)
├── mariadb (réplique en lecture, prête à promotion)
└── script de bascule (activation manuelle ou déclenchée)

registre-des-exercices/
├── rapport-2025-Q2.md
├── rapport-2025-Q3.md
├── rapport-2025-Q4.md
└── rapport-2026-Q1.md
```

Le serveur de secours n'est jamais un simple instantané figé : il reçoit en continu les mêmes déploiements applicatifs que le serveur principal, via le même pipeline d'intégration continue, de sorte qu'il exécute à tout moment exactement la même version du code, sans décalage qui compliquerait un exercice de bascule.

## Le déroulé d'un exercice trimestriel

Chaque exercice suit un scénario écrit à l'avance, mais avec un horaire tenu volontairement secret jusqu'au dernier moment pour l'équipe technique non impliquée dans sa préparation, afin de reproduire une part de l'imprévu propre à un incident réel :

1. Coupure volontaire du serveur principal, simulant une panne complète plutôt qu'une dégradation partielle.
2. Déclenchement manuel du script de bascule, qui promeut la réplique MariaDB du serveur de secours en source d'écriture.
3. Mise à jour de l'enregistrement DNS A vers l'adresse du serveur de secours, avec mesure précise du délai de propagation observé chez plusieurs résolveurs publics.
4. Vérification fonctionnelle complète du site sur le serveur de secours : affichage des pages, soumission d'un formulaire de test, connexion à l'espace d'administration.
5. Chronométrage de bout en bout, depuis la coupure initiale jusqu'au moment où le site redevient pleinement accessible pour un visiteur extérieur.

> L'essentiel à retenir : Un plan de reprise non testé reste une hypothèse, pas une garantie ; La bascule DNS et la bascule applicative doivent être exercées ensemble ; Chaque exercice trimestriel produit un rapport qui sert de preuve de fiabilité

## Ce que le TTL DNS change concrètement

Le premier exercice, il y a un an, a révélé un problème que le schéma d'architecture ne laissait pas anticiper : l'enregistrement DNS principal était configuré avec un TTL de 86 400 secondes, hérité d'une configuration ancienne jamais revue depuis. Le délai de propagation observé lors de cet exercice a dépassé quatre heures chez certains résolveurs, un délai incompatible avec l'objectif de continuité de service visé.

Le TTL a depuis été abaissé à 300 secondes en fonctionnement normal, un compromis qui limite la charge sur les serveurs DNS tout en garantissant une propagation de bascule en quelques minutes plutôt qu'en plusieurs heures. Ce changement n'aurait probablement jamais été identifié sans l'exercice réel, un schéma d'architecture sur papier ne révélant jamais ce type de détail de configuration hérité.

## Le rapport d'exercice comme preuve de fiabilité

Chaque exercice donne lieu à un rapport écrit qui documente le temps total de bascule, tout écart par rapport au scénario attendu, et les actions correctives décidées pour l'exercice suivant. Sur les quatre derniers exercices, ce rapport a permis de suivre une amélioration continue et mesurable : le temps de bascule complet est passé de plus de quatre heures lors du premier exercice à moins de dix minutes lors du plus récent.

> Un plan de reprise qui n'a jamais été rejoué en conditions réelles n'est qu'une hypothèse rédigée avec confiance ; seul l'exercice répété transforme cette hypothèse en garantie mesurable.

## En résumé

Une architecture de bascule DNS et applicative ne prouve sa valeur qu'à travers des exercices réguliers, menés en conditions proches du réel, avec un horaire volontairement imprévisible et un rapport écrit à chaque itération. C'est cette répétition trimestrielle, plus que la sophistication du schéma initial, qui a permis de réduire le temps de bascule réel d'un facteur supérieur à vingt en un an, et de transformer un plan de continuité théorique en un mécanisme dont l'équipe connaît précisément le comportement.