Un hébergeur avec qui nous travaillons a fini par nous confier un mandat clair : faire passer les quatre-vingts sites WordPress qu’il héberge encore sur une version de PHP vieillissante vers une version activement maintenue, avant la fin du support de sécurité. Le risque n’était pas seulement technique — chaque site appartenait à un client différent, avec des extensions différentes, et personne n’avait d’inventaire à jour de ce qui tournait réellement où.
Nous détaillons ici la méthode suivie, pas la compatibilité du code elle-même (déjà traitée ailleurs) : comment organiser une migration de cette ampleur sans y passer un temps disproportionné, et sans provoquer une vague d’incidents simultanés sur tout le parc.
Étape un : l’inventaire avant toute décision
Impossible de planifier un calendrier de migration sans savoir, site par site, quelles extensions sont actives et quelle version de PHP elles annoncent supporter. Un script WP-CLI exécuté sur chaque site du parc a permis de constituer cet inventaire en une matinée :
#!/usr/bin/env bash
for SITE in /var/www/*/; do
cd "$SITE" || continue
echo "=== $SITE ==="
wp core version
wp plugin list --status=active --fields=name,version --format=csv
done > inventaire-parc.csv
Ce simple export a suffi à repérer les cas les plus risqués : des sites avec des extensions abandonnées depuis plusieurs années, jamais mises à jour, dont la compatibilité avec une version récente de PHP n’était garantie par personne.
Étape deux : des tests de compatibilité automatisés
Plutôt que de tester manuellement chaque site, un environnement miroir a été mis en place : chaque site du parc était cloné automatiquement (fichiers et base) vers un serveur de test tournant déjà sur la nouvelle version de PHP, avec un script qui relevait les erreurs fatales sur les pages principales :
wp eval-file verifier-erreurs.php --url=https://miroir-test.exemple.test/site-client-42/
Ce script parcourait une liste d’URL représentatives par site (accueil, une page de contenu, le formulaire de contact) et signalait toute erreur fatale ou avertissement de dépréciation grave rencontré. Les sites sans anomalie détectée passaient directement en vague de migration ; les autres étaient mis de côté pour un examen manuel du code des extensions en cause.
Étape trois : des vagues de dix sites
Migrer les quatre-vingts sites en une seule opération aurait maximisé le risque en cas de problème imprévu non détecté par les tests automatisés. La migration a été découpée en six vagues d’une dizaine de sites chacune, espacées de plusieurs jours, en commençant par les sites les plus simples (peu d’extensions, code homogène) et en terminant par les configurations les plus complexes.
| Vague | Nombre de sites | Profil |
|---|---|---|
| 1 et 2 | 20 | Sites vitrines simples, peu d’extensions |
| 3 et 4 | 30 | Sites avec formulaires et intégrations tierces |
| 5 et 6 | 30 | Sites e-commerce et configurations complexes |
Ce découpage a permis de limiter le rayon d’impact d’un incident aux dix sites de la vague en cours, et d’ajuster la méthode entre chaque vague à partir des problèmes réellement rencontrés — un avertissement de dépréciation ignoré à tort en vague 1 a par exemple été traité plus strictement à partir de la vague 3.
Étape quatre : la bascule et le filet de sécurité
Sur un hébergement mutualisé, changer la version de PHP d’un site se fait généralement via un réglage par domaine dans le panneau d’hébergement, sans réinstallation. La procédure appliquée pour chaque site d’une vague :
- Sauvegarde complète (fichiers et base) horodatée, avant tout changement ;
- Changement de la version de PHP pour ce domaine précis ;
- Vérification immédiate des mêmes URL représentatives testées sur le miroir ;
- En cas d’anomalie, retour à l’ancienne version de PHP en quelques minutes, le temps d’investiguer sans pression.
Sur un parc mutualisé, le changement de version de PHP est réversible presque instantanément : c’est ce qui rend cette migration beaucoup moins risquée qu’elle n’y paraît, à condition de vérifier immédiatement après chaque bascule plutôt que le lendemain.
Ce que l’inventaire a révélé de plus surprenant
Le résultat le plus utile de cette migration n’a pas été la montée de version elle-même, mais l’inventaire qu’elle a forcé à produire : sept sites tournaient encore avec une extension totalement abandonnée par son auteur, sans mise à jour depuis plus de trois ans. Cette information, invisible avant l’inventaire, a permis d’ouvrir une discussion avec l’hébergeur sur le remplacement de ces extensions, indépendamment de la migration PHP elle-même.
En résumé
Migrer quatre-vingts sites clients vers une version récente de PHP n’est pas un problème technique complexe pris site par site : c’est un problème d’organisation à l’échelle du parc. L’inventaire préalable, les tests automatisés sur un miroir et le découpage en vagues progressives ont transformé une opération qui semblait risquée en une routine répétée six fois, avec un nombre d’incidents constatés en production ramené à zéro.
