Moderniser le code legacy avec l'IA : ce qui fonctionne et ce qui tourne mal

Le plus grand bénéfice de l'IA sur les systèmes anciens ne réside pas dans la réécriture, mais dans la compréhension. Un modèle peut expliquer du code non documenté, rendre visibles les dépendances et écrire des tests pour le comportement existant — précisément les trois choses qui rendent une modernisation planifiable. La traduction automatique vers un nouveau langage ou un nouveau framework est en revanche l'usage le plus risqué.

Qu'est-ce que le code legacy ?

La définition la plus utile vient de Michael Feathers : le code legacy est du code sans tests. Pas du vieux code, pas du code mal écrit — du code pour lequel on ne peut pas vérifier si une modification a cassé quelque chose.

Cette définition est si utile parce qu'elle nomme le véritable problème. Un ancien système bien testé peut être modifié sans danger. Du code fraîchement généré sans tests est, selon cette définition, immédiatement du legacy — dès le jour de sa création.

En quoi l'IA aide-t-elle réellement sur les systèmes anciens ?

Sur trois tâches qui précèdent toute modernisation et qui étaient jusqu'ici les plus coûteuses.

• Comprendre. Un modèle peut résumer une procédure de 900 lignes, énumérer les embranchements et nommer les cas particuliers traités. Cela ne remplace pas une vérification, mais réduit la prise en main de jours à quelques heures.
• Documenter. Produire à partir du code existant une description de l'état actuel — avec la précision expresse qu'il s'agit de l'état réel et non de l'état souhaité.
• Sécuriser. Écrire des tests qui figent le comportement actuel. C'est la condition de toute modification ultérieure et le travail que personne n'aime faire.

Le troisième point a un revers qu'il faut connaître : de tels tests cimentent aussi les erreurs existantes. C'est voulu — vous sécurisez le comportement, pas l'exactitude — mais cela doit être clair pour toutes les personnes impliquées, sinon une exécution de tests au vert passera plus tard pour une preuve de justesse.

Pourquoi la réécriture automatique est-elle si risquée ?

Parce que le savoir contenu dans le vieux code ne figure pas dans le code. Une condition qui paraît absurde au premier regard est souvent la trace d'un cas particulier réel : un client avec un contrat différent, un jour férié, une particularité d'un ancien stock de données.

Un modèle qui transpose le code dans un nouveau langage voit cette condition comme une bizarrerie et, avec une certaine probabilité, la simplifie jusqu'à la faire disparaître. Le résultat est plus lisible, compile, passe les tests — et se comporte différemment dans le seul cas pour lequel la condition existait. Ce cas ne se remarque généralement qu'en exploitation, et la cause est alors difficile à trouver, parce que le nouveau code a l'air correct.

Comment aborder une modernisation avec l'aide de l'IA ?

En quatre phases, dont les deux premières apportent l'essentiel du bénéfice.

• Phase 1 — Cartographier. Qu'est-ce qui existe, qu'est-ce qui dépend de quoi, qu'est-ce qui est réellement utilisé ? L'IA est ici performante et le risque est nul, car rien n'est modifié.
• Phase 2 — Sécuriser. Des tests pour le comportement actuel des zones que l'on veut toucher. Pas pour tout — pour ce qui est concerné.
• Phase 3 — Encercler. Encapsuler l'ancienne partie derrière une interface et la remplacer morceau par morceau, plutôt que de tout échanger d'un coup. L'ancien système reste exécutable jusqu'au bout.
• Phase 4 — Remplacer. Maintenant, un modèle peut traduire — brique par brique, avec les tests de la phase 2 comme étalon et un humain qui remet en question chaque simplification.

Qui commence à la phase 4 saute précisément le travail qui fait la différence entre une modernisation et une reconstruction coûteuse au comportement inconnu.

À quoi reconnaît-on qu'une modernisation en vaut la peine ?

Au coût des modifications, pas à l'âge du code. Un système vieux de douze ans, dans lequel on modifie un détail deux fois par an, n'est pas un problème mais un investissement amorti.

Les signaux qui comptent : les modifications prennent un temps disproportionné ; les corrections d'erreurs en créent de nouvelles ; personne n'ose toucher à certaines zones ; une exigence ne peut techniquement plus être mise en œuvre ; les mises à jour de sécurité des bibliothèques utilisées ne sont plus disponibles. Ce dernier point gagne en poids, car les obligations de notification du règlement européen sur la cyberrésilience (Cyber Resilience Act) s'appliquent à partir du 11 septembre 2026 — qui doit notifier en 24 heures les vulnérabilités activement exploitées a besoin d'un système dans lequel les vulnérabilités peuvent effectivement être corrigées.

Si vous souhaitez être accompagné sur ce chemin : c'est précisément à cela que travaille notre développement SaaS et logiciel.

Questions fréquentes sur le code legacy

À partir de quand le code est-il considéré comme legacy ?

Selon Michael Feathers, dès l'instant où il n'a pas de tests. L'âge ne joue aucun rôle dans cette définition — ce qui a été généré hier et n'a pas été sécurisé en relève.

Une IA peut-elle reconstruire entièrement une ancienne application ?

Elle peut construire une application qui semble faire la même chose. Qu'elle traite les mêmes cas particuliers se décide avec les tests de la phase 2 — sans eux, vous n'avez pas d'étalon, mais un espoir.

Qu'en est-il de COBOL, ABAP et des langages anciens similaires ?

Pour expliquer et documenter, les modèles fonctionnent de manière utilisable là aussi. Pour la traduction, il en va comme ailleurs, en plus aigu : plus le langage est spécialisé, moins il y a de matériel d'entraînement et plus les particularités risquent d'être simplifiées jusqu'à disparaître.

Combien de temps dure une telle modernisation ?

Cela dépend presque entièrement de ce qu'il y a à sécuriser en phase 2 — et cela peut être estimé sérieusement après la phase 1, pas avant. Une estimation avant la cartographie est une conjecture.

À la phase 4, tout se joue sur la question de savoir si chaque simplification est remarquée. Code Guardian vérifie les modifications par rapport à l'existant plutôt que par rapport à la commande — un regard froid sur le diff, qui demande ce qui a en réalité disparu ici.

Sources

• Michael Feathers, Working Effectively with Legacy Code (définition : code sans tests).
• Règlement (UE) 2024/2847 (Cyber Resilience Act) : obligations de notification à partir du 11 septembre 2026, obligations principales à partir du 11 décembre 2027.

Au 27 juillet 2026. Classement technique général, pas un conseil juridique.