Ce n'est pas une question d'âge
Une application de dix ans, documentée, testée et maintenue par une équipe qui la connaît n'est pas du legacy : c'est un actif. Une application livrée il y a dix-huit mois, dont la connaissance n'a jamais été partagée et dont personne ne sait relancer l'environnement de test, en est déjà. Le critère n'est pas la date de naissance du code, c'est la capacité à le modifier sans croiser les doigts.
Trois éléments font basculer un projet dans cette catégorie : la connaissance qui n'a pas été écrite, les dépendances qui ne reçoivent plus de correctifs de sécurité, et l'absence de filet automatique qui dirait si une modification casse quelque chose.
Pourquoi c'est un risque métier, pas un sujet technique
Tant que rien ne bouge, un code legacy fait très bien son travail. Le risque apparaît le jour où il faut bouger : une évolution réglementaire, un partenaire qui change son API, un besoin commercial urgent, un incident de sécurité sur une bibliothèque hors support. Chacune de ces situations impose de toucher au code, et c'est à ce moment qu'on découvre le coût réel de la connaissance perdue.
Il y a aussi un effet plus sourd : l'équipe évite l'application. Les demandes s'accumulent en « on verra plus tard », les utilisateurs contournent avec des tableurs, et l'écart se creuse entre ce que fait le logiciel et ce dont le métier a besoin.
Reprendre plutôt que tout jeter
Le réflexe de la réécriture complète est le plus cher et le plus risqué : il jette avec le code toutes les règles métier implicites que personne n'a documentées, celles qui sont apparues au fil des années de production. La démarche qui fonctionne commence par comprendre. On établit une cartographie applicative, on remet l'application sous contrôle, on installe des tests sur les parcours critiques, puis on modernise par morceaux en gardant le service en ligne.
C'est le cœur de notre travail de reprise de projet : redonner à une équipe la capacité de décider ce qu'elle fait de son application, au lieu de subir ce qu'elle contient. La dette technique accumulée devient alors un plan de travail chiffré, pas une inconnue.
