Réécrire un service Scala en Java, faire passer un million de lignes de Python 2 à Python 3, sortir une application COBOL de son mainframe : ces chantiers se comptaient hier en trimestres, parfois en années. Les modèles de langage promettent de les compresser en jours. La promesse est réelle — mais elle ne tient qu'à une condition rarement mise en avant : un filet de tests solide et une revue humaine systématique. Sans cet échafaudage, la traduction automatique de code est bien moins fiable que les démonstrations ne le laissent croire. Voici ce que disent les chiffres, et comment migrer sans casser.
La promesse : des migrations qui prenaient des mois
Le discours commercial est spectaculaire, et il faut le lire avec la bonne distance. Certains agents de code généralistes — ces outils qui lisent un dépôt entier, éditent plusieurs fichiers, lancent les tests et proposent un commit — affichent des records de vitesse. Un éditeur rapporte une conversion de 10 000 lignes de Scala vers Java en quatre jours, là où l'estimation manuelle tournait autour de dix semaines-ingénieur. Un autre cas cité fait état de 50 000 lignes de Python migrées vers Go en une vingtaine d'heures, contre deux à trois mois estimés.
⚠️ Ces chiffres sont annoncés par l'éditeur, pas issus d'un audit indépendant. Ils décrivent des cas favorables, sur des bases probablement bien testées au départ. Traitez-les comme un plafond marketing, jamais comme une garantie sur votre propre code.
Côté outillage packagé, l'écosystème s'est structuré. GitHub Copilot app modernization pour Java est passé en disponibilité générale le 22 septembre 2025 : il cible Maven et Gradle, les versions Java 8 à 25 et Spring Boot, corrige les builds cassés, traite des CVE et adapte les tests, avec un argumentaire assumé de « jours au lieu de mois ». Son pendant .NET (commande @modernize-dotnet) fait migrer du .NET Framework vers .NET 8 et au-delà. Amazon Q Developer, via /transform et AWS Transform (disponible depuis le 15 mai 2025), adresse Java 8/11 vers 17/21, le .NET Framework vers le cross-platform et même le COBOL vers Java. IBM propose watsonx Code Assistant for Z, adossé à un modèle Granite 20B affiné sur des paires COBOL-Java, pour les migrations mainframe. L'offre existe. Reste à savoir ce qu'elle vaut réellement.
Ce qui marche vraiment : les succès encadrés
Les réussites documentées à grande échelle existent, et elles sont impressionnantes. Google a publié le détail d'une migration de types int32 vers int64 dans sa base publicitaire : 80 % des modifications ont été rédigées par l'IA, avec environ 50 % de temps en moins, un prédicteur identifiant les fichiers concernés à 91 %, et plus de 75 % des changements générés effectivement intégrés. Sur d'autres chantiers internes documentés — une migration de tests JUnit 3 vers JUnit 4 touchant 5 359 fichiers et 149 000 lignes en trois mois, avec 87 % de changements acceptés sans retouche, ou un passage de Joda-Time à java.time avec 89 % de temps économisé — le constat se répète.
Airbnb a raconté sa migration de 3 500 fichiers de tests d'Enzyme vers React Testing Library : six semaines de travail effectif, contre un an et demi estimé manuellement, en faisant grimper le taux d'automatisation de 75 % à 97 %. Le point commun de tous ces succès n'est pas le modèle utilisé. C'est la mécanique autour du modèle.
Le point commun : un pipeline, pas un prompt
Aucune de ces équipes n'a « demandé à l'IA de traduire le code » puis fusionné le résultat. Chacune a construit une chaîne de validation automatique qui rejette tout ce qui ne compile pas, ne passe pas les tests ou modifie le comportement observable. Le modèle propose ; le pipeline dispose. C'est cette distinction — succès encadré contre traduction brute — qui explique l'écart vertigineux avec les chiffres de laboratoire.
Le contrepoint honnête : la traduction brute est peu fiable
Sortie de son échafaudage, la traduction de code par LLM chute lourdement. L'étude « Lost in Translation » (ICSE 2024), sur 1 700 échantillons, mesure un taux de traductions correctes compris entre 2,1 % et 47,3 % selon le modèle, et recense quinze catégories de bugs récurrents. Un code peut être syntaxiquement impeccable et sémantiquement faux : il compile, il tourne, et il ne fait pas la même chose. Sur une traduction de C vers Rust avec GPT-4, la même veine de recherche relève 50 % d'erreurs de compilation, 39,3 % d'erreurs à l'exécution et 10,7 % d'échecs de tests. La figure suivante oppose ces deux mondes.
Le danger le plus sournois est sécuritaire. Une analyse dédiée mesure un taux d'introduction de vulnérabilités (VIR) de 28,6 % à 45 % lors des traductions, tandis que 54,3 % à 71,9 % des vulnérabilités présentes dans le code source sont préservées telles quelles. Pire : les relecteurs humains ne détectent ces régressions que dans environ 49,6 % des cas — l'équivalent d'un tirage à pile ou face. S'ajoutent deux pièges spécifiques aux LLM. L'hallucination de paquets (le « slopsquatting ») : jusqu'à 19,7 % de paquets inexistants suggérés dans certaines mesures — un taux redescendu à 4,62-6,10 % sur les modèles de frontière 2026, mais jamais nul. Et le faux sentiment de sécurité : une étude Stanford (CCS 2023) montre que les développeurs assistés produisent du code moins sûr tout en étant convaincus du contraire ; sur 89 scénarios CWE, une assistance de génération a produit du code vulnérable dans environ 40 % des cas.
⚠️ Le piège du « ça compile, donc c'est bon ». La compilation ne prouve rien sur l'équivalence de comportement. Une migration peut passer le build, passer une partie des tests, et introduire une faille ou un changement de logique invisible. Sans tests de non-régression qui capturent le comportement avant migration, vous n'avez aucun oracle pour attraper ces écarts. C'est exactement le sujet de notre article sur écrire des tests avec l'IA : le filet de sécurité se construit d'abord.
La méthode : migrer sous filet
La leçon des réussites documentées tient en une phrase : la fiabilité ne vient pas du modèle, elle vient de la chaîne. Voici le pipeline sûr, reconstitué à partir des pratiques publiées.
📖 Golden master tests (tests de caractérisation). Avant de toucher au code, on écrit des tests qui figent le comportement actuel du système — même ses bizarreries. Ils ne valident pas ce que le code devrait faire, mais ce qu'il fait réellement. Ils deviennent l'oracle contre lequel toute version migrée est comparée. Sur du Java, un outil comme Diffblue Cover automatise cette génération (par apprentissage par renforcement, sans LLM), ce qui en fait un vrai filet de non-régression.
Une fois le comportement capturé, on ne migre pas d'un bloc. Le motif Strangler Fig (Fowler) consiste à remplacer le système par petits lots testables, en faisant coexister ancien et nouveau, plutôt que par un big-bang risqué. Chaque lot passe ensuite une batterie de filtres automatiques avant tout regard humain. Le pipeline décrit par Google en enchaîne six : réponse non vide, nettoyage des espaces, analyse syntaxique (AST) valide, changement réellement nécessaire, build réussi, puis tests de non-régression au vert. Ce n'est qu'après ce tamis que la revue humaine intervient — et elle reste indispensable, car le goulot d'étranglement n'est plus la production de code mais sa vérification.
💡 Ajoutez du differential testing. Faites tourner l'ancienne et la nouvelle version côte à côte sur les mêmes entrées et comparez les sorties. C'est le moyen le plus économique d'attraper les divergences sémantiques que ni le compilateur ni les tests unitaires ne voient. Les build et suites de tests existants deviennent alors un oracle réutilisé en boucle : certains outils re-tentent la migration itérativement tant que les tests échouent.
Ce basculement change le rôle du développeur. Il produit moins, il valide davantage. C'est le cœur de notre article de fond sur le développeur, réviseur plutôt que producteur : dans une migration assistée, la valeur se déplace vers la conception des tests, la lecture critique des diffs et le jugement d'équivalence.
Choisir l'approche selon le type de migration
Toutes les migrations ne se ressemblent pas. Le bon outil dépend du couple risque sémantique / effort, comme le résume la matrice ci-dessous.
Montée de version (Java 8 vers 17, .NET Framework vers .NET moderne, une dépendance dépréciée) : c'est le terrain le plus sûr, et pas seulement pour les LLM. Les approches déterministes y excellent. Moderne et son moteur open source OpenRewrite ne passent pas par un modèle de langage : ils opèrent sur un arbre sémantique (LST) via des « recipes » — plus de 10 000 recettes disponibles. Lors de la remédiation Log4Shell, cette approche a couvert 400 dépôts et 38 000 points d'appel avec zéro régression. Pour ce type de transformation reproductible, un moteur déterministe est souvent préférable à un LLM, précisément parce qu'il ne hallucine pas. Codemod.com propose une logique voisine, « compiler-aware », en CLI open source.
Changement de langage (Scala vers Java, Python vers Go) : c'est là que les agents de code apportent le plus, mais aussi là où le risque sémantique culmine. C'est le domaine où les taux bruts de 2,1-47,3 % s'appliquent, donc le domaine qui exige le plus d'échafaudage.
Migration de framework (Enzyme vers React Testing Library, une API interne dépréciée) : effort volumineux mais risque modéré quand une suite de tests existe déjà, comme l'a montré le chantier Airbnb. C'est un excellent premier candidat pour se roder à la méthode.
Mainframe (COBOL vers Java) : effort et risque maximaux. Le COBOL porte encore environ 70 % des transactions bancaires selon IBM, souvent sans tests et sans documentation. Les offres spécialisées — watsonx Code Assistant for Z, la brique COBOL d'AWS Transform — visent ce créneau, mais aucune ne dispense de reconstruire d'abord un filet de caractérisation. Ici, la migration est autant un projet d'archéologie logicielle qu'un projet d'IA.
Un dernier repère : la migration assistée par IA prolonge des pratiques qui existaient avant les LLM (codemods déterministes, transformations AST). Dropbox a fait passer plus d'un million de lignes de Python 2 à 3, Stripe a migré de Flow vers TypeScript par codemod — sans modèle de langage. Le LLM n'a pas inventé la migration outillée ; il en élargit le périmètre, au prix d'une vigilance accrue. La même logique de sécurisation vaut d'ailleurs pour refactoriser du legacy sans tout casser.
🎯 À retenir. L'IA rend fiables les migrations encadrées, pas les migrations improvisées. Un : capturez le comportement dans des tests avant de migrer. Deux : avancez par petits lots (Strangler Fig), jamais en big-bang. Trois : intercalez des filtres automatiques (AST, build, tests) avant toute revue. Quatre : pour une montée de version, préférez souvent un moteur déterministe. Cinq : gardez la revue humaine comme dernier rempart — c'est désormais le vrai travail.
📖 Note d'honnêteté. Les capacités et chiffres cités ici proviennent de publications d'éditeurs, d'études de cas d'entreprises et de travaux de recherche, à jour au 5 juillet 2026 ; les records de vitesse d'agents de code sont auto-déclarés par leurs éditeurs, non audités. Le résultat sur votre code dépendra entièrement de votre pipeline de tests et de la rigueur de votre revue — pas du modèle choisi. Nous documentons des méthodes vérifiables ; nous ne migrons pas votre base à votre place, et aucun chiffre de cet article ne constitue une garantie sur votre propre chantier.
Pour aller plus loin
La migration assistée est un cas d'école du bon usage de l'IA en ingénierie : puissante sous contrainte, dangereuse sans. Pour recevoir nos analyses d'outils et nos méthodes vérifiées, abonnez-vous à la newsletter AISkillsPro. Et pour une cartographie complète des outils d'IA pour le développement — capacités, statuts et limites à jour — téléchargez notre lead magnet « Atlas IA 2026 ».