Moderniser une application PHP legacy sans tout réécrire

Votre application PHP tourne depuis des années. Elle fait le job, les utilisateurs s'en servent au quotidien, et le chiffre d'affaires dépend en partie d'elle. Mais sous le capot, la situation se dégrade : les montées de version sont impossibles, chaque correction de bug est une aventure, et plus personne ne veut toucher à certains modules. La tentation de tout réécrire est forte. C'est presque toujours une erreur.

En tant qu'agence spécialisée en modernisation d'applications PHP, nous accompagnons des entreprises qui font face à cette situation. Voici l'approche qui fonctionne.

Pourquoi la réécriture complète est un piège

La réécriture complète (le "big rewrite") est le projet le plus risqué en ingénierie logicielle. Joel Spolsky l'a dit en 2000, et c'est toujours vrai en 2026. Les raisons sont structurelles :

• Le périmètre explose : l'ancienne application fait des centaines de choses, dont certaines que personne ne documente. La nouvelle doit toutes les reproduire, plus les nouvelles fonctionnalités. Le budget double, puis triple.
• Le temps de développement est sous-estimé : pendant que l'équipe réécrit, l'ancienne application continue de recevoir des corrections et des évolutions. La cible bouge en permanence.
• Les risques de régression sont énormes : des comportements implicites de l'ancienne application (contournements, cas limites, règles métier non documentées) sont oubliés dans la réécriture et se révèlent en production.

La bonne approche, c'est la modernisation progressive. On ne jette pas l'existant : on l'améliore par étapes, en commençant par ce qui a le plus d'impact.

Étape 1 : diagnostiquer l'état réel

Avant toute intervention, il faut comprendre où 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 détaille le processus.

Les points à évaluer en priorité :

• Version du framework : Symfony 3, 4 ou 5 ? Laravel 5 ou 6 ? Pas de framework du tout ? Le guide de migration Symfony détaille les implications de chaque version.
• Couverture de tests : zéro test est courant dans les projets legacy. C'est le premier frein à toute évolution. Les tests automatisés sont la priorité numéro un.
• Qualité du code : l'analyse statique avec PHPStan révèle les problèmes structurels invisibles à l'œil nu. Le code mort accumulé est aussi un signal de dette.
• Infrastructure : déploiements manuels, pas de CI/CD, serveur non maintenu ? Le passage à Docker et à une pipeline d'intégration continue stabilise l'environnement avant même de toucher au code.

L'audit Symfony gratuit de 30 minutes est un bon point d'entrée pour une première évaluation.

Étape 2 : stabiliser avant de moderniser

La première erreur est de vouloir moderniser le code avant de stabiliser le processus. Sans filet de sécurité, 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 protéger les parcours critiques : les flux de paiement, les calculs métier, les intégrations tierces. Des tests fonctionnels de bout en bout (smoke tests) suffisent pour commencer. Ils se rajoutent sans modifier le code existant.

Automatiser les déploiements

Passer d'un déploiement manuel (FTP, SSH, "on fait attention") à une pipeline CI/CD réduit drastiquement le risque. Chaque modification est testée automatiquement avant d'arriver en production. C'est un investissement de quelques jours qui se rentabilise dès le premier mois.

Introduire l'analyse statique

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

Étape 3 : moderniser par modules

Une fois l'application stabilisée, la modernisation peut commencer. L'approche modulaire est la clé : on isole un module, on le modernise, on vérifie que tout fonctionne, puis on passe au suivant.

L'approche Strangler Fig

Inspirée du pattern Strangler Fig de Martin Fowler, cette stratégie consiste à construire les nouvelles fonctionnalités 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'expérience sur la migration vers une architecture hexagonale détaille cette approche sur un cas concret. C'est la méthode que nous utilisons le plus souvent chez nos clients.

Migrer le framework

Si l'application tourne sur un framework obsolète (Symfony 3, Zend Framework, CodeIgniter), la migration vers une version LTS de Symfony est une priorité. 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 à l'étape 2.

Extraire les services

Les applications legacy sont souvent monolithiques : tout est dans le même code, sans séparation claire. L'extraction de services (authentification, notifications, calculs métier) dans des modules indépendants, reliés par Symfony Messenger ou des API internes, apporte de la flexibilité sans imposer une architecture micro-services complète. Notre article sur le choix entre micro-services et monolithe modulaire aide à trouver le bon équilibre.

Étape 4 : sécuriser et pérenniser

La modernisation ne s'arrête pas à la refonte du code. Elle inclut la mise en place des gardes-fous qui empêcheront le retour de la dette technique :

• Pipeline CI/CD complète : lint, analyse statique, tests, déploiement automatisé. Chaque PR est validée avant d'être mergée.
• Montées de version planifiées : les versions LTS de Symfony garantissent un support de 3 ans. Planifier les montées de version évite les ruptures.
• Documentation technique : une documentation à jour, produite avec l'approche Diataxis, facilite l'onboarding des nouveaux développeurs et réduit la dépendance aux sachants.
• Sécurité applicative : audit de sécurité, gestion des CVE, mises à jour régulières des dépendances.

Faut-il internaliser ou externaliser ?

La modernisation d'une application legacy demande des compétences pointues en Symfony, en architecture et en gestion de dette technique. Si votre équipe n'a pas ces compétences en interne, externaliser à un prestataire spécialisé est souvent le choix le plus efficace.

Notre offre de reprise de projets Symfony est conçue pour ces situations : nous prenons le relais sur des applications existantes, avec un audit honnête et une stabilisation progressive. Pour les équipes qui veulent monter en compétences en parallèle, nos formations Symfony en entreprise combinent transfert de connaissances et travail sur le code réel du projet.

La première étape, dans tous les cas, est un diagnostic. L'audit Symfony gratuit de 30 minutes permet d'évaluer la situation et de définir un plan d'action réaliste, sans engagement. Avant de rédiger un cahier des charges, cet échange pose les bases du projet et évite de partir dans la mauvaise direction.