36. Le legacy : un système qui a une histoire et des utilisateurs
Pourquoi ce chapitre existe
Le mot legacy est souvent employé comme un jugement : ancien, mal écrit, difficile à aimer. Cette lecture est peu utile. Un système hérité est d'abord un système qui porte des décisions, des données et des usages accumulés dans le temps. Il peut être mal documenté, risqué ou coûteux ; il peut aussi contenir une valeur métier que la réécriture la plus élégante échouerait à reproduire.
Le traiter avec mépris conduit à sous-estimer ce qu'il sait déjà faire. Le traiter comme intouchable transfère ses coûts à chaque changement futur. L'enjeu est de rendre ses risques visibles, de protéger les comportements qui comptent et de créer une trajectoire de transformation proportionnée.
Les idées essentielles
- Le legacy n'est pas défini par l'âge ou le langage, mais par le coût et le risque de le changer.
- Son comportement réel est souvent la seule spécification de décisions métier anciennes ; il doit être découvert avant d'être remplacé.
- Une réécriture n'est pas une stratégie par défaut : elle concentre les inconnues, les migrations et la double maintenance.
- La transformation vise d'abord la capacité de changement et de récupération, pas la conformité à une esthétique d'architecture.
Lire l'existant comme une source de connaissance
Un système ancien contient des règles explicites dans le code, mais aussi des contrats implicites dans les données, les exports, les procédures support et les habitudes des utilisateurs. Une valeur inhabituelle peut être un bug historique, une exception réglementaire ou un contournement nécessaire à un client important. La distinguer demande des faits : exemples de production, historique de décisions, conversations métier et tests de caractérisation.
| Signal observé | Interprétation trop rapide | Investigation utile |
|---|---|---|
| Condition étrange | « Code mort à supprimer » | Identifier les données et scénarios qui l'atteignent |
| Table très partagée | « Il faut la découper » | Comprendre auteurs, lecteurs, usages de reporting et audit |
| Déploiement risqué | « Le code est mauvais » | Cartographier contrats, données, configuration et plan de retour |
| Expert incontournable | « Il faut documenter » | Associer documentation, pratique accompagnée et réduction de couplage |
La contrainte dominante guide le premier investissement
Un système peut être difficile à tester, mais son risque le plus urgent peut être une vulnérabilité, une dépendance non maintenue, une donnée impossible à restaurer ou une personne seule capable d'intervenir. Commencer par une grande refonte générale évite de choisir. Commencer par la contrainte qui cause le plus de dommage rend l'investissement visible et vérifiable.
Il reflète les priorités, connaissances et contraintes de plusieurs périodes. Le juger avec les standards actuels sans comprendre son contexte décourage le partage d'information. L'exigence consiste à voir lucidement le risque présent et à décider de sa réduction, pas à réécrire l'histoire pour désigner des responsables.
Anti-patterns
Déclarer une réécriture avant la découverte
Une nouvelle architecture peut sembler évidente depuis l'extérieur. Sans inventaire des comportements, données et intégrations, l'équipe découvre tardivement ce que l'ancien système gérait déjà. La réécriture devient alors plus longue, tout en continuant à dépendre du legacy qu'elle devait remplacer.
Réserver l'amélioration au « jour où il y aura du temps »
Un système fragile absorbe ce temps par les incidents, les délais et les contournements. Les améliorations qui protègent le flux — caractérisation, observabilité, automatisation d'une opération risquée — doivent être intégrées aux décisions de produit et de capacité.
Remplacer un outil sans traiter le comportement
Changer de langage, framework ou infrastructure peut être nécessaire. Il ne clarifie pas automatiquement les invariants, les contrats ou les responsabilités. La nouvelle pile peut reproduire les mêmes dépendances invisibles sous une forme plus moderne.
Bonnes pratiques
Écrire une carte de risque du système
Décrire les parcours critiques, données sensibles, dépendances, opérations manuelles, zones de connaissance concentrée et mécanismes de récupération. La carte n'a pas besoin d'être exhaustive : elle doit permettre de prioriser les premières sécurisations et de constater le progrès.
Préserver le service pendant la transformation
La modernisation est un travail sur un système qui doit continuer à servir ses utilisateurs. Prévoir les corrections, obligations légales et apprentissages qui surviendront pendant la trajectoire évite de traiter l'ancien monde comme figé et de créer une double maintenance non financée.
Checklist — Un système legacy est-il compris assez pour agir ?
- Quels parcours, données et obligations font aujourd'hui la valeur du système ?
- Où se trouvent les risques dominants : sécurité, récupération, changement, expertise, coûts ?
- Quels comportements existants sont connus, incertains ou seulement supposés ?
- Quelles équipes, outils ou usages externes dépendent réellement de lui ?
- Quelle première amélioration réduit un risque concret sans exiger une réécriture ?
- Comment le service continuera-t-il à évoluer pendant la transformation ?
À retenir
Un système legacy n'est pas une dette abstraite à effacer. C'est un patrimoine vivant à comprendre, sécuriser et transformer sans perdre les comportements qui rendent encore service. La lucidité sur son histoire est le premier levier de sa modernisation.