FR
Contact
Contact

Articles

PHP 8.2 arrive en fin de vie le 31 décembre 2026 : que faire d’ici là

Publié leDates et versions vérifiées le 25 octobre 2026.

Le projet PHP assure les correctifs de sécurité de PHP 8.2 jusqu’au 31 décembre 2026 (php.net, page des versions supportées). Sortie le 8 décembre 2022, cette branche a quitté le support actif le 31 décembre 2024 et ne reçoit depuis que des correctifs de sécurité. La dernière version disponible au moment où nous écrivons est la 8.2.35, publiée le 21 octobre 2026. Après le 31 décembre, php.net ne publiera plus aucune version 8.2. Toutes les dates de fin de vie de PHP, Laravel et Symfony figurent dans notre calendrier EOL.

Cette version d’octobre n’avait rien d’une mise à jour de routine. D’après l’avis de sécurité publié par php.net le 21 octobre 2026, PHP 8.2.35 corrige deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, qui peuvent permettre l’exécution de code à distance sans authentification. Les mêmes correctifs sont sortis dans les versions 8.3.36, 8.4.27 et 8.5.12, et php.net précise qu’aucune mesure de contournement ne protège complètement : seule la mise à jour est sûre. Si une faille de ce niveau est découverte en janvier, aucun correctif ne sortira pour 8.2.

Cet article explique ce qui change au 1er janvier, comment repérer ce qui retient votre application sur 8.2, quelle version viser, et que faire si vous n’êtes pas prêt à temps.

Ce qui change au 1er janvier 2027

Rien ne s’arrête. L’application continue de tourner exactement comme avant. La différence apparaît le jour où quelqu’un trouve une vulnérabilité dans PHP lui-même, comme en octobre : le correctif sort pour les branches supportées, pas pour 8.2. En phase de sécurité uniquement, php.net ne publie déjà de versions qu’en cas de besoin. Ce que vous perdez, ce sont donc les correctifs de toutes les failles découvertes après le 31 décembre, quel qu’en soit le nombre.

Cette date compte aussi à trois autres titres.

  • PHP 8.4 quitte le support actif le 31 décembre 2026 et ne reçoit plus ensuite que des correctifs de sécurité, jusqu’au 31 décembre 2028. À partir de janvier, seules les versions 8.5 et 8.6 bénéficient de corrections de bugs régulières. Le calendrier de sortie de PHP 8.6 (wiki.php.net) prévoit la version stable pour le 19 novembre 2026.
  • Les plateformes fixent leurs propres dates. Google App Engine standard cesse de prendre en charge son runtime php82 le 31 décembre 2026 et le retire le 31 décembre 2027 : à partir de là, les déploiements sur ce runtime ne fonctionnent plus. AWS Elastic Beanstalk prévoit de retirer sa plateforme PHP 8.2 le 31 mars 2027. Certains hébergeurs facturent le maintien d’une version que le projet PHP ne corrige plus. L’hébergeur allemand mittwald demande actuellement 5 € HT par version de PHP, par projet et par mois pour les versions que la communauté ne corrige plus (aujourd’hui 8.1 et antérieures), puis 15 € dans une seconde phase, sans garantie de correctifs.
  • Les paquets des distributions ne suivent pas le calendrier de php.net. Debian 12 fournit PHP 8.2 comme version par défaut et maintient son propre paquet php8.2. Le support à long terme de Debian 12 est prévu jusqu’au 30 juin 2028 (wiki Debian LTS). Si votre PHP vient des dépôts Debian, consultez le Debian security tracker pour php8.2 avant de tout caler sur le 31 décembre. Votre échéance réelle est peut-être celle de Debian, pas celle de php.net.

Étape 1 : vérifier ce qui tourne vraiment

Vérifiez sur le serveur de production, à la fois en ligne de commande et du côté du processus qui sert les requêtes web, car les deux peuvent utiliser des versions différentes :

php -v
php -m
ps aux | grep -E "php-fpm" | head -3

Sous Debian et Ubuntu, le processus maître de PHP-FPM affiche le chemin de sa configuration, par exemple /etc/php/8.2/fpm/php-fpm.conf. C’est cette version qui sert réellement vos utilisateurs. Notez aussi d’où vient le binaire : paquet de la distribution, dépôt tiers, tag d’image Docker ou réglage dans le panneau de l’hébergeur. Chaque source a sa propre procédure de mise à jour et sa propre date de fin.

Étape 2 : trouver ce qui vous retient sur 8.2

Dans la plupart des cas, c’est le framework ou une dépendance qui maintient l’application sur 8.2. Composer vous indique lesquels :

composer why-not php 8.4

La commande liste les paquets installés dont la contrainte PHP exclut 8.4. C’est le périmètre minimal du chantier : un paquet dont la contrainte reste ouverte, comme >=7.2, n’apparaît pas dans cette liste et peut pourtant casser sous 8.4.

Regardez ensuite le framework, car c’est lui qui fixe le plafond :

FrameworkPHP supportéFin des correctifs de sécurité
Laravel 108.1 à 8.34 février 2025 (passée)
Laravel 118.2 à 8.412 mars 2026 (passée)
Laravel 128.2 à 8.524 février 2027
Laravel 138.3 à 8.517 mars 2028
Symfony 6.48.1 ou plus récentnovembre 2027
Symfony 7.48.2 ou plus récentnovembre 2029

Sources : laravel.com/docs/13.x/releases et symfony.com/releases, consultés le 25 octobre 2026.

Une application Laravel 10 ne peut pas dépasser PHP 8.3, et Laravel 10 lui-même ne reçoit plus de correctifs de sécurité depuis février 2025. Dans ce cas, la montée de version de PHP et celle du framework forment un seul projet, et il revient moins cher de les planifier ensemble.

Enfin, passez les extensions en revue. PHP 8.4 a retiré IMAP, OCI8, PDO_OCI et PSpell de la distribution PHP pour les déplacer vers PECL. Si php -m affiche imap et que votre code appelle imap_open(), réglez ce point en premier. Un hébergement mutualisé qui vous fait passer en 8.4 ne proposera peut-être pas du tout la version PECL.

Étape 3 : choisir la version cible

CibleFin des correctifs de sécuritéCe que vous gagnez à partir de janvier 2027
8.331 décembre 2027un an, déjà en sécurité uniquement
8.431 décembre 2028deux ans
8.531 décembre 2029trois ans, avec des corrections de bugs jusqu’à fin 2027

Dans la plupart des bases de code, passer de 8.2 à 8.4 ne demande guère plus de travail que de passer à 8.3 : l’étape intermédiaire en 8.3 se justifie rarement. Par défaut, nous visons 8.4, et nous retenons 8.5 quand toutes les dépendances l’acceptent déjà, ce que composer why-not php 8.5 vous montrera. Une version sortie depuis quelques semaines, comme le sera 8.6 en décembre, est une mauvaise cible quand l’échéance approche. Laissez aux bibliothèques le temps de suivre.

Étape 4 : savoir ce qui casse entre 8.2 et 8.4

PHP 8.3 a peu changé pour une application web classique. Le gros du travail se situe en 8.4, et il s’agit surtout de dépréciations :

  • Paramètres implicitement nullables. function find(User $user = null) est déprécié et devient ?User $user = null. Dans les bases de code anciennes, c’est de loin la modification la plus fréquente, et elle est mécanique.
  • Réglages de session. session.sid_length et session.sid_bits_per_character sont dépréciés. Vérifiez php.ini, les fichiers .user.ini et les appels à ini_set().
  • trigger_error() avec E_USER_ERROR est déprécié. Levez une exception à la place.
  • E_STRICT disparaît en tant que niveau d’erreur et la constante est dépréciée. Les anciens gestionnaires d’erreurs maison y font souvent référence.
  • Comportements plus stricts. exit() lève une TypeError quand le type de l’argument est invalide, round() refuse les modes d’arrondi invalides, et les attributs PDO MySQL comme ATTR_EMULATE_PREPARES attendent désormais des booléens.

Par défaut, PHP journalise les dépréciations et poursuit l’exécution. Vérifiez d’abord votre gestionnaire d’erreurs : les anciens frameworks et beaucoup de callbacks set_error_handler() maison transforment chaque notice en exception, et la première dépréciation devient alors une erreur fatale. Même avec le gestionnaire par défaut, une application peut passer tous ses tests sous 8.4 tout en écrivant des milliers de messages de dépréciation par heure. Faites-la tourner en 8.4 en préproduction avec E_DEPRECATED journalisé, utilisez-la vraiment, et lisez le journal avant de basculer la production.

Étape 5 : laisser les outils faire la partie mécanique

Rector applique à votre code des jeux de règles par version de PHP, mais il vérifie aussi quelle version de PHP votre projet utilise et ignore toute règle qui en exige une plus récente. Sauf si vous définissez withPhpVersion(), il déduit cette version de la borne inférieure de require.php dans composer.json. Résultat : ->withPhpSets(php84: true) ne se comporte pas de la même façon selon la contrainte.

  • Avec "php": "^8.2", Rector n’applique que les règles jusqu’à 8.2. Les règles 8.4 sont ignorées, y compris celle qui rend explicites les paramètres nullables.
  • Avec "php": "^8.4", Rector applique tout jusqu’à 8.4, y compris une syntaxe qui n’existe qu’en 8.3 et 8.4, comme les constantes de classe typées. Ce code ne tourne pas sous 8.2.

Pendant la transition, gardez "php": "^8.2" et lancez la seule règle 8.4 dont vous avez besoin tout de suite, avec une petite configuration à part : ->withRules([ExplicitNullableParamTypeRector::class])->withPhpVersion(PhpVersion::PHP_84). Le ?User qu’elle écrit fonctionne à partir de PHP 7.1. Relevez la contrainte à ^8.4 le jour de la bascule, puis lancez le jeu php84 complet. À chaque passage, commencez par --dry-run et relisez le diff. Sur une grosse base de code, il est long, et presque tout y est correct.

PHPStan 2 accepte une plage, phpVersion: {min: 80200, max: 80400}, et signale alors une bonne partie de ce qui cassera sur l’une ou l’autre version. Ajoutez 8.4 à la matrice de CI à côté de 8.2, pour que chaque modification soit testée sur les deux jusqu’à la bascule.

Ce que les outils ne vous apportent pas, c’est la preuve que l’application fait toujours ce qu’elle faisait. S’il n’existe aucun test sur les parcours qui rapportent de l’argent (connexion, commande, facturation, export nocturne), écrivez-en quelques-uns qui enregistrent le comportement actuel avant de changer le runtime sous l’application.

Si vous n’êtes pas prêt au 31 décembre

Cela arrive, et il existe des réponses raisonnables, à envisager dans cet ordre :

  1. Si vous utilisez les paquets de votre distribution, vérifiez jusqu’à quand elle corrige php8.2. Vous disposez peut-être de plus de temps que ne le laisse penser php.net.
  2. Achetez du temps en connaissance de cause. Les builds PHP corrigés de fournisseurs comme Freexian, TuxCare ou Zend, ou l’offre de support étendu d’un hébergeur, maintiennent l’interpréteur corrigé. Ils ne corrigent ni votre framework ni vos dépendances Composer : considérez-les comme une passerelle, avec une date de fin.
  3. Réduisez l’exposition pendant le chantier. Maintenez tout le reste à jour, lancez composer audit chaque semaine en tâche planifiée dans la CI, désactivez les extensions PHP inutilisées et fixez la date de bascule.

Rester quelques semaines en 8.2 en janvier est un risque maîtrisable, à condition que la date de bascule soit fixée et consignée par écrit.

Un plan pour les semaines qui restent

Fin octobre, il reste environ neuf semaines, et pour la plupart des équipes les deux dernières tombent pendant les fêtes. Un plan qui tient dans ce délai : une semaine pour les étapes 1 et 2, une semaine pour choisir la cible et mettre à jour les dépendances, deux à trois semaines pour les modifications de code et les tests, une à deux semaines en préproduction, puis la bascule en production avant la mi-décembre, avec une procédure de retour arrière écrite. Si la liste de l’étape 2 comprend une montée de version du framework, partez du principe que la bascule glissera au premier trimestre et mettez la passerelle en place dès maintenant.

Pour un second regard sur cette liste, envoyez-nous votre composer.lock. Nous vous répondons avec les dates de support de vos versions de PHP et de framework, et le nombre d’avis de sécurité connus et de paquets abandonnés que le fichier fait apparaître, gratuitement et sans accès à votre code. Pour une vue complète, le Debt Check (300 €) ajoute un court questionnaire et vous remet un rapport sous trois jours ouvrés : les risques par ordre de priorité, ce qui bloque le passage à une version supportée, et la démarche que nous recommandons avec des fourchettes de prix. Un Takeover (reprise de l’application) ou une formule Care peuvent souvent être chiffrés à prix ferme directement à partir de ce rapport. Une montée de version reçoit son prix ferme après un Code Audit.

Sources

Vérifiées le 25 octobre 2026.

Un second regard sur votre application ?

Envoyez-nous votre composer.lock. Nous vous répondons avec les dates de support de vos versions de PHP et de framework, et le nombre d’avis de sécurité connus et de paquets abandonnés que le fichier fait apparaître, gratuitement et sans accès à votre code.

Envoyer votre composer.lock Réserver un Debt Check