Un tiers des sites PHP tournent sans correctifs, et 8.2 est le suivant

D'après l'enquête d'usage de W3Techs du 22 octobre 2026, 34,7 % des sites web qui utilisent PHP tournent sur PHP 7 ou plus ancien, et toutes ces versions ont dépassé leur fin de vie. Le même jour, la page des versions supportées de php.net indique que PHP 8.2 reçoit des correctifs de sécurité jusqu'au 31 décembre 2026, soit dans 70 jours. Si vous vous occupez de sites clients, d'un compte d'hébergement mutualisé ou d'une vieille application interne, c'est cette semaine qu'il faut vérifier de quel côté de cette ligne se trouve chacun d'eux, car l'avis du 21 octobre sur les RCE du cœur de PHP a montré ce qu'elle coûte.

Ce que dit l'enquête, et ce qu'elle ne dit pas

W3Techs indique que PHP est utilisé par 69,3 % des sites dont il parvient à identifier le langage côté serveur. Parmi ces sites PHP, la version 8 représente 65,3 %, la version 7 26,9 %, la version 5 7,7 % et la version 4 0,1 %. Deux réserves vont avec ces chiffres. L'enquête ne compte que ce qui se voit de l'extérieur : un site qui masque sa version de PHP n'apparaît pas dans la répartition par version. Et elle ne donne que les versions majeures : les 65,3 % de « 8 » incluent 8.0 et 8.1, déjà en fin de vie, et 8.2, à quelques semaines de la sienne. La part réelle en fin de vie est donc d'au moins 34,7 %.

En général, un vieux PHP survit pour des raisons banales : un hébergeur mutualisé garde une ancienne version disponible pour ne rien casser, une agence a livré un site il y a des années et personne ne s'occupe de ses mises à jour, ou un plugin ou un paquet a figé le runtime et n'a jamais été remplacé. Rien de tout cela ne se voit depuis le navigateur, et c'est précisément pour ça que ça continue de tourner.

Ce que signifie « support de sécurité uniquement »

php.net donne à chaque branche deux ans de support actif à partir de sa première version stable, puis deux ans de correctifs de sécurité critiques uniquement, publiés au besoin, puis la fin de vie. « Sécurité uniquement » veut dire que les bugs ordinaires restent en l'état ; seules les failles sérieuses ont droit à une version. Après la date de fin, plus rien. Selon les termes du projet lui-même, les utilisateurs d'une version en fin de vie peuvent être exposés à des vulnérabilités de sécurité non corrigées.

L'avis d'octobre en est un bon exemple. Il indique que PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet PHP. Vu la gravité, l'équipe sécurité a tout de même publié des rétroportages minimaux du code source pour 7.4, 8.0 et 8.1, pour cette version seulement, et uniquement pour ceux qui compilent PHP eux-mêmes. Ma lecture, qui est une déduction et pas une promesse de qui que ce soit : ne bâtissez pas votre plan sur l'idée que cela se reproduira.

Un plan de migration daté

Les dates viennent directement de php.net. 8.3 reçoit des correctifs de sécurité jusqu'au 31 décembre 2027. 8.4 est en support actif jusqu'au 31 décembre 2026 et reçoit des correctifs de sécurité jusqu'au 31 décembre 2028. 8.5 est en support actif jusqu'au 31 décembre 2027 et reçoit des correctifs de sécurité jusqu'au 31 décembre 2029. Pour un site en 8.2 aujourd'hui, 8.4 ou 8.5 est la cible raisonnable ; passer en 8.3 fait gagner un an et oblige à tout refaire bientôt. Avant de changer de runtime, vérifiez que les dépendances du projet l'acceptent :

# the version the command line runs
php -r 'echo PHP_VERSION, PHP_EOL;'
# run under the target PHP: do the dependencies accept it?
composer check-platform-reqs

N'oubliez pas que la ligne de commande et le serveur web peuvent utiliser des versions de PHP différentes : confirmez aussi celle qui sert les requêtes.

Si quelqu'un d'autre gère le serveur, posez trois questions par écrit. Quelle version de PHP le site utilise-t-il en production, pour les requêtes web ? À quelle date passera-t-il en 8.4 ou 8.5 ? Qui applique les mises à jour de sécurité de PHP, et celles du 21 octobre ont-elles été appliquées ?

La prochaine étape, aujourd'hui : listez vos sites, notez à côté de chaque nom la version de PHP qu'il sert, et donnez à chaque entrée sous 8.3 une date de migration avant la fin de l'année. Source : php.net, versions supportées.