Migration PHP 8.4 et 8.5
PHP 8.2 n'aura plus de correctifs de sécurité après le 31 décembre 2026. Il est temps de migrer.
Chaque version de PHP est maintenue quatre ans. Passé ce délai, plus aucune faille n'est corrigée : votre site reste en ligne, mais il devient une cible, et votre hébergeur finira par retirer cette version de son offre.
Les failles critiques corrigées le 21 octobre 2026 l'ont rappelé : les versions 8.1 et antérieures n'ont reçu aucune correction officielle (voir notre article). PHP 8.1 n'est plus maintenu depuis le 31 décembre 2025. PHP 8.2 le rejoint le 31 décembre 2026. Si votre application tourne sur l'une de ces versions, ou plus ancienne encore, N-SENS la migre vers PHP 8.4 ou 8.5, framework et dépendances compris, sans interrompre votre activité.
Où en est votre version de PHP ?
Date de fin des correctifs de sécurité, d'après le calendrier officiel publié sur php.net. Les versions « Maintenu » reçoivent encore des corrections de bugs et de sécurité.
| Version | Fin des correctifs | État |
|---|---|---|
| PHP 7.4 et avant | 28 nov. 2022 | Fin de vie |
| PHP 8.0 | 26 nov. 2023 | Fin de vie |
| PHP 8.1 | 31 déc. 2025 | Fin de vie |
| PHP 8.2 | 31 déc. 2026 | Fin imminente |
| PHP 8.3 | 31 déc. 2027 | Sécurité seule |
| PHP 8.4 | 31 déc. 2028 | Maintenu |
| PHP 8.5 | 31 déc. 2029 | Maintenu |
Pour connaître votre version : votre hébergeur l'indique dans son espace client, ou votre développeur peut lancer php -v sur le serveur.
Pourquoi une migration PHP n'est pas une simple mise à jour
Changer de version de PHP dans l'interface de l'hébergeur prend une minute. Les problèmes commencent juste après : chaque version majeure retire des fonctions, durcit les règles et rend des comportements anciens incompatibles.
- Fonctions supprimées :
mysql_*,each(),create_function()… Une application écrite pour PHP 5 s'arrête net. - Comparaisons modifiées : depuis PHP 8,
0 == "abc"vautfalse. Des conditions qui fonctionnaient « par hasard » changent de résultat sans message d'erreur. - Erreurs plus strictes : les fonctions internes lèvent une exception au lieu d'un simple avertissement quand elles reçoivent un mauvais type.
- Dépréciations en série :
nullpassé aux fonctions internes (8.1), propriétés dynamiques (8.2), types nullables implicites (8.4). Elles remplissent les journaux puis deviennent des erreurs. - Dépendances bloquées : un framework ancien (CakePHP 2 ou 3, Symfony 3, Laravel 5, Zend Framework) ou une bibliothèque abandonnée ne s'installe pas sur une version récente de PHP.
Certaines erreurs sont visibles immédiatement. D'autres, comme les comparaisons modifiées, faussent un calcul ou un filtre sans aucun message : c'est pourquoi une migration se teste avant d'aller en production.
Notre méthode de migration
1. Inventaire
Version de PHP en production, framework, dépendances Composer, extensions, hébergement. Une analyse automatique (PHPStan, PHPCompatibility) liste chaque ligne de code incompatible avec la version cible.
2. Filet de sécurité
Avant de toucher au code : des tests sur les parcours qui comptent (connexion, commande, paiement, exports) et un environnement de recette identique à la production.
3. Corrections et mises à jour
Corrections automatisées avec Rector quand c'est sûr, à la main sinon. Mise à jour du framework et des dépendances, version par version si nécessaire, en séparant toujours la montée de PHP de celle du framework.
4. Mise en production maîtrisée
Bascule de la version de PHP sur le serveur, surveillance des erreurs pendant les jours qui suivent, retour arrière prévu. Puis un contrat de maintenance pour ne plus jamais prendre trois versions de retard.
Et le framework ?
Une migration de PHP entraîne souvent celle du framework : les anciennes versions ne s'installent pas sur PHP 8.4. Nous migrons régulièrement :
- CakePHP 2, 3 et 4 vers CakePHP 5, notre framework historique ;
- Zend Framework vers Laminas ou Symfony ;
- les anciennes versions de Symfony et de Laravel vers leur dernière version maintenue ;
- Drupal 7 vers Drupal 10 ou 11, et Magento 1 vers Magento 2.
Si l'application n'a plus de mainteneur, de documentation ni de tests, notre offre de reprise d'application PHP commence par la remettre sous contrôle.
Questions fréquentes
Que se passe-t-il après le 31 décembre 2026 pour PHP 8.2 ?
Le site continue de fonctionner, mais plus aucune faille découverte dans PHP 8.2 ne sera corrigée. Les hébergeurs retirent ensuite les versions en fin de vie de leurs offres, souvent avec un préavis court, ce qui force une migration dans l'urgence.
Vers quelle version de PHP migrer ?
PHP 8.4 ou PHP 8.5 : ce sont les deux versions maintenues le plus longtemps (jusqu'à fin 2028 et fin 2029). Viser PHP 8.3 ne donne qu'un an de répit.
Combien de temps prend une migration PHP ?
D'une à deux semaines pour une application récente et bien testée, à plusieurs mois pour une application ancienne dont le framework doit aussi changer de version. L'inventaire initial permet de le chiffrer précisément.
Peut-on migrer sans interrompre le site ?
Oui. Le code est rendu compatible avec l'ancienne et la nouvelle version de PHP, testé en recette, puis la version de PHP est changée sur le serveur : la bascule elle-même prend quelques minutes et se défait aussi vite.
Mon application tourne sous CakePHP 2, Zend Framework ou Symfony 3 : est-ce possible ?
Oui, mais il faut d'abord monter le framework de version, car ces versions ne fonctionnent pas officiellement sur PHP 8. C'est le cas de figure le plus fréquent que nous traitons.
Votre application tourne sur PHP 8.2 ou plus ancien ?
Indiquez-nous votre version de PHP et votre framework, ou appelez-nous au +33 (0)1 84 80 48 01 : nous chiffrons la migration.
Faire chiffrer ma migration