Le problème à résoudre
Une migration sans coupure absolue n’est pas toujours réaliste pour un site qui écrit en permanence. L’objectif professionnel est de limiter la fenêtre, éviter la perte de données et garder un retour arrière clair.
Séparez les données statiques des écritures : fichiers, base, commandes, formulaires et médias envoyés. La stratégie d’une vitrine diffère de celle d’une boutique active.
Reconnaître les bons signaux
| Signal observé | Interprétation probable | Premier contrôle |
|---|---|---|
| Deux versions du site | Écritures réparties pendant DNS | Geler ou synchroniser la base |
| Certificat invalide | Nom non préparé sur la cible | Émettre TLS avant bascule |
| E-mails perdus | DNS mail modifié par erreur | Conserver MX et TXT |
Les notions à maîtriser
- Le TTL ne force pas tous les utilisateurs à basculer au même instant.
- Un fichier hosts permet de tester le nouveau serveur avec le vrai nom avant DNS.
- La dernière synchronisation doit être courte, traçable et compatible avec les écritures.
- Le retour arrière devient dangereux si les deux sites ont accepté des commandes divergentes.
Méthode de diagnostic
Plan d’action recommandé
- Réduire le TTL suffisamment tôt.
- Effectuer un premier transfert complet puis une synchronisation différentielle.
- Geler brièvement les écritures ou utiliser une réplication adaptée.
- Basculer le DNS et surveiller ancien et nouveau serveurs.
- Fermer l’ancien seulement après validation métier et expiration des caches.
Tester la cible avant le changement DNS
Notez d’abord les réponses DNS actuelles. La commande curl --resolve permet ensuite d’interroger la nouvelle IP avec le nom et le TLS définitifs, sans modifier le DNS public.
dig +noall +answer example.fr A
dig +noall +answer example.fr MX
curl --resolve example.fr:443:203.0.113.10 -I https://example.fr/Remplacez le domaine et l’adresse d’exemple. Testez aussi formulaires, tâches, e-mails et parcours métier ; une réponse HTTP 200 ne valide pas toute l’application.
Erreurs fréquentes à éviter
- Modifier aussi les MX alors que seule l’adresse web change.
- Supprimer l’ancien serveur avant la fin des caches.
- Oublier les tâches cron qui continuent à envoyer ou modifier des données.
Indicateurs à suivre
| Indicateur | Repère | Pourquoi le suivre |
|---|---|---|
| Écritures divergentes | 0 | Évite la perte métier |
| Erreurs HTTP | Stables ou en baisse | Valide la cible |
| Requêtes ancien serveur | Tendent vers 0 | Guide l’arrêt |
Checklist avant validation
- Une mesure de référence est conservée.
- Le changement est testé hors production lorsque c’est possible.
- Une sauvegarde ou un retour arrière est disponible.
- Les dépendances web, e-mail et DNS ont été contrôlées.
- Les journaux et alertes sont surveillés après intervention.
- Le résultat est documenté avec date et responsable.
Questions fréquentes
Peut-on garantir zéro coupure ?
On peut souvent rendre la coupure imperceptible, mais une application très active nécessite une stratégie de synchronisation spécifique.
Faut-il changer le TTL le jour même ?
Non : réduisez-le au moins un ancien TTL complet avant.
Comment tester avant DNS ?
Avec le fichier hosts ou un proxy de prévisualisation utilisant le nom final et le certificat prévu.
Sources techniques
Pour vérifier les règles et approfondir le sujet :
Besoin de préparer une migration ?
L’inventaire, la synchronisation finale, le DNS et le retour arrière doivent être cadrés avant la bascule.
Voir l’accompagnement à la migration