Le site d’un client dans la formation professionnelle recevait environ 40 000 visites mensuelles au moment où nous avons entamé sa migration d’un thème classique vieillissant vers un thème bloc. Impossible d’envisager une coupure prolongée : chaque heure d’indisponibilité représentait un coût direct en inscriptions manquées et en image dégradée pour un site qui vit largement du bouche-à-oreille numérique.
Ce projet n’a pas été le premier de ce type pour notre équipe, mais c’est celui où nous avons le mieux formalisé une méthode de bascule à faible risque, que nous détaillons ici en nous concentrant sur le déroulé opérationnel plutôt que sur la réécriture du thème elle-même, traitée par ailleurs.
Une préproduction fidèle, pas approximative
La première condition d’une bascule sans coupure est de disposer d’un environnement de préproduction qui reproduit fidèlement le serveur de production : même version de PHP, même configuration de cache, mêmes plugins actifs. Nous avons cloné l’intégralité de la base de données et des fichiers vers cet environnement, puis développé et validé le nouveau thème bloc dessus pendant plusieurs semaines, avec des allers-retours de validation client réguliers.
Un écart de configuration entre préproduction et production, même mineur (une extension de cache absente, par exemple), aurait pu faire apparaître au dernier moment un problème que la préproduction n’aurait pas révélé.
Le déroulé du jour de bascule
Le jour J, la bascule a suivi une séquence précise, répétée à l’identique lors d’une répétition générale une semaine avant la date réelle :
- Activation d’une page de maintenance légère, sans rechargement complet du serveur, via un fichier
.maintenanceplacé à la racine du site pendant l’opération. - Synchronisation finale de la base de données de production vers l’environnement où le nouveau thème avait déjà été validé, pour intégrer les derniers contenus publiés depuis le début du projet.
- Bascule du thème actif via WP-CLI plutôt que par l’interface d’administration, pour limiter les manipulations manuelles sous pression :
wp theme activate theme-bloc-client. - Purge complète des caches (objet, page, CDN) pour éviter qu’une version mise en cache de l’ancien thème ne persiste après la bascule.
- Suppression du fichier
.maintenanceet vérification immédiate d’un échantillon de pages critiques (accueil, page de vente principale, formulaire d’inscription).
L’ensemble de cette séquence, chronométrée lors de la répétition générale, a duré quatre minutes le jour réel, la majeure partie du temps étant consacrée à la purge des caches multiples plutôt qu’à la bascule du thème elle-même.
Le plan de retour arrière, condition non négociable
Aucune bascule de cette ampleur ne se lance sans un plan de retour arrière testé au préalable, pas seulement documenté sur le papier. Nous avons validé, lors de la répétition générale, qu’une réactivation de l’ancien thème via wp theme activate ancien-theme suffisait à restaurer un état fonctionnel en cas de problème bloquant découvert après la bascule, la structure de contenu n’ayant pas été modifiée en base de données pendant l’opération.
Un plan de retour arrière qu’on n’a jamais testé n’est pas un plan de retour arrière, c’est un espoir. Sur ce projet, nous l’avons exécuté deux fois en répétition avant de le considérer fiable.
Le suivi post-bascule, souvent négligé
Les heures qui suivent une bascule sont aussi critiques que la bascule elle-même. Nous avons surveillé en continu, pendant les six heures suivant l’opération, les journaux d’erreurs serveur, le taux d’erreurs 404 (pour détecter d’éventuelles URL cassées) et les indicateurs Core Web Vitals via un outil de suivi déjà en place, afin de détecter toute régression de performance introduite par le nouveau thème avant que le client ne s’en aperçoive lui-même.
En résumé
Une migration de thème sans coupure perceptible sur un site à fort trafic repose moins sur une prouesse technique ponctuelle que sur une préparation méthodique : environnement de préproduction fidèle, séquence de bascule répétée à l’avance, plan de retour arrière réellement testé, et surveillance active dans les heures qui suivent. C’est cette rigueur de préparation, plus que la rapidité d’exécution le jour J, qui garantit une transition invisible pour les visiteurs.
