Tu lances un php -v, tu vois 8.3.x, tu te dis que c’est bon. Et pourtant ta page web te claque un message du style « Your Composer dependencies require PHP >= 8.2.0 ». Ce bug est infâme parce qu’il te donne l’impression que PHP ment.
Spoiler : PHP ne ment pas. Tu as juste deux (ou trois) PHP sur la machine, et ce n’est pas le même qui exécute le code en HTTP. La CLI (terminal), Apache (mod_php), PHP-FPM (service séparé) et même un cron peuvent tous pointer sur des versions différentes. On va le prouver proprement, puis corriger sans faire un « upgrade au hasard » qui casse la prod.
Le symptôme typique : PHP 8.3 en CLI, PHP 8.1 (ou 8.0) côté web
Dans la vraie vie, ça arrive souvent après un upgrade partiel. Tu installes php8.3, tu bascules ton terminal, Composer se met à tourner, tu rebuild des vendors, tout a l’air sain. Et puis dès que tu passes par Apache/Nginx, l’app tombe sur une erreur de compatibilité.
Le message « requires PHP >= … » vient généralement de vendor/composer/platform_check.php (généré par Composer) ou d’un framework qui vérifie la version à l’exécution. Et là, ce qui compte, c’est la version de PHP qui répond à la requête HTTP, pas celle que tu obtiens dans ton shell.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Ce que je vérifie en 2 minutes : prouver quelle version sert le HTTP
Avant de toucher à la config, je veux une preuve simple et reproductible. Le plus efficace, c’est de faire répondre le serveur avec la version et le SAPI, sans dépendre de ton framework.
<?php
// /tmp/php-probe.php (à déposer temporairement dans le docroot ou un vhost isolé)
header('Content-Type: text/plain; charset=utf-8');
echo 'PHP_VERSION=' . PHP_VERSION . "\n";
echo 'PHP_SAPI=' . PHP_SAPI . "\n";
echo 'Loaded php.ini=' . (php_ini_loaded_file() ?: 'none') . "\n";
Tu appelles ce fichier via le navigateur (ou mieux, via curl depuis une autre machine) et tu regardes ce que ça dit. Si tu vois PHP_SAPI=apache2handler, tu es sur mod_php. Si tu vois fpm-fcgi, tu es sur PHP-FPM. Et si la version affichée n’est pas celle de php -v, tu as trouvé ton coupable.
Petit détail qui fait gagner du temps : si tu testes en local sur le serveur, curl http://127.0.0.1/php-probe.php peut passer par un vhost différent de celui exposé publiquement (ServerName, default vhost, etc.). Si le problème est visible « de l’extérieur », teste aussi « de l’extérieur ».
Comprendre le piège : CLI, Apache mod_php et PHP-FPM sont trois mondes différents
La CLI, c’est ton binaire /usr/bin/php (ou un autre selon ton PATH). C’est ce que Composer utilise quand tu fais composer install dans un terminal. Tu peux être en 8.3 ici et être parfaitement heureux.
Apache avec mod_php, c’est un module chargé dans Apache. Apache peut très bien charger un vieux libapache2-mod-php8.1 pendant que ta CLI est en 8.3. Et tant que ce module est actif, c’est lui qui exécute tes scripts .php en HTTP. Dans ce cas, tu auras souvent PHP_SAPI=apache2handler dans ton probe.
PHP-FPM, c’est un service séparé (voire plusieurs services) qui écoute sur un socket Unix ou un port TCP. Tu peux avoir php8.1-fpm et php8.3-fpm installés en parallèle, et ton Nginx/Apache peut être configuré pour parler au mauvais socket. Dans ce cas, ton probe affichera fpm-fcgi, mais pas la bonne version.
Diagnostic côté CLI : vérifier ce que ton terminal exécute vraiment
Je commence par le terminal, parce que ça permet déjà de voir si tu as une installation multi-version, et si tu as un PATH « créatif » (typiquement avec des bins dans /usr/local/bin ou un conteneur).
which php
php -v
php --ini
php -i | head -n 20
Si which php pointe vers un truc inattendu, ne va pas plus loin : tu n’as pas la même notion de « PHP par défaut » que ton système. Sur Debian/Ubuntu, le binaire est souvent géré par update-alternatives, mais Apache/FPM ont leur propre logique, et c’est précisément ça qui fait le piège.
Diagnostic côté Apache : repérer un vieux mod_php encore chargé
Si ton probe indique apache2handler, on arrête de deviner et on regarde les modules Apache chargés. Sur Ubuntu/Debian :
apachectl -M | grep php te donne rapidement si un module PHP est actif. Tu peux aussi passer par a2query -m php8.1 (ou 8.2/8.3 selon ce que tu as) pour confirmer.
Ce que je vois souvent : quelqu’un a installé PHP 8.3 et libapache2-mod-php8.1 est resté activé. Apache n’est pas « au courant » de ton php CLI. Il charge ce qu’on lui dit de charger.
Diagnostic côté PHP-FPM : vérifier la version du pool réellement utilisé
Si le probe indique fpm-fcgi, la question devient : « à quel FPM le serveur web parle ? ». Là, le meilleur indice n’est pas ton terminal, c’est la conf Nginx/Apache.
Sur Nginx, tu cherches le fastcgi_pass. S’il pointe vers un socket du style unix:/run/php/php8.1-fpm.sock, tu as ta réponse. Sur Apache en mode proxy_fcgi, tu cherches les directives SetHandler ou les ProxyPassMatch qui finissent par un socket PHP.
Ensuite, côté services, regarde ce qui tourne vraiment : systemctl status php8.1-fpm, systemctl status php8.3-fpm. Une autre classique : tu as bien installé php8.3-fpm, mais il n’est pas démarré, donc la conf pointe vers 8.1 « parce que ça marche ».
Pourquoi Composer te rend le bug encore plus confus
Composer exécute ses checks et scripts en CLI. Donc tu peux très bien faire un composer install en PHP 8.3 et générer un vendor/ cohérent avec 8.3. Puis, quand tu appelles l’app via HTTP en PHP 8.1, elle se fait recaler par le platform check. Résultat : tu as l’impression que Composer a « changé d’avis » entre deux commandes.
Autre piège : tu as parfois des scripts post-install (cache warmup, artisan, bin/console, etc.). Ils passent en CLI et réussissent. Le site, lui, tombe au premier hit. L’écart de version est invisible tant que tu n’as pas fait ton probe côté HTTP.
Fix propre n°1 (recommandé) : passer sur PHP-FPM et arrêter mod_php
Mon avis est assez simple : si tu as le choix, préfère PHP-FPM. C’est plus clair à opérer, ça se scale mieux, et tu évites les mélanges bizarres de modules Apache. Surtout, tu peux faire cohabiter plusieurs versions plus proprement (même si l’objectif, c’est d’en avoir une seule en prod).
Concrètement, ça veut dire : désactiver le module PHP Apache, activer la partie proxy_fcgi, installer/démarrer la bonne version de FPM, puis pointer ton vhost sur le bon socket. Après ça, tu redémarres Apache et tu retestes ton probe.
Le point important : ne « bricole » pas juste pour faire disparaître l’erreur. Assure-toi que ton serveur web parle bien au FPM voulu, sinon tu vas te retrouver avec un incident qui revient au prochain reboot ou à la prochaine mise à jour.
Fix propre n°2 : si tu restes en mod_php, désactive l’ancien module et active le bon
Si tu es sur Apache/mod_php et que tu veux rester comme ça (WordPress en petit VPS, legacy, contraintes, ok), alors il faut être cohérent : un Apache doit charger un module PHP, et c’est celui que tu veux.
Sur Debian/Ubuntu, le scénario classique est : désactiver php8.1 côté Apache, activer php8.3 (si tu as le module), redémarrer Apache, et vérifier via le probe que PHP_VERSION a bougé et que tu es toujours en apache2handler. Tant que tu n’as pas une preuve via HTTP, ce n’est pas « réglé », c’est juste « plausible ».
Attention à un détail : même si tu as PHP 8.3 en CLI, tu peux ne pas avoir libapache2-mod-php8.3 installé. Dans ce cas, tu peux tourner en rond pendant une heure. Ne force pas : passe sur FPM, tu y gagneras en lisibilité.
Fix propre n°3 : aligner la CLI sur la version « serveur » (ou l’inverse), mais en connaissance de cause
Le réflexe « je change le PHP par défaut » via update-alternatives peut aider… mais ce n’est pas la solution au problème web. C’est juste une façon d’éviter un autre piège, celui du dev qui lance des commandes en croyant parler au même PHP que la prod.
Moi je m’en sers comme garde-fou : je choisis une version cible (ex: 8.3), j’aligne la CLI dessus pour que Composer, les scripts, les cron et les outils soient cohérents, puis je m’assure séparément que le serveur web est aussi sur cette version via FPM/mod_php. Si tu ne fais que l’un des deux, tu restes dans l’entre-deux, et c’est là que les « requires PHP >= » reviennent.
Après le fix : comment éviter que ça revienne au prochain upgrade
Une fois que c’est réglé, je garde un truc en tête : ce bug revient quand quelqu’un modifie une seule couche (CLI ou SAPI web) et oublie l’autre. Donc j’essaie de rendre l’écart visible.
Le minimum syndical, c’est de documenter dans ton README infra « quelle version de PHP sert le HTTP » et « où est le socket FPM ». Si tu veux être un peu plus sérieux, ajoute un petit endpoint interne (protégé) qui renvoie PHP_VERSION et PHP_SAPI, et fais un smoke test en CI/CD qui le lit après déploiement. Pas besoin d’un monitoring de luxe : juste un test qui échoue si la version n’est pas celle attendue.
Et si tu héberges plusieurs apps sur le même serveur, sois strict sur les vhosts. Le « default site » qui répond à la place du bon, c’est exactement le genre de détail qui transforme un diagnostic simple en chasse au trésor.
Les erreurs fréquentes que je vois (et qui font perdre du temps)
La plus courante : corriger la CLI (ou Composer) alors que le problème est 100% côté serveur web. Changer /usr/bin/php ne changera pas magiquement le module Apache déjà chargé en mémoire.
La deuxième : redémarrer le mauvais service. Quand tu changes une conf FPM, c’est php8.x-fpm que tu redémarres. Quand tu changes un vhost Nginx/Apache, c’est Nginx/Apache. Et quand tu changes mod_php, c’est Apache. Ça paraît évident, mais en incident, on se trompe vite.
La troisième : laisser plusieurs FPM en parallèle « au cas où » sans savoir qui utilise quoi. Ce n’est pas un crime d’avoir plusieurs versions installées. Le problème, c’est de ne pas avoir une vérité claire par application.
Mon avis : ce bug est banal, mais il révèle un vrai souci d’exploitation
Voir « PHP >= 8.2 requis » alors que tu es en 8.3, c’est un classique. Mais ce n’est pas juste un petit bug de config. C’est un signal que ta prod est trop implicite, et que tes couches (web server, FPM, CLI, cron) ne sont pas traitées comme un ensemble cohérent.
La bonne nouvelle, c’est qu’une fois que tu prends l’habitude de prouver la version côté HTTP (probe/healthcheck) et de faire parler la conf (socket FPM, modules Apache), tu règles ça vite. Et surtout, tu ne te fais plus avoir par un php -v qui te donne un faux sentiment de sécurité.
