9. Vieillir n'est pas échouer : dette et systèmes legacy
Tout logiciel qui sert longtemps accumule des traces de ses décisions passées : règles devenues rares, données anciennes, dépendances encore nécessaires, raccourcis pris sous contrainte, personnes qui connaissent mieux une zone que d'autres. On appelle souvent cela du legacy. Ce mot ne veut pas dire « mauvais » ; il décrit un système précieux, mais devenu difficile à comprendre ou à changer.
La dette technique est une contrainte, pas une faute morale
La dette technique représente un coût futur créé par une solution provisoire ou devenue inadéquate. Elle est parfois rationnelle : pour répondre à une urgence, on peut choisir une solution moins élégante mais sûre à court terme. Elle devient dangereuse lorsqu'elle ralentit régulièrement un changement important, produit des incidents ou concentre la connaissance chez une seule personne.
Dire « il faut tout réécrire » est tentant quand une zone est pénible. Pourtant une réécriture totale recrée aussi les règles oubliées, les cas particuliers et les dépendances cachées. Elle peut immobiliser l'équipe pendant longtemps sans améliorer le service existant.
Transformer par étapes
Une démarche plus sûre consiste à :
- observer le comportement actuel et le caractériser ;
- identifier la contrainte qui fait le plus de dommage maintenant ;
- créer une frontière ou un point de transition autour d'elle ;
- remplacer une part mesurable du système ;
- vérifier que l'ancien et le nouveau produisent le résultat attendu ;
- retirer l'ancien chemin seulement lorsqu'il n'est plus utilisé.
Cette approche semble moins spectaculaire, mais elle permet de continuer à servir les utilisateurs tout en réduisant le risque. Elle produit aussi une connaissance réutilisable, ce qui est souvent le vrai gain.
Pour aller plus loin : comprendre le legacy, créer de la sécurité et moderniser progressivement.