Institut de formation politique - Janvier 2020 - Présent - Paris
Reprise d’une application PHP/Laravel critique d’environ 100 000 lignes de code,
sans aucun test et dont le développeur historique avait quitté le projet.
L’application reposait sur PHP 7 et Laravel 5, présentait des vulnérabilités
critiques, des traitements automatiques défaillants et de graves problèmes
de performances.
Sécurisation et stabilisation de l’existant, puis mise en place d’une stratégie
de modernisation progressive plutôt qu’une réécriture risquée. Le projet est
toujours en production et fait aujourd’hui l’objet d’une maintenance ponctuelle.
Une application critique devenue intouchable
L’IFP dispose d’une application métier développée sur mesure pour gérer ses campagnes de dons. Livrée en 2015 avec Laravel 5, elle avait été maintenue pendant plusieurs années avant de devenir progressivement difficile à faire évoluer.
Le problème est alors classique : l’application fait environ 100 000 lignes de code, mais ne dispose d’aucun test automatisé. Après plusieurs années d’évolution, il est devenu difficile de distinguer les comportements intentionnels des effets de bord ou des contraintes métier accumulées au fil du temps.
Au fil des années, les mises à jour et les évolutions ont donc été réduites au minimum. L’application repose toujours sur PHP 7 et Laravel 5 et accumule les problèmes : traitements automatiques défaillants, problèmes de performances et plusieurs dizaines de bugs plus ou moins gênants.
La situation était particulièrement sensible : cette application joue un rôle important dans le fonctionnement de l’IFP. Sa disponibilité constituait donc un enjeu important pour l’organisation.
Reprendre un système que je ne connaissais pas
Lorsque l’IFP fait appel à moi en janvier 2020, je possède une ancienne expérience de PHP acquise lors de stages, une dizaine d’années auparavant, mais aucune expérience de Laravel.
Le client me connaît cependant par l’intermédiaire d’un réseau commun et sait que je commence alors à me spécialiser dans la reprise de systèmes existants. Cette confiance permet de commencer directement par le problème plutôt que par la technologie.
En une semaine, je deviens suffisamment opérationnel pour comprendre le fonctionnement général de l’application et intervenir dessus. Le premier mois est consacré à éteindre les incendies sans en provoquer de nouveaux.
Les bugs sont corrigés un par un, avec prudence, en tenant compte de l’absence totale de tests. Les traitements automatiques défaillants sont remis en état, notamment ceux qui intervenaient dans les processus financiers de l’organisation.
La sécurité constitue également une priorité immédiate. L’application présente plusieurs vulnérabilités nécessitant une intervention rapide. Avant d’engager une opération de modernisation, la priorité est donc de réduire son exposition et de renforcer sa sécurité.
Cette première phase n’a pas pour objectif de rendre le logiciel moderne. Elle vise simplement à faire en sorte que l’outil puisse continuer à faire son travail sans mettre l’organisation en danger.
Ne pas réécrire pour le plaisir de réécrire
Une fois les urgences maîtrisées, la question de la mise à niveau de l’application se pose naturellement. Une réécriture complète est alors chiffrée à plusieurs dizaines de milliers d’euros, mais son coût et son niveau de risque rendent cette approche difficile à justifier dans l’immédiat.
Une mise à niveau directe du legacy aurait cependant nécessité de modifier un système d’environ 100 000 lignes de code sans aucun filet de sécurité. Sans tests et avec une connaissance incomplète des comportements historiques de l’application, une telle opération aurait transformé un problème de maintenabilité en risque de régression généralisée.
La stratégie retenue est donc différente : conserver l’existant suffisamment longtemps pour continuer à faire fonctionner le métier, tout en construisant une voie de sortie progressive.
Le projet est assaini et intégré à un pipeline d’intégration continue. Cette nouvelle capacité permet notamment de réutiliser proprement l’application pour un autre projet.
Un rapport sur l’état du système est également produit afin de donner au client une vision claire de la dette technique et du coût réel d’une remise à niveau.
Construire à côté plutôt que casser l'existant
Lorsqu’un nouveau besoin apparaît après deux années de maintenance, il fournit l’occasion de construire une nouvelle base technique plutôt que d’ajouter une nouvelle couche de complexité à l’ancien système.
Un nouveau projet Laravel est créé avec une approche test-first (TDD), une intégration continue et un déploiement automatisé. Une variante du Strangler Fig Pattern est utilisée : Apache sert de routeur entre les deux applications. Lorsqu’une fonctionnalité existe dans le nouveau système, elle est servie par celui-ci ; sinon, la requête continue d’être traitée par le legacy.
Cette approche permet de migrer une fonctionnalité à la fois, sans imposer de réécriture globale ni interrompre le fonctionnement de l’application historique.
Une première fonctionnalité est ainsi extraite du legacy et reconstruite sur la nouvelle base.
Le risque est maîtrisé, la décision appartient au client
La modernisation complète n’a finalement pas été engagée : une fois le danger immédiat écarté, le client a choisi de conserver l’existant et de limiter la migration aux évolutions présentant un bénéfice suffisant.
Ce choix est cohérent avec l’objectif initial : l’application continue de fonctionner et peut être maintenue sans imposer immédiatement une réécriture représentant plusieurs dizaines de milliers d’euros.
La nouvelle architecture reste néanmoins une voie de sortie disponible si les priorités du client évoluent. La transformation n’est donc pas devenue une fin en soi : elle pourra reprendre lorsque le besoin métier le justifiera.
Six ans plus tard
L’application est toujours utilisée par l’organisation. Depuis 2020, j’interviens ponctuellement pour assurer sa maintenance et répondre aux besoins du client.
La relation a donc évolué d’une reprise urgente d’un système complexe vers une maintenance ponctuelle et durable. Je reste disponible lorsque le client en a besoin, sans chercher à imposer une modernisation ou un volume de prestation qui ne correspond pas à ses priorités.
Le projet illustre finalement une approche assez simple du legacy : sécuriser d’abord, comprendre ensuite, puis transformer uniquement lorsque le bénéfice justifie le risque et le coût.