Moderniser une application Symfony legacy sans tout réécrire

La modernisation doit d’abord réduire les risques

Une application Symfony existante peut souvent évoluer sans réécriture complète. Le choix dépend de son état, de ses dépendances, des besoins métier et des contraintes de migration. Il faut d’abord déterminer les comportements à préserver et les obstacles aux changements, sans considérer une approche comme systématiquement plus sûre.

Les bases sont opérationnelles : environnements reproductibles, sauvegardes de la base avec restauration éprouvée, déploiements prévisibles et processus critiques documentés, comme la prise de commande. Des tests de bon fonctionnement, ou smoke tests, vérifient rapidement les parcours élémentaires. Les règles importantes et les intégrations demandent des tests ciblés ; les tests de caractérisation consignent le comportement existant sans prouver sa justesse.

Repérer les responsabilités dans le code existant

Contrôleurs, dépôts de données ou méthodes de requête, types de formulaire et validateurs, services partagés, commandes console et tâches planifiées sont autant de points de départ. Leurs responsabilités ne sont pas forcément bien délimitées. Les gabarits de vue montrent ce que les utilisateurs voient et manipulent, sans constituer automatiquement des contrats publics d’API.

Délimiter une modification, puis la vérifier

Les risques prioritaires et les dépendances déterminent l’ordre des travaux. Ce cycle est un repère, pas un calendrier de mise à niveau imposé :

Comprendre les processus → protéger les comportements clés
Délimiter → modifier → vérifier
  Refusé : corriger et vérifier de nouveau
  Accepté : préparer la reprise, puis déployer
Observer les effets → décider de la suite

Une étape peut isoler des requêtes, sortir des décisions métier d’un contrôleur ou remplacer un ancien service derrière une interface. Déplacer une requête dans un dépôt ne la rend pas plus rapide en soi. Une interface n’est utile que si elle crée une véritable séparation des responsabilités.

PHPStan peut être introduit progressivement sur le code modifié et ses dépendances pertinentes. Il détecte des problèmes de types et de contrats, pas toute erreur de comportement. Les tests et l’analyse statique se complètent sans supprimer le risque de migration.

Les dépendances se mettent à jour par groupes compatibles et maîtrisables, selon les guides de mise à niveau concernés, en visant des versions maintenues. Certaines évolutions exigent des changements coordonnés. La validation et le plan de reprise doivent aussi couvrir les données : revenir à l’ancien code ne suffit pas nécessairement à annuler une migration.

Quand envisager un remplacement

Une réécriture peut convenir à un produit profondément différent ou à un système dont la technologie ne répond plus aux exigences de sécurité ou d’exploitation à un coût acceptable. La comparaison avec une modernisation progressive doit inclure les données historiques, les intégrations, la coexistence temporaire, la vérification des comportements requis et les modalités de bascule. Aucun facteur ne tranche seul.

Les règles existantes doivent être comprises, pas conservées automatiquement. Certaines portent des connaissances métier essentielles ; d’autres méritent une évolution décidée explicitement.

L’approche GiSoft

GiSoft se concentre sur les changements qui lèvent des obstacles concrets au développement. Nous précisons les comportements requis, ajoutons des tests là où ils réduisent le risque, observons les effets des déploiements et gardons un périmètre maîtrisable. L’objectif est une application plus facile à faire évoluer, pas simplement réorganisée.