Comment moderniser une application PHP legacy en 2026 : un plan étape par étape, sans réécriture

Comment moderniser une application PHP legacy ?

On modernise une application PHP legacy de façon progressive : on l'audite, on installe un filet de sécurité autour des parcours qui rapportent de l'argent, on la passe sur une version supportée de PHP 8.x, puis on fait grandir une application sur un framework moderne à côté de l'ancien code et on migre les modules un par un derrière les mêmes URL. Les fonctionnalités IA viennent par-dessus une fois le cœur stabilisé. À chaque étape, l'application continue de servir vos clients, et vous pouvez vous arrêter avec un système meilleur que celui de départ.

C'est ainsi que nous abordons le legacy dans nos services de développement PHP et de développement Symfony. PHP est notre langage back-end principal, et la plupart des applications legacy que nous voyons présentent les mêmes symptômes : une vieille version de PHP sans correctifs de sécurité, des bibliothèques abandonnées, aucun test, de la logique métier mélangée aux templates, un déploiement qu'une seule personne comprend, et une équipe qui a peur de toucher à quoi que ce soit.

Le plan en bref :

1. Audit (1 à 2 semaines)
2. Filet de sécurité : supervision, sauvegardes et tests sur les parcours critiques
3. PHP 8.x supporté pour le code existant
4. Framework moderne à côté du code legacy
5. Migration module par module derrière les mêmes URL
6. Retrait du code legacy
7. Ajout de fonctionnalités IA sur un cœur stable

Pourquoi ne pas tout réécrire à partir de zéro ?

Une réécriture complète est la façon la plus coûteuse de moderniser, et la plus risquée. Elle arrête ou ralentit le développement de fonctionnalités pendant des mois, elle doit redécouvrir des règles métier qui ne vivent que dans l'ancien code et dans la tête des utilisateurs de longue date, et elle bascule tout en un seul jour, qui est justement le moment où les règles oubliées refont surface sous forme d'incidents.

Nous privilégions la migration progressive et le disons ouvertement. Une réécriture n'est justifiée que dans des cas précis, et même alors nous préférons faire tourner l'ancien et le nouveau côte à côte pendant un temps.

Que doit couvrir un audit d'application PHP legacy ?

L'audit fixe l'ordre de tout le reste : il doit donc être concret. En 1 à 2 semaines, nous examinons :

• La version de PHP et les extensions, et ce qui casse sur la version cible.
• Les dépendances : quelles bibliothèques sont abandonnées ou bloquées sur un vieux PHP, car ce sont généralement elles qui dictent le rythme de la mise à jour.
• Le framework : aucun, un framework maison, ou une vieille version de Symfony, Laravel, Zend ou CodeIgniter.
• La base de données : schéma, index manquants, requêtes construites par concaténation de chaînes, et problèmes de qualité des données.
• La sécurité : risques d'injection, authentification obsolète, secrets dans le code, gestion des fichiers téléversés.
• L'hébergement et le déploiement : comment le code arrive en production, sauvegardes, supervision et qui détient les accès.
• Les parcours critiques pour l'activité : inscription, commande, facturation, rapports, imports, et lesquels ont des tests.

Vous recevez un rapport écrit avec les risques classés par impact, et un plan avec un devis forfaitaire pour le jalon suivant.

Pourquoi les tests et la supervision passent-ils en premier ?

Parce que chaque étape suivante modifie du code que personne ne comprend entièrement, et que vous devez savoir immédiatement quand quelque chose casse. Avant de toucher à la version de PHP ou à la structure, nous ajoutons :

• Une supervision des erreurs en production, pour que les nouvelles erreurs après chaque mise en ligne soient visibles en quelques minutes.
• Des sauvegardes et une restauration testée, pas seulement une tâche de sauvegarde.
• Des tests de caractérisation sur les parcours qui rapportent de l'argent. Ces tests enregistrent ce que fait l'application aujourd'hui, à tort ou à raison, pour qu'un changement de comportement soit détecté avant que les clients ne le voient.
• Un déploiement reproductible via la CI, pour que n'importe quel ingénieur puisse mettre en ligne et revenir en arrière.

L'analyse statique avec PHPStan démarre aussi à ce stade, à un niveau bas, relevé pas à pas à mesure que le code s'améliore.

Quel est le chemin de mise à jour vers PHP 8.x ?

Le chemin consiste d'abord à passer le code existant, sans changer sa structure, sur une version supportée de PHP 8.x, pour que les correctifs de sécurité arrivent à nouveau et que l'outillage moderne fonctionne. PHP 7.x, 8.0 et 8.1 ne reçoivent plus de correctifs de sécurité, et PHP 8.2 en est à sa dernière année de support de sécurité.

Les étapes : analyse statique par rapport à la version cible pour lister les incompatibilités ; mise à jour ou remplacement des bibliothèques ; Rector pour les changements mécaniques comme les fonctions et signatures dépréciées ; revue manuelle du reste, en particulier les comparaisons de chaînes et de nombres et la gestion des erreurs ; puis un environnement de préproduction sous la nouvelle version et une mise en ligne progressive sous supervision. Pour une application métier typique, cela prend 3 à 12 semaines.

Comment fonctionne le pattern strangler en PHP ?

Le pattern strangler consiste à faire grandir une nouvelle application autour de l'ancienne, qui reprend progressivement ses routes jusqu'à ce que l'ancien code puisse être éteint. En PHP, c'est pratique, car les deux applications peuvent partager le même serveur, la même base de données et la même session.

Comment nous le mettons en place :

1. Un seul point d'entrée. Les requêtes arrivent d'abord sur une nouvelle application Symfony. Si elle a une route pour l'URL, elle répond ; sinon, elle transmet la requête au code legacy, qui fonctionne comme avant.
2. Des données partagées. Les deux applications utilisent d'abord la même base de données. Le nouveau code y accède via des entités Doctrine mappées sur les tables existantes : aucune migration de données n'est nécessaire le premier jour.
3. Une session et une connexion partagées, pour que les utilisateurs ne remarquent jamais quelle partie a servi une page.
4. Les nouvelles fonctionnalités uniquement dans la nouvelle application, dès le premier jour.
5. Module par module. Les anciennes pages et les anciens endpoints migrent un par un, chacun avec des tests avant la bascule, derrière les mêmes URL.
6. Retrait de chaque module legacy quand le trafic montre que plus rien ne l'utilise.

Cela étale le coût sur plusieurs versions et laisse l'activité tourner. L'équipe livre des fonctionnalités tout du long, et à tout moment le système est meilleur qu'avant.

Quel framework utiliser pour le nouveau code ?

Pour les systèmes métier à longue durée de vie, nous utilisons Symfony, notre framework par défaut : architecture explicite, séparation entre le domaine et la base de données grâce à Doctrine, versions à support long terme et mises à jour prévisibles. Ce sont exactement les qualités dont une équipe a besoin après des années de souffrance avec du legacy. Ritoria, une plateforme Symfony que nous avons construite avec 54 entités métier, a tourné en production sur AWS pendant deux ans et demi, à travers 292 commits et 120 migrations de base de données d'évolution continue : c'est le type d'évolution régulière qu'un système modernisé doit permettre.

Si votre équipe travaille déjà avec Laravel, migrer vers Laravel est une voie valable, et nous y travaillons via notre service de développement Laravel. Si le code legacy tourne déjà sur une vieille version de Symfony, le plan devient une mise à jour de Symfony, une version majeure à la fois. Notre comparaison Symfony ou Laravel pour un SaaS explique les compromis.

Comment ajouter de l'IA à une application PHP modernisée ?

Une fois que le cœur tourne sur un PHP supporté avec des tests, les fonctionnalités IA sont construites comme des services et des tâches de fond ordinaires qui appellent les API OpenAI ou Anthropic Claude : elles suivent donc les mêmes droits, la même journalisation et les mêmes tests que le reste du code. Les premières fonctionnalités typiques sont la rédaction et le résumé, la recherche et les réponses sur vos propres documents avec le RAG, et des agents qui agissent via votre logique métier existante, avec validation humaine pour tout ce qui touche à l'argent ou à la communication avec les clients.

Lorsqu'une fonctionnalité exige un traitement de données lourd ou des modèles sur mesure, nous ajoutons un service Python séparé que l'application PHP appelle via une API, au lieu de faire passer le produit à un nouveau langage. Notre propre produit AI Resume Master est construit ainsi : PHP et Symfony pour le produit, React pour l'interface et Python pour la génération par IA, et il a atteint 50 000 utilisateurs actifs mensuels. L'approche est détaillée sur notre page intégration IA.

Combien coûte la modernisation d'une application PHP legacy ?

Le coût dépend de ce que révèle l'audit : l'écart de versions, la liste des dépendances, la couverture de tests et le degré d'imbrication de la logique. C'est pourquoi nous chiffrons la modernisation après l'audit, avec un prix forfaitaire pour chaque jalon, au lieu de deviner à l'avance.

Notre taille minimale de projet est de 10 000 USD. Si vous prévoyez une modernisation continue en parallèle de votre feuille de route, une équipe de développement dédiée sur un budget mensuel est souvent le modèle le plus simple.

Notre verdict et comment nous commençons

Ne réécrivez pas par défaut. Atteignez une version supportée de PHP, placez des tests autour de ce qui rapporte de l'argent, et passez à un framework moderne module par module pendant que l'activité continue. Ajoutez l'IA sur un cœur stable. Nous commençons par un court appel et un audit qui se termine par un rapport écrit et un plan. Consultez nos services de développement PHP et de développement Symfony, ou contactez-nous en nous indiquant votre version actuelle de PHP et ce qui ne fonctionne pas.