Peu de dirigeants de PME savent quelle version de PHP fait tourner leur site. C'est normal, ce n'est pas leur métier, et tant que le site fonctionne, la question ne se pose jamais. Le problème est que PHP suit un cycle de vie strict, avec des dates de fin de support précises, et qu'une version arrivée en fin de vie cesse totalement de recevoir des correctifs de sécurité, même en cas de faille critique découverte après cette date. Or PHP 8.1, encore largement répandu, a atteint cette fin de vie le 31 décembre 2025.
Ce que signifie concrètement une fin de vie PHP
Chaque version majeure de PHP traverse deux phases après sa sortie : d'abord un support actif d'environ deux ans, avec corrections de bugs et de failles de sécurité, puis une phase de support de sécurité uniquement, également d'environ deux ans, où seules les failles critiques sont corrigées. Une fois ces deux phases écoulées, la version n'est plus maintenue du tout. Aucune faille découverte après cette date ne sera corrigée, quelle que soit sa gravité. Un site qui continue de tourner sur cette version reste exposé indéfiniment à toute vulnérabilité identifiée par la suite.
Où en est chaque version actuellement
À la date de rédaction de cet article, PHP 8.1 est en fin de vie depuis le 31 décembre 2025 et ne reçoit plus aucune mise à jour. PHP 8.2 est encore maintenu, mais uniquement en support de sécurité, et atteindra sa propre fin de vie le 31 décembre 2026, dans quelques mois. PHP 8.3 est également en phase de sécurité uniquement, avec une fin de vie prévue fin 2027. Les versions les plus récentes, PHP 8.4 et 8.5, sont en support actif complet. Ces échéances évoluent d'une version à l'autre, il est donc utile de vérifier régulièrement le calendrier officiel plutôt que de se fier à une date mémorisée une fois pour toutes.
Pourquoi tant de sites restent sur une version obsolète
La cause la plus fréquente n'est pas la négligence, mais l'hébergement mutualisé. De nombreux hébergeurs conservent une version par défaut ancienne pendant longtemps, parce que changer la version PHP d'un serveur mutualisé peut casser des sites clients qui dépendent de comportements spécifiques à cette version. Un site WordPress installé depuis plusieurs années, avec des extensions elles mêmes anciennes, peut ainsi se retrouver bloqué sur PHP 8.1 ou une version antérieure sans qu'aucune alerte ne soit jamais remontée au propriétaire du site.
Les risques réels, au delà du discours alarmiste
Une version de PHP en fin de vie n'est pas dangereuse en soi le lendemain de sa date de fin de support, mais le risque augmente avec le temps qui passe. Chaque mois qui suit la fin de vie voit potentiellement de nouvelles vulnérabilités découvertes dans le langage lui même, jamais corrigées faute de mainteneur actif sur cette branche. À cela s'ajoute un problème indirect tout aussi important : de nombreuses extensions WordPress, bibliothèques PHP et outils de sécurité cessent progressivement de garantir leur compatibilité avec les versions trop anciennes, ce qui peut créer des conflits ou des failles inattendues au fil des mises à jour de ces composants tiers.
Comment vérifier sa propre version
Pour un site WordPress, l'information est visible dans le tableau de bord d'administration, sous Outils puis Santé du site, dans la section informations sur le serveur. Pour un développement PHP sur mesure, la fonction phpversion() appelée dans un script temporaire donne la réponse immédiatement. La plupart des panneaux d'hébergement, comme cPanel ou Plesk, affichent également la version active dans leurs paramètres PHP, avec souvent la possibilité de la changer directement depuis l'interface.
Comment migrer sans casser le site
Une montée de version PHP n'est jamais totalement anodine, car chaque version majeure retire certaines fonctions dépréciées et modifie parfois des comportements par défaut. La bonne pratique consiste à tester la migration sur un environnement de préproduction identique au site en production, avec les mêmes extensions et le même thème, avant de basculer l'environnement réel. Sur WordPress, mettre à jour le cœur, le thème et toutes les extensions vers leurs dernières versions avant la migration réduit fortement les risques d'incompatibilité, car les éditeurs sérieux adaptent progressivement leur code aux nouvelles versions de PHP.
Points à vérifier avant publication : confirmer les dates de fin de vie exactes de PHP 8.1, 8.2, 8.3, 8.4 et 8.5 sur le calendrier officiel PHP.net au moment de la publication, car ces échéances peuvent être ajustées, et vérifier que la procédure décrite pour consulter la version PHP dans WordPress correspond toujours à l'interface actuelle du tableau de bord.