Strangler Fig : migration d’un monolithe PHP existant vers Laravel sans gel des fonctionnalités

Toute application PHP legacy finit par cette réunion. Le code a dix ans, personne ne veut toucher au module de commandes, le framework n’a pas eu de version depuis 2019, et quelqu’un propose une réécriture. Dix-huit mois, dit-on. Gel des fonctionnalités pendant ce temps.

Ce type de projet échoue presque toujours, pour la même raison : l’activité ne peut pas s’arrêter dix-huit mois, donc on continue de modifier l’ancien système, le nouveau prend du retard, et la migration devient une cible mouvante. Deux ans plus tard, deux systèmes, dont un inachevé.

Le modèle strangler fig évite cela en supprimant la bascule unique. Les nouvelles fonctionnalités sont développées sous Laravel, les existantes migrées route par route, et le trafic est dirigé vers le système qui gère chaque chemin. L’ancienne application rétrécit jusqu’à disparaître.

La frontière de routage

Tout repose sur la capacité à envoyer une requête vers l’une ou l’autre application sans que l’utilisateur ne s’en aperçoive. Placez un reverse proxy devant les deux et routez selon le chemin.

• Par défaut, tout vers l’application legacy dès le premier jour, ainsi le proxy ne change rien et peut être déployé indépendamment de la migration.
• Migrez une route à la fois en l’ajoutant à la liste Laravel du proxy. C’est désormais votre mécanisme de migration, et il s’agit d’un simple changement de configuration.
• Gardez le retour arrière trivial. Revenir à l’ancien système pour une route doit être un changement de configuration et un rechargement, pas un déploiement. Vous en aurez besoin.
• N’ajoutez pas de logique complexe au routage. Les préfixes de chemin suffisent. Router selon le segment utilisateur ou un feature flag semble séduisant mais double le nombre d’états à gérer.

Cette seule brique d’infrastructure transforme un pari de dix-huit mois en une suite de décisions hebdomadaires.

Sessions et authentification : commencez par là

Le premier vrai obstacle, celui qui bloque les migrations bâclées : un utilisateur doit pouvoir se connecter sur une page legacy et rester authentifié lors d’une requête suivante sur Laravel.

1. Déplacez le stockage de session là où les deux applications peuvent lire — Redis ou la base de données — avant de migrer la moindre route.
2. Définissez un format de sérialisation commun. Deux applications PHP avec des frameworks différents ne sérialisent pas forcément la session de la même façon. Testez-le explicitement.
3. Partagez le domaine et le chemin du cookie, et alignez son nom.
4. Confiez l’authentification à un seul système. Généralement Laravel, une fois la route de connexion migrée, l’application legacy ne faisant alors que lire la session.
5. Testez l’expiration et la régénération de session à la frontière. Se déconnecter d’un côté tout en restant connecté de l’autre est une faille de sécurité, pas un simple désagrément.

La frontière de la base de données

La solution pragmatique pour la plupart des migrations : les deux applications partagent une seule base de données, sans tenter de refondre le schéma pendant la migration.

Cela dérange, et c’est normal. Migrer le code et le schéma en même temps double les causes possibles de chaque problème et vous empêche de déplacer une seule route de façon indépendante. Passez d’abord sur Laravel ; améliorez le schéma ensuite, quand vous n’avez plus qu’une seule base de code à faire évoluer.

• Mappez le schéma existant avec des modèles Eloquent tel quel, y compris les noms de tables que vous n’auriez jamais choisis.
• Écrivez dans les mêmes tables, pour que les deux systèmes partagent la même source de vérité, sans couche de synchronisation susceptible de dysfonctionner.
• Attention aux triggers et procédures stockées hérités : ils contiennent souvent de la logique métier non documentée, qui s’exécutera aussi sous Laravel.
• Introduisez des migrations uniquement pour les nouvelles tables. Ne laissez pas le système de migration de Laravel prendre le contrôle du schéma existant en cours de projet.
• Surveillez le code hérité qui écrit des horodatages ou des identifiants d’une façon inattendue pour Eloquent. C’est une source fréquente de bugs subtils.

Par quoi commencer la migration

L’ordre compte plus que la vitesse.

1. Commencez par une fonctionnalité à faible risque et visible : une page statique, un formulaire de contact, une section d’aide. L’objectif est de valider le routage, la gestion de session et le déploiement de bout en bout, pas d’apporter de la valeur.
2. Les nouvelles fonctionnalités, à partir de maintenant. Tout ce qui est développé après le premier jour va sur Laravel. C’est ce qui rend la migration auto-financée : la feuille de route finance la croissance du nouveau système.
3. Passez ensuite aux zones les plus modifiées. Ce que l’équipe modifie le plus souvent bénéficie le plus d’une base de code maintenable, et l’effort est immédiatement rentable.
4. Les pages à fort trafic côté client, où la migration apporte aussi des gains de performance et de SEO.
5. Le checkout, le paiement et le traitement des commandes en dernier. Risque maximal, coût d’erreur maximal, et à ce stade l’équipe aura déjà migré une douzaine de cas plus simples.
6. L’administration et le back-office en tout dernier, sauf si cela bloque réellement. Les utilisateurs internes tolèrent l’imperfection ; les clients non.

L’instinct pousse à commencer par le pire module. Résistez. Démarrer par la partie la plus difficile, c’est cumuler la première migration et la découverte de tous les problèmes d’infrastructure en même temps.

Maintenir l’avancement de la feuille de route

C’est tout l’enjeu, et il faut le protéger délibérément.

• Fixez une répartition stable – par exemple 70 % feuille de route, 30 % migration – et tenez-la. Une migration qui absorbe toute la capacité devient un problème métier en moins d’un trimestre, et ces problèmes sont arrêtés.
• Faites en sorte que chaque route migrée apporte quelque chose. Corrigez un bug connu, améliorez la page, ajoutez une petite fonctionnalité. Une migration sans valeur visible pendant six mois perd son sponsor.
• Communiquez l’avancement en routes migrées et fichiers hérités supprimés. Supprimer du code est la seule preuve incontestable qu’une migration « strangler fig » progresse.
• Ne touchez pas au code hérité sauf pour corriger des bugs. Toute amélioration sur un système voué à disparaître est une dépense inutile.

Les modes d’échec

1. Blocage à 60 %. Les routes simples sont migrées, il ne reste que les difficiles, et la douleur a suffisamment diminué pour que l’urgence disparaisse. Vous maintenez alors deux systèmes indéfiniment, ce qui est pire que l’un ou l’autre. Définissez à l’avance ce qui déclenche la finalisation du projet.
2. Construire une couche d’abstraction entre les deux systèmes. Cela semble être une bonne pratique, mais c’est un troisième système à maintenir, qui survivra à la migration qu’il devait servir.
3. Migrer le schéma en même temps. Cela double le nombre de variables à chaque incident.
4. Manque de discipline sur la suppression. Si le code hérité n’est pas supprimé au fur et à mesure de la migration des routes, vous ne migrez pas, vous dupliquez.
5. Sous-estimer ce qui n’est pas documenté. Tâches cron, endpoints de webhook, rapports mensuels de la finance, intégrations oubliées. Faites-en l’inventaire avant de commencer ; si vous les découvrez en production, ce sont eux qui vous trouveront.

Quand ne pas procéder ainsi

La méthode « strangler fig » n’est pas toujours adaptée. Ne l’utilisez pas si l’application héritée est réellement petite : en dessous de quelques milliers de lignes, une réécriture directe est plus rapide et la gestion du double système est inutile. N’y recourez pas si le système hérité est voué à être abandonné dans son ensemble plutôt que remplacé. Et évitez-la si c’est la logique métier elle-même qui doit changer : migrer une logique que vous comptez supprimer, c’est faire le travail deux fois.

C’est le schéma suivi pour la plupart de nos prestations de développement Laravel sur des systèmes hérités, en complément de l’étape d’audit décrite dans reprendre une base de code PHP existante. Notre offre plateforme Laravel et nos prestations de modernisation PHP sur mesure couvrent les deux volets du problème.

Faites valider la séquence

Les choix de routage, de gestion de session et de séquencement déterminent la réussite. Nous les examinerons avant que vous n’engagiez vos ressources. Contactez notre équipe : réponse sous un jour ouvré.