Quarante sites, quarante configurations différentes, et une seule version de PHP à faire progresser sur l’ensemble du parc : PHP 8.3, sorti le 23 novembre 2023, apporte des améliorations de performance réelles et une durée de support étendue par rapport à PHP 8.1, mais chaque montée de version majeure sur un parc hétérogène pose la même question. Faut-il basculer tous les sites d’un coup, ou étaler la migration sur plusieurs semaines ?
La réponse retenue a été l’étalement, avec une méthode reproductible plutôt qu’une décision au cas par cas pour chacun des quarante projets. Ce retour d’expérience détaille l’ordre de migration choisi, les outils de test utilisés et les deux incidents mineurs rencontrés en cours de route.
Classer les sites avant de migrer
La première étape n’a pas été technique mais organisationnelle : dresser l’inventaire des extensions installées sur chacun des quarante sites, avec leur dernière date de mise à jour et leur déclaration explicite de compatibilité PHP 8.3. Cet inventaire a permis de répartir les sites en trois groupes : ceux dont toutes les dépendances annonçaient déjà la compatibilité, ceux avec une ou deux extensions incertaines, et ceux qui reposaient sur du code sur mesure ancien jamais audité.
Les sites du premier groupe, une quinzaine, ont constitué la première vague de migration. Les sites du troisième groupe, cinq au total, ont été traités en dernier, avec un audit de code préalable pour identifier les fonctions dépréciées ou les usages incompatibles avec les changements de typage plus stricts introduits par les versions récentes de PHP.
Un environnement miroir par site, pas un test générique
Tester une montée de version PHP sur un environnement générique ne suffit pas dès que le parc dépasse une dizaine de sites : chaque projet a sa combinaison propre d’extensions, de thème et de code métier. La méthode retenue a été de cloner chaque site dans un environnement de staging strictement identique à sa production, base de données incluse via une synchronisation wp db export suivie d’un import, puis de basculer ce clone sur PHP 8.3 avant de lancer une série de vérifications automatisées.
#!/bin/bash
# migration-php83.sh — bascule un site staging vers PHP 8.3
SITE=$1
ssh agence@serveur "cd /var/www/$SITE && wp cli info"
ssh agence@serveur "a2dismod php8.1 && a2enmod php8.3 && systemctl restart apache2"
ssh agence@serveur "cd /var/www/$SITE && wp plugin list --status=active --format=csv"
Ce script minimal a été exécuté pour chacun des quarante sites, avec vérification manuelle de la liste des extensions actives après bascule, avant tout passage en production.
Le rythme des vagues
Chaque vague comprenait cinq sites au maximum, migrés le même jour, avec un délai d’observation de 48 heures avant de lancer la vague suivante. Ce délai a permis, lors de la troisième vague, de repérer une incompatibilité entre une extension de formulaire ancienne et la gestion plus stricte des arguments nullables en PHP 8.3, révélée uniquement après un pic de trafic sur le site concerné et invisible lors des tests de staging à faible charge.
- Vague 1 : 15 sites entièrement compatibles selon l’inventaire, aucun incident.
- Vague 2 : 12 sites avec une extension incertaine, deux avertissements de dépréciation corrigés en amont.
- Vague 3 : 8 sites, un incident de formulaire corrigé en quatre heures grâce au délai d’observation.
- Vague 4 : 5 sites à code sur mesure ancien, audit préalable complet, aucun incident en production.
Le rollback comme filet, pas comme aveu d’échec
Chaque migration a été précédée de la conservation explicite de l’environnement PHP 8.1 en parallèle sur le serveur, activable en une commande en cas de problème bloquant. Ce filet n’a été utilisé qu’une seule fois, pour le site concerné par l’incident de formulaire, le temps de livrer un correctif ciblé plutôt que de laisser le site en panne pendant la résolution.
Un rollback préparé à l’avance coûte quelques minutes de configuration ; un rollback improvisé en pleine nuit coûte une nuit entière.
Pour aller plus loin
Six semaines pour quarante sites, avec un seul incident bloquant corrigé en quelques heures grâce au rythme par vagues : la méthode a démontré sa valeur par rapport à un big bang qui aurait exposé l’ensemble du parc au même risque le même jour. Sur un parc de cette taille, l’inventaire préalable des dépendances reste l’étape la plus rentable, largement avant l’écriture du moindre script de migration.
