“Legacy” est un mot qui résume un peu trop facilement un constat. On l’utilise pour désigner un système ancien, difficile à faire évoluer, dont les coûts d’exploitation augmentent à mesure que les compétences se raréfient. Le diagnostic n’est pas faux. Mais il est souvent confondu avec la solution.
Une majorité de programmes de modernisation échouent ou s’enlisent non pas parce que la cible est mal pensée, mais parce que la trajectoire choisie ne correspondait pas aux contraintes réelles du système et de l’organisation qui l’opère. Avant de choisir comment moderniser, il faut comprendre ce qu’on modernise. Et pourquoi ce système-là, dans ce contexte-là, résiste à l’évolution.
Ce qui rend un système “legacy”
Un système ne devient pas legacy par son âge. Il le devient parce que son adhérence aux opérations, à des contraintes externes et à la connaissance tacite d’une équipe rend toute évolution coûteuse et risquée.
Un monolithe Java de douze ans qui sert quelques milliers de requêtes par jour, dont la base est documentée, dont les flux sont compréhensibles et dont l’équipe a su moderniser progressivement, n’est pas un legacy au sens problématique du terme. Un système écrit il y a trois ans, mais dont aucun membre actuel de l’équipe ne maîtrise les règles métier enfouies, dont les déploiements demandent des opérations manuelles tribales et dont la moindre évolution exige des semaines de validation, l’est.
Les vrais signaux d’un legacy difficile à transformer sont plus opérationnels qu’architecturaux. Une dépendance à un fournisseur historique qui impose un format figé. Un traitement nocturne dont seul un opérateur saura redémarrer la procédure manuelle en cas d’incident. Un paramètre métier qui vit dans une procédure stockée que personne n’a relue depuis cinq ans. Une intégration partenaire dont les contraintes contractuelles ne permettent aucune modification du protocole.
Ces facteurs déterminent à la fois ce qui rend la transformation difficile et ce qui doit conditionner le choix de trajectoire. Modernisation et lisibilité du système sont indissociables : un système qu’on ne comprend qu’à moitié ne se modernise pas, il se réécrit à l’aveugle.
Les trajectoires de modernisation
Plusieurs trajectoires existent. Aucune n’est universellement supérieure. Le choix se fait en fonction du couplage opérationnel du système, du temps disponible, de la maturité de l’équipe et de la valeur métier qui reste à extraire de l’existant.
L’encapsulation. On place une couche d’abstraction devant le système existant (une API gateway, une anti-corruption layer) qui découple les consommateurs du système legacy. Le legacy n’est pas modifié, mais son environnement extérieur cesse de s’y adhérer. Utile quand le système est stable mais que ses interfaces brutes empêchent l’évolution du reste du SI. Limite : on ne traite pas la dette du legacy lui-même, on l’isole.
La réécriture progressive. Le Strangler Fig pattern formalise cette approche : un routage progressif redirige les flux vers de nouveaux composants, et l’ancien rétrécit jusqu’à disparaître. Utile sur les systèmes où l’on peut extraire des modules avec leurs frontières fonctionnelles. La mécanique de la coexistence demande à être conçue sérieusement : ce n’est pas une phase transitoire qu’on subit, c’est un état à concevoir.
Le replatforming. On migre le système sur une infrastructure ou une plateforme moderne sans en réécrire la logique métier. Conteneurisation d’une application Java, migration d’une base Oracle vers PostgreSQL, déplacement vers un PaaS managé. Utile pour réduire les coûts d’exploitation et débloquer une dépendance critique (fin de support, contrat sortant), sans rouvrir la question de la dette applicative.
La réécriture complète. Plus rare qu’elle ne le prétend, mais parfois rationnelle. Lorsque le système est de taille modeste, que ses règles métier sont bien documentées (ou peuvent être redérivées d’une source de vérité externe), qu’un effort d’opération en parallèle est finançable et qu’aucune contrainte de continuité n’oblige à la coexistence, refaire à neuf peut être plus rapide et plus sûr qu’une réécriture progressive. Règle pratique : si la trajectoire progressive demanderait plus de dix-huit mois pour un périmètre que l’on peut isoler et redécouper avec confiance, l’option de la réécriture complète mérite d’être étudiée sérieusement. Ce n’est pas un dogme contre l’option, c’est un test de réalisme.
Le remplacement par une solution du marché. Lorsqu’un composant interne ne porte plus de différenciation métier (gestion documentaire, signature, paie, comptabilité auxiliaire), son remplacement par une solution SaaS ou commerciale est souvent l’option de moindre risque. La complexité se déplace alors vers la migration des données et l’intégration, qui restent des chantiers significatifs, mais l’effort d’opération continue retombe.
Le décommissionnement. Tout système n’a pas vocation à être modernisé. Certains traitements peuvent être simplement arrêtés parce que leur usage a disparu, leur valeur métier s’est érodée ou leur fonction a été reprise par un autre composant. Identifier ces zones et les éteindre proprement libère de la bande passante pour ce qui compte vraiment. C’est souvent la décision la plus puissante d’un programme de modernisation, et la moins prise.
Ces trajectoires se combinent. Sur un programme réel, on encapsule un module, on réécrit progressivement un deuxième, on décommissionne un troisième, on remplace un quatrième par du SaaS. Le travail de cadrage initial consiste à identifier la bonne trajectoire pour chaque composant, pas à appliquer une méthode unique à tout l’ensemble.
Ce qui distingue les trajectoires viables des trajectoires dangereuses
Une trajectoire choisie sur le papier peut s’écrouler en exécution si plusieurs facteurs structurants n’ont pas été lus correctement.
Le couplage opérationnel. Plus un système est imbriqué dans les opérations en cours (transactions financières, déclarations réglementaires en temps réel, partenaires externes branchés en synchrone), plus la fenêtre pour le transformer rétrécit. Certains systèmes ne supportent pas la moindre indisponibilité ; d’autres tolèrent des bascules de quelques minutes. Cette tolérance détermine la palette de trajectoires réalistes plus sûrement que toute considération architecturale.
La profondeur de connaissance métier qui se trouve dans le code. Un système qui matérialise vingt ans de règles métier dispersées, sans documentation à jour et sans test de référence, ne se réécrit pas. Pas d’un coup. Il faut d’abord externaliser ces règles dans une source de vérité utilisable par les deux systèmes (legacy et nouveau), et c’est un chantier en soi, parfois plus long que la transformation elle-même.
La maturité de l’équipe sur la cible. Une équipe qui maîtrise parfaitement le legacy mais découvre la stack cible est exposée à un risque qu’on sous-estime systématiquement. La capacité à opérer une nouvelle architecture, à diagnostiquer un incident dans un environnement nouveau, à comprendre les défaillances spécifiques au paradigme cible, se construit sur des mois. Une trajectoire qui ignore cette montée en compétence produit un système plus moderne mais plus difficile à opérer, ce qui n’est pas une réussite.
Les contraintes business non négociables. Régulateur, partenaires contractuels, fenêtres de mise en production imposées par d’autres acteurs : ce qui paraît être de la friction administrative est souvent la contrainte la plus rigide d’un programme. Une trajectoire viable doit composer avec ces contraintes dès la phase de cadrage. Les ignorer revient à découvrir tardivement qu’aucune des étapes prévues n’est exécutable dans le calendrier réel.
Lorsqu’une trajectoire échoue, c’est rarement parce qu’elle était techniquement mauvaise. C’est généralement parce qu’un de ces facteurs avait été lu avec optimisme.
Ce que les programmes qui réussissent ont en commun
Les programmes de modernisation qui aboutissent partagent quelques traits observables. Pas une méthode, pas un cadre standard : des dispositions qu’on retrouve, et dont l’absence laisse rarement une trajectoire saine.
Les programmes qui aboutissent prennent une décision explicite sur ce qu’on ne modernisera pas. C’est moins évident qu’il y paraît : une grande partie de l’énergie d’un programme part dans des composants qui n’avaient pas vraiment besoin d’évoluer. Identifier dès le cadrage les zones qui peuvent rester en l’état, parce qu’elles fonctionnent, qu’elles ne bloquent rien et que leur dette ne menace rien à court terme, libère du budget pour ce qui doit réellement bouger.
La progression d’un programme ne se mesure pas en pourcentage d’avancement. C’est un flux continu où ce qui compte est le rapport entre la valeur livrée et la dette restante. Les programmes solides regardent des indicateurs opérationnels : nombre d’incidents qui ont touché les zones déjà transformées, capacité à déployer en production sans coordination manuelle, temps moyen de réparation. Ces indicateurs disent ce qui s’améliore réellement, là où un pourcentage d’avancement dit surtout ce qui rassure le pilotage.
Le dispositif de bascule se conçoit au moment du cadrage, pas à la fin du chantier. Le moment où l’on bascule un flux d’un ancien système vers un nouveau est rarement le moment où ce dispositif s’invente. Sur les programmes qui réussissent, la stratégie de routage, les mécanismes de rollback, le protocole de comparaison parallèle sont définis au début, testés tôt, et rodés bien avant la première bascule réelle. Sur les programmes qui dérapent, ces questions arrivent dans les derniers jours, et c’est généralement là que tout casse.
Et l’ancien système se maintient sérieusement pendant la transformation. Une équipe qui considère le legacy comme “déjà mort” accumule de la dette pendant le programme : incidents non corrigés proprement, paramètres ajustés à la volée, documentation laissée à l’abandon. Ces résidus migrent ensuite vers le nouveau système, ou empêchent sa stabilisation. Le maintien en condition de confiance du legacy pendant la transition est une dépense parallèle qui paraît être un coût, mais qui en évite plusieurs autres.
Ces traits ne sont pas une checklist. Ce sont des dispositions qui apparaissent quand le programme est cadré par des gens qui ont déjà conduit ce genre de transformation. Lorsqu’on les voit absentes au démarrage, le risque est rarement compensé par la suite.
Un exemple : système bancaire COBOL
Un programme conduit pour un acteur bancaire illustre ces principes. Le système concerné gérait les comptes courants de trois millions de clients, écrit en COBOL, en production depuis quinze ans.
Le diagnostic initial a identifié douze modules critiques aux comportements imbriqués. Aucun n’aurait pu être réécrit isolément sans déstabiliser les autres. La décision a été de ne pas transformer tout l’ensemble : le module “Virements”, plus forte valeur métier et complexité maîtrisable, a été choisi comme premier candidat. La trajectoire retenue était la réécriture progressive avec routage devant le monolithe COBOL, soit une variante de Strangler Fig adaptée aux contraintes transactionnelles bancaires.
La bascule s’est faite par segments de clients. Un premier pour cent du flux a été routé vers le nouveau composant en mode comparaison parallèle : chaque opération exécutée des deux côtés, les résultats comparés en continu. Aucune divergence sur trois semaines de production réelle. Le segment a été monté à dix pour cent, puis cinquante, puis cent, sur six mois. La bascule complète n’a jamais eu lieu en un instant, elle a été lissée sur tout ce temps. Aucun incident métier majeur en dix-huit mois de programme.
Ce qui a fait la différence n’est pas le choix technologique de la cible. C’est la décision de ne pas attaquer les douze modules en même temps, le dispositif de routage et de comparaison parallèle conçu dès le départ, et le maintien actif du COBOL pendant toute la durée du programme, y compris des corrections de bugs et des évolutions mineures, pour ne pas laisser dériver l’ancien système pendant la transition.
Conclusion
Un système legacy n’est pas un problème technique à résoudre en appliquant une méthode. C’est un état du système et de l’organisation qui demande à être lu avant d’être traité. Plusieurs trajectoires existent, et le travail de cadrage initial consiste moins à choisir un modèle qu’à arbitrer entre des contraintes (opérationnelles, organisationnelles, contractuelles) qui rendent telle ou telle trajectoire viable ou dangereuse.
La mécanique opérationnelle de la transformation, une fois la trajectoire arrêtée, est traitée ailleurs : ce qui se passe pendant la coexistence entre ancien et nouveau, et comment on la conçoit comme un système à part entière, fait l’objet d’un article dédié.
Cartographier l’existant, isoler les zones critiques, transformer sans interrompre l’exploitation : c’est ce que nous faisons aux côtés des équipes techniques. Modernisation et maintien en condition de confiance.