JB ServicesJulien Berton

PHP 8.2 en fin de support le 31 décembre 2026 : inventorier, choisir, migrer

Par Julien Berton, architecte IT · Publié le · 7 min de lecture

Le 31 décembre 2026, la branche 8.2 de PHP cessera de recevoir des correctifs de sécurité de la part du projet PHP. Après cette date, une nouvelle faille découverte dans PHP ne sera plus corrigée sur 8.2 par php.net. Il reste un peu plus de deux mois, et beaucoup de serveurs tournent encore en PHP 8.2, à commencer par ceux sous Debian 12, qui le fournit dans ses dépôts.

Les failles « php2shell » corrigées en urgence le 21 octobre ont rappelé à quel point PHP est présent partout, y compris dans des outils internes qu’on oublie. J’ai décrit dans un article précédent la méthode pour corriger une faille sans casser la production. Ici, la question est différente : que faire des instances qui vont sortir du support, et dans quel ordre.

Le calendrier de PHP

Depuis la révision du cycle de vie adoptée en 2024, chaque branche de PHP bénéficie de deux ans de support actif (corrections de bugs et de sécurité), puis de deux ans de correctifs de sécurité uniquement. La fin de support tombe toujours un 31 décembre. Pour les branches récentes, cela donne :

  • PHP 8.1 : fin de support le 31 décembre 2025, déjà dépassée ;
  • PHP 8.2 : correctifs de sécurité jusqu’au 31 décembre 2026 ;
  • PHP 8.3 : correctifs de sécurité jusqu’au 31 décembre 2027 ;
  • PHP 8.4 : jusqu’au 31 décembre 2028 ;
  • PHP 8.5 : jusqu’au 31 décembre 2029.

La page des versions supportées de php.net fait foi et mérite d’être consultée avant toute décision, car c’est elle qui indique l’état réel de chaque branche.

Debian 12 : un cas à part

Debian 12 « Bookworm » fournit PHP 8.2 dans ses dépôts. Une fin de support côté php.net ne signifie pas pour autant que ces serveurs deviennent vulnérables le 1er janvier. Debian a transféré en juillet 2026 le suivi de sécurité de Bookworm à son équipe LTS, qui l’assure jusqu’au 30 juin 2028. Pendant cette période, les correctifs sont rétroportés par Debian sur son paquet php8.2 et publiés sous forme d’avis DLA.

Trois réserves, que je vérifie systématiquement :

  • La couverture LTS n’est pas totale : elle ne porte pas sur toutes les architectures ni sur tous les paquets. Le paquet debian-security-support et sa commande check-support-status listent les paquets installés dont le suivi est limité ou arrêté.
  • Le PHP installé ne vient pas toujours de Debian : un dépôt tiers, une compilation maison ou une image de conteneur suivent leur propre politique. Un conteneur construit sur une image PHP 8.2 ne recevra plus de nouvelle version de PHP une fois la branche arrêtée.
  • Les applications avancent plus vite que la distribution : un CMS, un framework ou un outil métier peut abandonner PHP 8.2 dans une prochaine version. Rester sur la version de la distribution oblige alors à figer l’application, ce qui déplace le problème.

Debian 13 « Trixie » fournit PHP 8.4. Une montée de version de Debian 12 vers Debian 13 fait donc passer PHP de 8.2 à 8.4 d’un seul coup, en sautant une branche. C’est souvent le chemin le plus simple, à condition de traiter les changements des deux versions intermédiaires.

Étape 1 : inventorier les instances et leur origine

L’inventaire fait pour une correction d’urgence sert de base, mais il faut ajouter une information : d’où vient chaque PHP. Pour chaque instance, je relève :

  • la machine, son système et sa version ;
  • l’origine de PHP : paquet de la distribution, dépôt tiers, compilation, conteneur, hébergeur ;
  • les versions de la CLI et de chaque pool PHP-FPM, qui peuvent différer ;
  • les applications servies et les versions de PHP qu’elles supportent d’après leur éditeur ;
  • l’exposition : accessible depuis Internet, depuis le réseau interne, ou depuis un réseau d’administration seulement.

Les outils d’exploitation font partie de la liste : frontend de supervision, interface de gestion de bases de données, intranet, outils de ticketing. Ce sont souvent eux qui tournent sur la version la plus ancienne.

Étape 2 : classer chaque instance

L’origine de PHP détermine l’urgence. Je range les instances en trois groupes :

  1. Paquet d’une distribution encore suivie : les correctifs continuent d’arriver par la distribution. La migration se planifie avec la montée de version du système, sans précipitation mais avec une date.
  2. PHP 8.2 hors distribution (dépôt tiers, conteneur, compilation, hébergement mutualisé) : plus aucun correctif après le 31 décembre, sauf si le fournisseur s’engage par écrit. Ces instances passent en priorité.
  3. Application bloquée sur PHP 8.2 par son éditeur : en attendant une version compatible, l’instance est isolée. Accès restreint aux seuls utilisateurs qui en ont besoin, segment réseau dédié, reverse proxy filtrant, pas d’exposition directe sur Internet. C’est là que la segmentation réseau rend service.

Étape 3 : choisir la version cible

La cible se choisit d’abord en fonction de ce que supporte l’application, ensuite en fonction de la durée de support restante. PHP 8.3 sort du support fin 2027 : y migrer aujourd’hui revient à refaire le chantier dans un an. PHP 8.4 a l’avantage d’être la version de Debian 13 et reste supporté par php.net jusqu’à fin 2028. PHP 8.5 offre l’horizon le plus long, si l’application et ses extensions le supportent déjà.

Le manuel PHP publie un guide de migration pour chaque version, avec la liste des incompatibilités et des fonctionnalités dépréciées. Pour passer de 8.2 à 8.4, il faut lire les deux guides : celui de 8.3 et celui de 8.4.

Étape 4 : migrer sans régression

Une montée de branche de PHP change davantage de choses qu’un correctif de sécurité. Je procède comme pour toute migration d’infrastructure, avec un retour arrière possible à chaque étape :

  1. Environnement de test : clone de la machine virtuelle de production. Sous Proxmox VE comme sous VMware, un clone ou un instantané se fait en quelques minutes.
  2. Journalisation complète : en test, toutes les erreurs et tous les avertissements de dépréciation sont journalisés, pour voir ce que l’application déclenche avec la nouvelle version.
  3. Extensions : chaque extension compilée à part ou installée hors distribution doit exister pour la nouvelle branche. C’est un point de blocage fréquent.
  4. Configuration : php.ini, pools PHP-FPM et cache d’opcodes sont propres à chaque version ; les réglages de durcissement, dont expose_php = Off, doivent être reportés.
  5. Recette : parcours fonctionnels écrits à l’avance, tâches planifiées, appels d’API, puis lecture des journaux.
  6. Bascule : par lots, avec un point de retour arrière conservé jusqu’à validation, et un suivi dans la supervision pendant les jours qui suivent.

D’ici au 31 décembre

Le délai est court, et la fin d’année est rarement la période la plus calme. Un calendrier réaliste consiste à finir l’inventaire et le classement en novembre, à traiter en priorité les instances du deuxième groupe, et à poser une date pour celles qui dépendent de la distribution. Pour les applications bloquées, l’isolement doit être en place avant le 1er janvier, avec une échéance demandée à l’éditeur.

La même logique vaut pour tous les composants logiciels : connaître les dates de fin de support et les inscrire dans le plan de charge, comme pour la fin de support de vSphere 8. Un audit d’infrastructure permet de dresser cet inventaire et de prioriser ; je peux aussi conduire la migration avec votre équipe en intégration en régie.

Des serveurs encore en PHP 8.2 ? J’interviens sur l’inventaire, le choix de la version cible, la migration sans interruption et le durcissement des serveurs web. Voir l’offre cybersécurité & Zero Trust.

À lire aussi

Sources

L’auteur

Julien Berton, architecte IT et formateur freelance. Il conçoit, exploite et sécurise des infrastructures Debian, Cisco, VMware et Proxmox, et mène des migrations avec un retour arrière possible à chaque étape.

Parler de mes serveurs