ÉTUDE DE CAS 02 — LOGICIEL BESTT · GROUPE AURIOR
Migrer Symfony 5 → 7 / React 18 sans arrêter le produit
Deux produits en exploitation continue, un framework en fin de support, des milliers de lignes de code mort et aucun test. La migration qu'on repousse toujours — menée ici en six mois par produit, refonte UI comprise.
— LE PROBLÈME
Les deux produits tournaient sur Symfony 5, avec des dépendances figées depuis des années : impossibles à mettre à jour sans casser, y compris pour des correctifs de sécurité. Le code accumulait des milliers de lignes mortes ou de WIP abandonnés — chaque évolution devenait une fouille archéologique.
Et surtout : aucun test automatisé. Chaque mise en production reposait sur des vérifications manuelles, donc sur la chance. Migrer dans ces conditions, c'est le scénario classique du big bang qui dérape. Il fallait une autre approche.
— LES DÉCISIONS D'ARCHITECTURE
1Supprimer avant de migrer
Premier chantier : purger le code mort et les WIP abandonnés. Des milliers de lignes en moins, c'est autant de surface qu'on ne migre pas, qu'on ne teste pas, qu'on ne débogue pas. La migration réelle a porté sur un périmètre nettement réduit — et connu.
2Des paliers, pas un big bang
Migration par versions intermédiaires (5.4 → 6.4 → 7), en lots courts mergés en continu — pas de branche longue qui diverge pendant des mois. À chaque palier, le produit reste livrable : le run et le support client continuent en parallèle.
3Mantine plutôt qu'un design system maison
Pour la refonte du front en React 18, j'ai tranché en faveur de Mantine : composants accessibles, theming propre, vélocité immédiate pour une petite équipe. Construire notre propre bibliothèque aurait coûté des mois pour un résultat moins robuste.
4Les tests comme prérequis, pas comme finition
Chaque module migré devait arriver testé : PHPUnit côté back, Vitest côté front, Playwright en e2e sur les parcours critiques. Les e2e ont servi de filet anti-régression pendant toute la refonte UI — on refond l'écran, le parcours doit rester vert.
— L'IMPLÉMENTATION
Le rythme : des lots courts, cadrés par des spécifications techniques que je rédigeais puis répartissais dans l'équipe, avec revue de code systématique. La CI (GitLab + Jenkins, héritée du chantier précédent) exécutait l'ensemble des suites à chaque merge request.
La refonte Mantine s'est faite écran par écran, à périmètre fonctionnel constant — pas de « pendant qu'on y est ». Les demandes d'évolution étaient notées, priorisées, et traitées après stabilisation de chaque module.
— LES RÉSULTATS
AVEC LE RECUL
« Le duo gagnant : supprimer d'abord, migrer ensuite. La seule chose que je ferais plus tôt, c'est embarquer l'équipe sur Playwright dès la première semaine — les e2e ont changé notre rapport au risque. »