Moderniser une application PHP : migration PHP 8.4, Rector et Symfony

Pour moderniser une ancienne application PHP, on procède par étapes. On commence par un état des lieux : version de PHP, dépendances, couverture de tests. On monte ensuite de version en suivant les guides de migration officiels, une version majeure après l'autre. La réécriture répétitive est confiée à un outil de refactorisation automatisée, contrôlé par une analyse statique comme PHPStan. Enfin, l'application est remplacée module par module, par exemple avec Symfony, plutôt que réécrite d'un bloc.

• La version de PHP en production et l'écart avec PHP 8.4 : chaque version majeure intermédiaire a son propre guide de migration.
• Les extensions utilisées, surtout celles qui ne sont plus livrées avec le cœur du langage.
• Les dépendances tierces : sont-elles encore maintenues ? Une version compatible avec la cible existe-t-elle ?
• La présence de tests automatisés, même sommaires, sur les parcours critiques.
• Le niveau d'analyse statique que le code passe aujourd'hui sans erreur.
• Les zones de l'application qui changent souvent, et celles que personne n'ose plus toucher.

À qui confier la reprise d'une application PHP existante ?

Quand l'équipe interne manque de temps ou de recul sur un code ancien, la reprise d'application legacy peut être confiée à un prestataire spécialisé. C'est l'une des activités de Doing, entreprise de développement informatique installée à Saint-Étienne depuis plus de 30 ans. Sa trentaine de collaborateurs intervient auprès d'entreprises de Lyon à Paris et partout en France. Son offre de développement PHP sur mesure s'appuie notamment sur Laravel et Symfony.

• Reprise d'application legacy et applications de gestion sur mesure
• Audit et analyse, Sprint 0, architecture et UX/UI (phase « Viabiliser »)
• Maintenance en conditions opérationnelles et maintenance évolutive
• Hébergement, infogérance et formation, certifiée Qualiopi via son partenariat avec la Digital League

Que dit le guide officiel de migration vers PHP 8.4 sur les changements incompatibles ?

La documentation officielle de PHP publie, pour chaque version, un guide de migration en annexe du manuel. Il est découpé en rubriques : changements incompatibles avec les versions précédentes, nouvelles fonctionnalités, fonctionnalités dépréciées, extensions modifiées. Une application bloquée en PHP 7.2 ne saute donc pas directement à la 8.4. Il faut lire les guides 7.3, 7.4, 8.0, 8.1, 8.2, 8.3 puis 8.4, car chacun suppose le précédent appliqué.

Pour la 8.4, quelques points méritent une attention particulière sur du code ancien :

• Les paramètres implicitement nullables sont dépréciés. Une signature du type function f(Type $x = null) doit devenir ?Type $x = null. C'est un motif très répandu dans le code écrit avant PHP 7.1.
• Plusieurs extensions ont quitté le cœur du langage pour être distribuées séparément, dont IMAP, OCI8, PDO_OCI et pspell. Une application qui lit une boîte mail ou se connecte à une base Oracle doit l'anticiper dans son environnement.
• La constante E_STRICT est dépréciée, ce qui concerne les anciens réglages de gestion d'erreurs.

Le guide présente aussi les nouveautés, comme les « property hooks » ou la visibilité asymétrique des propriétés. Elles ne sont pas nécessaires pour migrer. Mieux vaut d'abord faire tourner l'application à l'identique sur la nouvelle version, puis adopter ces écritures plus tard, dans un second temps.

Une dépréciation ne casse rien sur le moment, mais elle annonce une suppression dans une version future. Faire remonter les avertissements de dépréciation dans les journaux de l'environnement de test donne une liste de travail concrète, bien plus fiable qu'une relecture manuelle.

Comment automatiser la mise à niveau d'un code PHP ancien ?

Sur une base de plusieurs centaines de fichiers, corriger chaque signature à la main prend du temps et provoque des erreurs. Les outils de refactorisation automatisée lisent le code sous forme d'arbre syntaxique et y appliquent des règles de transformation. Ces règles sont regroupées en ensembles qui correspondent à une version cible du langage ou d'un framework.

La documentation de ce type d'outil recommande une démarche progressive :

1. Configurer la cible dans un fichier de configuration à la racine du projet, en indiquant les dossiers à traiter et la version de PHP visée.
2. Lancer d'abord une simulation, qui affiche les modifications proposées sans toucher aux fichiers.
3. Avancer par petits lots : un ensemble de règles ou un dossier à la fois, chacun dans un commit séparé, pour que la revue reste lisible.
4. Repasser les tests et l'analyse statique après chaque lot.

L'analyse statique est le second outil indispensable. PHPStan examine le code sans l'exécuter et signale les appels à des méthodes inexistantes, les types incohérents ou le code mort. Il fonctionne par niveaux d'exigence croissants. Sur un code ancien, on part d'un niveau bas, on enregistre les erreurs existantes dans un fichier de référence (une « baseline »), puis on interdit toute nouvelle erreur. La dette reste visible et cesse de grossir.

L'ordre compte : l'analyse statique en premier, puis la refactorisation automatique, puis la montée de version de PHP. Une transformation automatique sur un code que personne ne sait vérifier ne fait que déplacer le risque.

Comment migrer une application legacy vers Symfony avec le pattern strangler ?

Le pattern dit « strangler » (l'étrangleur, par analogie avec le figuier qui pousse autour d'un arbre) part d'un constat simple : une réécriture complète gèle les évolutions pendant des mois et ne livre rien tant qu'elle n'est pas finie. On fait donc vivre côte à côte l'ancienne application et la nouvelle, et la nouvelle reprend les fonctionnalités l'une après l'autre.

La documentation officielle de Symfony consacre une page à la migration d'une application existante. Le principe : Symfony devient le point d'entrée unique des requêtes. Si une route est déjà gérée par le nouveau code, Symfony répond. Sinon, la requête est transmise au code legacy, qui continue de fonctionner comme avant.

Le choix du premier périmètre est stratégique. Une zone qui évolue souvent rapporte vite, une zone isolée limite le risque. L'idéal combine les deux. Le même raisonnement s'applique avec Laravel, qui sait aussi cohabiter avec un code existant derrière un point d'entrée commun.

Ce pattern a un coût : pendant la transition, il faut maintenir deux façons de faire et un socle partagé. Il ne vaut donc la peine que si la transition avance. Une migration abandonnée à mi-chemin laisse un système plus complexe que celui de départ.

Questions fréquentes sur la modernisation d'une application PHP

Faut-il réécrire entièrement une application PHP ancienne ?

Rarement. Une réécriture complète fait repartir de zéro des règles métier souvent mal documentées, qui ne vivent plus que dans le code. Une migration progressive conserve ces règles et livre de la valeur à chaque étape.

Peut-on passer directement de PHP 7 à PHP 8.4 ?

Techniquement, on installe la version de son choix. Mais les changements incompatibles s'additionnent d'une version à l'autre. Lire chaque guide de migration intermédiaire et tester à chaque palier permet de savoir quelle modification a cassé quoi.

La refactorisation automatisée suffit-elle ?

Non. Elle traite très bien les transformations mécaniques : signatures, syntaxe obsolète, fonctions renommées. Elle ne remplace ni les tests, ni l'analyse statique, ni la relecture humaine des changements de comportement.

Combien de temps prend une modernisation ?

Cela dépend de la taille du code, de l'écart de version, des extensions utilisées et de la présence de tests. Un audit préalable reste le seul moyen d'obtenir une estimation sérieuse pour un projet donné.

Pour une entreprise qui préfère se faire accompagner, des prestataires comme Doing, à Saint-Étienne, proposent la reprise d'application legacy, l'audit préalable et la maintenance évolutive, avec une équipe d'une trentaine de collaborateurs qui travaille sur PHP avec Laravel et Symfony.