Moderniser une application legacy sans tout réécrire

Face à une application vieillissante, la tentation est forte : tout refaire à neuf. C'est parfois nécessaire, mais c'est rarement la meilleure première étape, et c'est souvent la plus risquée. La bonne nouvelle, c'est qu'on peut moderniser une application legacy par étapes, sans grand soir technique, en gardant le système en marche. Voici comment éviter le piège du big-bang et avancer de façon réversible.

Pourquoi les réécritures « from scratch » échouent si souvent

Repartir d'une page blanche paraît séduisant. Dans les faits, c'est un piège classique. D'abord parce qu'un vieux système contient des années de règles métier accumulées, de cas particuliers et de traitements critiques : tout réécrire, c'est risquer d'en perdre une partie en route. Ensuite parce qu'une refonte complète crée un tunnel : des mois sans nouvelle valeur livrée, pendant lesquels l'ancien système continue d'évoluer, vous courez après une cible mouvante. S'ajoutent le « second-system effect » (la nouvelle version veut tout faire mieux et devient trop ambitieuse) et un budget qui dérape. Beaucoup de big-bangs finissent en projet abandonné, ou en application neuve… mais moins adaptée au terrain que l'ancienne.

Il y a aussi un effet d'organisation : pendant une réécriture intégrale, les équipes doivent maintenir l'ancien et construire le neuf, en double. La charge double, la motivation s'érode au fil des mois sans livraison, et le moindre imprévu repousse une date de bascule déjà lointaine. Le risque n'est pas seulement technique, il est humain et financier : c'est ce qui rend le big-bang si difficile à mener à terme.

Le principe : étrangler le legacy, pas le détruire

L'approche la plus éprouvée s'appelle le strangler fig pattern (le « figuier étrangleur », d'après Martin Fowler). L'image est parlante : plutôt que d'abattre l'arbre d'un coup, on fait pousser le nouveau système autour de l'ancien. On construit les nouvelles briques à côté, on redirige le trafic fonction par fonction vers le neuf, et le legacy rétrécit progressivement jusqu'à ne plus rien porter, on peut alors le débrancher en douceur. À chaque étape, le système reste opérationnel, et chaque bascule est petite, testable et réversible. C'est l'opposé exact du big-bang.

L'image vient d'un texte de Martin Fowler publié il y a plus de vingt ans, et il y ajoute un avertissement rarement cité : cette approche demande une discipline de découpage que la réécriture n'exige pas. Il faut être capable d'isoler une fonction, de router le trafic vers l'une ou l'autre implémentation, et d'accepter de faire coexister deux systèmes plus longtemps qu'on ne le souhaiterait. C'est le prix de la réversibilité, et c'est un prix bien inférieur à celui d'un projet qui ne livre rien pendant dix-huit mois. Texte d'origine : le motif Strangler Fig.

L'avantage décisif de cette approche, c'est qu'elle délivre de la valeur en continu. Au lieu d'attendre 18 mois une hypothétique mise en service, on livre des améliorations dès les premières semaines : un module plus rapide, une donnée enfin accessible, une intégration qui débloque une équipe. Le financement devient plus facile à défendre, car chaque étape produit un résultat visible, et le projet peut s'arrêter ou se réorienter à tout moment sans qu'on ait « tout misé » sur une bascule finale.

Les stratégies incrémentales, du moins au plus invasif

« Moderniser » n'est pas un geste unique : c'est un curseur entre risque et valeur. Du plus léger au plus profond :

• encapsuler avec des API : on laisse le legacy en place et on l'expose proprement derrière une façade, pour le connecter au reste du SI sans y toucher ;
• replatformer : déplacer l'application vers une plateforme moderne (cloud, conteneurs) avec des adaptations ciblées, sans réécrire la logique ;
• refactorer : améliorer le code à fonctionnalités constantes, le rendre lisible et testable ;
• réécrire un module critique isolé, derrière son API, sans toucher au reste ;
• remplacer une brique par une solution moderne ou un SaaS quand l'existant n'a plus de valeur propre.

Un motif complémentaire mérite d'être connu quand la brique à remplacer est enfouie au milieu du code plutôt qu'exposée en périphérie : le branch by abstraction. Le principe consiste à introduire d'abord une couche d'abstraction devant l'ancienne implémentation, puis à construire la nouvelle derrière la même interface, et enfin à basculer. L'intérêt par rapport à une branche Git de longue durée est décisif : le travail reste intégré en continu dans la branche principale, donc sans conflit de fusion accumulé sur des mois. Référence : Branch by Abstraction.

La plupart des modernisations réussies combinent plusieurs de ces leviers, appliqués au bon module au bon moment. Un exemple typique : on commence par exposer le vieux système derrière une API (encapsulation) pour pouvoir brancher un nouveau front ou un CRM ; puis on réécrit le module de facturation, le plus critique, derrière cette même API ; et on ne touche au reste que plus tard, une fois la valeur déjà livrée. À aucun moment l'entreprise ne s'arrête de fonctionner.

Par où commencer : la valeur, pas la techno

L'erreur la plus courante est de choisir la technologie avant d'avoir compris le problème. La bonne séquence est inverse : cartographier l'existant, classer les modules par risque et par valeur, puis viser des quick wins, ce qui débloque vite les équipes pour un effort maîtrisé. On garde le legacy en marche et on attaque en priorité ce qui coûte le plus cher ou fait courir le plus de risque. C'est tout l'objet d'une phase de cadrage ou d'un audit de dette technique en amont : décider sur des faits, pas sur une intuition.

Garder le système en marche pendant la bascule

Une migration progressive impose une discipline qui, justement, la rend sûre. Les feature flags permettent d'activer le neuf pour une partie des utilisateurs seulement. Le double-run (faire tourner l'ancien et le nouveau en parallèle et comparer les résultats) sécurise les modules sensibles avant la bascule définitive. Des tests de non-régression garantissent qu'on n'a rien cassé. Et à chaque étape, on conserve la réversibilité : si quelque chose dérape, on revient en arrière sans drame. L'IA peut accélérer ce travail, génération de tests, documentation, aide à la migration, à condition de l'encadrer, comme nous l'expliquons à propos de l'IA appliquée au code legacy.

Cette réversibilité se mesure, ce qui permet de piloter la migration sur des nombres plutôt que sur une impression de risque. Le programme de recherche DORA suit quatre indicateurs : fréquence de déploiement, délai entre un commit et sa mise en production, taux d'échec des changements et temps de rétablissement après incident. Les deux derniers sont exactement ceux qui doivent rester stables pendant une bascule progressive : si le taux d'échec grimpe, c'est que l'incrément était trop gros. Référence : le rapport DORA.

Ces interrupteurs demandent eux-mêmes une hygiène, faute de quoi ils deviennent la dette suivante. La littérature distingue plusieurs familles selon leur durée de vie : les release toggles, temporaires, doivent être retirés dès la bascule terminée, alors que les toggles de configuration métier peuvent rester. La règle pratique tient en une phrase : un flag sans date de retrait prévue est un flag qu'on retrouvera dans trois ans, avec du code mort des deux côtés. Référence : Feature Toggles.

Quand le big-bang se justifie quand même

Soyons honnêtes : la réécriture complète n'est pas toujours à proscrire. Elle peut s'imposer quand la technologie est totalement morte ou non sécurisable, quand le périmètre est petit et bien compris, ou quand une contrainte réglementaire l'exige. Mais ce sont les exceptions, et la décision doit reposer sur un diagnostic, pas sur une lassitude vis-à-vis de l'ancien outil. Dans le doute, l'approche incrémentale reste la moins risquée, et la plus rapide à délivrer de la valeur. Pour approfondir le rôle de l'IA dans ce type de trajectoire, voir notre dossier sur la modernisation d'un SI legacy avec l'IA.

Une application legacy qui vous freine, mais que vous ne voulez pas risquer de casser ? On définit avec vous une trajectoire par étapes, réversible et chiffrée. Cette démarche fait partie de notre offre de modernisation applicative, discutons-en.