Moderniser une application PHP legacy sans tout reecrire

Votre application PHP tourne depuis des annees. Elle fait le job, les utilisateurs s'en servent au quotidien, et le chiffre d'affaires depend en partie d'elle. Mais sous le capot, la situation se degrade : les montees de version sont impossibles, chaque correction de bug est une aventure, et plus personne ne veut toucher a certains modules. La tentation de tout reecrire est forte. C'est presque toujours une erreur.

En tant qu'agence specialisee en modernisation d'applications PHP, nous accompagnons des entreprises qui font face a cette situation. Voici l'approche qui fonctionne.

Pourquoi la reecriture complete est un piege

La reecriture complete (le "big rewrite") est le projet le plus risque en ingenierie logicielle. Joel Spolsky l'a dit en 2000, et c'est toujours vrai en 2026. Les raisons sont structurelles :

• Le perimetre explose : l'ancienne application fait des centaines de choses, dont certaines que personne ne documente. La nouvelle doit toutes les reproduire, plus les nouvelles fonctionnalites. Le budget double, puis triple.
• Le temps de developpement est sous-estime : pendant que l'equipe reecrit, l'ancienne application continue de recevoir des corrections et des evolutions. La cible bouge en permanence.
• Les risques de regression sont enormes : des comportements implicites de l'ancienne application (contournements, cas limites, regles metier non documentees) sont oublies dans la reecriture et se revelent en production.

La bonne approche, c'est la modernisation progressive. On ne jette pas l'existant : on l'ameliore par etapes, en commencant par ce qui a le plus d'impact.

Etape 1 : diagnostiquer l'etat reel

Avant toute intervention, il faut comprendre ou on met les pieds. Un audit technique approfondi cartographie la dette technique, identifie les risques et priorise les actions. Notre article sur comment se passe un audit chez Efficience IT detaille le processus.

Les points a evaluer en priorite :

• Version du framework : Symfony 3, 4 ou 5 ? Laravel 5 ou 6 ? Pas de framework du tout ? Le guide de migration Symfony detaille les implications de chaque version.
• Couverture de tests : zero test est courant dans les projets legacy. C'est le premier frein a toute evolution. Les tests automatises sont la priorite numero un.
• Qualite du code : l'analyse statique avec PHPStan revele les problemes structurels invisibles a l'oeil nu. Le code mort accumule est aussi un signal de dette.
• Infrastructure : deployements manuels, pas de CI/CD, serveur non maintenu ? Le passage a Docker et a une pipeline d'integration continue stabilise l'environnement avant meme de toucher au code.

L'audit Symfony gratuit de 30 minutes est un bon point d'entree pour une premiere evaluation.

Etape 2 : stabiliser avant de moderniser

La premiere erreur est de vouloir moderniser le code avant de stabiliser le processus. Sans filet de securite, chaque modification est un risque. La stabilisation passe par :

Mettre en place les tests

Pas besoin de viser 100% de couverture. L'objectif est de proteger les parcours critiques : les flux de paiement, les calculs metier, les integrations tierces. Des tests fonctionnels de bout en bout (smoke tests) suffisent pour commencer. Ils se rajoutent sans modifier le code existant.

Automatiser les deploiements

Passer d'un deploiement manuel (FTP, SSH, "on fait attention") a une pipeline CI/CD reduit drastiquement le risque. Chaque modification est testee automatiquement avant d'arriver en production. C'est un investissement de quelques jours qui se rentabilise des le premier mois.

Introduire l'analyse statique

PHPStan au niveau 1, puis progressivement monter. Rector pour automatiser les corrections de syntaxe et les mises a jour de code. Ces outils corrigent des centaines de problemes sans intervention manuelle.

Etape 3 : moderniser par modules

Une fois l'application stabilisee, la modernisation peut commencer. L'approche modulaire est la cle : on isole un module, on le modernise, on verifie que tout fonctionne, puis on passe au suivant.

L'approche Strangler Fig

Inspiree du pattern Strangler Fig de Martin Fowler, cette strategie consiste a construire les nouvelles fonctionnalites dans une architecture moderne (par exemple une architecture hexagonale avec Symfony) tout en laissant l'ancien code en place. Progressivement, le nouveau code remplace l'ancien, module par module.

Notre retour d'experience sur la migration vers une architecture hexagonale detaille cette approche sur un cas concret. C'est la methode que nous utilisons le plus souvent chez nos clients.

Migrer le framework

Si l'application tourne sur un framework obsolete (Symfony 3, Zend Framework, CodeIgniter), la migration vers une version LTS de Symfony est une priorite. L'outil Rector automatise une grande partie des modifications de code. Le reste se fait manuellement, en s'appuyant sur les tests mis en place a l'etape 2.

Extraire les services

Les applications legacy sont souvent monolithiques : tout est dans le meme code, sans separation claire. L'extraction de services (authentification, notifications, calculs metier) dans des modules independants, relies par Symfony Messenger ou des API internes, apporte de la flexibilite sans imposer une architecture micro-services complete. Notre article sur le choix entre micro-services et monolithe modulaire aide a trouver le bon equilibre.

Etape 4 : securiser et perenniser

La modernisation ne s'arrete pas a la refonte du code. Elle inclut la mise en place des gardes-fous qui empecheront le retour de la dette technique :

• Pipeline CI/CD complete : lint, analyse statique, tests, deploiement automatise. Chaque PR est validee avant d'etre mergee.
• Montees de version planifiees : les versions LTS de Symfony garantissent un support de 3 ans. Planifier les montees de version evite les ruptures.
• Documentation technique : une documentation a jour, produite avec l'approche Diataxis, facilite l'onboarding des nouveaux developpeurs et reduit la dependance aux sachants.
• Securite applicative : audit de securite, gestion des CVE, mises a jour regulieres des dependances.

Faut-il internaliser ou externaliser ?

La modernisation d'une application legacy demande des competences pointues en Symfony, en architecture et en gestion de dette technique. Si votre equipe n'a pas ces competences en interne, externaliser a un prestataire specialise est souvent le choix le plus efficace.

Notre offre de reprise de projets Symfony est concue pour ces situations : nous prenons le relais sur des applications existantes, avec un audit honnete et une stabilisation progressive. Pour les equipes qui veulent monter en competences en parallele, nos formations Symfony en entreprise combinent transfert de connaissances et travail sur le code reel du projet.

La premiere etape, dans tous les cas, est un diagnostic. L'audit Symfony gratuit de 30 minutes permet d'evaluer la situation et de definir un plan d'action realiste, sans engagement. Avant de rediger un cahier des charges, cet echange pose les bases du projet et evite de partir dans la mauvaise direction.