Sur un serveur qui héberge plusieurs sites WordPress pour plusieurs clients, il est rare que tous acceptent de migrer vers la même version de PHP au même moment. Un client conservateur reste sur une version ancienne par peur de casser une extension métier critique, un autre a déjà basculé pour profiter des gains de performance de PHP 8. Forcer une version unique sur tout le serveur revient à immobiliser le client le plus prudent, ou à casser le site du plus avancé.
La solution ne consiste pas à choisir entre les deux, mais à faire cohabiter plusieurs versions de PHP sur la même machine, chacune isolée dans son propre pool PHP-FPM. Ce n’est ni complexe ni exotique : c’est une pratique standard d’hébergement mutualisé maison, à condition de comprendre comment nginx et PHP-FPM se répartissent le travail.
Installer plusieurs versions sans conflit
Sur Debian ou Ubuntu, le dépôt tiers Ondřej Surý (largement utilisé dans l’écosystème PHP) permet d’installer plusieurs versions côte à côte sans qu’elles ne s’écrasent :
sudo apt install php7.4-fpm php7.4-mysql
sudo apt install php8.0-fpm php8.0-mysql
Chaque version installe son propre service systemd (php7.4-fpm, php8.0-fpm) et son propre socket, ce qui permet de les démarrer, arrêter ou redémarrer indépendamment sans affecter les autres versions installées.
Un pool PHP-FPM par site
Le fichier de pool par défaut se trouve dans /etc/php/8.0/fpm/pool.d/www.conf. Plutôt que de le modifier, il est préférable de créer un fichier dédié par site, avec un nom explicite :
[siteclient1]
user = siteclient1
group = siteclient1
listen = /run/php/siteclient1-php8.0.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 4
Ce niveau d’isolation, un utilisateur système et un pool par site, évite qu’un script défaillant sur un site ne consomme les processus PHP disponibles pour les autres, et facilite le diagnostic : les logs de chaque pool restent séparés.
Faire pointer nginx vers le bon socket
Chaque site a son propre bloc serveur nginx, avec une directive fastcgi_pass qui pointe vers son socket dédié :
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/siteclient1-php8.0.sock;
}
C’est cette ligne, et elle seule, qui détermine quelle version de PHP exécute le site. Rien dans le code de WordPress ne « sait » quelle version tourne : c’est entièrement une décision de configuration serveur, invisible depuis l’application elle-même.
Migrer un site vers une nouvelle version sans risque
- Installer la nouvelle version de PHP-FPM à côté de l’ancienne, sans toucher au pool existant.
- Créer un nouveau pool pointant vers cette version, avec un nom de socket distinct.
- Tester le site sur un sous-domaine temporaire ou en environnement de préproduction avec ce nouveau pool.
- Une fois validé, changer simplement la ligne
fastcgi_passdu bloc serveur nginx du site en production. - Conserver l’ancien pool actif quelques jours, au cas où un retour arrière rapide serait nécessaire.
Vérifier quelle version tourne réellement
Un doute fréquent, surtout après une migration : quelle version de PHP exécute réellement un site donné ? La commande WP-CLI suivante donne la réponse sans ambiguïté, exécutée depuis le dossier du site concerné :
wp eval 'echo PHP_VERSION;'
Sur un serveur qui héberge plusieurs clients, la pire erreur est de traiter PHP comme une propriété globale du serveur. C’est une propriété de chaque site, et chaque site a le droit d’avancer à son propre rythme.
En résumé
Faire cohabiter plusieurs versions de PHP n’est pas une complexité superflue, c’est ce qui permet à un serveur d’agence de servir des clients à des rythmes de mise à jour différents sans les bloquer les uns par rapport aux autres. Un pool PHP-FPM par site, un socket nommé explicitement, et une ligne fastcgi_pass par bloc serveur suffisent à organiser proprement cette cohabitation.
