Votre application PHP tourne depuis des années, personne n'ose y toucher, et le serveur affiche une version de PHP qui ne reçoit plus de correctifs de sécurité. Bonne nouvelle : moderniser une application PHP ancienne ne passe presque jamais par une réécriture totale. La méthode qui marche : auditer, poser des tests, puis migrer par étapes vers PHP 8 et Laravel.
Faut-il vraiment tout réécrire ?
Soyons clairs : non, et c'est souvent la pire idée. Une réécriture complète immobilise l'équipe pendant des mois, reproduit les mêmes oublis, et oblige à refaire des règles métier que personne ne sait plus expliquer. Le vieux code est moche, mais il contient des années de cas particuliers qui fonctionnent.
La vraie question : qu'est-ce qui coûte aujourd'hui ? Une faille potentielle, des pannes à chaque mise à jour, un développeur qui part avec la mémoire du code ? Ça, on le voit souvent.
Que regarder dans l'audit avant de toucher au code ?
L'audit sert à décider, pas à produire un rapport de plus. On regarde la version de PHP et des bibliothèques, les dépendances abandonnées, les fichiers qui mélangent requêtes SQL et affichage, et les zones que tout le monde évite. On repère aussi les parcours qui rapportent de l'argent : commande, devis, facturation.
C'est là que se joue le périmètre.
Notre page sur la reprise d'une application existante détaille ce que nous regardons en premier, et une analyse des besoins évite de moderniser des écrans que plus personne n'utilise.
Comment tester un code qui n'a jamais eu de tests ?
On ne couvre pas tout. On écrit quelques tests sur les parcours critiques : créer une commande, calculer un prix, émettre une facture. Ils figent le comportement actuel, même discutable. Si une étape change le résultat, on le sait le jour même, pas trois semaines plus tard chez un client.
À côté, PHPStan, un outil d'analyse statique, débusque les erreurs de type, et Rector réécrit automatiquement une bonne partie de la syntaxe dépassée. Ils dégrossissent. La relecture humaine reste nécessaire.
Comment migrer vers PHP 8 et Laravel par étapes ?
D'abord PHP lui-même, par paliers de version, en corrigeant les incompatibilités à chaque marche. Ensuite Laravel, qui s'installe à côté de l'ancien code plutôt qu'à sa place. Un module après l'autre, on déplace écrans et logique vers la nouvelle structure pendant que le reste tourne. L'ancien et le nouveau cohabitent, puis l'ancien rétrécit.
Chaque étape doit être livrable seule, avec un retour en arrière possible. Une fois en place, on peut verrouiller la structure avec des règles d'architecture vérifiées automatiquement, pour que le désordre ne revienne pas.
Et si l'application est trop abîmée ?
Ça arrive : framework maison sans documentation, base de données incohérente, aucun accès au code d'origine. Reconstruire un module à neuf devient alors plus raisonnable que le réparer, mais module par module, jamais d'un bloc.
Nous accompagnons des entreprises de Provence dans ce type de chantier, notamment autour de Berre-l'Étang. Même règle partout : l'activité ne s'arrête pas.
- Une réécriture totale est rarement justifiée : l'audit dit ce qui coûte vraiment.
- Quelques tests sur les parcours critiques valent mieux qu'une couverture parfaite jamais écrite.
- On monte PHP par paliers, puis on installe Laravel à côté de l'ancien code.
- Chaque étape est livrable seule, avec un retour en arrière possible.
Questions fréquentes
Peut-on passer directement de PHP 5 ou 7 à PHP 8 ?
Rarement d'un seul bond. On monte par paliers de version, en corrigeant les incompatibilités à chaque marche, avec des outils d'analyse statique et de refactoring automatique pour dégrossir le travail.
Laravel est-il obligatoire pour moderniser une application PHP ?
Non. Passer à PHP 8 suffit parfois à régler l'urgence. Laravel apporte surtout une structure, des tests et des mises à jour de sécurité suivies, ce qui compte si l'application doit durer.
L'application peut-elle rester en service pendant la migration ?
Oui, c'est même le but de la migration par étapes. Les anciens écrans et les nouveaux cohabitent, et on bascule un module à la fois.
