Beaucoup d’entreprises vivent avec des applications internes qu’elles n’osent plus toucher. Le code tourne mais repose sur une technologie vétuste qui n’est plus maintenue. Il n’y a plus de mises à jour de sécurité, et donc les failles s’accumulent (les mots de passes sont stockés avec MD5 sans salage par exemple). Si la question d’une mise à jour technique s’est régulièrement posée, le pas n’a jamais été franchi et la dette s’est accumulée. La codebase de l’entreprise est donc conservée sans être entretenue, faute de mieux.
Or, le 16 juillet 2026, l’entreprise américaine Anthropic a
annoncé avoir intégralement réécrit
Bun en Rust à l’aide de son modèle de langage Claude. A l’heure de l’IA générative, l’équilibre a changé. Pour les systèmes multi-agents et les derniers modèles de langage, l’échelle de la base de code est atteinte. La
migration d’un backend de 100 000 lignes de code par des modèles d’IA est une tâche
accessible en
deux semaines.
L’objectif de la migration est multiple : on met à jour la stack technique, on s’assure que la migration ne change que la syntaxe (et non le comportement) du code, et on détecte au passage des bugs ou des failles. La migration se déroule de la manière suivante :
On cartographie les endpoints du code legacy : ce sont les points d’entrée à partir desquels la migration s’opère
Pour chacun des endpoints, des agents IA génèrent des tests pour construire un “Golden master”
On passe ensuite à la migration du code proprement dite, avec des workflows IA respectant une logique de parcours en profondeur pour chaque endpoint
Chaque agent itère pour que le code migré respecte exactement les tests du Golden master
Les différents workflows sont recollés pour factoriser le code et détecter des erreurs de compilation
A la fin, on obtient un rapport décrivant les bugs détectés par les différents agents et les tests auxquels on a volontairement dérogé (parce qu’il s’agissait de bugs qu’on n’a pas voulu reproduire)
Garantir un comportement identique
Comment s’assurer de
l’exactitude de la migration ? C’est l’idée de la méthode du
Golden master. Pour que le comportement soit le même, il faut que chaque requête ait la même réponse, même si c’est une erreur 500 (internal server error). Il faut que toutes les réponses, y compris les bugs et les erreurs, persistent dans le même état, avant et après la migration. Ces erreurs doivent être signalées, mais il faut que la correction de chacune soit contrôlée.
Le changement de comportement doit rester une exception. Il faut donc écrire
un maximum de tests : des tests unitaires, des tests d’intégration, et des tests end-to-end. Tester aussi la gestion des erreurs et des cas pathologiques.
Pour renforcer la robustesse et la pertinence des tests, on adopte une structure “adversarial” : un agent attaquant et un défenseur. L’attaquant n’a accès qu’aux contrats des fonctions (quels arguments prend-elle ? que renvoie-t-elle ? à quoi sert-elle ?). Son objectif est d’écrire des tests : les happy paths, mais aussi et surtout les cas pathologiques. En face, l’agent défenseur est celui qui est responsable de la migration proprement dite. Il faudra donc que le défenseur itère si nécessaire jusqu’à ce que la migration satisfasse les tests que l’attaquant aura générés.
L’idée derrière cette structure attaquant/défenseur est d’empêcher le phénomène de complaisance (
sycophancy) des agents IA dans l’écriture des tests. En ne donnant à l’attaquant que les contrats et non le code des fonctions qu’il doit tester, on évite que les tests soient tautologiques et ne soient que la retranscription du code.
Ecrire des tests est aussi une assurance pour l’avenir : en cas d’ajout de fonctionnalités futures, des tests robustes et exhaustifs déjà présents permettent de s’assurer de la compatibilité des modifications avec le reste de l’application.
Migrer sa codebase
Pour la migration, le système multi-agent est architecturé de la façon suivante : un orchestrateur génère des sous-agents pour migrer chacun des endpoints. Il a aussi pour rôle de factoriser le code et de mettre en commun les résultats à la fin de la migration.
Chaque sous-agent a la responsabilité d’un endpoint. Il doit le transcrire dans le nouveau langage. Par exemple, chez Galadrim, un modèle vue-contrôleur (
MVC) en NET 4.8 a été migré vers un backend en .NET 9 et un frontend en React.
Claude Code, de l’entreprise Anthropic, est un harnais efficace pour ce genre de tâche : un agent principal (l’orchestrateur) engendre automatiquement les sous-agents chargés de l’écriture des tests et de la migration. Nous procédons par vagues : à chaque vague, 3 sous-agents sont chargés de migrer des endpoints. Chaque sous-agent a la responsabilité d’un groupe d’endpoint (par exemple, quatre endpoints CRUD font partie d’un même groupe, qu’un sous-agent devra migrer).
Il peut être nécessaire, pour faire tourner une codebase ancienne, d’utiliser une VM Windows (c’est le cas pour le .NET 4.8 par exemple) afin de générer les tests end-to-end. Les agents chargés de générer les tests se connectent alors automatiquement à la VM pour envoyer la requête et récupérer la réponse du legacy pour construire le Golden Master.
Une fois que toutes les vagues de migration sont terminées, l’orchestrateur est chargé de recoller les bouts et de factoriser le code. C’est le cas notamment si des fonctions ont été dupliquées lors de la migration car nécessaires pour plusieurs endpoints. C’est aussi l’occasion de vérifier qu’il n’y a pas de problèmes de compilation (que la simplification pourrait causer) et que l’application migrée se lance correctement.
Détecter bugs et failles de sécurité
En balayant le code de tests, on peut aussi détecter des bugs majeurs passés sous silence jusqu’alors, et de failles de sécurité. Par exemple, on a découvert dans l’application legacy qu’un endpoint était exposé publiquement, sans nécessité d’authentification (contrairement à tous les autres), et donc que les données auxquelles il donnait accès pouvait être lues sans restriction. Un passage exhaustif dans le code permet aussi de détecter du code mort, qui ne servirait pas et qui polluerait le reste. Cela peut notamment se manifester par des tables présentes en base de données mais qui sont invisibles pour l’application car inutilisées.
En somme, faire la migration de sa codebase à l’aide d’un système multi-agents, c’est d’une part mettre à jour son code pour assurer sa maintenabilité et sa rapidité, mais c’est aussi détecter au passage les risques de sécurité et les bugs majeurs présents dans un code qui n’est plus maintenu.
Bilan : avec l’IA, deux semaines pour migrer sa codebase
Combien coûterait un tel projet ? La migration manuelle coûterait des dizaines voires des centaines de milliers d’euros et prendrait plusieurs mois. C’est la raison pour laquelle les codebases n’évoluent pas et restent dans le même état à long terme.
L’approche multi-agents au contraire réduit drastiquement les ordres de grandeur. Chez Galadrim, nous convertissons un backend de 120 000 lignes en deux semaines. Avec le modèle Opus 4.8 d’Anthropic, les ordres de grandeur sont les suivants :
2,5 milliards de tokens (pour la plupart des tokens de cache, moins chers que des tokens d’input ou d’output)
1 800 $ de coût API
4 000 tests générés
40 heures d’inférence environ, parallélisées pour la plupart (lorsque 3 agents tournent pendant 1h en parallèle, cela représente 3h d’inférence pour 1h de temps réel)
