Reprendre une plateforme financière Symfony sans jamais l'arrêter

Ce que j’ai repris

Le client est une société de gestion de fonds. Toute son activité passe par une plateforme privée, accessible sur identifiants, utilisée par plus de 400 personnes. Elle tourne sous Symfony, le framework PHP que j’utilise pour les plateformes sur mesure.

En août 2025, son dirigeant me la confie. Elle est déjà passée entre les mains de deux prestataires avant moi. Voici ce que j’ai trouvé en ouvrant le projet.

Ce que trois prestataires laissent derrière eux

Une plateforme reprise, ce n’est pas une liste de bugs. C’est un empilement.

Chaque intervenant a apporté ses conventions, ses outils et ses habitudes. Personne n’a retiré ceux du précédent. Dans la base de données, les tables portaient des noms dans trois langues différentes selon la période où elles avaient été créées.

Mais le symptôme le plus net n’était pas dans le code métier. Il était dans les dépendances. Pour générer un simple document PDF, la plateforme embarquait quatre bibliothèques différentes. Quatre outils pour une seule fonction, installés par trois personnes qui ne se sont jamais parlé.

Le vrai problème n’était pas technique

Construire une plateforme financière de zéro, c’est déjà difficile. En reprendre une écrite par d’autres, c’est pire : il faut comprendre des décisions qu’on n’a pas prises, pour des raisons qu’on ne connaît pas.

Trois contraintes se sont additionnées dès le premier jour.

• La plateforme tournait, avec des clients dessus. Rien ne pouvait s’arrêter. Il fallait réparer un système vivant.
• Un nouveau service devait sortir, et la date était fixée. Donc pas seulement réparer : faire évoluer en parallèle pour accueillir un produit qui n’existait pas encore.
• La donnée financière n’est pas mon métier. Je sais construire un système. Je ne suis pas gestionnaire de fonds. Les calculs devaient être justes, et la seule façon d’y arriver, c’était de travailler serré avec le client plutôt que d’interpréter des spécifications tout seul dans mon coin.

C’est la deuxième qui commandait tout : la date. Sans elle, j’aurais pris une autre décision.

Je ne travaille pas pour mes clients. Je travaille avec eux. Sur un système financier, ce n’est pas une posture — c’est la seule façon d’avoir les bons chiffres.

La décision, et ce que j’ai écarté

J’ai posé moi-même la question de la réécriture complète, dès le début. C’était la solution la plus confortable pour moi : repartir propre, avec mes conventions, sans hériter des choix de personne.

Je l’ai écartée en quelques jours, pour trois raisons qui n’ont rien de technique.

• Trop long et trop cher pour tenir la date du nouveau produit.
• Des clients étaient déjà sur la plateforme. Il fallait corriger les blocages de toute façon — réécriture ou pas, ce travail-là devait être fait.
• Payer deux fois le même système pour arriver plus tard au même endroit, ça ne se défend pas.

J’ai donc stabilisé l’existant tout en développant le nouveau service dessus. C’est moins gratifiant à raconter qu’une réécriture. C’est nettement plus utile au client. C’est aussi ce que décrit ma méthode de travail : comprendre avant d’agir, structurer avant de produire.

Ce que ça a donné

Le pari tenait sur une seule promesse : livrer à temps sans jamais couper le service. Un an plus tard, c’est le résultat que je retiens.

Le volume de travail, mesuré honnêtement

Depuis mon premier commit sur le projet :

Ces chiffres portent sur le code applicatif seul : logique métier, gabarits, configuration, migrations. Les bibliothèques tierces, les assets compilés et les fichiers générés en sont exclus. Ils ajoutaient 443 000 lignes qui n’ont rien à voir avec le travail réalisé, et les compter aurait multiplié le chiffre par cinq sans rien dire de vrai.

Les 31 000 lignes retirées comptent autant que celles ajoutées. Sur une plateforme héritée, retirer du code pendant qu’on lui ajoute des fonctionnalités, c’est ce qui distingue la stabilisation de l’empilement.

Ce que la mise en production est devenue

Ce qui a changé, ce n’est pas qui appuie sur le bouton. C’est tout ce qu’il y a autour.

Un modèle de branches Git qui permet de fusionner librement, de ne rien perdre et de revenir vite sur la branche principale en cas de correction urgente. Et un fichier Makefile qui regroupe en une seule commande les opérations serveur qui revenaient à chaque mise en ligne.

Un an plus tard, la mission continue

Une mission de sauvetage s’arrête quand l’incendie est éteint. Celle-ci ne s’est pas arrêtée.

Le mandat initial était clair : réparer ce qui bloquait, et livrer le nouveau service à la date prévue. Les deux ont été faits. Ce qui a suivi n’était pas prévu au départ — je suis depuis le partenaire technique de la plateforme. Je la fais évoluer, je la maintiens, et je reste disponible pour les décisions techniques qui engagent l’entreprise, avec une réserve de 40 heures garantie chaque mois.

Rien n’oblige un dirigeant à reconduire une collaboration. Elle se rejoue à chaque mission, à chaque devis, à chaque échéance tenue ou manquée. Celle-ci dure depuis août 2025 parce qu’elle continue d’être utile — c’est le seul type de relation qui m’intéresse, et c’est aussi la raison pour laquelle je ne prends que quelques projets de ce type à la fois.

C’est enfin ce que la décision de départ a rendu possible. Une plateforme stabilisée progressivement se fait évoluer ensuite, mois après mois. Une plateforme reconstruite dans l’urgence pour tenir une date, beaucoup moins.

L’outil est en place. Je ne le laisse pas décider.

Le déploiement automatisé existe sur ce projet. L’outillage est installé, configuré, prêt à pousser une version en production sans que personne n’intervienne. Je ne m’en sers pas en automatique.

Ce n’est pas un retard, c’est une décision. Une plateforme financière en production, avec des utilisateurs qui consultent leurs données au moment où vous déployez, ce n’est pas l’endroit où l’on découvre un incident quinze minutes après tout le monde. Je déclenche la mise en production, je la regarde se dérouler, et je suis là si quelque chose se passe mal.

Ce que j’ai automatisé, c’est le contenu de l’opération, pour qu’aucune étape ne soit oubliée. Pas la responsabilité de la lancer. Le jour où le rythme de livraison et la couverture de tests le justifieront, le déclenchement automatique s’activera en une ligne. Aujourd’hui, ce serait un risque pris pour un confort qui n’est que le mien.

Ce que ce projet a demandé de moi

La compétence qui a le plus servi ici n’est pas technique. C’est de poser les bonnes questions au bon moment.

Je ne suis pas gestionnaire de fonds. Quand un calcul m’échappait, je n’ai pas deviné : j’ai demandé. C’est ce qui évite les erreurs sur des chiffres qui engagent le client. Et c’est aussi ce qui fait gagner du temps — le temps d’un dirigeant est précieux, le mien aussi, et une question de deux minutes coûte toujours moins cher qu’une semaine passée dans la mauvaise direction.

Questions fréquentes sur la reprise d’un projet existant