Est-il dangereux de garder une application en PHP 7 ?

Oui, pour une application exposée sur internet. Toute la branche PHP 7 est en fin de vie depuis le 28 novembre 2022 selon php.net : les failles découvertes depuis n'y sont plus corrigées par le projet PHP. Le risque augmente avec les dépendances, elles aussi figées, et avec les hébergeurs qui retirent peu à peu les versions anciennes.

Passer de PHP 5 à PHP 8 suffit-il à moderniser une application ?

Non. La montée de version supprime le risque de sécurité lié au langage et rend l'application à nouveau hébergeable, mais elle laisse intacts le code mal organisé, l'absence de tests et les écrans datés. C'est une étape indispensable et souvent la première, pas une modernisation complète. Elle se fait plus sûrement version par version, avec des tests.

Faut-il réécrire une vieille application PHP dans un autre langage ?

Rarement par principe. PHP moderne, avec un framework maintenu comme Symfony ou Laravel, convient très bien à une application métier, et le recrutement reste facile. Changer de langage se justifie quand l'application doit de toute façon être réécrite et que l'équipe qui la maintiendra maîtrise mieux une autre technologie.

Combien de temps prend la modernisation d’une application PHP ?

Une montée de version sur une application de taille moyenne, outillée et testée, se compte en semaines. Un refactoring progressif vers un framework moderne ou une réécriture module par module s'étale sur plusieurs mois, avec des livraisons régulières. Le délai dépend surtout de la taille du code, de la présence de tests et du nombre de dépendances abandonnées.

Notre développeur PHP est parti, peut-on quand même moderniser ?

Oui, à condition de récupérer le code source complet, la base de données, les accès d'hébergement et toute documentation existante. Un audit permet ensuite de mesurer l'état du code et des dépendances. Le départ du développeur est souvent le bon moment pour décider, parce que la personne qui reprend devra de toute façon comprendre l'application.

MaintenanceMéthodeApplication métierBudget

Moderniser une application PHP vieillissante : montée de version, refactoring ou réécriture

Publié le 7 novembre 202611 min de lecture

Pour moderniser une application PHP vieillissante, commencez par la remettre sur une version de PHP encore maintenue, puis décidez entre trois voies : la garder telle quelle une fois à jour, la restructurer progressivement dans un framework moderne, ou la réécrire module par module. La réécriture complète d'un coup est presque toujours la plus risquée. Le bon choix dépend de la valeur du code existant, de la présence de tests et des évolutions attendues, pas de l'âge de l'application.

Les pages sur le sujet sont souvent écrites pour des développeurs (quelle fonction a changé entre deux versions) ou par des agences qui vendent une refonte. Celle-ci s'adresse au dirigeant qui finance l'application, qui entend « on ne peut plus y toucher » et qui doit décider quoi faire.

Pourquoi tant d'applications PHP vieillissent mal

PHP fait tourner une grande partie du web : selon W3Techs (relevé du 6 novembre 2026), il équipe 69,1 % des sites dont le langage serveur est connu. Parmi eux, 26,1 % tournent encore en PHP 7 et 7,6 % en PHP 5, deux branches que le projet PHP ne maintient plus.

Les applications métier en PHP ont souvent la même histoire : écrites il y a dix ou quinze ans, parfois par un seul développeur, sans framework ou avec un framework aujourd'hui abandonné, puis enrichies année après année. Elles marchent, elles portent l'activité, et plus personne n'ose les modifier.

Les signaux d'alerte

La version de PHP n'est plus maintenue. Selon le calendrier officiel de php.net, seules les branches 8.2 à 8.5 reçoivent encore des correctifs de sécurité en novembre 2026, et la 8.2 n'en recevra plus après le 31 décembre 2026. La page des versions en fin de vie date la fin de PHP 5.6 au 31 décembre 2018, de PHP 7.4 au 28 novembre 2022 et de PHP 8.1 au 31 décembre 2025.
L'hébergeur prévient qu'il retire votre version. C'est souvent le déclencheur réel, avec une date imposée.
Les bibliothèques sont figées. Le gestionnaire de dépendances refuse les mises à jour, ou il n'y en a pas : le code a été copié à la main dans le projet.
Chaque correction en casse une autre. Il n'existe aucun test automatique, et la recette se fait en production.
Une seule personne comprend le code, ou plus personne.

Ces signaux sont la traduction concrète de la dette technique, expliquée sans jargon dans la dette technique pour un dirigeant.

Les quatre options

Option	Ce qu'on fait	Pour quel cas	Risque principal
Montée de version	Passer à un PHP maintenu sans changer l'architecture	Code correct, besoin surtout de sécurité	Laisser la dette fonctionnelle intacte
Refactoring progressif	Restructurer le code par petites étapes, souvent vers un framework	Logique métier précieuse, code désorganisé	Projet long sans fin visible
Réécriture module par module	Remplacer l'application morceau par morceau, l'ancienne tournant	Écrans et architecture à refaire, activité à préserver	Période de cohabitation à gérer
Remplacement	Passer à un logiciel du marché	Besoin devenu standard	Perdre ce qui vous différenciait

La montée de version

C'est la première étape dans presque tous les cas, parce qu'elle supprime le risque le plus urgent. Elle se fait de préférence version par version, en lisant les guides de migration publiés par php.net pour chaque branche, et avec l'aide d'outils : Rector réécrit automatiquement une partie du code pour une nouvelle version, et PHPStan repère par analyse statique les erreurs que la montée provoquera. Ces outils accélèrent le travail, ils ne remplacent ni les tests ni la relecture.

Le refactoring progressif

On garde l'application en service et on la restructure par petites étapes : sortir la logique métier des pages, isoler l'accès à la base, introduire un framework maintenu (Symfony et Laravel sont les plus répandus) d'abord pour les nouvelles fonctions, puis pour les anciennes. Cette voie préserve des années de règles métier éprouvées. Elle exige une discipline : chaque étape livrée, testée, et un objectif final daté.

La réécriture module par module

Quand l'architecture et les écrans sont à refaire, on remplace l'application morceau par morceau : un nouveau module prend en charge une fonction, l'ancienne application continue de servir le reste, et on recommence jusqu'à ce qu'il ne reste plus rien de l'ancien. C'est la méthode dite de l'étrangleur, détaillée dans la refonte d'une application métier par étapes. Elle évite le « grand soir » où tout bascule d'un coup.

Le remplacement

Si votre besoin est devenu standard (facturation simple, gestion de contacts, prise de rendez-vous), un logiciel du marché peut faire mieux qu'une application maison à maintenir. Le raisonnement est le même que dans logiciel sur mesure ou progiciel.

Ce qu'une montée de version casse le plus souvent

Sans entrer dans le détail technique, voici ce qui demande du travail quand une vieille application change de version de PHP, et que votre prestataire devrait mentionner dans son estimation :

les fonctions retirées du langage, notamment l'ancienne extension d'accès à MySQL, très présente dans le code des années 2000, qu'il faut remplacer partout ;
un langage devenu plus strict : des erreurs autrefois ignorées arrêtent désormais l'exécution, et c'est souvent là que se cachent des bugs anciens ;
les bibliothèques sans version compatible, à remplacer par un équivalent maintenu, avec parfois un effet sur le comportement ;
les accents et caractères spéciaux, quand l'application et la base n'utilisaient pas le même encodage ;
l'environnement : version du serveur web, du moteur de base de données, des tâches planifiées, qui doivent souvent bouger en même temps.

Un devis qui ne parle d'aucun de ces points sous-estime probablement le chantier.

Quand ne pas moderniser

Toutes les applications ne méritent pas un chantier. Si l'outil sert à une poignée de personnes en interne, sans accès depuis internet, et qu'il doit être remplacé dans l'année par un logiciel du marché, une sécurisation minimale et un plan de sortie suffisent. De même, une application dont plus personne ne se sert vraiment peut simplement être archivée : ses données exportées, le serveur éteint.

Comment choisir : cinq questions

La logique métier est-elle juste ? Si les calculs, les règles et les cas particuliers sont fiables, ils valent de l'or : préférez la montée de version ou le refactoring.
Existe-t-il des tests ? Sans tests, toute modification est un pari. Écrire d'abord des tests qui figent le comportement actuel est souvent le meilleur premier investissement.
Les écrans conviennent-ils encore ? Une application qui ne s'utilise pas sur mobile, ou que les nouveaux salariés trouvent incompréhensible, appelle une réécriture des écrans au moins.
Quelles évolutions sont prévues ? Ouvrir un portail client, connecter un ERP, ajouter une API : plus la liste est longue, plus une architecture moderne se rentabilise.
Qui maintiendra l'application ensuite ? La technologie retenue doit être maîtrisée par la personne ou l'équipe qui en aura la charge.

Un audit de l'application existante répond aux trois premières questions en quelques jours, avant tout engagement.

Ce qui fait le coût

Le prix d'une modernisation PHP dépend moins de la technologie que de quatre facteurs : la taille du code, l'absence de tests, le nombre de dépendances abandonnées à remplacer, et l'écart entre la version actuelle et la cible. Une application en PHP 5 sans framework coûte plus cher à remettre à niveau qu'une application en PHP 7.4 sur un framework encore suivi. Pour les postes de coût propres à une refonte et la façon de lire un devis, voyez le prix de la refonte d'un logiciel métier.

Le choix du mode de contrat compte aussi : une montée de version bien cadrée se prête au forfait, un refactoring long gagne à être découpé en étapes chiffrées une à une. Le sujet est traité dans forfait ou régie.

Les erreurs les plus fréquentes

Repartir de zéro d'un coup. La réécriture complète en parallèle de l'existant oublie toujours des règles que seul l'ancien code connaissait, et l'activité attend pendant des mois.
Sauter plusieurs versions sans filet. Passer de PHP 5 à PHP 8 en une fois, sans tests, multiplie les erreurs silencieuses.
Moderniser le code sans toucher à l'hébergement. Un serveur lui-même en fin de vie annule le bénéfice ; c'est souvent le moment de migrer l'application vers le cloud.
Oublier la base de données. Encodage des caractères, version du moteur, requêtes écrites à la main : la base vieillit avec le code.
Ne rien documenter. Chaque règle redécouverte pendant la modernisation doit être écrite, sinon la dette se reforme.

La sécurité pendant la transition

Tant que l'application tourne sur une version non maintenue, réduisez l'exposition : accès limité aux utilisateurs qui en ont besoin, authentification renforcée, sauvegardes testées, journal des connexions. Ce ne sont pas des solutions durables, mais elles réduisent le risque pendant les semaines ou les mois de travail. Les bases sont rappelées dans la sécurité d'une application métier. Et si l'application a été abandonnée par son prestataire, commencez par récupérer le code et les accès, comme l'explique reprendre un projet logiciel abandonné.

Par où commencer

Relevez la version de PHP et celle du framework, s'il y en a un. Votre hébergeur ou votre développeur vous la donne en une minute.
Récupérez le code source complet, la base de données et les accès. Les droits sur ce code sont définis au cas par cas dans le contrat d'origine : vérifiez-le.
Faites auditer l'état du code, des dépendances et des tests.
Traitez d'abord la sécurité par une montée de version.
Décidez ensuite de la suite, et si les écrans doivent changer, voyez-les avant de payer : nous construisons un prototype visuel gratuit de la future application, présenté en visio sous 5 jours ouvrés, comme l'explique voir son logiciel avant de le payer.