Fin de vie de PHP 8.2 (31 déc. 2026) : que faire ?

PHP 8.2 arrive en fin de vie le 31 décembre 2026. Après cette date, le projet PHP ne publie plus de correctifs de sécurité pour cette version. Votre site continue de fonctionner, mais la prochaine faille PHP sérieuse, comme PHP2Shell en octobre, ne sera pas corrigée pour 8.2. La solution est de passer à PHP 8.4 (correctifs de sécurité jusqu’au 31 décembre 2028), ou à 8.3 (jusqu’au 31 décembre 2027) si un plugin ou un framework dont vous dépendez n’est pas prêt pour 8.4. Pour un site WordPress aux plugins à jour, cela représente en général quelques heures de tests. Le code sur mesure ancien, les plugins abandonnés et les images Docker prennent plus de temps : commencez donc en novembre, pas le 30 décembre.

Ce que la fin de vie signifie, et ce qu’elle ne signifie pas

• Votre site ne s’arrête pas le 1er janvier. PHP 8.2 continue de fonctionner. Ce qui s’arrête, ce sont les correctifs de php.net, et les images Docker officielles ne sont plus mises à jour.
• Le risque augmente avec le temps. Chaque faille de sécurité découverte dans PHP après le 31 décembre reste ouverte sur 8.2. En octobre 2026, PHP2Shell a montré à quel point cela compte : les attaques ont commencé le jour de la publication du correctif.
• Votre hébergeur peut vous faire migrer. Beaucoup d’hébergeurs basculent les sites vers une version de PHP plus récente après la fin de vie, parfois avec peu de préavis, et certains font payer le maintien d’une ancienne version. Un changement forcé sur un site jamais testé, c’est un message d’erreur critique à la place de votre site.
• Les distributions Linux sont un cas particulier. Certaines distributions continuent de corriger leur propre paquet PHP 8.2 tant qu’elles prennent en charge la distribution elle-même. Si votre serveur exécute PHP depuis les paquets de votre distribution, consultez le suivi de sécurité de cette distribution. Cela ne concerne pas les versions php.net, les images Docker officielles ni la plupart des panneaux d’hébergement.

Les versions de PHP et leurs dates de fin

Version	Sortie	Corrections de bugs jusqu’au	Correctifs de sécurité jusqu’au
PHP 8.1 et antérieures	2021 ou avant	Terminé	Terminé (8.1 le 31 décembre 2025)
PHP 8.2	8 décembre 2022	Terminé le 31 décembre 2024	31 décembre 2026
PHP 8.3	23 novembre 2023	Terminé le 31 décembre 2025	31 décembre 2027
PHP 8.4	21 novembre 2024	31 décembre 2026	31 décembre 2028
PHP 8.5	20 novembre 2025	31 décembre 2027	31 décembre 2029

Chaque version de PHP reçoit deux ans de corrections de bugs, puis deux ans de correctifs de sécurité uniquement. Si vous utilisez 8.1 ou une version plus ancienne, vous êtes déjà sans correctifs : traitez cette mise à niveau en premier.

Vers quelle version passer ?

• PHP 8.4 pour la plupart des sites. Il est pris en charge jusqu’à fin 2028, vous ne referez donc pas l’exercice l’an prochain. WordPress 6.8 et les versions suivantes le prennent en charge.
• PHP 8.3 si quelque chose bloque 8.4. Un ancien plugin, un thème ou une bibliothèque qui n’a pas été mis à jour. Cela vous donne un an de plus, jusqu’au 31 décembre 2027.
• PHP 8.5 si vous repartez de zéro ou si votre stack est à jour. WordPress le prend en charge à partir de la 6.9 ; Laravel 12 et 13 aussi. Beaucoup de plugins sont testés sur cette version plus tard que sur 8.4.

Avec Laravel, la version de PHP et celle de Laravel vont ensemble. Laravel 11 fonctionne avec PHP 8.2 à 8.4, mais ses propres correctifs de sécurité se sont arrêtés le 12 mars 2026. Laravel 12 fonctionne avec 8.2 à 8.5, avec des correctifs de sécurité jusqu’au 24 février 2027. Laravel 13 exige PHP 8.3 ou plus récent. Une application sous Laravel 10 ou 11 est une bonne occasion de faire évoluer les deux.

Vérifier quelle version de PHP vous utilisez

• WordPress : Outils, Santé du site, Infos, puis la section Serveur affiche la version de PHP.
• Panneau d’hébergement : cPanel, Plesk, DirectAdmin et la plupart des hébergeurs managés l’affichent dans les réglages PHP ou sous « Select PHP version ».
• Votre propre serveur : php -v en ligne de commande. Le serveur web peut utiliser une autre version que la ligne de commande : vérifiez donc aussi une page phpinfo(), et supprimez-la tout de suite après.
• Docker : regardez la ligne FROM de votre Dockerfile (par exemple php:8.2-fpm), ou lancez docker run --rm your-image php -v.

Notre guide MigrateXtoY sur la fin de vie de PHP 8.2 détaille ce qui casse selon la plateforme (WordPress, WooCommerce, Magento, Laravel, Drupal) et les outils utiles.

Ce qui peut casser lors de la mise à niveau

Passer de 8.2 à 8.3 ou 8.4 est un petit pas comparé au saut de PHP 7 à 8. La plupart des changements sont de nouveaux avertissements de dépréciation, qui remplissent vos journaux mais n’arrêtent pas le site. Ce qui casse vraiment un site :

• Les plugins et thèmes non mis à jour depuis des années. Ils sont la cause la plus courante d’un écran blanc ou d’une erreur critique après un changement de version de PHP.
• Les extensions supprimées. PHP 8.4 n’inclut plus IMAP, OCI8, PDO_OCI et Pspell ; elles sont passées dans PECL. Un plugin qui lit une boîte mail avec imap_open(), ou une application qui communique avec Oracle, a besoin de l’extension installée séparément ou d’un remplacement.
• Le code sur mesure dont les avertissements ont été ignorés. Les dépréciations des versions précédentes deviennent des erreurs dans les suivantes. Si vos journaux en sont remplis, corrigez-les dès maintenant.
• Les dépendances Composer avec une plage PHP stricte. composer why-not php 8.4 liste les paquets qui bloquent la mise à niveau.

Comment mettre à niveau sans interruption

1. Faites une sauvegarde des fichiers et de la base de données, stockée hors du serveur.
2. Mettez d’abord tout le reste à jour : le cœur de WordPress, les plugins et les thèmes, ou vos paquets Laravel et Composer. Supprimez les plugins que vous n’utilisez pas.
3. Testez sur une copie. La plupart des hébergeurs proposent un site de préproduction. Passez la copie à la nouvelle version de PHP et activez la journalisation des erreurs (WP_DEBUG_LOG dans WordPress, le journal Laravel pour Laravel).
4. Parcourez ce qui rapporte de l’argent : formulaires, paiement, règlements, connexion, recherche, tâches planifiées et e-mails envoyés par votre site.
5. Lisez le journal des erreurs. Corrigez les erreurs fatales avant la mise en ligne ; notez les dépréciations pour plus tard.
6. Basculez le site en production à un moment calme, et laissez l’ancienne version sélectionnable dans votre panneau d’hébergement pour revenir vite en arrière.
7. Pour Docker : modifiez la ligne FROM, reconstruisez avec docker build --pull, vérifiez l’espace disque libre avant la construction, et redéployez chaque conteneur.

Si le site casse malgré tout après un changement, notre checklist sur un site WordPress hors ligne couvre le mode de récupération et le retour en arrière.

Dans notre travail : deux façons dont une échéance PHP arrive

Le 21 octobre, nous avons corrigé la plateforme Laravel d’un client contre PHP2Shell. Elle tourne dans Docker sur PHP 8.2, sur un seul serveur cloud. La mise à jour a d’abord demandé trois corrections : l’image Docker officielle n’avait pas encore la version corrigée, nous avons donc construit l’image de base nous-mêmes ; le disque était plein à 100 %, nous l’avons doublé de 15 à 30 Go ; et plus que le site web était ouvert sur internet, nous avons donc fermé tous les ports sauf 80 et 443. La plateforme tournait sous PHP 8.2.35 le jour même. Mais 8.2.35 ne fait que gagner du temps : cette même plateforme a maintenant l’échéance du 31 décembre, et une mise à niveau est plus facile en novembre que pendant la prochaine urgence.

La seconde façon, c’est l’échelle. Pour une agence de design néerlandaise, nous maintenons plus de 50 sites WordPress sous leur nom, environ 10 heures par mois depuis juillet 2026. Quand PHP2Shell a été publié, nous sommes intervenus sur leurs sites en quelques minutes. Une date de fin de vie est la version lente du même travail : une liste de sites, une échéance et une vérification par site. Que vous gériez un site ou cinquante, le travail est le même : savoir quelle version chaque site utilise, tester avant que l’hébergeur ne bascule à votre place, et garder un moyen de revenir en arrière.

Plus sur ce qui s’est passé en octobre : PHP2Shell : que faire maintenant pour votre site WordPress ou Laravel.

Ce que cela coûte

Option	Prix HT	Bon à savoir
Le faire soi-même	Votre temps	Convient à un site WordPress aux plugins à jour et avec une copie de préproduction chez votre hébergeur.
Votre hébergeur	Souvent inclus	La plupart des hébergeurs changent la version ; peu testent votre site ou corrigent ce qui casse.
Carte d’heures WDDW	910 € pour 14 heures	Des heures prépayées pour la mise à niveau, les tests et les corrections, avec des heures restantes pour les mises à jour régulières.
Aide d’urgence WDDW	75 €/heure, sans minimum	Si l’hébergeur a déjà basculé et que le site est en panne : un développeur senior démarre le jour même.

Vous préférez que les mises à jour de PHP et des plugins soient traitées chaque mois plutôt que dans l’urgence ? Voyez combien coûte la maintenance d’un site. Les agences qui gèrent de nombreux sites clients peuvent lire comment nous procédons sous leur nom dans Maintenance WordPress en marque blanche pour agences.

Mettez à niveau avant l’échéance

Envoyez-nous l’adresse de votre site. Un développeur senior vérifie quelle version de PHP il utilise, le teste sur PHP 8.4 sur une copie, corrige ce qui casse et bascule le site en production avec un moyen de revenir en arrière. WordPress, WooCommerce, Laravel ou Docker : nous travaillons avec l’hébergement que vous avez. Contactez-nous → ou, si le site est déjà en panne, demandez une aide d’urgence.

Vous dirigez une agence ? Nous mettons à niveau les sites de vos clients sous votre nom, sous NDA. Jusqu’au 31 décembre : achetez 2 cartes d’heures, la 3e est offerte. Voir l’offre agences →

Faits vérifiés le 6 novembre 2026. Sources : PHP supported versions, PHP 8.4 migration guide, WordPress PHP compatibility, Laravel support policy.