Quiconque héberge plus d'un site PHP finit par se heurter au mur des versions. Un vieux site client fait tourner un thème ou une extension qui casse au-delà de PHP 7.4. L'app que vous développez aujourd'hui veut 8.3 ou 8.4 pour ses propriétés typées et ses performances. Un troisième projet est bloqué sur du code d'époque 5.6 que personne n'a le budget de moderniser. Le réflexe est de monter un serveur distinct par époque — mais c'est du gaspillage et c'est inutile. Une seule machine Linux peut faire tourner toutes les versions de PHP à la fois, chaque site épinglé sur exactement celle dont il a besoin. Voici comment ça marche, et comment garder ça propre.

Pourquoi le multi-PHP compte

Legacy et moderne, côte à côte. Pas besoin de forcer un vieux site sur un PHP récent (et de le voir afficher une page blanche) ni de brider une nouvelle app sur un ancien. Chacun obtient sa bonne version.
Mises à niveau sans risque. Vous pouvez passer un site de 8.1 à 8.3 isolément, le tester et revenir en arrière — sans toucher aux douze autres sites de la machine.
Un serveur, plusieurs époques. Aucun VPS supplémentaire juste pour séparer les versions de PHP. Héberger un site 5.6 à côté d'un site 8.4 ne coûte quasiment rien.

Le mécanisme qui rend cela possible, c'est PHP-FPM (FastCGI Process Manager), et le comprendre, c'est tout l'enjeu.

Comment fonctionne l'exécution de plusieurs versions

Les distributions Linux modernes permettent d'installer plusieurs versions de PHP en parallèle. Sur Ubuntu/Debian, la voie courante est le PPA ondrej/php, qui empaquette php5.6-fpm, php7.4-fpm, php8.1-fpm, … php8.4-fpm en services distincts qui cohabitent sans souci.

Chaque version installée exécute son propre master FPM, et chaque master peut faire tourner plusieurs pools. Un pool est un groupe de processus workers isolé, avec sa propre config : l'utilisateur sous lequel il tourne, ses limites de ressources et — surtout — sa propre socket d'écoute. Le tableau est donc :

php7.4-fpm  →  pool : siteA  →  /run/php/siteA.sock   (tourne sous l'utilisateur siteA)
php8.4-fpm  →  pool : siteB  →  /run/php/siteB.sock   (tourne sous l'utilisateur siteB)

Votre serveur web (Nginx) n'exécute pas PHP lui-même — il transmet les requêtes .php à une socket via FastCGI. Donc « quelle version de PHP ce site utilise-t-il ? » se répond par une ligne dans la config Nginx du site : vers quelle socket il transmet.

# Site A sur PHP 7.4
location ~ \.php$ {
    fastcgi_pass unix:/run/php/siteA.sock;
    include fastcgi_params;
}

Pointez ce fastcgi_pass vers la socket du pool 7.4 et le site tourne en 7.4 ; pointez-le vers la socket du pool 8.4 et il tourne en 8.4. Changer la version PHP d'un site revient simplement à re-pointer sa socket et recharger Nginx. Tout le reste — fichiers, base de données — est intact.

L'isolation : la partie qu'on saute

Faire tourner un pool par site ne concerne pas que les versions ; c'est aussi ainsi qu'on sépare les locataires. Deux règles font le gros du travail :

Un utilisateur Linux par pool. Faites tourner le pool FPM de chaque site sous son propre utilisateur dédié (pas un www-data partagé). Ainsi, une extension compromise sur un site ne peut pas lire les fichiers ni les identifiants de base d'un autre — les permissions de l'OS l'en empêchent.
open_basedir par pool. Définissez open_basedir dans la config de chaque pool pour épingler son PHP à la racine de ce site (plus son dossier temporaire). Même un script bogué ou malveillant ne peut alors physiquement pas lire hors de son répertoire.

Réussissez ces deux points et « plusieurs versions de PHP sur une machine » signifie aussi « plusieurs sites isolés en toute sécurité sur une machine ». (Plus de détails sur cette isolation en couches dans héberger plusieurs sites clients sur un seul VPS.)

Les pièges à surveiller

Le PHP en CLI est une version différente. Le php obtenu en ligne de commande (pour Composer, WP-CLI, cron) est le défaut système — souvent pas la version qu'utilise le pool FPM d'un site donné. Utilisez les binaires spécifiques (php7.4, php8.4) ou définissez le défaut par site pour que vos tâches cron ne tournent pas sous la mauvaise version.
Les extensions sont par version. php-redis, php-imagick, php-gd et consorts doivent être installés pour chaque version de PHP séparément (php8.4-redis, php7.4-redis). Un site qui a « perdu » une extension après un changement de version a généralement juste besoin du paquet de cette extension pour la nouvelle version.
Chaque pool coûte de la mémoire. Chaque pool garde des workers en RAM. Une douzaine de pools actifs, ça s'additionne — dimensionnez pm.max_children par pool et surveillez la mémoire, plutôt que de laisser chaque pool croire qu'il possède toute la machine.
Rechargez, n'oubliez pas. Après avoir modifié un pool ou une socket, rechargez le service FPM et Nginx. Une config renouvelée non rechargée est une config non active.

Le faire à la main est fastidieux — rendez-le en un clic

Rien de tout cela n'est difficile isolément. Mais le câbler correctement pour chaque site — installer la bonne version FPM, créer un pool sous l'utilisateur du site avec le bon open_basedir et les bonnes limites, générer une socket, re-pointer Nginx, recharger les deux services, garder CLI et extensions alignés — fait beaucoup d'étapes fastidieuses et faillibles à répéter à la main à chaque ajout de site ou changement de version.

C'est exactement ce qu'un panel devrait absorber. ShadowPanel gère toute la pile multi-PHP pour vous :

PHP 5.6 à 8.4, installés en parallèle et prêts par site.
Changez la version d'un site depuis un menu déroulant — le panel régénère le pool FPM isolé du site, re-pointe la socket Nginx et recharge les deux services. Pas de SSH, pas d'édition de config.
Isolation appliquée par défaut — chaque pool tourne sous l'utilisateur Linux du site avec open_basedir imposé.
Extensions et config par site gérées via le panel, pour qu'un changement de version ne supprime pas discrètement ce dont le site a besoin.

Vous choisissez la version ; le panel fait la plomberie — en toute sécurité, à l'identique à chaque fois.

En résumé

Vous n'avez pas besoin d'un serveur par époque de PHP. Une seule machine, PHP-FPM et un pool isolé par site vous permettent de faire tourner 5.6 à côté de 8.4, chaque site sur exactement la version qu'il lui faut — et, bien fait, chaque site scellé des autres. Les concepts sont simples ; le câblage par site est fastidieux et facile à rater subtilement. ShadowPanel transforme « changer la version PHP de ce site » en un menu déroulant, avec l'isolation intégrée.

curl -fsSL https://shadowpanel.de/install.sh | bash

Voir les tarifs et télécharger →

Faire tourner plusieurs versions de PHP sur un serveur (5.6 à 8.4), par site