Quand le code devient plus fragile que le métier qu'il sert
Il existe un moment dans la vie de beaucoup d'applications PHP où chaque modification devient une source d'anxiété. On hésite à corriger un bug de peur d'en introduire trois autres. On reporte les évolutions parce que personne ne comprend vraiment comment les pièces s'emboîtent. Ce moment n'est pas une fatalité, et il ne justifie pas de tout recommencer à zéro.
Cet article s'appuie sur un guide de modernisation PHP publié sur DEV Community pour proposer une approche structurée, applicable par étapes, sans couper le service.
Pourquoi la réécriture totale échoue presque toujours
La refonte complète exerce une attraction réelle sur les équipes techniques. Le code existant est douloureux à lire, les règles métier sont éparpillées, les tests sont absents. Repartir de zéro semble rationnel.
En pratique, cette décision accumule les risques :
- Les règles métier implicites, jamais documentées, doivent être réapprises ou réinventées.
- Le système en production continue d'évoluer pendant que la réécriture avance, créant un écart permanent entre les deux.
- La date de bascule arrive toujours trop tôt ou trop tard, et la confiance dans le nouveau système est difficile à construire sans historique.
L'approche incrémentale répond à ces problèmes en maintenant le système existant en état de marche pendant que l'on améliore ses fondations, bloc par bloc.
Les premières étapes concrètes
Évaluer avant de toucher
Avant toute modification, un audit de l'état réel s'impose. Quelle version de PHP est utilisée ? Existe-t-il des dépendances non gérées ? Quels sont les points d'entrée critiques du système ? Des outils statiques comme PHPStan permettent de cartographier la qualité du code existant sans l'exécuter.
Cette étape révèle souvent que la situation est moins catastrophique qu'elle n'y paraît, et surtout qu'elle identifie les zones à stabiliser en priorité.
Passer à une version PHP supportée
Travailler sur une version de PHP qui ne reçoit plus de correctifs de sécurité est un risque opérationnel immédiat. La montée de version doit précéder toute autre transformation. Elle est rarement triviale sur du code ancien, mais elle est non négociable et souvent moins coûteuse que prévu lorsqu'on la traite sérieusement.
Introduire Composer et l'autoloading
L'une des fractures les plus nettes entre le PHP des années 2000 et le PHP actuel est la gestion des dépendances. Sans Composer, chaque bibliothèque est incluse manuellement, les versions ne sont pas contrôlées, et les conflits sont invisibles jusqu'à la mise en production.
Introduire Composer, même dans un projet existant, est une étape discrète mais structurante. Elle ouvre la porte à l'autoloading PSR-4, qui permet d'organiser le code en classes chargées automatiquement plutôt qu'en fichiers inclus à la main.
Construire un filet de sécurité de tests
Refactoriser du code sans tests, c'est rénover un bâtiment sans pouvoir vérifier que les murs porteurs tiennent. Les tests ne doivent pas couvrir tout le système d'un coup : ils doivent cibler les comportements critiques, ceux qui coûtent le plus cher quand ils cassent.
Une couverture partielle mais fiable sur les fonctionnalités essentielles suffit pour commencer à modifier le code avec confiance.
Le Strangler Fig Pattern pour migrer vers Symfony
Le nom vient d'un figuier étrangleur qui pousse autour d'un arbre existant jusqu'à le remplacer complètement, sans jamais l'abattre. Appliqué à une application PHP, le principe est identique :
- On identifie une fonctionnalité à migrer.
- On la réécrit dans le nouveau système (ici, Symfony).
- On redirige le trafic correspondant vers la nouvelle version.
- On recommence avec la fonctionnalité suivante.
L'ancienne application reste en production et continue de gérer ce qu'elle gère. Le nouveau système grandit à côté, puis progressivement en remplacement. À aucun moment on ne parie l'ensemble du système sur une bascule unique.
Symfony se prête particulièrement bien à cette approche grâce à son système de routage, son injection de dépendances, et sa capacité à coexister avec du code PHP procédural via des points d'entrée partagés.
Progresser sans perdre de vue l'objectif
La modernisation incrémentale n'est pas une errance sans direction. Chaque étape doit répondre à une question précise : qu'est-ce que ce changement rend possible que nous ne pouvions pas faire avant ?
Introduire Composer rend les mises à jour de bibliothèques reproductibles. Ajouter des tests rend les modifications moins risquées. Migrer une fonctionnalité vers Symfony rend cette partie du code maintenable par n'importe quel développeur PHP formé aux pratiques actuelles.
L'accumulation de ces petits gains produit, au fil des itérations, un système que l'équipe comprend, que les nouveaux arrivants peuvent prendre en main, et que l'on peut faire évoluer sans crainte.
Ce que ça change pour vous
Si vous êtes dirigeant et que votre application interne fonctionne mais que personne n'ose la modifier, cette situation a un coût réel : chaque évolution repoussée est une opportunité manquée ou un risque qui grossit. La modernisation progressive ne demande pas d'arrêter votre outil pendant des mois, et elle ne nécessite pas de repayer pour quelque chose qui existe déjà. Elle améliore ce qui est en place, par étapes planifiées, avec des résultats visibles à chaque phase. Demander un audit technique avant un devis de refonte est une façon simple de savoir où vous en êtes réellement.
