Le 14 juin dernier à 6 heures du matin, une plateforme de formation continue comptant plus de 40 000 modules a basculé d’un hébergement mutualisé vieillissant vers une nouvelle infrastructure dédiée, sans interrompre l’accès des professionnels inscrits à des sessions en cours. L’enjeu n’était pas seulement technique : une coupure prolongée aurait retardé des validations de modules soumises à des délais de certification.
La bascule elle-même — changement de serveur, migration de base de données, changement de DNS — est une opération connue. Ce qui a fait la différence sur ce projet a été la stratégie de cache appliquée avant, pendant et après la bascule, pensée pour éviter que le nouveau serveur ne se retrouve submergé par une vague de requêtes non mises en cache au moment précis où le trafic reprenait.
Le risque identifié en amont
Un cache de page, quel qu’il soit, part vide sur un serveur neuf. Sans précaution, les premières minutes suivant la bascule DNS auraient vu converger vers le nouveau serveur l’ensemble du trafic habituel, sans qu’aucune page ne soit encore en cache, obligeant chaque requête à regénérer intégralement son contenu : rendu PHP complet, requêtes SQL, agrégation des métadonnées de progression pour chaque module de formation.
Avec 40 000 modules et plusieurs milliers d’utilisateurs actifs quotidiennement, un tel scénario aurait pu saturer le pool PHP-FPM du nouveau serveur en quelques minutes, provoquant précisément la coupure que la migration cherchait à éviter.
Le préchauffage avant bascule
Trois jours avant la bascule, le nouveau serveur a été mis en service en parallèle de l’ancien, accessible uniquement par une URL de test non indexée. Un script WP-CLI a parcouru l’ensemble des URL les plus consultées (pages de modules actifs, tableaux de progression, catalogues de formations) pour préchauffer le cache de page avant même que le trafic réel ne soit redirigé :
wp cache-warmer run --sitemap=https://test-nouveau-serveur.exemple/sitemap.xml \
--concurrency=10 --delay=200Ce préchauffage a été rejoué toutes les six heures jusqu’à la bascule, pour que le cache reste synchronisé avec les mises à jour de contenu effectuées en parallèle sur l’ancien serveur en production.
La synchronisation entre DNS et cache
La bascule DNS elle-même, avec un TTL abaissé à 60 secondes une semaine avant l’opération pour accélérer la propagation, a été déclenchée seulement après confirmation que le cache du nouveau serveur affichait un taux de succès supérieur à 90 % sur un test de charge simulant le trafic habituel. L’ordre des opérations, écrit noir sur blanc dans un plan de bascule partagé avec toute l’équipe, a été le suivant :
- Vérification du taux de succès du cache préchauffé sur le nouveau serveur (seuil fixé à 90 %).
- Passage de l’ancien serveur en mode lecture seule pour geler les écritures en base de données.
- Export final de la base de données et import sur le nouveau serveur, avec vérification d’intégrité.
- Bascule du DNS vers la nouvelle adresse IP.
- Surveillance en temps réel du taux de succès du cache et de la charge PHP-FPM pendant les trente minutes suivantes.
- Purge sélective uniquement des pages modifiées pendant la fenêtre de gel, une fois la bascule confirmée stable.
Ce qui s’est réellement passé le jour J
| Moment | Taux de succès du cache | Charge PHP-FPM |
|---|---|---|
| Juste après bascule DNS | 91 % | 34 % |
| 15 minutes après | 94 % | 28 % |
| 1 heure après | 97 % | 19 % |
L’interruption perçue par les utilisateurs, mesurée par le temps où une partie du trafic pointait encore vers l’ancien serveur en lecture seule avant propagation complète du DNS, a été de quatre minutes, très loin des plusieurs heures redoutées en cas de cache froid sur le nouveau serveur.
Une migration sans coupure ne se joue jamais au moment de la bascule elle-même : elle se joue dans les jours précédents, quand le cache du nouveau serveur atteint un niveau de maturité comparable à celui qu’il remplace.
Ce que le contenu pédagogique n’a pas eu besoin de connaître
Le contenu des modules de formation, leur structure pédagogique et leur validation métier n’ont fait l’objet d’aucune adaptation particulière pour cette migration : la stratégie de cache s’est appliquée uniformément, indépendamment de la nature du contenu, comme elle l’aurait fait pour un catalogue e-commerce ou un site d’actualités.
Ce qu’on retient
Un cache préchauffé avant bascule transforme une migration à risque en une opération presque silencieuse pour les utilisateurs. Le seuil de 90 % de taux de succès fixé comme condition de déclenchement de la bascule DNS a servi de garde-fou objectif, retirant toute pression sur une décision qui aurait pu, sinon, être prise trop tôt par optimisme ou trop tard par excès de prudence.
