Migration PHP legacy vers Symfony : moderniser sans arrêter la production
Votre application tourne depuis des années. Elle fait vivre votre activité, elle contient des règles métier que personne n'a jamais écrites ailleurs, et son socle technique n'est plus tenable. Une migration PHP legacy bien menée ne consiste pas à tout jeter pour repartir de zéro : elle consiste à déplacer votre application vers une base à jour en gardant votre métier intact, morceau par morceau.
Je suis Marc-Antoine Boyer-Dager, développeur Symfony freelance basé à Saint-Denis (97400), La Réunion. Je travaille en local sur l'île et en remote pour la France métropolitaine. Ma spécialité : les migrations legacy. PHP 5 vers 8, Symfony 3 vers 7, monolithes vieillissants vers des architectures propres et testées. J'interviens sur du code en production, avec des utilisateurs réels et des contraintes métier que personne ne peut se permettre d'ignorer.
Les signes qu'il est temps d'agir
La plupart des dirigeants que je rencontre ne me contactent pas pour « faire du Symfony ». Ils me contactent parce que quelque chose bloque.
La version de PHP n'est plus maintenue
Une application en PHP 5 ou en PHP 7.x non supporté ne reçoit plus de correctifs de sécurité. Votre hébergeur finira par vous forcer la main, souvent avec un préavis court. Une migration PHP 5 vers PHP 8 anticipée coûte moins cher qu'une migration faite sous la pression d'une coupure annoncée.
Chaque modification casse autre chose
C'est le symptôme le plus fiable de la dette technique PHP : le code n'a pas de tests, les responsabilités sont mélangées, et personne n'ose plus toucher certains fichiers. Le développement ralentit jusqu'à ce que la moindre évolution devienne un projet en soi.
Vous dépendez d'une seule personne
Quand un seul développeur comprend l'application, vous ne pilotez plus votre outil de production. Une migration est aussi l'occasion de rendre le code lisible par d'autres et de documenter les décisions.
Un framework figé dans une version ancienne
Une application Symfony 2 ou 3 vous prive des outils actuels, des bundles maintenus et des recrutements faciles. La migration Symfony 3 vers Symfony 7 se fait par paliers, version par version, pas en un saut unique.
Ce que je fais concrètement
Je prends en charge la partie technique de bout en bout, sur une stack que je maîtrise au quotidien : Symfony 7, PHP 8.3, Doctrine, MariaDB.
- Audit de code PHP legacy : cartographie de l'existant, inventaire des dépendances, repérage des zones à risque et des règles métier enfouies dans le code.
- Plan de migration incrémentale : découpage en lots livrables, avec un ordre qui traite d'abord ce qui bloque et ce qui menace la sécurité.
- Mise à niveau du langage et du framework : passage aux versions supportées de PHP et de Symfony, remplacement des composants abandonnés.
- Reprise de données : scripts de migration de schéma et de contenu, avec vérification de l'intégrité avant bascule.
- Refonte d'application métier PHP quand la réécriture d'un module est plus raisonnable que sa réparation, ce qui se décide avec vous, chiffres de complexité en main.
- Tests automatisés posés au fur et à mesure, pour que chaque lot migré soit vérifiable autrement qu'à l'œil.
Comment je procède
- Audit et cadrage. Je lis le code, j'interroge vos équipes, je liste les fonctionnalités réellement utilisées. Cette étape produit un document : état des lieux, risques classés, options de migration avec leurs conséquences. Vous pouvez arrêter là et repartir avec le document, il vous appartient.
- Plan de migration incrémentale. Nous découpons le chantier en lots qui partent en production les uns après les autres. Chaque lot a un périmètre, un critère de réussite et une procédure de retour arrière. L'objectif est simple : à aucun moment vous ne devez avoir deux versions de votre application qui s'ignorent.
- Exécution par lots, avec l'ancienne application en service. Je travaille sur des branches, je pose des tests sur le code que je touche, je livre par incréments. L'ancien et le nouveau cohabitent le temps nécessaire. Les bascules se font sur des créneaux choisis avec vous, jamais un vendredi soir par surprise.
- Transfert de compétences. Je documente les décisions d'architecture, les procédures de déploiement et les points de vigilance. Si vous avez une équipe interne, je la forme sur le code livré. Je suis certifié FPA et j'ai formé plus de 50 apprenants, donc la transmission fait partie du travail, elle n'est pas un bonus en fin de mission.
Un choix fait sans trace écrite, c'est une dette de contexte. C'est pour cette raison que chaque décision non évidente est consignée, avec son contexte et ses alternatives écartées.
Pourquoi la migration incrémentale plutôt que la réécriture complète
La réécriture totale est séduisante sur le papier. Dans les faits, elle demande de reproduire des années de règles métier à partir d'une documentation qui n'existe pas, pendant que l'ancienne application continue d'évoluer. Le nouveau chantier court derrière l'ancien et la bascule est repoussée.
La migration incrémentale accepte l'existant comme point de départ. Vous voyez des résultats en production tôt, vous gardez la main sur le budget, et vous pouvez suspendre le chantier entre deux lots si votre activité l'exige. Sur des applications avec des utilisateurs réels, c'est la seule approche qui laisse une marge de manœuvre.
Travailler avec un développeur Symfony freelance à La Réunion
J'ai sept ans d'expérience sur des applications en production. À Saint-Denis et dans le nord de l'île, je me déplace pour les réunions de cadrage et les phases sensibles. Pour le reste, et pour mes clients en métropole, je travaille en remote avec un rythme de points réguliers et un accès direct à l'avancement.
Vous traitez avec la personne qui écrit le code. Pas de couche commerciale, pas de relais : les questions techniques trouvent une réponse le jour où vous les posez.
Questions fréquentes
- Combien de temps prend une migration PHP 8 ?
- Cela dépend grandement de l'outil audité : taille du code, nombre de dépendances abandonnées, présence ou non de tests. À titre indicatif, l'audit seul prend de 3 à plusieurs semaines selon ces critères. Je donne une fourchette précise pour la migration elle-même une fois l'audit fait, jamais avant.
- Faut-il tout réécrire ?
- Presque jamais. La réécriture complète se justifie sur des périmètres restreints, par exemple un module dont la logique est devenue incompréhensible ou dont le besoin métier a changé. Pour le reste, on migre l'existant. Votre code contient des années d'arbitrages métier, les jeter revient à les payer une seconde fois.
- Que devient mon code métier ?
- Il est identifié pendant l'audit, isolé, testé, puis déplacé. C'est le point le plus délicat d'une migration : ces règles sont rarement documentées et souvent dispersées. Je les extrais et je les couvre par des tests avant de toucher à quoi que ce soit, pour que le comportement observé reste le même après bascule.
- Mon application va-t-elle s'arrêter pendant la migration ?
- Non, c'est le principe de l'approche par lots. L'application reste en service pendant tout le chantier. Les bascules qui demandent une fenêtre d'indisponibilité sont annoncées à l'avance, planifiées sur un créneau que vous choisissez, et accompagnées d'une procédure de retour arrière testée.
- Peut-on continuer à faire évoluer l'application pendant la migration ?
- Oui, avec un arbitrage. Les correctifs et les évolutions urgentes passent, mais les nouvelles fonctionnalités sont mieux placées sur la partie déjà migrée que sur l'ancienne, sinon vous payez le travail deux fois. Nous fixons cette règle au cadrage.
- Comment savoir si mon application vaut la peine d'être migrée ?
- C'est justement la question à laquelle l'audit de code PHP legacy répond. Il compare le coût de la migration à celui du maintien en l'état et à celui d'un remplacement par un outil du marché. Il arrive que la conclusion soit de ne pas migrer, et je vous le dirai.
- Travaillez-vous uniquement à La Réunion ?
- Non. Je suis basé à Saint-Denis et j'interviens sur place sur l'île, mais je travaille aussi en remote pour des clients en France métropolitaine. Le décalage horaire est plutôt un avantage : une partie du travail est faite avant le début de votre journée.
Parlons de votre application
Si vous hésitez à lancer le chantier, commencez par l'audit. Vous saurez ce que contient votre code, ce qu'il coûte de le garder en l'état, et ce que la migration implique vraiment. Aucun engagement de refonte n'est nécessaire pour en parler. Prenez rendez-vous pour un premier échange. Décrivez-moi votre application, sa version de PHP et ce qui vous inquiète, et je vous dis dès cet appel si je suis la bonne personne pour ce chantier.