# Migrer un parc de 40 sites d’agence vers WordPress 7.0 : notre check-list

> Liste de contrôle priorisée couvrant PHP 8.4, dépréciations et tests, pour une migration de parc de sites clients vers WordPress 7.0 sans interruption de service.

- Auteur : Clément Hadrot
- Publié le : 2026-06-30
- Mis à jour le : 2026-06-30
- Catégorie : Thèmes
- URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/migrer-parc-40-sites-agence-wordpress-7-checklist/

## L’essentiel

- Un parc de 40 sites impose un ordre de migration priorisé, jamais un big bang
- Les dépréciations PHP 8.4 doivent être vérifiées site par site, pas globalement
- Une fenêtre de rollback doit exister pour chaque site avant sa bascule

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=json
```

Cette 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.

1. Sites sans personnalisation détectée (thème enfant standard, aucun snippet additionnel)
2. Sites avec personnalisations mineures documentées (quelques hooks additionnels, sans modification du cœur du thème)
3. Sites avec personnalisations lourdes ou modifications directes du thème parent, à traiter en dernier et avec un accompagnement renforcé

> L'essentiel à retenir : Un parc de 40 sites impose un ordre de migration priorisé, jamais un big bang ; Les dépréciations PHP 8.4 doivent être vérifiées site par site, pas globalement ; Une fenêtre de rollback doit exister pour chaque site avant sa bascule

## 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}/"
done
```

## 4. 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.