Startup B2B
Comment une marketplace B2B a débloqué son développement produit grâce à une migration de framework en 3 semaines
Contexte
Cette startup opère une marketplace B2B dans le secteur de la restauration. La plateforme est au cœur de l'activité : c'est l'outil quotidien des utilisateurs.
L'application avait été développée sur Symfony 3.5, une version du framework PHP dont le support a pris fin en 2021. Avec le temps, la situation s'était dégradée progressivement : les bugs s'accumulaient, les bibliothèques tierces n'étaient plus compatibles, et il devenait impossible de monter la version de PHP. En pratique, l'équipe ne pouvait plus corriger les problèmes existants ni développer les nouvelles fonctionnalités prévues dans la roadmap.
Le dirigeant, sans profil technique, n'avait pas de ressources internes pour évaluer la situation ni pour mener la migration. Le besoin était précis : débloquer le développement le plus vite possible, dans un budget serré.
Défis
Défi #1 — Trouver la bonne stratégie de migration sur un projet fortement contraint
L'écart entre la version en place (Symfony 3.5) et les versions récentes du framework était trop important pour une montée de version progressive. Le changement de paradigme introduit par Symfony 4 rendait l'upgrade pas-à-pas instable et chronophage. Après un audit du code et des dépendances, la décision a été de repartir d'une base propre sur Symfony 5.4 et de réintégrer le code métier module par module.
Cette approche était la seule viable dans le temps imparti, mais elle impliquait de gérer manuellement chaque dépendance : bibliothèques abandonnées à remplacer par des alternatives, librairies développées en interne par un ancien membre de l'équipe à réintégrer autrement, images Docker et Elasticsearch devenues indisponibles à recréer. Aucune documentation complète n'existait, et personne en interne ne pouvait répondre aux questions sur l'historique des choix techniques.
Défi #2 — Livrer une application fonctionnelle sans filet de sécurité complet
Le projet disposait de tests automatisés, mais leur couverture était partielle. Sur une migration de cette ampleur, où chaque composant pouvait se comporter différemment après la transition, les tests existants ne suffisaient pas à garantir que rien ne cassait. Il n'y avait pas non plus d'environnement de staging fiable ni d'interlocuteur technique côté client pour valider les cas métier complexes.
La validation a été faite en combinant les tests automatisés disponibles avec des passes manuelles systématiques sur l'ensemble des parcours utilisateurs. L'objectif était de livrer une application stable sur les fonctionnalités existantes, en toute transparence sur ce qui restait à faire pour atteindre la cible technique finale.
Résultats
- La plateforme a été migrée vers Symfony 5.4 en 3 semaines, rendant le développement à nouveau possible. Les bugs liés à l'obsolescence du framework ont été éliminés, et l'écosystème technique est redevenu maintenable.
- Les parcours utilisateurs critiques fonctionnent sans régression. La migration n'a pas impacté l'expérience des restaurateurs et fournisseurs qui utilisent la plateforme au quotidien.
- Un nouveau lead tech a pu reprendre le projet sur des bases saines. La mission a été conçue pour permettre une passation fluide : le code est structuré, l'environnement de développement fonctionne, les prochaines étapes sont identifiées.
- La migration n'est pas terminée, et c'était le plan. Le passage à PHP 8 et la modernisation de l'architecture restent à faire. La mission a permis de débloquer la situation et de poser le socle pour la suite, dans le budget convenu. Le lead tech arrivé ensuite dispose d'une feuille de route claire pour continuer.
Ce qu'on a appris
Sur une intervention d'urgence avec un budget serré, la tentation est de promettre une résolution complète. C'est un piège. Mieux vaut cadrer très clairement ce qui sera fait et ce qui ne le sera pas, dès le départ. Dans ce cas, la cible finale était PHP 8 avec une architecture modernisée. Le budget permettait d'atteindre Symfony 5.4 sur PHP 7, ce qui débloquait le développement sans aller jusqu'à la cible. Poser ce cadre dès l'audit évite les malentendus en fin de mission.
L'autre point : quand il n'y a personne en face côté tech (pas de CTO, pas de lead, pas de développeur), chaque question sur l'historique du code reste sans réponse. Le temps passé à comprendre des choix passés non documentés peut facilement doubler la charge de travail. C'est un facteur à intégrer dans le chiffrage dès le départ, pas à découvrir en cours de mission.
