Dans le passé, les migrations de langages de programmation à grande échelle étaient le genre de projets que les équipes d’ingénierie repouss...
Dans le passé, les migrations de langages de programmation à grande échelle étaient le genre de projets que les équipes d’ingénierie repoussaient pendant des années. Ces migrations étaient coûteuses, perturbatrices et extrêmement risquées. Une entreprise pouvait passer plusieurs trimestres à maintenir simultanément deux versions d’implémentation, pour finalement obtenir un remplaçant dont le comportement différait de l’original.
Claude Code est en train de changer la donne.
Anthropic a récemment dévoilé son processus de migration de code à grande échelle utilisant des agents d’IA. Le cas le plus remarquable est celui de Jarred Sumner, créateur de Bun, qui a migré le cœur de Bun de Zig vers Rust. En moins de deux semaines, le flux de travail Claude Code a généré plus d’un million de lignes de code, et la suite de tests existante de Bun était déjà validée par l’intégration continue avant la fusion.
Ce projet n’a pas été réalisé en demandant simplement au modèle de « réécrire Bun en Rust » en attendant une réponse parfaite. Il reposait sur un système soigneusement conçu, comprenant un manuel de règles, une cartographie des dépendances, une file d’attente mécanisée, des réviseurs adversaires, des compilateurs, des tests de non-régression et des vérifications de cohérence comportementale.
La leçon fondamentale est directe : pour une migration de cette envergure, les développeurs ne devraient pas passer la plupart de leur temps à corriger des fichiers un par un. Ils devraient améliorer le processus de génération, de révision et de validation de ces fichiers.
Jarred Sumner a initialement construit Bun avec Zig. Ce langage permettait à un développeur indépendant d’obtenir à la fois un contrôle de bas niveau et des performances proches de celles du C, sans avoir à faire face à toute la complexité de l’écosystème des grands langages système.
Ce choix a aidé Bun à se développer rapidement dès le début. Sumner a déclaré avoir écrit la première version en environ un an, dans un petit appartement à Oakland, avant l’ère des modèles de codage modernes.
En 2026, Bun était devenu un environnement d’exécution, un gestionnaire de paquets, un exécuteur de tests et un outil de construction largement utilisé pour JavaScript et TypeScript. Ses outils en ligne de commande étaient téléchargés des dizaines de millions de fois par mois, et des produits comme Claude Code dépendaient fortement de Bun.
Cette croissance a également rendu les anciens compromis techniques impossibles à ignorer.
Bun associe un moteur JavaScript à collecte de déchets à une mémoire native gérée manuellement. En Zig, les développeurs doivent raisonner explicitement sur les allocations, le nettoyage, les chemins d’erreur et les cycles de vie des objets. L’équipe de Bun a investi massivement dans les sanitizers, les tests de fuzzying, les builds de sécurité et les tests de fuite mémoire, mais les erreurs d’utilisation après libération, les doubles libérations, les fuites et les erreurs de cycle de vie persistaient.
Rust offre une base différente. Son système de propriété, son vérificateur d’emprunts et son nettoyage automatique peuvent convertir de nombreux problèmes de mémoire à l’exécution en erreurs de compilation.
Historiquement, cet avantage ne suffisait pas à justifier une réécriture complète. Bun contient des centaines de milliers de lignes de code Zig, ainsi que de nombreuses intégrations natives. Une réécriture traditionnelle aurait pu consommer un an ou plus d’une petite équipe d’ingénierie, tout en ralentissant le développement de fonctionnalités et les correctifs de sécurité.
Claude Code a rendu une migration entièrement mécanisée réalisable.
Sumner a utilisé une version préliminaire de Claude Fable 5 et les flux de travail dynamiques de Claude Code pour effectuer la migration.
L’écriture et la révision principales
Le processus a fonctionné sans interruption pendant 11 jours. Environ 50 flux de travail dynamiques ont géré différentes étapes, notamment :
.zig en fichiers .rsAu débit maximal, le flux de travail produisait environ 1 300 lignes de code par minute. Chaque unité de code générée était examinée par deux réviseurs adversaires indépendants, puis les modifications confirmées étaient appliquées par un correcteur.
La demande d’extraction finale a ajouté plus d’un million de lignes de code dans plus de 2 000 fichiers modifiés.
Avant la fusion, la suite de tests existante de Bun passait dans l’intégration continue. Après la fusion, 19 régressions sont apparues, qu’Anthropic a rapportées comme ayant toutes été corrigées par la suite. Le portage Rust a été publié avec Claude Code en juin 2026.
Ce résultat ne prouve pas que le million de lignes de code initialement généré était correct. Sumner a clairement indiqué que les premières traductions produites ne fonctionnaient pas. La clé du succès résidait dans le système de rétroaction qui transformait progressivement les sorties inutilisables en code compilé, testé et comportementalement compatible.
La migration de Bun a consommé environ :
C’est une somme non négligeable, mais bien inférieure au coût traditionnel d’une migration qui nécessiterait plusieurs ingénieurs à plein temps pendant des années.
Anthropic estime qu’une migration d’un million de lignes aurait auparavant pu prendre quatre ans et coûter entre 3 et 4 millions de dollars en ressources d’ingénierie. L’IA change la donne, car une migration ne nécessite plus une crise existentielle pour justifier son coût.
Des erreurs mémoire persistantes, un écosystème de langage vieillissant, des processus de construction coûteux ou des goulots d’étranglement de maintenance récurrents peuvent désormais suffire à rendre une migration digne d’être évaluée.
Cependant, les comparaisons doivent être faites avec prudence. Le coût en jetons n’est pas le coût total du projet. L’équipe a également besoin de planification humaine, d’infrastructure, de tests, de révision de code, de travail de sécurité et de maintenance après la fusion.
Cette migration était principalement motivée par la fiabilité, et non par la vitesse brute.
Bun était déjà performant en Zig. Le problème était la coordination sécurisée entre la mémoire native gérée manuellement et l’environnement d’exécution JavaScript à collecte de déchets.
Les catégories de défaillance courantes comprenaient :
En Rust sûr, bon nombre de ces erreurs ne peuvent pas être compilées. Les valeurs ont une propriété claire, le nettoyage des ressources est lié au cycle de vie des objets, et le compilateur vérifie les références avant l’exécution du programme.
L’objectif de cette migration était de préserver l’architecture existante de Bun, ses structures de données, son comportement et ses performances. Elle était délibérément plus proche d’un portage mécanique que d’une refonte complète.
Cette décision a été cruciale. Si le système avait été repensé et le langage changé simultanément, la comparaison des comportements aurait été extrêmement difficile.
Jarred Sumner n’est pas le seul ingénieur d’Anthropic à utiliser Claude Code pour des migrations majeures.
Mike Krieger, co-responsable des laboratoires Anthropic et co-fondateur d’Instagram, a migré en un week-end une base de code Python interne en environ 165 000 lignes de code TypeScript.
La migration principale a consommé environ 27 millions de jetons, impliquant :
L’outil d’origine devait être livré sous forme d’un seul binaire. Avec la chaîne d’outils Python, la compilation prenait environ huit minutes par plateforme, et la matrice de construction complète retardait chaque version d’environ 30 minutes.
Après la migration vers TypeScript :
Krieger ne disposait pas d’une suite de tests exhaustive et multilingue. Au lieu de cela, Claude
Un cadre de test de cohérence couvrant sept scénarios réels a été créé, puis les résultats produits par l'ancienne et la nouvelle implémentation ont été comparés.
Claude a également conçu des tests de bout en bout supplémentaires, les a exécutés pendant quatre nuits consécutives, a corrigé les échecs, puis a répété le processus. Cela a permis de révéler des différences de comportement subtiles que les scénarios originaux n'avaient pas anticipées.
Les migrations à grande échelle sont intimidantes car elles impliquent une multitude de modifications répétitives. Ce sont précisément ces caractéristiques qui les rendent appropriées pour les workflows basés sur des agents intelligents.
Les grandes bases de code peuvent généralement être décomposées en fichiers, packages, crates, modules ou groupes de dépendances. Des agents intelligents indépendants peuvent traiter simultanément des unités sans lien entre elles.
Le graphe de dépendances détermine quelles unités peuvent avancer en parallèle et lesquelles doivent attendre.
L'implémentation d'origine contient déjà les comportements, les cas limites, les structures de données et les détails d'intégration requis.
Le modèle n'a pas besoin d'inventer des fonctionnalités produit ; sa tâche consiste à préserver le système existant dans un nouveau langage ou framework.
Les agents intelligents fonctionnent mieux lorsqu'ils peuvent évaluer mécaniquement leurs propres résultats.
Le compilateur, la suite de tests, la comparaison des différences de sortie, les benchmarks ou les cadres de test de cohérence fournissent des signaux concrets au système. L'agent peut ainsi s'améliorer en continu, sans nécessité de jugement humain pour chaque tentative intermédiaire.
Les erreurs de compilation deviennent la tâche suivante, les tests échoués deviennent la tâche suivante, les plantages deviennent aussi la tâche suivante.
Cela transforme
une vaste tâche de migration en une file d'attente qui peut être réduite de manière itérative.
Lorsqu'un réviseur identifie le même problème dans plusieurs fichiers, la meilleure solution n'est pas de corriger manuellement chaque fichier un par un.
Il faut plutôt mettre à jour le manuel de règles et regénérer le lot affecté. Cela évite que la même erreur ne se reproduise dans les travaux ultérieurs.
L'idée la plus importante dans le processus d'Anthropic est de considérer le code généré comme le produit d'un système de production.
Supposons que 200 fichiers traduits contiennent la même erreur de propriété. Les corriger manuellement résoudrait peut-être les erreurs visibles, mais le workflow pourrait encore produire la même erreur.
Une méthode plus efficace est la suivante :
Le code s'améliore parce que le processus de production est optimisé.
Cela ressemble à l'ingénierie logicielle classique. Un défaut de production récurrent devrait conduire à améliorer les tests, les règles de typage, les vérifications statiques ou le processus – et non simplement à appliquer un autre correctif isolé.
Avant de commencer une migration à grande échelle, il faut définir comment l'équipe pourra prouver la correction de la nouvelle implémentation.
Sans mécanisme d'évaluation, il est impossible de déterminer une condition d'achèvement fiable.
Le mécanisme d'évaluation doit évaluer l'implémentation d'origine et l'implémentation cible dans des conditions équivalentes. Les tests existants peuvent dépendre de fonctions privées ou de mécanismes internes spécifiques au langage qui disparaîtront lors du portage.
Anthropic recommande trois préparatifs :
Une suite de tests qui ne peut pas détecter une panne connue n'est pas un mécanisme d'évaluation valide pour une migration.
Bun a un avantage significatif : la majeure partie de sa suite de tests est écrite en TypeScript plutôt qu'en Zig, de sorte que la même suite peut tester l'implémentation Rust.
Pour les projets sans cet avantage, des outils de test par équivalence peuvent comparer les entrées et sorties réelles entre les deux versions.
Anthropic a synthétisé les enseignements de ces projets dans le processus en six étapes suivant.
La première phase crée les documents partagés que suivront tous les agents ultérieurs.
Le manuel de règles définit comment les concepts du langage source sont mappés vers le langage cible.
Pour les migrations qui préservent la structure, le manuel de règles peut inclure :
Dans une migration de remaniement, le manuel de règles s'apparente davantage à un document d'architecture.
Jarred Sumner, par le biais de dialogues avec Claude et de révisions humaines, a élaboré le guide de portage de Bun. Le produit final faisait plusieurs centaines de lignes.
Le dépôt doit être divisé selon l'ordre des dépendances.
Un script déterministe peut générer un mappage des dépendances en examinant les imports, les manifestes, les fichiers de construction et les relations de symboles. Ce résultat aide l'orchestrateur à déterminer quels fichiers peuvent être convertis indépendamment et lesquels doivent être traités de manière coordonnée.
Le langage source et le langage cible suivent des règles différentes.
Pour une migration de Zig vers Rust, la propriété mémoire est la principale lacune. Pour une migration de Python vers TypeScript, les formes d'objets implicites et les interfaces doivent être transformées en contrats explicites.
L'inventaire des lacunes doit enregistrer les aspects qu'une simple traduction ne peut résoudre, incluant spécifiquement :
Le manuel de règles doit être créé avant l'inventaire des lacunes, car l'inventaire dépend en partie de ce que les règles générales ne peuvent pas traiter.
Ne traduisez pas des milliers de fichiers immédiatement.
Sélectionnez d'abord quelques fichiers complexes et représentatifs pour un petit essai à usage unique. L'objectif est de révéler les défauts des règles avant qu'ils ne se propagent à l'ensemble du dépôt.
Lors de l'essai de Bun :
Le résultat de cette phase est un manuel de règles optimisé – et non du code de production.
Pour une migration de remaniement, le test équivalent consiste à faire attaquer le document de conception par un réviseur contradictoire, puis à exécuter un test de bout en bout à usage unique.
Une fois les règles validées par l'essai, le dépôt peut être traité via une file d'attente parallèle.
Une configuration unitaire typique comprend :
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
La file d'attente doit prendre en charge la reprise après une interruption. L'état d'avancement doit pouvoir être déterminé en vérifiant les fichiers ou en enregistrant les artefacts, sans dépendre de la mémoire d'un seul agent.
Les agents doivent toujours marquer de manière cohérente le travail non terminé, par exemple :
TODO(portage) : Expliquer pourquoi cette partie ne peut pas être traduite en toute sécurité
Il n'est pas nécessaire d'utiliser le modèle le plus cher pour chaque unité. Un modèle de configuration inférieure peut gérer la traduction à volume élevé, tandis qu'un modèle plus puissant peut être réservé aux réviseurs, aux décisions architecturales et aux modifications de règles.
La première construction complète transforme les erreurs du compilateur en une file de travail structurée.
En fonction du coût de la construction,
le compilateur peut être exécuté à l'intérieur de chaque boucle d'agent, ou via un orchestrateur séparé.
Pour le projet Bun, le coût de compilation de l'ensemble de l'espace de travail est élevé, donc lors de la traduction des fichiers, l'agent Claude n'exécute pas arbitrairement des commandes cargo. Le processus qui le remplace est le suivant :
Cela évite que des dizaines d'agents ne lancent simultanément des constructions coûteuses.
Les erreurs systématiques du compilateur doivent mettre à jour les règles. Par exemple, le langage cible peut rejeter les dépendances circulaires que le compilateur source tolère en chargement différé. Il s'agit d'un problème au niveau du processus, et non d'une simple collection d'erreurs de fichiers isolés.
Une compilation réussie prouve seulement que le langage cible accepte le code.
L'étape suivante utilise des exécutions de base et des tests de fumée pour détecter les plantages, les échecs d'initialisation, les ressources manquantes, les hypothèses invalides et les pannes d'intégration.
Les cas d'échec doivent toujours être classés par cause.
Si 40 tests de fumée échouent à cause du même schéma d'initialisation erroné, il faut corriger la règle de migration et régénérer le code affecté, plutôt que d'attribuer 40 correctifs indépendants.
Le niveau final est la cohérence comportementale.
Exécutez simultanément sur les deux bases de code les suites de tests portables, les outils de vérification de conformité, les comparaisons de sortie et les tests de performance correspondants.
Pour chaque cas d'échec :
La base de code d'origine est toujours la référence, sauf si le projet a l'intention explicite de modifier le comportement.
L'absence de suite de tests ne permet pas de sauter cette étape. L'équipe peut s'appuyer sur Claude pour créer des outils de vérification de conformité externes basés sur des scénarios réels et valider ces outils en cas de comportement délibérément altéré.
Anthropic a publié un kit de démarrage public contenant des invites, des modèles et des scripts génériques basés sur le processus de migration.
Ce dépôt est un matériel de référence, et non un produit de migration entièrement géré. Ses invites sont des modèles de refactorisation, et non un enregistrement exact du processus du projet Bun.
Sur les systèmes macOS ou Linux :
curl -fsSL https://claude.ai/install.sh | bash
Sur les systèmes Windows PowerShell :
irm https://claude.ai/install.ps1 | iex
Avant d'exécuter des scripts d'installation à distance, examinez d'abord le contenu du script et les politiques de sécurité de votre organisation.
Dans le dépôt à migrer, exécutez :
git clone https://github.com/anthropics/code-migration-kit-with-claude-code.git ./migration-kit
Cette étape facultative copie la compétence de migration dans le répertoire local des compétences de Claude Code :
cp -r migration-kit/skill ~/.claude/skills/code-migration
Suivez les instructions pour mettre à jour le chemin du kit dans le fichier SKILL.md installé.
Dépôt.
Utilisez d'abord l'invite de faisabilité en lecture seule du kit :
prompts/00-feasibility.md
Le résultat doit répondre à trois questions :
« Ne pas migrer » est un résultat valide.
Avant de commencer la traduction :
Exécutez ensuite les invites de migration dans l'ordre, sans sauter directement à la traduction à grande échelle.
La migration de Bun n'a pas bien commencé.
Lorsque de nombreux agents travaillaient dans un même dépôt, leurs opérations Git interféraient les unes avec les autres. Un agent exécutait git stash, un autre utilisait git stash pop, et un autre réinitialisait l'arbre de travail.
Sumner a modifié le flux de travail pour empêcher les agents d'exécuter librement des commandes Git destructrices. Il a ensuite divisé le travail en quatre fragments de workflow, chacun utilisant un arbre de travail indépendant et coordonnant plusieurs agents.
Cet exemple souligne un point clé : les autorisations des agents doivent correspondre à la conception du flux de travail.
Un agent de codage disposant d'un accès shell étendu peut :
La couche d'orchestration doit limiter les commandes, définir la propriété des fichiers, sérialiser les opérations coûteuses et faciliter la restauration.
Les leçons tirées par Anthropic peuvent être résumées en quelques règles pratiques.
Chaque base de code a des systèmes de construction, une couverture de test, un comportement d'exécution, des contraintes de déploiement et une tolérance au risque différents.
Utilisez le cadre en six étapes comme point de départ, puis laissez Claude l'adapter au dépôt réel.
L'agent de correction peut traiter les échecs individuels. L'attention humaine a plus de valeur lorsqu'elle est utilisée pour identifier des schémas répétitifs, des règles manquantes, des hypothèses dangereuses et des problèmes d'architecture.
L'agent d'implémentation ne doit pas être son seul vérificateur.
Fournissez au vérificateur un contexte indépendant et informez-le qu'il doit supposer que le code généré est erroné. Sa tâche est d'identifier pourquoi le code échoue, s'écarte ou enfreint le manuel de règles.
Utilisez des compilateurs, des tests, des outils d'analyse statique, des différences de sortie, des benchmarks et des scripts déterministes comme outils d'évaluation.
Une vérification subjective « ça a l'air correct » ne peut pas valider en toute sécurité des changements de millions de lignes.
Les tâches de traduction à volume élevé peuvent être confiées à des modèles plus petits ou moins chers. Le modèle le plus performant doit être responsable de la création des règles, de l'architecture, des échecs ambigus et de la vérification.
Le travail humain à plus forte valeur ajoutée doit être effectué avant la génération à grande échelle :
Une fois ces bases solides et fiables, la majeure partie du travail restant se transforme en tâches mécanisées de type file d'attente.
Les tâches de migration qui doivent s'exécuter pendant plusieurs jours doivent pouvoir résister aux plantages, aux redémarrages, aux pannes de modèle et aux interruptions d'infrastructure.
L'état d'achèvement doit être déterminé sur la base d'artefacts persistants sur le disque, de validations, de résultats de test et de l'état de la file d'attente, et non d'une seule conversation longue.
Anthropic rapporte que le code de Bun écrit en Rust est en production.
Cette migration n'a pas éliminé tous les compromis. Environ 4 % du code Rust se trouve encore dans des blocs unsafe, principalement pour des opérations de pointeur de petite taille aux frontières C et C++.
Cependant, la nouvelle implémentation a apporté des améliorations significatives :
Ces résultats montrent clairement l'intérêt de la migration. L'objectif n'est pas de générer une grande quantité de code écrit par l'IA, mais de créer un système plus sûr, plus léger et plus facile à maintenir tout en conservant le comportement d'origine.
Une migration à grande échelle est adaptée aux workflows par agent lorsque :
Elle peut être moins adaptée lorsque :
Pouvoir générer rapidement des millions de lignes de code ne rend pas la migration automatiquement raisonnable.
Réécrit en Rust ?
Oui. Jarred Sumner a utilisé le workflow dynamique de Claude Code et un modèle Claude en préversion pour migrer le cœur de Bun de Zig vers Rust. Ce processus a généré plus d’un million de lignes de code en moins de deux semaines, suivi de compilation, tests, relecture et correctifs post-fusion.
Selon le rapport d’Anthropic, environ 5,9 milliards de tokens d’entrée non mis en cache et 690 millions de tokens de sortie ont été consommés. Au tarif de l’API, le coût du modèle est estimé à environ 165 000 dollars, sans compter les ressources humaines et l’infrastructure.
Anthropic indique que la suite de tests existante de Bun passait en CI avant la fusion. Après la fusion, 19 régressions ont été découvertes, puis corrigées.
L’objectif principal est d’améliorer la sécurité mémoire et de réduire les problèmes récurrents de cycle de vie, comme les corruptions mémoire, les utilisations après libération, les doubles libérations et les fuites mémoire. Le système de propriété et de types de Rust permet de détecter bon nombre de ces problèmes à la compilation.
Non. Une migration réussie nécessite des évaluateurs rigoureux, des règles claires, une analyse des dépendances, des permissions contrôlées, des files d’attente reproductibles, une relecture adversarial et une supervision humaine. Certains projets ne devraient pas du tout être migrés.
Un relecteur adversarial reçoit les modifications générées dans un environnement indépendant, avec pour mission de trouver des défauts plutôt que d’approuver les changements. Le rôle du relecteur est distinct de celui de l’implémenteur, ce qui réduit le risque que l’auteur défende ses propres résultats.
Idéalement, une suite de tests complète est nécessaire, surtout si elle peut tester le comportement public indépendamment du langage d’implémentation. Sans cela, l’équipe peut construire un cadre de validation comparant les scénarios réels et les sorties entre l’ancien et le nouveau système.
Non. Anthropic décrit ce dépôt comme un kit de démarrage généralisé et remanié. La migration réelle de Bun a utilisé des composants plus spécifiques, y compris un manuel de règles long et un workflow dynamique personnalisé.
Tests d’équivalence comportementale.
Si Claude Code a permis la migration réussie de Bun, ce n’est pas parce qu’il a généré en une seule fois une réécriture parfaite d’un million de lignes. La clé du succès réside dans le système de production rigoureux que l’équipe a construit autour du modèle : manuel de règles, cartographie des dépendances, liste des lacunes, projet pilote, files de traduction parallèles, relecture adversarial, boucle de compilation, tests de fumée et vérification de cohérence comportementale.
La même approche a aidé Anthropic à migrer une grande base de code Python vers TypeScript en un week-end. Dans les deux cas, l’importance de la validation objective a largement dépassé la vitesse de génération initiale.
L’IA peut réduire considérablement le coût et le délai des migrations à grande échelle, à condition que le processus soit interruptible et récupérable, que les permissions soient contrôlées, et que les défauts récurrents améliorent continuellement les règles de génération du code.
La véritable avancée ne réside pas dans la capacité de l’IA à écrire un million de lignes de code — mais dans des boucles soigneusement conçues qui génèrent, remettent en question, testent et corrigent ces lignes de manière répétée, jusqu’à ce que le comportement du nouveau système corresponde parfaitement à celui de l’ancien.
Partez d’une phrase et obtenez un site complet en quelques minutes.
