Moderniser un système existant auquel personne n’ose toucher : réécrire, refactoriser ou remplacer progressivement

Beaucoup d’entreprises installées depuis longtemps ont un système dont on parle avec prudence en réunion. La facturation, les stocks ou la production reposent sur lui, de nombreuses personnes l’ont modifié, rares sont celles qui le comprennent dans le détail, et chaque évolution est lente et coûteuse.

Quand vient enfin le moment de trancher, une phrase revient souvent sur la table : on réécrit tout à partir de zéro. L’idée est séduisante, mais risquée : l’ancien code est une archive de règles métier, d’exceptions et de correctifs accumulés au fil des années, bien souvent jamais mis par écrit, et jeter ce code d’un seul coup, c’est aussi jeter ce savoir. Or la modernisation d’un système legacy ne se résume pas à « laisser en l’état » ou « réécrire » et, pour un grand système critique, il est souvent plus sûr de le remplacer brique par brique, sans interrompre son exploitation.

Les symptômes : un système qui fait peur à l’entreprise

Michael Feathers, auteur du livre Working Effectively with Legacy Code, définit tout simplement le code legacy comme du code sans tests. Un système legacy ne se reconnaît donc pas à son âge, mais au fait qu’on puisse ou non le modifier en toute sécurité. Les signes typiques :

• Une seule personne comprend le système. Si elle s’en va, l’entreprise perd la capacité de faire évoluer un processus clé.
• La peur des mises en production. Les modifications s’accumulent dans de grosses livraisons, si bien qu’en cas d’erreur, la cause est plus difficile à identifier.
• Des technologies obsolètes, pour lesquelles il est difficile de recruter et que leur éditeur a cessé de maintenir.
• Des risques de sécurité impossibles à éliminer sans intervenir sur le cœur du système.
• L’impossibilité de connecter de nouveaux outils. Le système n’a pas de couche API, c’est-à-dire pas d’interface définie pour l’échange de données, de sorte que chaque connexion à un site e-commerce ou à un outil d’IA devient un projet à part entière.

Ce sont autant de formes de dette technique, une notion que l’article Une entreprise est un seul produit aborde comme un principe valable pour toute l’entreprise.

Le secteur public n’est pas épargné. Dans un rapport de juillet 2025, le GAO, l’organe américain de contrôle des comptes publics, a identifié les 11 systèmes fédéraux les plus critiques qui ont besoin d’être modernisés. Huit d’entre eux utilisent des langages obsolètes comme le COBOL et l’assembleur, et sept, selon les agences concernées, fonctionnent avec des vulnérabilités connues qu’il est impossible de corriger sans modernisation.

Pourquoi « on réécrit tout à partir de zéro » est si tentant

La réécriture big bang consiste à construire un système entièrement neuf, puis à y basculer toute l’entreprise d’un seul coup. Elle promet de repartir sur des bases saines, avec une technologie moderne. Dans un essai publié en 2000, Joel Spolsky avance une raison moins flatteuse : si les développeurs trouvent l’ancien code désordonné, c’est surtout parce qu’il est plus difficile de lire du code que d’en écrire. Il qualifie le fait de réécrire du code en repartant de zéro de pire erreur stratégique qu’un éditeur de logiciels puisse commettre. Il cite l’exemple de Netscape : la première bêta publique de la version 6.0 est sortie près de trois ans après la version 4.0 et, entre-temps, la part de marché de l’entreprise a fortement chuté.

C’est un point de vue tranché, mais on peut nommer concrètement les mécanismes d’échec :

• Des règles cachées. Selon Spolsky, les parties peu élégantes de l’ancien code sont souvent des corrections de bugs qui ne sont apparus qu’après des semaines d’utilisation réelle. La réécriture les fait disparaître, et les mêmes bugs peuvent resurgir, là encore seulement en production.
• Un double développement. D’après les auteurs de Thoughtworks, les demandes courantes des métiers continuent d’être traitées dans l’ancien système, si bien que l’entreprise finance deux flux de développement à la fois.
• Une longue période sans création de valeur. Martin Fowler rappelle que le remplacement d’un système informatique d’envergure prend beaucoup de temps et que les utilisateurs ne peuvent pas attendre aussi longtemps les nouvelles fonctionnalités.
• Une cible mouvante. Les auteurs de Thoughtworks décrivent une organisation qui a enchaîné des programmes de modernisation de trois à cinq ans. Dans chacun d’eux, l’évolution des besoins métier a pris de vitesse la stratégie technologique et il a fallu tout reprendre depuis le début. Là où le programme était mené en big bang, cela revenait à jeter l’essentiel du travail.

Six options, et dans quels cas chacune convient

1. Conserver et stabiliser. Mettre en place la supervision des erreurs et des pannes, les sauvegardes et la documentation, et former une deuxième personne qui comprenne le système. Convient lorsque le système remplit son rôle et évolue rarement. C’est souvent le moyen le moins coûteux de réduire le risque.
2. Refactoriser. Selon Martin Fowler, le refactoring est une modification de la structure interne d’un logiciel qui le rend plus facile à comprendre et moins coûteux à modifier, sans changer son comportement observable. Convient lorsque la technologie reste adaptée, mais que le code est devenu enchevêtré.
3. Migrer vers une nouvelle infrastructure, par exemple d’un serveur interne vers le cloud. Convient lorsque la douleur vient de l’exploitation ou du matériel. Changer d’infrastructure ne guérira pas une logique applicative défaillante.
4. Remplacer progressivement. Convient aux grands systèmes critiques qui ne peuvent pas s’arrêter, dont personne ne connaît le comportement dans son intégralité et qui peuvent encore fonctionner longtemps en parallèle des nouveaux.
5. Acheter une solution du marché. Pour un processus standard comme la comptabilité ou la gestion des temps, un développement spécifique est souvent superflu, mais c’est alors au processus de s’adapter au produit. Ce choix est analysé dans l’article Sept outils SaaS ou un seul système ?
6. Décommissionner. Si le système sert un processus qui a disparu, il faut encore vérifier qu’aucun autre système ni aucun rapport n’y puise de données.

Strangler fig : le nouveau système pousse à côté de l’ancien

Le strangler fig pattern doit son nom à une métaphore de Martin Fowler : en 2001, dans les forêts tropicales du Queensland, il a observé des figuiers étrangleurs qui enveloppent peu à peu leur arbre hôte, jusqu’à le remplacer. De la même manière, le nouveau système ne se construit pas à la place de l’ancien, mais à côté de lui. Il en reprend les fonctions l’une après l’autre, jusqu’au moment où l’ancien peut être mis hors service.

La documentation de Microsoft en décrit le mécanisme : entre les utilisateurs et les deux systèmes, on insère une façade, c’est-à-dire un intermédiaire qui redirige progressivement les requêtes de l’ancien système vers le nouveau, par exemple d’abord uniquement le calcul des devis. Pour les utilisateurs, la migration est transparente. Selon Feathers, l’ancien système reste disponible comme solution de repli en cas de problème.

Fowler ne cache pas le prix à payer : une architecture de transition permettant aux deux systèmes de fonctionner en parallèle, vouée à disparaître une fois le remplacement achevé. Selon lui, un risque plus faible et une valeur obtenue plus tôt l’emportent sur ce coût, car les parties remplacées sont petites. Il prévient toutefois que sans évolution de la culture et du management, le nouveau système finira lui aussi dans un désordre comparable.

Les données, la partie la plus difficile

Le code peut être remplacé morceau par morceau, mais pendant la transition, les deux systèmes ont besoin des données en même temps. La migration de données, c’est-à-dire le transfert des informations de l’ancienne structure vers la nouvelle, ne se résume pas à une simple copie. Des chercheurs du Trinity College Dublin soulignent que les données des anciens systèmes sont souvent de piètre qualité, qu’il faut les faire correspondre à la nouvelle structure et, fréquemment, les nettoyer. En pratique, il s’agit par exemple de doublons, de champs détournés de leur usage initial et de valeurs que seul l’ancien code sait interpréter.

Microsoft recommande de séparer les données progressivement, domaine par domaine : alimenter la nouvelle base de données par un chargement initial, répercuter les modifications suivantes grâce au change data capture, une technique qui capte les changements dans l’ancienne base, vérifier la concordance des données avant la bascule, et ne supprimer les anciens objets qu’après la validation du nouveau système. Jusque-là, un retour arrière reste possible ; au-delà, il devient nettement plus complexe et plus risqué.

Pendant la transition, il doit être clair, pour chaque type de données, quel système constitue la source unique de vérité. Si l’adresse d’un client peut être modifiée dans les deux systèmes, chacun risque d’en avoir une différente. Notre conclusion pratique : chaque donnée ne doit être modifiée par les utilisateurs que dans un seul système, les autres systèmes se contentant de la reprendre depuis celui-ci. Le rôle plus large des données est abordé dans l’article Vos données sont votre longueur d’avance.

Comment savoir ce que fait réellement le système

Feathers fait remarquer que chacun a en tête une idée de ce que fait le système, mais oublie d’aller voir ce qu’il fait en réalité. Trois sources permettent d’y voir clair :

• L’observation des utilisateurs. Regarder ce que les gens font avec le système, et non ce qu’ils en disent. C’est là qu’apparaissent les contournements, les tableurs tenus en parallèle et les étapes manuelles.
• Les logs, autrement dit les journaux d’activité du système. Ils montrent quelles fonctions sont utilisées, à quelle fréquence et par qui, et aident à repérer des dépendances inattendues.
• Les tests du comportement actuel. Feathers décrit les tests de caractérisation : on pose une question au code et l’on consigne la réponse obtenue comme résultat attendu. On obtient ainsi des tests de non-régression, c’est-à-dire des contrôles automatiques qui vérifient après chaque modification que ce qui fonctionnait fonctionne toujours.

Les auteurs de Thoughtworks relatent le cas d’une équipe qui testait en production le remplacement d’un middleware d’intégration, le logiciel qui relie les autres systèmes entre eux. Peu après, des rapports de gestion critiques ne tombaient plus juste. Après de longues recherches, il est apparu que la base de données du middleware était répliquée dans un entrepôt de données dont ces rapports tiraient leurs chiffres. Seul un mécanisme temporaire, chargé de compléter les données manquantes dans l’entrepôt, a permis de régler le problème.

Dans quel ordre avancer : douleur maximale, risque minimal

La migration ne doit pas être la première étape. Là aussi, nous suivons l’ordre Remove, Simplify, Automate, Augment : d’abord supprimer, puis simplifier, et seulement ensuite automatiser et enrichir. Les auteurs de Thoughtworks soulignent que la plupart des systèmes legacy s’alourdissent avec le temps de fonctionnalités que personne n’utilise, en s’appuyant sur un rapport du Standish Group de 2014 selon lequel elles représentent 50 % des fonctionnalités. Pour un système donné, ce chiffre n’est qu’indicatif : ce sont les logs qui montreront la réalité. Une fonctionnalité supprimée n’a besoin d’être ni analysée, ni migrée, ni testée, et les contournements des limites de l’ancien système gagnent à être simplifiés lors du transfert plutôt que recopiés.

La première partie à remplacer doit causer une douleur tangible, par exemple freiner l’activité commerciale, tout en étant relativement découplée du cœur du système. Feathers conseille de se concentrer sur les parties qui vont se développer tout en posant des difficultés, et de trouver, pour rediriger les requêtes, des coutures (seams), nom qu’il donne aux endroits où un comportement peut être remplacé par un autre.

Les risques, et comment les mesurer pendant la transition

Le remplacement progressif ne supprime pas le risque : il le fractionne en morceaux plus petits et mesurables. La décision du régulateur britannique FCA du 20 décembre 2022 illustre le scénario inverse. Le week-end du 20 au 22 avril 2018, la banque TSB a transféré l’essentiel de ses opérations et de ses données clients vers une nouvelle plateforme encore non éprouvée. Il s’en est suivi de graves dysfonctionnements de la banque en ligne et mobile ainsi que des paiements par carte et, au 7 avril 2019, la banque avait reçu 225 492 réclamations. La FCA a relevé des manquements dans la planification, les tests, la gestion des risques et la supervision du prestataire externe, a souligné qu’après la mise en service, la banque ne pouvait pratiquement plus revenir à l’ancienne plateforme, et lui a infligé une amende de 29,75 millions de livres sterling.

Vicent Martí, de GitHub, a décrit en 2015 une voie plus sûre. L’équipe remplaçait l’une des parties les plus critiques du code directement en production : l’ancien et le nouveau code tournaient en parallèle, leurs résultats étaient comparés et l’utilisateur recevait toujours celui de l’ancien code. L’expérience a démarré sur 1 % des requêtes et a été progressivement étendue, jusqu’à tourner pendant 24 heures sur 100 % des requêtes sans divergence. La comparaison a en outre mis au jour 2 bugs graves dans l’implémentation d’origine, que personne n’avait détectés pendant des années.

Voici donc ce qu’il faut suivre :

• La concordance des résultats entre l’ancienne et la nouvelle solution sur des données réelles, avant la bascule.
• Le taux d’erreur et les performances après chaque redirection.
• Le retour arrière : la rapidité avec laquelle l’entreprise revient à la situation initiale.
• La cohérence des données et le nombre de corrections manuelles.
• La part d’activité reprise par le nouveau système. Si elle ne progresse pas dans la durée, le projet se transforme en double exploitation sans fin.

Quand une réécriture complète se justifie

Une réécriture complète n’est pas toujours une erreur. Feathers la présente comme une décision économique, une affaire de retour sur investissement, mais lui-même commence par tenter le refactoring et rappelle qu’il est la plupart du temps inutile de réécrire tout le système, et que des réécritures ciblées de certaines parties se révèlent souvent très efficaces. Microsoft précise dans quels cas le remplacement progressif n’est pas adapté : lorsque le système est petit et peut facilement être remplacé d’un bloc, lorsque le code source n’est pas accessible ou lorsque l’ancienne solution doit être décommissionnée rapidement. Les auteurs de Thoughtworks admettent la parité fonctionnelle, c’est-à-dire la reproduction fidèle des anciennes fonctionnalités, pour les systèmes dont la spécification est bien connue et où une entrée donnée doit produire une sortie donnée, mais ils jugent ces cas exceptionnels.

Notre avis : une réécriture se défend aussi lorsque l’activité a tellement évolué que l’ancien système soutient une manière de travailler que l’entreprise est en train d’abandonner. Mais il s’agit alors d’un nouveau produit, avec un nouveau cahier des charges, et non d’une copie des anciennes fonctionnalités.

La modernisation d’un système legacy ne commence donc pas par le choix d’une technologie, mais par la compréhension du travail que le système accomplit pour l’entreprise, des parties qui servent réellement et de l’endroit précis où le bât blesse. Faire l’impasse sur ce diagnostic, c’est choisir à l’aveugle entre réécriture et refactoring.

Ce qu’il faut retenir

• Vous ne choisissez pas seulement entre « laisser en l’état » et « réécrire », mais parmi six options. La stabilisation, une solution du marché ou le décommissionnement coûtent souvent moins cher qu’une réécriture.
• Avant la migration, déterminez ce que fait réellement le système : grâce à l’observation des utilisateurs, aux logs et à des tests du comportement actuel.
• Commencez par supprimer les fonctionnalités inutilisées, sinon vous les migrerez et les testerez pour rien.
• Remplacez un grand système critique brique par brique, en commençant là où la douleur est la plus forte et le risque le plus faible, et gardez une possibilité de retour arrière.
• Définissez une source unique de vérité pour chaque type de données et mesurez la concordance des résultats, le taux d’erreur et la part d’activité reprise par le nouveau système.