40 sites clients, tous construits sur le même thème de base d’agence, chacun avec ses personnalisations propres accumulées au fil des années : cette hétérogénéité rend impossible une migration en bloc vers WordPress 7.0. Cette check-list priorisée organise la migration de ce parc, en tenant compte de la réalité de personnalisations qui divergent d’un site à l’autre malgré un socle commun. Elle ne traite ni la migration des extensions tierces installées sur certains sites, ni les questions d’hébergement du parc.
1. Cartographier les divergences par rapport au thème de base
Avant tout calendrier de migration, un audit rapide de chaque site du parc identifie l’écart réel avec le thème de base d’agence : personnalisations dans un thème enfant, snippets ajoutés directement en base via un plugin de code personnalisé, ou modifications directes du thème parent constatées malgré la consigne de ne jamais le faire.
wp theme list --path=/var/www/site-client/ --status=active --format=jsonCette commande WP-CLI, exécutée sur chaque site via un script parcourant l’ensemble du parc, permet de confirmer rapidement quel thème enfant est actif et sa version, avant même d’entrer dans le détail du code.
2. Prioriser les sites à faible divergence
Les sites qui n’ont reçu aucune personnalisation au-delà de la configuration standard du thème enfant constituent le groupe à migrer en premier : le risque de régression y est structurellement plus faible, et ce groupe sert aussi de validation du processus de migration lui-même avant de l’appliquer aux sites plus complexes.
- Sites sans personnalisation détectée (thème enfant standard, aucun snippet additionnel)
- Sites avec personnalisations mineures documentées (quelques hooks additionnels, sans modification du cœur du thème)
- Sites avec personnalisations lourdes ou modifications directes du thème parent, à traiter en dernier et avec un accompagnement renforcé
3. Auditer la compatibilité PHP 8.4 site par site
Même si le thème de base a déjà été audité pour la compatibilité PHP 8.4, chaque personnalisation ajoutée par un site individuel doit être vérifiée séparément — un snippet ajouté isolément peut réintroduire un motif de code incompatible, invisible depuis un audit portant uniquement sur le thème parent.
for site in $(cat liste-sites.txt); do
vendor/bin/phpcs --standard=PHPCompatibility --runtime-set testVersion 8.4 \
"/var/www/${site}/wp-content/themes/theme-enfant-${site}/"
done4. Préparer une fenêtre de rollback par site
Chaque site du parc doit disposer, avant sa bascule individuelle, d’une sauvegarde complète (base de données et fichiers) prise juste avant la migration, et d’une procédure de restauration testée séparément de la procédure globale du parc. Un rollback qui fonctionne pour un site standard peut échouer sur un site aux personnalisations lourdes si la procédure n’a pas été testée spécifiquement sur ce profil.
- Sauvegarde horodatée, conservée au minimum 15 jours après la migration effective
- Script de restauration testé sur une copie du site avant la bascule réelle en production
- Fenêtre de surveillance renforcée de 48 heures après chaque bascule individuelle
5. Communiquer un calendrier différencié aux clients
Les clients dont le site présente des personnalisations lourdes doivent être informés en amont d’un délai de migration plus long que les clients au site standard, avec une explication claire de la raison. Cette transparence évite l’incompréhension d’un client qui verrait son site migré en dernier sans comprendre pourquoi, alors que d’autres clients du même parc auraient déjà basculé plusieurs semaines auparavant.
Sur un parc hétérogène, ne communiquez jamais une date de migration unique pour l’ensemble des clients. Un calendrier différencié, expliqué honnêtement, évite bien plus de tension qu’une promesse de date uniforme qui ne pourra pas être tenue pour les cas les plus complexes.
6. Valider fonctionnellement avant de clore chaque migration
La bascule technique réussie ne suffit pas à clore une migration individuelle. Un test fonctionnel minimal — connexion, publication d’un article test, vérification de l’affichage des formulaires principaux du site — doit être exécuté et documenté pour chacun des 40 sites avant de considérer sa migration terminée.
En résumé
Migrer un parc de sites hétérogène vers WordPress 7.0 impose un ordre de priorité fondé sur le niveau réel de divergence de chaque site par rapport au socle commun, jamais un calendrier uniforme fondé sur le seul nombre de sites à traiter. Auditer chaque site individuellement pour la compatibilité PHP 8.4, préparer un rollback testé au niveau du site plutôt qu’au niveau du parc, et communiquer honnêtement un calendrier différencié restent les trois leviers qui ont le plus réduit le risque sur cette migration.
