Comprendre et moderniser d'anciennes bases de code avec l'IA

Le code legacy sans tests ne se réécrit pas simplement comme ça – les tests de caractérisation et les petites étapes rendent la modernisation assistée par IA sûre.

Ce qui rend le code legacy particulier

Le développeur Michael Feathers a défini un jour, de façon lapidaire, le code legacy comme du « code sans tests ». C'est exactement ce qui le rend dangereux à modifier : personne – pas même un agent IA – ne peut vérifier si un changement casse le comportement s'il n'existe aucun test capturant ce comportement.

Première étape : capturer le comportement, pas l'améliorer

Avant de restructurer quoi que ce soit, tu as besoin de tests de caractérisation. Ce sont des tests qui notent ce que le code fait MAINTENANT – même si ça semble bizarre, voire buggé. Ce n'est pas un jugement de qualité, juste un instantané qui protège les changements ultérieurs.

Deuxième étape : migrer progressivement

Une réécriture complète est risquée : rien ne fonctionne de façon fiable tant que la nouvelle version n'est pas terminée, et un comportement ancien subtil se perd souvent en route. La migration progressive est une approche plus éprouvée – un motif connu sous le nom de « figuier étrangleur » (strangler fig) : de nouvelles parties poussent petit à petit autour de l'ancien code, jusqu'à ce que l'ancien puisse finalement être désactivé.

Où les agents IA sont particulièrement utiles ici

Un agent peut résumer rapidement de gros modules non documentés et proposer des tests de caractérisation possibles – un travail qui coûte normalement très cher en l'absence de documentation. Ce qui reste important : comprendre et sécuriser d'abord, changer seulement ensuite.

EXEMPLE

Prompt : « Ce module de 1 800 lignes n'a ni tests ni doc. Résume d'abord ce qu'il fait fonctionnellement. Écris ensuite des tests de caractérisation pour les cinq fonctions les plus importantes, qui capturent le comportement ACTUEL – même s'il semble bizarre. Ne change encore aucun code. »

🛠️ EXERCICE — À TOI DE JOUER

Prends un module non testé et confus d'un de tes projets (ou d'un projet open source) et sécurise-le avec des tests de caractérisation avant de changer quoi que ce soit.

Fais d'abord résumer par l'agent ce que le module fait fonctionnellement, sans changer de code.
Identifie avec lui 3 à 5 entrées/appels typiques et fais écrire par l'agent des tests qui capturent les sorties actuelles comme valeur attendue.
Seulement après : effectue un premier petit changement isolé et vérifie si les tests de caractérisation sont toujours verts.

✅ AUTO-VÉRIFICATION

☐ Les tests couvrent-ils les chemins les plus importants, pas seulement le cas le plus simple ?
☐ As-tu délibérément capturé le comportement ACTUEL, au lieu de déjà le « améliorer » en testant ?
☐ Après le premier changement, est-ce que tout est encore vert – ou un test rouge montre-t-il exactement ce qui a changé ?

QUIZ RAPIDE

Qu'est-ce qu'un test de caractérisation ?