Depuis la faille PHP2Shell d’octobre 2026, beaucoup de dirigeants ont reçu le même conseil de leur hébergeur : « il faut passer à PHP 8 ». Dit comme ça, on imagine une mise à jour de plus, comme celle de son téléphone. Pour une application construite à l’époque de PHP 7, c’est rarement aussi simple. Ce qui pose problème, c’est moins la version de PHP que la façon dont votre programme a été construit. Et c’est souvent elle qu’il faut revoir.
Le jour où la mise à jour casse le site
Le scénario est classique. L’hébergeur annonce qu’il passe ses serveurs en PHP 8. Le lundi matin, le site affiche une page blanche. Ou pire : la vitrine s’affiche normalement, mais le paiement échoue sans message d’erreur, et personne ne s’en aperçoit avant les premiers appels de clients.
Le prestataire remet l’ancienne version en urgence et tout repart. Sauf que l’ancienne version, c’est justement celle qui ne reçoit plus de correctifs de sécurité. Retour à la case départ, avec une mauvaise nouvelle en prime : on sait maintenant que le site ne supporte pas le changement.
PHP 8 tolère beaucoup moins d’approximations
Pensez à l’électricité d’une maison des années 1990. Elle fonctionne, les lampes s’allument. Mais le jour où vous rénovez, l’électricien vous explique qu’elle ne passe plus les normes et qu’il faut refaire une partie du tableau. Le passage de PHP 7 à PHP 8 ressemble beaucoup à ça.
PHP 7 laissait passer de petites erreurs dans le code. Il affichait un avertissement dans un fichier que personne ne lisait, puis continuait. PHP 8, lui, s’arrête net sur bon nombre de ces erreurs. Un code qui « marchait quand même » depuis dix ans se met à planter.
Il y a plus sournois. Certains calculs donnent un autre résultat sans prévenir. Un exemple réel : PHP 7 considérait qu’un mot comme « abc » était égal au chiffre zéro, PHP 8 non. Si un test de stock ou de code promo reposait sur cette bizarrerie, il change de comportement sans le moindre message d’erreur.
Enfin, certaines instructions ont tout simplement disparu de PHP 8, et chaque nouvelle version (8.2, 8.4, 8.5) en a marqué d’autres comme vouées à disparaître. Avant de changer de serveur, une application écrite pour PHP 7 doit donc être relue en détail.
Le piège du framework : la charpente vieillit avec le reste
La plupart des applications ne sont pas écrites à partir de rien. Elles reposent sur un framework ou un CMS (Laravel, Symfony, MODX, Zend…), une sorte de charpente prête à l’emploi sur laquelle le développeur a monté vos fonctionnalités. Chaque version de cette charpente ne fonctionne qu’avec certaines versions de PHP. Changer PHP oblige donc à changer de charpente, et c’est là que le chantier grossit.
Laravel
Les versions récentes exigent un PHP récent : Laravel 13, sorti en mars 2026, demande au minimum PHP 8.3. Une application restée en Laravel 5 ou 6 doit donc franchir sept ou huit versions majeures, chacune avec ses changements. Même un projet en Laravel 11 n’est déjà plus couvert : son support de sécurité s’est arrêté le 12 mars 2026.
MODX
Pour profiter d’un PHP récent, il faut passer de MODX 2 à MODX 3, et cette mise à jour casse la compatibilité sur plusieurs points. Le support officiel de MODX le reconnaît : certaines extensions n’ont jamais été adaptées, en particulier celles qui ne gèrent pas PHP 8. Les utilisateurs signalent d’ailleurs régulièrement des sites qui plantent après la mise à jour.
Zend Framework et les frameworks abandonnés
Zend Framework n’est plus développé depuis 2020 ; le projet a été repris sous un autre nom, Laminas. Il n’y a donc pas de version suivante à installer, il faut migrer vers autre chose.
Pour reprendre l’image de la maison : changer la charpente, c’est démonter une partie du toit. Les pièces qui s’appuyaient dessus (votre code métier) doivent être reprises une à une.
Les briques dont plus personne ne s’occupe
Une application d’entreprise utilise des dizaines de modules écrits par d’autres : le paiement en ligne, la génération des factures en PDF, l’envoi d’e-mails, la liaison avec votre logiciel de comptabilité. Tant que leurs auteurs les entretiennent, ils suivent les nouvelles versions de PHP. Quand l’auteur arrête, le module reste figé.
Prenez SimpleCart, un module de boutique en ligne pour MODX : il ne sera jamais adapté à MODX 3, et son support a pris fin le 31 décembre 2025. Une boutique construite dessus ne peut pas simplement monter de version. Il faut remplacer tout le tunnel de commande.
C’est un peu comme une cuisine équipée dont le fabricant a fermé : le jour où le four lâche, vous ne trouvez pas de pièce, et le modèle de remplacement n’a pas les mêmes dimensions. Il faut alors retoucher les meubles autour.
Le développement maison : là où ça coince le plus
Beaucoup de PME suisses tournent sur une application développée sur mesure il y a dix ou quinze ans, souvent un extranet clients ou un portail de commandes pour les revendeurs. Elle marche et tout le monde la connaît. Le développeur qui l’a écrite, lui, est souvent parti depuis longtemps.
Le problème, c’est que vos règles de gestion sont enfouies dans ce code. Le calcul des frais de port pour le Tessin ou la remise accordée au client historique : personne ne les a écrits ailleurs. Et il n’existe en général aucun test automatique, c’est-à-dire aucun programme qui vérifie après chaque modification que ces calculs donnent toujours le bon résultat.
Modifier ce code pour PHP 8, c’est donc travailler à l’aveugle. On corrige une ligne, et une remise disparaît trois écrans plus loin sans que personne ne le voie. Dans ce cas, réécrire les parties sensibles proprement, avec des tests, revient souvent moins cher que de rapiécer l’existant pendant des mois.
Mise à jour, migration ou réécriture : comment savoir où vous en êtes
Toutes les applications n’ont pas besoin d’être réécrites, et un prestataire qui vous dit le contraire sans avoir regardé votre code mérite qu’on lui pose des questions. Il existe trois trajectoires.
La mise à jour
Votre application est récente, sur un framework encore entretenu. On adapte quelques lignes et on teste avant de basculer. C’est la révision chez le garagiste.
La migration par étapes
La base est saine, mais le framework a plusieurs versions de retard. On le fait monter version par version, en corrigeant au fur et à mesure. Ça prend plus de temps, mais l’application reste en service pendant tout le chantier, comme une rénovation pièce par pièce pendant qu’on habite la maison.
La réécriture
La charpente est trop vieille et plus personne ne sait vraiment comment le code fonctionne. On reconstruit l’application sur une base moderne, en reprenant vos règles de gestion une par une. On ne refait pas tout d’un coup : les parties les plus critiques passent en premier.
La grille pour vous situer
| Criterion | Plutôt une mise à jour | Plutôt une migration par étapes | Plutôt une réécriture |
|---|---|---|---|
| Version de PHP actuelle | 8.2 ou plus | 7.4 à 8.1 | 7.3 ou moins |
| Framework ou CMS | Version encore supportée | Une ou deux versions de retard | Abandonné, ou très en retard (Laravel 5, MODX 2, Zend) |
| Modules externes | Tous entretenus | Quelques-uns à remplacer | Plusieurs abandonnés, dont des modules clés |
| Tests automatiques | Oui | Partiels | Aucun |
| Connaissance du code | L’équipe d’origine est là | Code documenté, équipe changée | Développeur parti, rien d’écrit |
Si la plupart de vos réponses tombent dans la dernière colonne, il faudra réécrire. Le diagnostic servira surtout à décider par quoi commencer.
Ce qui fait varier le budget
On nous demande souvent un prix au téléphone. Honnêtement, c’est impossible à donner sans avoir ouvert le code, pour la même raison qu’un entrepreneur ne chiffre pas une rénovation sans regarder derrière les murs. Ce qui pèse le plus dans la balance :
- la taille de l’application, c’est-à-dire le nombre d’écrans et de fonctions réellement utilisés (souvent moins que ce qui existe) ;
- les connexions avec d’autres logiciels, comme la comptabilité, l’ERP, le paiement ou la logistique ;
- l’état du code existant et de sa documentation ;
- le volume et la propreté des données à reprendre ;
- les langues, quand l’application tourne en français, allemand et italien.
Un premier diagnostic de quelques jours permet de trancher entre les trois trajectoires et de chiffrer le chantier avec une marge raisonnable. Sans lui, n’importe quel devis est une estimation à l’aveugle.
Et si on ne fait rien ?
La tentation est compréhensible : l’application marche, on verra l’année prochaine. Mais le calendrier ne vous attend pas.
Les versions 7.4, 8.0 et 8.1 de PHP n’ont reçu aucun correctif officiel pour la faille PHP2Shell d’octobre 2026 (voir notre article PHP2Shell : pourquoi votre site en PHP 7 ou 8.1 est exposé). PHP 8.2 sera à son tour abandonné le 31 décembre 2026. Chaque mois passé sur ces versions, c’est un mois sans serrure de rechange.
Il y a aussi un coût moins visible. Plus le code vieillit, moins on trouve de développeurs prêts à le reprendre, et plus chaque petite modification prend de temps. Sans compter la responsabilité de l’entreprise : la nLPD exige des mesures de sécurité adéquates pour les données clients, ce qu’une version sans correctif rend difficile à défendre.
Enfin, même une application moderne demande un entretien régulier. Laravel 12, par exemple, ne reçoit plus de correctifs de sécurité après le 24 février 2027. Une montée de version par an coûte bien moins cher qu’une réécriture tous les dix ans.
Le vrai sujet, c’est la charpente
Passer de PHP 7 à PHP 8 sur une application d’entreprise, c’est rarement une affaire de réglage serveur. Si votre application repose sur un vieux Laravel, sur MODX 2 ou sur un développement maison sans tests, il faudra reprendre une bonne partie de sa structure. Autant le savoir avant de lancer les travaux qu’en plein milieu.
Dans le prochain article, on entre dans le concret : comment se déroule une réécriture en PHP 8.5, étape par étape, et ce que votre entreprise y gagne.
Questions fréquentes
Peut-on passer directement de PHP 7.4 à PHP 8.5 ?
Techniquement oui, mais rarement sans travail sur le code. Toutes les incompatibilités accumulées entre 8.0 et 8.5 tombent d’un coup, et le framework doit en général suivre.
Mon application est en Laravel, est-ce forcément une réécriture ?
Non. Une application en Laravel 9 ou 10 avec un code propre se migre souvent version par version. La réécriture devient intéressante quand l’écart est grand (Laravel 5 ou 6) et que le code n’a pas de tests.
Et pour un site MODX 2 ?
Tout dépend des extensions utilisées. Si elles existent en version MODX 3, la migration est envisageable. Si des extensions clés sont abandonnées, il faut les remplacer, voire repenser le site.
Combien de temps dure une migration ?
De quelques jours pour une mise à jour simple à plusieurs mois pour une réécriture. Le diagnostic initial sert justement à le chiffrer.
Sources
- Laravel, notes de version 13.x et politique de support
- Benjamin Crozat, versions de Laravel et statut du support
- MODX Support, passer de Revolution 2 à 3
- Forum MODX, problèmes de mise à jour avec PHP 8
- modmore, fin du support de SimpleCart
