Zéro legacy n'est pas une stratégie

La baisse du coût de production du code a ravivé une vieille ambition : éliminer tout le parc legacy et maintenir chaque composant à jour en permanence.

Cette ambition est compréhensible. Les agents de programmation fondés sur l’IA peuvent inspecter des dépôts inconnus, rédiger des tests, effectuer des migrations répétitives, mettre à jour des dépendances et reproduire une modification éprouvée dans de nombreux composants. Un travail qui aurait autrefois occupé la feuille de route pendant des années peut maintenant être réalisé en quelques semaines voir jours.

Mais le « zéro legacy » n’est pas un objectif d’affaires utile. Il confond l’âge du code avec son coût de possession.

Un ancien code stable, compris, sûr et peu coûteux à exploiter peut être un actif. Un nouveau code que personne ne peut expliquer, qui change plus vite qu’il ne peut être vérifié ou qui dépend d’un fournisseur fragile peut déjà être legacy.

L’argument de l’IA poussé trop loin

Dans un récent podcast (transcription ici [en]), Quentin Adam, PDG de Clever Cloud, a décrit l’utilisation de l’IA dans le cadre d’un vaste effort visant à réduire, puis à éliminer, environ quinze ans de legacy accumulé pour que fin 2026 seulement du code écrit en 2026 tourne.

Le simple fait que quelque chose soit possible implique-t-il nécessairement que ce soit souhaitable ? Qu’y a-t-il de si problématique à s’appuyer sur du code éprouvé, stable et qui a fait ses preuves ?

Peut-être n’était-ce finalement qu’une formule de style, une manière plus « catchy » de dire : « Nous voulons avoir résorbé nos principaux chantiers de dette technique d’ici la fin de l’année. »

Ou bien est-ce le symptôme d’un malaise plus profond qui gagne progressivement la tech et ses décideurs ?

Le legacy est une d’abord situation business

Un système devient legacy lorsque ses contraintes entravent de façon importante ce que l’organisation doit accomplir. L’âge peut y contribuer, mais il ne le définit pas.

Ces conditions peuvent soutenir un dossier d’investissement. « Le code est ancien » n’est pas une justification en soit.

Un registre de dette devrait donc relier chaque condition technique aux revenus, aux coûts d’exploitation, au risque, au délai de livraison ou à un plan d’affaires approuvé. Une fois ce lien explicite, la modernisation peut rivaliser pour le capital sur la même base que les autres investissements.

Ce que l’IA rend moins coûteux

Utilisée dans un système d’ingénierie contrôlé, l’IA peut réduire les efforts nécessaires dans plusieurs volets de la modernisation :

• Cartographier les dépendances et repérer les motifs répétés dans un vaste dépôt
• Produire une première version des tests manquants autour du comportement observé
• Expliquer des modules inconnus afin qu’un ingénieur expérimenté puisse les examiner
• Appliquer un modèle de migration connu à de nombreux composants semblables
• Mettre à jour l’utilisation d’un cadriciel ou d’une bibliothèque lorsque la cible est bien définie
• Comparer les interfaces et relever les incompatibilités probables
• Produire de la documentation et des comptes rendus de décisions à partir de sources examinées

Le point commun n’est pas la génération de code. C’est une tâche délimitée qui dispose d’une source de vérité et d’un moyen de vérifier le résultat.

Cet aspect est important, car une grande partie du travail de modernisation est répétitive plutôt que conceptuellement nouvelle. Une fois qu’une équipe a établi un modèle sûr pour un service, un module ou une interface, un agent peut l’aider à l’appliquer aux vingt suivants.

Ce que l’IA ne fait pas disparaître

Les risques les plus coûteux d’une ré-architecture se situent souvent en dehors de l’écriture du code.

Comportements cachés. Les systèmes matures contiennent des règles métier qui n’ont jamais été écrites. Certaines sont des fonctionnalités. D’autres sont des accommodements consentis à des clients importants. Certaines ressemblent à des erreurs jusqu’au jour où elles sont supprimées.

Migration des données. Un nouveau schéma est facile à dessiner. Déplacer des données en production tout en préservant leur sens, leur historique, leur contrôle d’accès et leur rapprochement est plus difficile.

Bascule et retour arrière. L’organisation doit toujours décider comment les anciens et les nouveaux composants coexisteront, comment le trafic sera déplacé et ce qui se produira lorsque le nouveau chemin échouera.

Préparation opérationnelle. La surveillance, la gestion des incidents, les procédures de soutien, la planification de la capacité et les frontières de sécurité doivent fonctionner avant le retrait de l’ancien chemin.

Responsabilité organisationnelle. Les nouvelles frontières entre services échouent lorsqu’elles recoupent mal la façon dont les équipes travaillent réellement. La ré-architecture modifie les responsabilités autant que le logiciel.

Coût de renonciation. Les ingénieurs et les spécialistes métier affectés à une réécriture ne livrent pas autre chose. Une génération de code plus rapide réduit ce coût, mais ne le ramène pas à zéro.

L’IA peut aider à inspecter et à exécuter. Elle ne peut pas accepter ces risques au nom de l’entreprise.

L’équation dangereuse de la réécriture

Une réécriture complète est souvent justifiée par une comparaison simple :

La maintenance de l’ancien système semble coûteuse. La production de nouveau code paraît désormais bon marché. Son remplacement doit donc coûter moins cher.

Les termes manquants sont la découverte, l’équivalence, la transition et l’adoption.

Les spécifications de l’ancien système se trouvent rarement au même endroit. Elles sont réparties entre le code, les données, les tests, les billets de soutien, les contrats, les habitudes des utilisateurs et la mémoire des employés. Avant de reproduire ou de supprimer délibérément un comportement, une réécriture doit découvrir lesquels sont importants.

L’IA peut générer une mise en œuvre plausible avant la fin de cette découverte. Le projet paraît alors plus rapide à ses débuts. Cela ne réduit pas l’importance des connaissances manquantes. Le risque est plutôt de créer un plus grand volume de logiciel dont il reste à établir l’exactitude.

C’est pourquoi le volume de code produit mesure mal l’avancement d’une modernisation. Voici des mesures plus utiles :

• La part du trafic de production prise en charge de façon sûre par le nouveau chemin
• La réduction du délai de modification pour la capacité d’affaires visée
• La réduction du coût d’infrastructure par transaction utile
• Les incidents, le taux de retour arrière et le temps de reprise
• Les anciens composants, chemins de données et procédures opérationnelles réellement retirés
• Les capacités d’affaires livrées avant que le programme n’atteigne son état final

Choisir parmi cinq actions

Un système en difficulté n’a pas toujours besoin d’être réécrit. Une revue devrait envisager au moins cinq options.

Le résultat peut être un parc mixte. Ce n’est pas un échec. Il s’agit souvent de la cible économiquement juste.

Ré-architecturer autour d’une contrainte, pas d’une mode

Avant d’approuver des travaux structurels, nommez la contrainte qu’ils élimineront et le seuil à partir duquel l’investissement sera rentable.

Ces questions protègent l’organisation contre deux erreurs équivalentes : conserver un système nuisible parce que son remplacement semble dangereux et remplacer un système utile parce qu’une nouvelle technologie paraît inévitable.

Moderniser par tranches qui résistent au contact de la production

Pour de nombreux systèmes essentiels aux revenus, la voie la plus sûre est un remplacement progressif derrière des frontières stables. La description mise à jour par Martin Fowler de la Strangler Fig Application met l’accent sur les résultats recherchés, la décomposition en plus petites parties, la livraison de ces parties et le changement organisationnel nécessaire pour maintenir le nouveau système.

Voici une séquence concrète :

1. Mesurer le système actuel sous une charge et à un coût réels.
2. Repérer une capacité d’affaires dotée d’une frontière claire et d’un bénéfice important.
3. Définir l’interface entre les anciens et les nouveaux chemins.
4. Établir les tests de comportement, de performance, de sécurité et de coût avant la migration.
5. Déplacer une part contrôlée du trafic, des utilisateurs ou des données.
6. Comparer les résultats et tester le retour arrière.
7. Ne retirer l’ancien chemin qu’une fois ses obligations opérationnelles elles aussi transférées.
8. Utiliser les apprentissages pour choisir la tranche suivante.

L’IA peut accélérer plusieurs étapes, en particulier l’analyse, la création de tests et la répétition d’un modèle établi. La migration reste guidée par les preuves.

Les systèmes sains portent leur histoire

Une entreprise bien gérée devrait s’attendre à ce que son parc logiciel contienne du code d’âges différents. Les composants stables préservent des comportements éprouvés. Les composants en évolution active absorbent les nouvelles exigences. Les composants transitoires permettent de déplacer la valeur sans bascule dangereuse.

L’objectif n’est pas le zéro legacy. L’objectif est un parc où l’âge ne détermine pas le risque, où les comportements importants sont compris, où les contraintes coûteuses sont visibles et où chaque remplacement majeur répond à une raison d’affaires.

L’IA rend davantage d’options de modernisation économiquement possibles. Une bonne direction technologique doit encore décider lesquelles en valent la peine.