Fin du support de sécurité de PHP 8.2 le 31/12/2026 : que faire ?

PHP 8.2 cesse de recevoir des correctifs de sécurité le 31 décembre 2026. C’est la date publiée par l’équipe PHP sur sa page des versions supportées. Après cette date, une application qui tourne encore en PHP 8.2 continue de fonctionner, mais toute nouvelle faille dans le moteur PHP restera ouverte pour cette branche. Cet article rassemble le calendrier officiel, les versions à viser, les changements à prévoir et un plan de migration, avec la source de chaque date.

Ce que change le 31 décembre 2026

Chaque branche de PHP passe par trois états, définis sur php.net. En support actif, les bogues et les failles sont corrigés et des versions correctives sortent régulièrement. En correctifs de sécurité uniquement, seules les failles critiques sont corrigées, et les versions ne sortent qu’au besoin. En fin de vie, plus rien n’est publié : php.net recommande alors de mettre à jour au plus vite, car les utilisateurs « peuvent être exposés à des failles de sécurité non corrigées ».

PHP 8.2 est sortie le 8 décembre 2022. Son support actif s’est terminé le 31 décembre 2024 ; elle ne reçoit depuis que des correctifs de sécurité, jusqu’au 31 décembre 2026. Le 1er janvier 2027, elle rejoint la liste des branches non supportées, où figure déjà PHP 8.1 depuis le 31 décembre 2025.

Ce rythme découle d’une règle adoptée par le projet PHP (RFC « Release cycle update ») : chaque branche reçoit deux ans de corrections de bogues puis deux ans de correctifs de sécurité, et les fins de support sont alignées sur le 31 décembre.

Les failles PHP2Shell, rendues publiques le 21 octobre 2026, montrent ce que cette date veut dire : l’équipe PHP a publié des versions corrigées pour les branches 8.2 à 8.5 seulement ; PHP 8.1 et les versions plus anciennes n’en ont reçu aucune. PHP 8.2 a été corrigée cette fois-ci ; une faille publiée après le 31 décembre 2026 ne le sera plus. L’article PHP2Shell : vérifier sa version de PHP, poser la parade, corriger détaille la marche à suivre.

Le calendrier officiel des versions PHP

Dates relevées sur php.net le 17 octobre 2026 et recoupées avec endoflife.date :

Deux lectures utiles. D’abord, PHP 8.3 est elle-même déjà en correctifs de sécurité seulement : une migration vers 8.3 ne repousse l’échéance que d’un an. Ensuite, PHP 8.4 quitte le support actif le même jour que PHP 8.2 quitte le support de sécurité : elle restera maintenue pour la sécurité deux années de plus.

Quelle version viser : 8.3, 8.4 ou 8.5 ?

La bonne cible est la version la plus récente que votre pile accepte entièrement : framework, bibliothèques, extensions et hébergement.

• PHP 8.4 offre des correctifs de sécurité jusqu’au 31 décembre 2028. C’est la cible raisonnable quand une partie des dépendances ne déclare pas encore PHP 8.5.
• PHP 8.5 ajoute un an de support (sécurité jusqu’au 31 décembre 2029). Elle suppose que chaque dépendance déclare la compatibilité ; c’est à vérifier, pas à supposer.
• PHP 8.3 ne se justifie que comme étape intermédiaire, par exemple si une dépendance bloque encore 8.4. Son support de sécurité s’arrête le 31 décembre 2027.

Composer répond à la question pour votre projet : la commande composer prohibits php 8.4 (alias why-not) liste les paquets qui empêchent de passer à cette version, avec la contrainte qui bloque. Répétez-la pour 8.5 avant de choisir.

Ce qui casse entre PHP 8.2 et les versions suivantes

Une montée de version saute rarement une seule marche : passer de 8.2 à 8.4 impose de traiter les changements de 8.3 et de 8.4. Le manuel PHP publie, pour chaque version, la liste des changements incompatibles et des fonctionnalités dépréciées. Quelques exemples tirés de ces guides :

PHP 8.3

• Incrémenter avec ++ une chaîne vide ou non alphanumérique est déprécié ; la fonction str_increment() est la voie prévue.
• Appeler get_class() ou get_parent_class() sans argument est déprécié.

PHP 8.4

• Les paramètres implicitement nullables sont dépréciés : function foo(T $a = null) doit devenir function foo(?T $a = null).
• Le niveau d’erreur E_STRICT est supprimé et sa constante dépréciée.
• exit() et die() se comportent désormais davantage comme des fonctions (coercition de type, respect de strict_types).

PHP 8.5

• L’opérateur « backtick », alias de shell_exec(), est déprécié.
• Les noms de conversion non canoniques (boolean), (integer), (double) et (binary) sont dépréciés au profit de (bool), (int), (float) et (string).
• Terminer un case par un point-virgule au lieu de deux-points est déprécié.

Une dépréciation ne casse rien tout de suite : elle produit un avertissement E_DEPRECATED et annonce une suppression future. Activer ces avertissements en préproduction donne la liste exacte des lignes à corriger.

Symfony et Drupal : les contraintes du framework

Le framework fixe souvent la cible plus sûrement que le calendrier de PHP.

• Symfony : la version 7.4, version à support long, demande PHP 8.2.0 ou plus ; elle reste donc installable aujourd’hui, mais votre PHP ne sera plus maintenu après le 31 décembre 2026. Symfony 8.0 exige PHP 8.4.0 ou plus : monter PHP d’abord ouvre la voie à Symfony 8.
• Drupal : d’après la page des exigences PHP de Drupal, les versions 11.1 à 11.4 ne prennent pas en charge PHP 8.2 ; elles acceptent PHP 8.3 et 8.4, et PHP 8.5 à partir de Drupal 11.3. Un site encore en Drupal 10 sous PHP 8.2 a donc deux chantiers liés : la version de PHP et celle de Drupal.

Un plan de migration en six étapes

1. Inventorier. Relever la version de PHP réellement utilisée partout : serveurs, conteneurs, intégration continue, tâches planifiées. Lister les extensions et les dépendances Composer.
2. Mesurer le blocage. Lancer composer prohibits php 8.4 (puis 8.5) et noter chaque paquet à mettre à jour ou à remplacer.
3. Sécuriser par les tests. Avant de toucher à la version, s’assurer que les parcours critiques sont couverts par des tests automatisés, au moins sur les fonctions qui rapportent ou qui exposent des données.
4. Corriger le code. Lire les guides de migration 8.3, 8.4 et 8.5, activer les avertissements E_DEPRECATED, et s’aider d’outils d’analyse : Rector, par exemple, applique des règles de montée de version jusqu’à la version de PHP déclarée dans composer.json.
5. Essayer en préproduction. Même version de PHP, mêmes extensions, mêmes données de test qu’en production ; vérifier les journaux d’erreurs et les tâches planifiées, pas seulement les pages.
6. Mettre en production avec un retour arrière prévu. Garder l’ancienne image ou l’ancien serveur prêt le temps de valider, et surveiller les journaux dans les jours qui suivent.

Et si la migration n’est pas prête à temps ?

Le 31 décembre 2026 n’éteint pas les serveurs. Mais chaque mois passé sur une branche non maintenue ajoute un risque que vous ne maîtrisez pas : une faille publiée dans le moteur PHP ne recevra plus de correctif officiel pour 8.2. Si l’échéance ne peut pas être tenue, documentez la situation, réduisez l’exposition (accès restreints, surveillance renforcée des journaux) et planifiez la migration avec une date. Vérifiez aussi la politique de votre hébergeur ou de votre distribution, qui peut maintenir ses propres paquets plus longtemps.

Pour les agences qui doivent prévenir plusieurs clients, la page Agences présente le travail en marque blanche. Pour un projet en direct, l’offre de migration décrit le déroulé au forfait, et le Diagnostic 48 h permet de chiffrer le travail avant de s’engager.