Version PHP obsolète : quels risques pour votre application, et que faire
LALucien Arbieu8 min de lecture
En bref
Une version PHP obsolète ne fait pas tomber votre application du jour au lendemain. Elle cesse de recevoir des correctifs de sécurité : chaque faille découverte ensuite reste ouverte.
PHP 8.1 et les versions antérieures ne sont plus corrigées. PHP 8.2 s’arrête le 31 décembre 2026.
Plus d’un site PHP sur trois tourne encore en version 7 ou 5, abandonnées depuis des années (W3Techs, octobre 2026).
La solution est presque toujours une montée de version par paliers, pas une refonte. Plus on attend, plus le chantier grossit.
Votre hébergeur vous a écrit que la version de PHP de votre application « n’est plus supportée ». Ou votre prestataire l’a mentionné en passant, sans proposer de date. Que faut-il en penser ? Le risque est réel, mais il n’est pas immédiat : c’est une dette qui grossit chaque mois. Votre application continue de fonctionner. Ce qui s’arrête, ce sont les correctifs de sécurité publiés par l’équipe de PHP. Toute faille trouvée après la date de fin de support reste exploitable sur votre serveur, indéfiniment.
Cet article explique comment savoir si vous êtes concerné, ce que vous risquez concrètement, et comment planifier la mise à jour sans arrêter votre activité.
Votre application est-elle concernée ?
La version de PHP s’affiche dans l’espace client de la plupart des hébergeurs. Sinon, posez la question à votre prestataire : il doit pouvoir répondre en une phrase. Comparez ensuite avec le calendrier officiel.
La version de PHP ne suffit pas. Si votre application est construite avec un framework, il a son propre calendrier. Pour Laravel, le plus répandu en France :
Le croisement des deux tableaux explique pourquoi la mise à jour est rarement un simple réglage : une application en Laravel 10 ne peut pas passer en PHP 8.4 sans d’abord changer de version de Laravel.
Ce que vous risquez concrètement
Le risque technique se traduit en quatre risques business.
Une faille connue, publiée, jamais corrigée
Quand une faille est découverte dans une version abandonnée, elle est documentée publiquement, mais aucun correctif n’est publié pour cette version. Les robots qui scannent le web à la recherche de serveurs vulnérables n’ont pas besoin de vous cibler : ils testent tout le monde. Si des données personnelles fuitent, le RGPD vous impose de notifier la CNIL dans les 72 heures (CNIL), et vos clients l’apprendront.
Une mise à jour imposée au mauvais moment
Les hébergeurs finissent par retirer les versions anciennes de leurs serveurs, ou par facturer leur maintien. Si votre application n’est pas prête, elle peut cesser de fonctionner le jour de la bascule, sans que vous ayez choisi la date.
Des briques qui ne s’installent plus
Les bibliothèques externes utilisées par votre application abandonnent progressivement les anciennes versions de PHP. Ajouter une fonctionnalité, brancher un nouveau moyen de paiement ou mettre à jour une connexion à un service tiers devient impossible sans tout mettre à jour d’un coup.
Un grand compte qui pose la question
Les questionnaires de sécurité des grands clients et des assureurs cyber demandent de plus en plus souvent si vos logiciels sont maintenus. Répondre « PHP 7.4 » à cette question peut suffire à perdre un contrat. C’est souvent ce moment-là, et non une attaque, qui déclenche la mise à jour.
Outil gratuit
Assistant de cadrage de projet
Clarifiez votre besoin et conservez une première note structurée.
Une montée de version se fait par paliers. Passer de PHP 8.2 à 8.3 est un chantier court. Passer de PHP 7.4 à 8.4, c’est traverser cinq versions, chacune avec ses changements de comportement, et souvent changer de framework en même temps. Le coût ne s’additionne pas : il se multiplie, parce que chaque palier oblige à tester toute l’application.
C’est la logique d’un bâtiment. Refaire l’étanchéité d’une toiture tous les quinze ans coûte peu. Attendre que l’eau soit dans les murs oblige à reprendre la charpente.
Que faire : la méthode en cinq étapes
Faire l’inventaire. Version de PHP, version du framework, liste des bibliothèques et de leur compatibilité. Cette étape suffit souvent à chiffrer le chantier.
Créer un environnement de test identique à la production, sur lequel on fait la montée de version sans toucher à l’application utilisée par vos clients.
Sécuriser les parcours critiques par des tests : connexion, commande, paiement, facturation. S’ils n’existent pas, on les écrit avant de toucher à quoi que ce soit.
Monter par paliers : une version de framework, puis une version de PHP, en vérifiant les parcours critiques à chaque étape.
Mettre en production avec un plan de retour arrière : si un problème apparaît, on revient à la version précédente en quelques minutes, pendant qu’on corrige.
Pour une application Laravel récente et testée, ce chantier se compte en jours. Pour une application ancienne sans tests, sur PHP 7, il se compte en semaines. Dans les deux cas, votre application reste en ligne pendant les travaux.
Mettre à jour ou refaire ?
Mettre à jour, dans la grande majorité des cas. Une application dont la logique métier est juste garde sa valeur, même si son code a vieilli. La refonte ne se justifie que dans des situations précises : code écrit sans framework et impossible à tester, version PHP 5, ou besoin métier qui a tellement changé que l’application ne correspond plus à votre activité.
Si un prestataire vous propose de tout refaire uniquement parce que la version de PHP est ancienne, demandez-lui de chiffrer aussi la montée de version. L’écart entre les deux devis vous dira beaucoup.
Vos questions sur les versions de PHP
Comment savoir quelle version de PHP utilise mon application ?
La version s’affiche généralement dans l’espace client de votre hébergeur, rubrique configuration ou PHP. Votre prestataire peut aussi vous la donner immédiatement. Demandez en même temps la version du framework utilisé, comme Laravel ou Symfony, car elle a son propre calendrier de support.
Que se passe-t-il quand une version de PHP n’est plus supportée ?
L’application continue de fonctionner, mais l’équipe de PHP ne publie plus de correctifs de sécurité pour cette version. Les failles découvertes ensuite restent exploitables. Avec le temps, les hébergeurs retirent la version et les bibliothèques externes cessent d’être compatibles, ce qui bloque les évolutions.
Quand PHP 8.2 arrive-t-il en fin de support ?
PHP 8.2 reçoit des correctifs de sécurité jusqu’au 31 décembre 2026. PHP 8.1 et les versions antérieures ne sont déjà plus corrigées. PHP 8.3 est couvert jusqu’au 31 décembre 2027, PHP 8.4 jusqu’au 31 décembre 2028 et PHP 8.5 jusqu’au 31 décembre 2029.
Combien de temps prend une montée de version PHP ?
Pour une application Laravel récente avec des tests, quelques jours. Pour une application ancienne, sans tests, qui doit traverser plusieurs versions de PHP et de framework, plusieurs semaines. L’inventaire initial permet de chiffrer le chantier avant de s’engager.
Mon application va-t-elle s’arrêter pendant la mise à jour ?
Non, si la méthode est la bonne. La montée de version se prépare sur un environnement de test distinct, et la mise en production se fait avec un plan de retour arrière. Vos clients continuent d’utiliser l’application pendant toute la durée des travaux.
Comment PeakLab gère une montée de version PHP
En tant qu’agence de développement Laravel, nous menons ces montées de version selon la méthode ci-dessus : inventaire, environnement de test avec vos données, tests des parcours critiques, puis paliers successifs. Vous suivez l’avancement sur l’environnement de test, avec un point chaque semaine ou toutes les deux semaines, et vous validez avant chaque mise en production.
Pour une application PHP sans framework ou sur un framework abandonné, notre approche d’agence web PHP commence par un audit qui compare honnêtement le coût d’une modernisation et celui d’une reconstruction. Le code reste à votre nom, documenté, et chaque livraison est couverte par une garantie de 30 jours. Si votre application a été construite par un prestataire qui ne répond plus, voyez notre accompagnement en reprise de code et migration de systèmes.
