Moderniser un logiciel legacy sans documentation avec un agent IA : la méthode

Un logiciel legacy est un système encore utile dont la connaissance a quitté l’équipe : la documentation manque, les auteurs sont partis, les tests n’existent pas. Il tourne, il porte des règles métier que personne ne sait plus énoncer, et chaque modification ressemble à un pari. Le moderniser commence par retrouver ce qu’il fait.

Les agents de code changent l’économie de cette étape. Ils lisent des milliers de lignes, cartographient les dépendances, rédigent une documentation et proposent des tests. Ils ne changent pas la règle de fond : rien ne bouge avant que le comportement actuel soit figé et vérifiable. Voici la méthode, de l’inventaire à la bascule réversible.

Un logiciel legacy est un système encore utile dont la connaissance a quitté l’équipe : documentation absente ou fausse, auteurs partis, tests manquants.

L’âge n’est pas le critère. Michael Feathers, dans Working Effectively with Legacy Code (2004), retient une définition opérationnelle : du code legacy est du code sans tests. Un module écrit l’an dernier peut donc être legacy dès sa livraison, si personne ne peut le modifier en sachant ce qu’il casse.

Trois questions posent le diagnostic. Qui sait pourquoi telle règle existe ? Que casse-t-on en changeant telle ligne ? Avec quel outil le système se reconstruit-il ? Sans réponse sûre, le logiciel est legacy, quel que soit son langage.

Le même diagnostic vaut pour un système d’IA hérité, traité dans reprendre un système d’IA construit par quelqu’un d’autre. La dette tient à l’écart entre ce que le système fait et ce que l’équipe croit qu’il fait, comme le détaille la dette technique d’un système d’IA.

Il existe quatre options : conserver en l’état, encapsuler derrière une interface, réécrire progressivement ou remplacer par un produit du marché.

La réécriture complète en une fois ne figure pas dans le tableau. C’est l’option la plus tentante et celle qui concentre le plus de risque : l’ancien système continue d’évoluer pendant la réécriture, et tout bascule le même jour.

Le choix tient à deux questions : le métier demande-t-il souvent des changements, et les règles du système sont-elles propres à l’entreprise ? Pour encapsuler un progiciel sans interface, voir brancher un modèle sur un progiciel sans API.

Un agent de code réduit fortement le coût de la compréhension : il lit, cartographie, documente et propose des tests, mais il ne garantit pas que ce qu’il écrit est vrai.

Ses apports se rangent en cinq usages :

• Lire et cartographier : points d’entrée, appels entre modules, accès aux bases, fichiers lus et écrits, tâches planifiées.
• Produire une documentation : description de chaque module, glossaire des règles métier repérées, diagramme de séquence. GitHub décrit cette séquence (explication du code, diagramme de flux, plan de tests) dans son exemple de migration d’une application COBOL vers Node.js.
• Écrire des tests de caractérisation : harnais d’exécution, cas limites, assertions sur les sorties actuelles.
• Aider à la traduction de langage : COBOL, Perl, Visual Basic ou Delphi vers un langage maintenu, fonction par fonction, sous le contrôle des tests.
• Analyser un binaire sans source : quand le code source est perdu, un outil comme REA donne à un agent la capacité d’inspecter un exécutable natif, une application JavaScript ou Electron, et d’en expliquer la logique. Voir REA, l’agent de rétro-ingénierie logicielle et rétro-ingénierie logicielle : ce que le droit autorise.

Ce qui ne change pas : la sortie d’un modèle n’est pas déterministe, et GitHub recommande lui-même de vérifier chaque proposition. Une documentation générée est une hypothèse sur le code, pas une description du code.

Par un inventaire : ce que le système contient, ce qu’il touche et qui l’utilise, avant la moindre ligne modifiée.

Je commence par faire produire à l’agent une carte du système en six rubriques : le code (langages, versions, compilation), les dépendances, les données (schémas, fichiers, formats), les interfaces avec d’autres applications, l’exploitation (tâches planifiées, déploiement) et les personnes (utilisateurs, derniers intervenants).

Chaque affirmation de cette carte porte une étiquette : vérifiée ou à vérifier. Une affirmation est vérifiée quand on l’a constatée en exécutant le système, ou quand une personne du métier l’a confirmée.

L’inventaire fixe aussi la première tranche à migrer : une fonction peu couplée au reste, utilisée régulièrement, dont la sortie est facile à observer. Elle sert d’abord à prouver que la chaîne complète fonctionne.

Avec des tests de caractérisation, aussi appelés golden master : ils enregistrent ce que le système fait aujourd’hui et deviennent la référence que toute modification doit respecter.

Un test de caractérisation, au sens de Feathers, ne dit pas ce que le code devrait faire : il décrit ce qu’il fait. On exécute le code sur une entrée, on écrit une assertion volontairement fausse, on lit la valeur réelle dans l’échec et on en fait la valeur attendue. Les bogues sont figés eux aussi : on les corrigera plus tard, explicitement.

À l’échelle du système, le golden master rejoue un jeu d’entrées représentatives et conserve les sorties complètes : fichiers produits, état de la base, messages émis. L’agent est efficace pour écrire le harnais et proposer des cas limites. Les entrées, elles, viennent de la production, anonymisée, ou de cas choisis avec le métier. Pour monter ce jeu rapidement, voir construire un jeu de tests en une journée.

On mesure ensuite ce que ces tests couvrent : une branche jamais exécutée par les tests est une branche que la migration peut casser en silence.

En appliquant le motif « strangler fig » décrit par Martin Fowler : le nouveau système grandit à côté de l’ancien et reprend ses fonctions une à une, jusqu’à ce que l’ancien puisse être retiré.

Fowler a décrit l’approche en 2004 sous le nom de Strangler Application, puis l’a renommée Strangler Fig Application, d’après le figuier étrangleur qui pousse autour de son arbre hôte. Le principe : une façade reçoit les appels et les dirige soit vers l’ancien code, soit vers le nouveau. Chaque fonction migrée réduit la surface de l’ancien système.

Fowler ne cache pas le coût : il faut construire une architecture transitoire, du code qui disparaîtra une fois la modernisation terminée. Il soutient que la baisse du risque et la valeur livrée plus tôt compensent cet effort.

L’agent intervient ici tranche par tranche. Il traduit ou réécrit une fonction, les tests de caractérisation de cette fonction tournent sur la nouvelle version, et la tranche suivante n’est ouverte qu’une fois la précédente en production.

En faisant tourner l’ancien et le nouveau sur les mêmes données réelles et en comparant leurs sorties, écart par écart, avant de confier le moindre résultat au nouveau.

Les tests de caractérisation couvrent les cas que l’on connaît. La comparaison en parallèle couvre ceux que personne n’a pensé à écrire. Le nouveau code reçoit une copie des appels, ou rejoue un lot de production ; sa sortie est enregistrée mais n’est utilisée par personne.

Chaque écart est classé dans l’une de trois catégories : un défaut du nouveau code, à corriger ; un défaut de l’ancien que l’on décide de corriger, par une décision métier tracée ; une différence acceptable, comme un arrondi ou un ordre de tri, déclarée explicitement. Un écart non expliqué bloque la bascule.

C’est la même logique que pour remplacer un modèle en production, décrite dans migrer un agent sans régression : le nouveau se juge sur ses sorties, comparées à l’existant.

En gardant l’ancien système prêt à reprendre la main : la bascule se fait par un réglage dans la façade, pas par une mise en production sans retour.

Chaque fonction migrée a son interrupteur, et la montée se fait par paliers : un service, un site, une partie des utilisateurs. Pendant toute la période de retour possible, les données écrites par le nouveau système restent lisibles par l’ancien, faute de quoi le retour en arrière devient une seconde migration.

Les critères de retour se fixent avant la bascule, pas pendant l’incident : quels seuils le déclenchent, et qui le décide.

L’ancien système n’est éteint qu’après une période sans retour couvrant au moins un cycle métier complet : une clôture mensuelle, une paie, un inventaire annuel selon le cas.

Quatre pièges reviennent : une documentation générée prise pour vraie, des règles métier implicites, des données mal comprises et du code confidentiel envoyé à un modèle sans cadre.

La documentation générée prise pour vraie

Une documentation produite par un agent est fluide, structurée et convaincante, y compris quand elle se trompe. Le risque est qu’elle devienne la référence de l’équipe sans avoir été confrontée à l’exécution.

Les règles métier implicites

Un seuil codé en dur, un cas particulier pour un client, un traitement qui ne s’exécute qu’en fin de mois : ces règles ne portent aucun nom dans le code. Elles n’apparaissent qu’en exécutant le système sur des données réelles, d’où l’importance du golden master et de la comparaison en parallèle.

Les données

Le code n’est que la moitié du système. Encodages anciens, champs détournés de leur usage, valeurs conventionnelles qui signifient « inconnu » : une migration qui traduit fidèlement le code mais interprète mal les données produit des résultats faux avec un code correct.

La confidentialité du code envoyé au modèle

Le code contient parfois des secrets (mots de passe en clair, adresses internes) et ses jeux d’essai des données personnelles. Avant d’envoyer un dépôt à un service de modèle, on vérifie le contrat, la conservation et l’usage pour l’entraînement, puis on retire les secrets. Les règles sont détaillées dans ce qu’on a le droit de mettre dans un prompt ; quand le code ne doit pas sortir, voir les petits modèles sur poste. Sur le code produit, voir le code écrit par un modèle et ce qu’on a le droit de livrer.

Quand le système est stable, rarement modifié et que sa plateforme reste supportée : la modernisation coûte alors plus qu’elle ne rapporte.

Un logiciel ancien qui rend son service, que le métier ne fait pas évoluer et dont l’environnement reçoit encore les correctifs de sécurité peut rester en place. Le moderniser pour un langage récent ajoute un risque sans contrepartie.

Les signaux inverses justifient d’agir : plateforme qui n’est plus maintenue, failles qui ne seront pas corrigées, compétences disparues, demandes métier bloquées faute de pouvoir modifier le code.

Même sans migration, l’inventaire et les tests de caractérisation gardent leur valeur : ils réduisent le risque du prochain incident et préparent la décision suivante. Pour arbitrer entre ces options sur un système précis, un audit IA part de cet inventaire et chiffre chaque scénario.

Analyse et méthode proposées par Anand Candassamy au 13 octobre 2026.