Idée principale

Le legacy se raconte comme un héritage : du code ancien, des décisions passées, des architectures fragiles, des dépendances mal documentées, des choix qui avaient un sens hier. Présenté ainsi, il est subi — on en hérite, on fait avec.

La part qu'on ne subit pas est celle qu'on est en train d'écrire. Un défaut transféré à quelqu'un d'autre, une spécification floue acceptée sans discussion, un test jamais écrit, une régression rejouée à la main sprint après sprint, une QA employée comme filet final, un code livré vite et mal compris : chacun de ces gestes est un renoncement daté, et chacun devient une ligne du legacy que l'équipe découvrira dans deux ans.

Ce qu'ils ont en commun n'est pas la précipitation. C'est un déplacement : la responsabilité de la qualité quitte celui qui pouvait encore l'exercer, et le produit conserve la trace de ce déplacement bien après que tout le monde a oublié la contrainte qui l'a motivé.

Pourquoi c'est important

Cela rend une fatalité arbitrable. Tant que le legacy est un héritage, il appelle des plans de reprise ; une fois vu comme une production courante, il devient une conséquence de décisions qu'on prend cette semaine, et sur lesquelles on peut agir sans budget dédié.

Cela donne aussi une liste d'indicateurs avancés : les gestes de report cités sont observables immédiatement, alors que leur effet ne l'est qu'après des années.

Nuances et limites

Tout report n'est pas une faute. Certaines dettes sont contractées sciemment, pour une raison datée, et se remboursent — la différence tient à ce qu'elles soient nommées comme telles au moment où on les prend.

Et le legacy ne vient pas seulement de renoncements : une technologie vieillit, un marché change, une architecture correcte devient inadaptée sans qu'aucun geste de report n'ait eu lieu.

Questions ouvertes

• Comment reconnaître, au moment où on le fait, qu'un report est une dette nommée plutôt qu'un renoncement ordinaire ?