D’après php.net, PHP 8.2 reçoit ses derniers correctifs de sécurité jusqu’au 31 décembre 2026. Après cette date, une faille découverte dans PHP 8.2 n’est plus corrigée par le projet PHP. Les branches 8.3 (jusqu’au 31 décembre 2027) et 8.4 (jusqu’au 31 décembre 2028) sont les cibles de migration les plus courantes ; PHP 8.1 et les versions antérieures sont déjà en fin de vie.
§ 01 / Calendrier
Dans le calendrier de php.net, chaque branche récente a environ deux ans de support actif (corrections de bogues et de sécurité), puis deux ans de correctifs de sécurité seulement. Ensuite, elle est en fin de vie.
| Version | Sortie | Support actif jusqu’au | Sécurité jusqu’au | Statut |
|---|---|---|---|---|
| PHP 8.5 | 20/11/2025 | 31/12/2027 | 31/12/2029 | Maintenue |
| PHP 8.4 | 21/11/2024 | 31/12/2026 | 31/12/2028 | Cible |
| PHP 8.3 | 23/11/2023 | 31/12/2025 | 31/12/2027 | Cible |
| PHP 8.2 | 08/12/2022 | 31/12/2024 | 31/12/2026 | À migrer |
| Version | Fin de vie | Dernière version publiée |
|---|---|---|
| PHP 8.1 | 31/12/2025 | 8.1.34 |
| PHP 8.0 | 26/11/2023 | 8.0.30 |
| PHP 7.4 | 28/11/2022 | 7.4.33 |
| PHP 5.6 | 31/12/2018 | 5.6.40 |
Sources : php.net, versions maintenues et branches en fin de vie, consultées le 22/10/2026.
§ 02 / Pourquoi migrer
php.net prévient que les utilisateurs d’une branche en fin de vie peuvent être exposés à des failles qui ne seront pas corrigées. Le site continue de tourner, mais chaque nouvelle faille reste ouverte.
En octobre 2026, la faille PHP2Shell a été corrigée pour PHP 8.2 à 8.5 seulement. Les sites en PHP 8.1 ou plus ancien n’ont eu ni version corrigée ni délai : filtrage d’urgence, puis migration contrainte.
Les frameworks relèvent leur version minimale de PHP : Symfony 7.4 demande PHP 8.2, Symfony 8 demande PHP 8.4. Rester sur une ancienne version de PHP bloque aussi les mises à jour de sécurité des bibliothèques.
Migrer avant l’échéance, c’est choisir la date, tester sans pression et garder l’ancienne version prête. Migrer après une alerte, c’est le faire dans l’urgence.
§ 03 / Choisir la cible
Il n’y a pas de bonne réponse unique : la cible dépend de vos dépendances, de votre hébergement et de l’horizon que vous visez. Les deux sont maintenues ; voici ce qui les distingue.
Sécurité jusqu’au 31/12/2027
Sécurité jusqu’au 31/12/2028
§ 04 / Méthode
Cinq étapes, les mêmes pour une application ou pour un parc. Rien ne part en production sans votre accord.
Version de PHP servie, extensions chargées, dépendances Composer et leurs contraintes, tâches planifiées (qui utilisent le PHP de la ligne de commande), environnements disponibles, hébergement.
Deux environnements identiques, l’un sur la version actuelle, l’autre sur la cible, avec les mêmes données. Les journaux de dépréciations sont activés sur les deux.
Les parcours critiques sont rejoués des deux côtés : connexion, formulaires, envois de fichiers, paiements, exports, tâches planifiées. Chaque écart est relevé, corrigé, puis vérifié.
Vous validez le banc, puis la date. La bascule se fait au moment choisi, lot par lot pour un parc, et le code reste sur votre Git.
L’ancienne version de PHP et l’ancien code restent prêts à être remis en service. La procédure de retour est écrite avant la bascule, pas après un incident.
§ 05 / Vigilance
Ce qui casse le plus souvent lors d’une montée de version de PHP, et comment le repérer avant la mise en production.
PHP 8.4 ne livre plus IMAP, OCI8, PDO_OCI et PSpell : ces extensions passent sur PECL. Comparez la liste des modules chargés entre l’ancienne et la nouvelle version, pour la ligne de commande et pour FPM.
php -m
php-fpm8.4 -m
Chaque version déprécie des usages qui disparaîtront plus tard. En 8.3 : incrémenter une chaîne vide ou non numérique, appeler get_class() sans argument. En 8.4 : les paramètres implicitement nullables, trigger_error() avec E_USER_ERROR. Les journaux du banc les révèlent avant qu’ils ne deviennent des erreurs.
Une bibliothèque qui plafonne sa version de PHP bloque la migration. Composer indique quels paquets empêchent la cible et si la plateforme satisfait toutes les contraintes.
composer why-not php 8.4
composer check-platform-reqs
La version du framework fixe la version minimale de PHP : Symfony 6.4 demande PHP 8.1, Symfony 7.4 PHP 8.2, Symfony 8 PHP 8.4. Une application Symfony ou Drupal ancienne se migre souvent en même temps que PHP.
Chaque PHP a sa configuration : celle de la ligne de commande n’est pas celle de FPM. Les tâches planifiées et les scripts de déploiement appellent souvent un « php » qui n’est pas celui du site : ils doivent changer de version en même temps.
Guides officiels : php.net, migrer vers PHP 8.3 et vers PHP 8.4 (liens dans les sources).
§ 06 / Offre
L’offre Migration PHP, Symfony, Drupal couvre PHP 8.2 → 8.3 ou 8.4, Symfony 6.4 → 7.4 LTS ou 8.x et Drupal 10 → 11, avec banc de test avant/après et retour arrière prévu. Périmètre, prix et livrable sont écrits avant de commencer.
§ 07 / Questions
Le site continue de fonctionner, mais le projet PHP ne publie plus aucun correctif de sécurité pour la branche 8.2. Toute faille découverte ensuite reste ouverte, comme ce fut le cas pour PHP 8.1 et les versions antérieures avec PHP2Shell en octobre 2026.
Oui, mais en traitant les changements de chaque version intermédiaire (8.0, 8.1, 8.2, 8.3 puis 8.4), documentés dans les guides de migration de php.net. Le framework doit souvent suivre : Symfony 8 demande PHP 8.4. Selon l’inventaire, la migration se fait en une bascule ou par marches successives, chacune validée sur le banc.
C’est possible et c’est la branche maintenue le plus longtemps (sécurité jusqu’au 31 décembre 2029), à condition que toutes vos dépendances, extensions et votre hébergement la supportent. Quand ce n’est pas encore le cas, PHP 8.4 ou 8.3 donnent une version maintenue sans attendre.
La plupart, oui. PHP 8.4 ne livre plus quatre extensions dans sa distribution : IMAP, OCI8, PDO_OCI et PSpell, désormais publiées sur PECL. Si votre application les utilise, il faut les installer depuis PECL ou les remplacer ; l’inventaire le repère avant la migration.
D’après symfony.com : PHP 8.1 minimum pour Symfony 6.4, PHP 8.2 minimum pour Symfony 7.4 LTS et PHP 8.4 minimum pour Symfony 8.x. Une application Symfony ancienne bloque souvent la montée de version de PHP : nous traitons alors les deux ensemble, marche par marche.
Le travail se fait sur un banc à part, sans toucher à la production. La bascule a lieu au moment que vous choisissez, et l’ancienne version reste prête à être remise en service si un problème apparaît.
L’adresse du site ou le nom de l’application, sa version de PHP et de framework, l’hébergement (serveur dédié, mutualisé, conteneurs) et ce qui presse. Nous revenons vers vous par écrit avec un premier avis ; le périmètre, le prix et le livrable sont écrits avant de commencer.
§ 08 / Sources
Sources consultées le 22/10/2026 ; cette page est mise à jour quand le calendrier de php.net évolue.
Dites-nous quelle application est concernée, sa version de PHP et de framework, et où elle est hébergée. Nous revenons vers vous par écrit avec un premier avis et la suite possible.
Avec votre accord, nous mesurons l’audience du site avec Google Analytics, de façon anonymisée. Les données sont transmises à Google, y compris hors de l’Union européenne. En savoir plus
