Comment Anthropic a réalisé une migration de code à grande échelle avec Claude Code

Introduction

Modifier le langage principal d'une base de code de production mature était auparavant le type de projet que les équipes repoussaient pendant des années. Ce travail est coûteux, risqué et difficile à estimer. Une migration pouvait prendre plusieurs trimestres d'ingénierie, pendant lesquels les deux implémentations s'éloignaient l'une de l'autre, pour finalement n'atteindre qu'une conformité comportementale incomplète.

Un récent projet interne d'Anthropic montre que cette situation commence à changer.

En juillet 2026, Anthropic a publié un rapport pratique détaillant comment ses développeurs ont utilisé Claude Code, Claude Fable 5, Claude Opus 4.8 et un flux de travail multi-agent dynamique pour migrer dix paquets de code en environ un mois. Ces paquets contenaient de dizaines à centaines de milliers de lignes de code.

Deux cas se sont particulièrement démarqués :

• Jarred Sumner, co-fondateur de Bun, a utilisé Claude Code pour migrer Bun de Zig à Rust, générant plus d'un million de lignes de code en moins de deux semaines.
• Mike Krieger, co-responsable d'Anthropic Labs, a converti une base de code Python en environ 165 000 lignes de TypeScript en un week-end.

L'enseignement important n'est pas qu'un modèle d'IA peut traduire rapidement des fichiers, mais qu'un système de migration bien conçu peut générer, examiner, tester, rejeter et régénérer du code de manière répétée avec une intervention humaine minimale.

Anthropic résume ainsi sa philosophie : le travail principal du développeur n'est pas de corriger manuellement chaque erreur générée, mais d'améliorer le processus qui produit continuellement ces erreurs.

Deux migrations de code qui changent le calcul des coûts

Bun : une migration de plus d'un million de lignes de Zig à Rust

Bun est une boîte à outils tout-en-un pour JavaScript et TypeScript, comprenant un runtime, un gestionnaire de paquets, un bundler, un exécuteur de tests et d'autres outils de développement. Son implémentation originale reposait fortement sur Zig et s'intégrait à une grande quantité de code C et C++.

Jarred Sumner a utilisé environ 50 flux de travail dynamiques Claude Code en 11 jours pour réaliser la migration vers Rust. La pull request fusionnée contenait plus d'un million de nouvelles lignes de code et des milliers de commits.

Avant la fusion, la suite de tests d'intégration continue existante de Bun passait sur toutes ses plateformes supportées. Anthropic a ensuite signalé 19 régressions après la fusion, qui ont depuis été corrigées.

Cette migration n'était pas une refonte à partir de zéro. L'objectif était de maintenir l'architecture et le comportement existants de Bun tout en remplaçant le langage d'implémentation. Cela a réduit le nombre de variables simultanées : le projet pouvait se concentrer sur la sémantique du langage, la propriété, la sécurité mémoire et la compatibilité, plutôt que de reconstruire le produit de zéro.

Le rapport officiel de Bun explique pourquoi Rust était attractif. De nombreux problèmes de stabilité récurrents concernaient la gestion du cycle de vie, les chemins de nettoyage oubliés, les utilisations après libération, etc., ainsi que les risques de double libération. En Rust sécurisé, plusieurs de ces problèmes deviennent des erreurs de compilation, plutôt que des problèmes découverts via des crashs en production, du fuzzing ou des revues manuelles.

Une migration de Python à TypeScript en un week-end

Le projet de Mike Krieger a emprunté une voie différente. Cette migration n'a pas cherché à préserver autant que possible la structure de fichiers originale, mais a impliqué davantage de réarchitecture.

Le résultat a été la génération d'environ 165 000 lignes de code TypeScript en un week-end. Le processus aurait utilisé :

• Des centaines d'agents.
• Huit étapes.
• Trois cycles de révision contradictoire.
• Un cadre de test de conformité comparant la sortie de chaque commande avec l'implémentation Python.

La raison métier était claire. Cet outil interne basé sur Python était distribué sous forme de binaire unique, mais la génération de ce binaire prenait environ huit minutes par plateforme, et environ 30 minutes pour l'ensemble de la matrice de publication.

Après la migration, la compilation prend environ deux secondes, le temps de démarrage est six fois plus rapide, et l'équipe a pu supprimer une pipeline de déploiement distincte.

Quand une migration de langage vaut-elle la peine d'être envisagée ?

Une migration de langage nécessite toujours une véritable raison d'ingénierie ou métier. Une génération de code plus rapide ne justifie pas chaque réécriture.

Les équipes reconsidèrent généralement le choix du langage lorsque l'environnement depuis la création du système a changé. Les déclencheurs typiques incluent :

1. Des compromis connus sont devenus des problèmes opérationnels récurrents.
2. Des langages ou écosystèmes plus récents offrent désormais un meilleur support d'outillage.
3. L'écosystème original est en déclin, ou il est difficile de recruter des talents dans ce domaine.
4. Les exigences de sécurité ou de sécurité mémoire ont changé.
5. Les performances de construction, de déploiement ou d'exécution sont devenues un goulot d'étranglement.
6. Le maintien de la compatibilité nécessite des solutions de contournement de plus en plus coûteuses.

L'utilisation initiale de Zig par Bun avait du sens. Pour un fondateur construisant seul un runtime très large avant l'avènement des agents de codage contemporains, ce langage offrait un contrôle de bas niveau qui a aidé Jarred Sumner à avancer rapidement.

Quelques années plus tard, Bun est devenu un outil de production largement utilisé avec une surface de maintenance beaucoup plus grande. Le coût des défauts récurrents liés à la mémoire a augmenté, et Claude Code a rendu le portage mécanique suffisamment réalisable pour être testé.

Ainsi, la décision n'était pas « Zig est mauvais et Rust est bon », mais plutôt que l'échelle actuelle de Bun, ses besoins opérationnels et les outils disponibles ont modifié les compromis.

Migration plus rapide, mais pas gratuite

Une migration de langage assistée par IA peut encore être coûteuse.

Anthropic rapporte que le projet Bun a consommé environ :

Catégorie d'utilisation	Quantité rapportée
Tokens d'entrée non mis en cache	5,9 milliards
Tokens de sortie	690 millions
Équivalent prix estimé de l'API	Environ 165 000 dollars

La partie principale de la migration Python vers TypeScript de Mike Krieger a utilisé environ 27 millions de tokens.

Ces chiffres sont bien inférieurs au coût d'ingénierie d'une migration traditionnelle de plusieurs années, mais ils ne sont pas négligeables. Les équipes doivent également prendre en compte :

• La supervision humaine.
• Les frais de calcul et d'API.
• L'infrastructure de test.
• La capacité CI.
• Les machines de construction.
• La révision et les corrections après fusion.
• Le coût d'opportunité pendant la migration.
• La maintenance à long terme du langage cible.

La réduction des coûts rend davantage de projets financièrement viables, mais elle n'élimine pas le besoin d'un business case.

Pourquoi les grandes migrations sont-elles si adaptées aux agents IA ?

Les grandes migrations de langage possèdent plusieurs caractéristiques qui les rendent particulièrement adaptées à la collaboration avec des agents de codage.

Le travail est parallélisable

Une migration implique souvent des centaines ou des milliers de fichiers, modules, paquets ou bibliothèques, qui peuvent être traités indépendamment une fois leurs dépendances comprises.

Les agents peuvent traduire des unités indépendantes en parallèle, plutôt que d'attendre un seul flux d'implémentation central. Le défi passe de la vitesse de frappe à l'orchestration, la cohérence et la validation.

L'ancien code sert de spécification détaillée

De nombreuses tâches logicielles commencent avec des exigences incomplètes. Une migration de langage a un point de départ bien plus fort : l'implémentation originale.

Le code source existant définit le flux de contrôle, les structures de données, les cas limites, le comportement d'erreur, les API publiques et le traitement spécifique à la plateforme. Lorsque les règles de migration ne sont pas claires, les agents peuvent s'y référer à tout moment.

Les tests fournissent un arbitre objectif

Les agents donnent le meilleur d'eux-mêmes lorsque le succès ou l'échec peut être vérifié mécaniquement.

Les compilateurs, les suites de tests, les scripts de conformité, les benchmarks ou les comparaisons de sortie déterministes fournissent une source de vérité unique pour le flux de travail. Le système n'a pas besoin de demander aux réviseurs si la nouvelle implémentation « semble correcte » ; il compare plutôt de manière répétée le comportement avec l'implémentation originale.

Les échecs se transforment automatiquement en éléments à faire

Les erreurs de compilation, les crashs, les échecs de tests et les différences de sortie décrivent naturellement le travail restant.

Le système de migration n'a pas besoin que des humains écrivent des tickets un par un.

Chaque élément de contrôle échoué peut être catégorisé et attribué à un agent de correction.

Les erreurs répétées peuvent être corrigées en amont

Lorsqu’un même problème apparaît dans plusieurs fichiers, le corriger manuellement un par un n’est pas la bonne approche.

Une meilleure solution consiste à mettre à jour la règle de migration à l’origine de l’erreur, puis à ne régénérer que les unités concernées. Cela transforme un défaut découvert en une amélioration permanente du processus.

Prérequis : Construire un juge fiable

Avant de traduire le code de production, il faut d’abord créer un système de validation capable d’évaluer les nouvelles et les anciennes implémentations dans des conditions équivalentes.

Sans juge fiable, le projet n’a pas de définition crédible de ce qu’est une tâche terminée.

Les suites de tests écrites dans le langage source peuvent reposer sur des fonctions privées, des classes internes ou des détails d’implémentation qui n’existent pas dans le langage cible. Ces tests ne peuvent pas toujours être migrés directement.

Anthropic recommande de préparer le système de juge en trois étapes.

1. Classifier les tests existants

Distinguer les tests qui expriment le comportement externe de ceux qui dépendent des détails d’implémentation interne.

Les tests externes concernent généralement le comportement en ligne de commande, les API publiques, les fichiers, le réseau, les sorties observables ou les scénarios d’application complets. Ce contenu est plus portable d’un langage à l’autre.

2. Réécrire les tests pour la portabilité

Convertir les tests orientés comportement en assertions pouvant s’exécuter sur les deux versions.

Utiliser un examinateur contradictoire indépendant pour s’assurer que les tests réécrits ne sont pas plus faibles que la version originale. Des tests plus faciles à réussir pourraient masquer des problèmes de compatibilité.

3. Valider le système de jugement lui-même

Exécuter le système de jugement sur l’implémentation originale et vérifier qu’il réussit.

Puis, casser intentionnellement le programme et confirmer que le système de jugement échoue. Si un système de validation ne peut pas détecter des défauts connus, il n’est pas prêt à superviser une migration.

Mike Krieger n’a pas construit une suite de tests entièrement portable à partir de zéro. Son équipe a créé un cadre de tests de conformité couvrant sept scénarios réels, et toute différence entre Python et TypeScript a été considérée comme un défaut.

Le processus de migration de code en six étapes de Claude

Étape 1 : Créer le manuel de règles, le graphe de dépendances et l’inventaire des écarts

La première étape pose les bases que tous les agents suivants utiliseront.

Construire d’abord le manuel de règles

Le manuel de règles décrit comment le langage source doit être mappé au langage cible.

Sa forme dépend de la stratégie de migration.

Pour une migration qui préserve la structure, le manuel peut contenir :

• Mappage des types.
• Mappage de la gestion des erreurs.
• Règles de propriété.
• Conventions de nommage.
• Alternatives aux bibliothèques standard.
• Modèles d’interface de fonctions externes.
• Règles pour les opérations asynchrones.
• Instructions pour les constructions non supportées.

Pour une refonte, le manuel se rapproche davantage d’un document d’architecture. Il définit les nouvelles limites des composants, les interfaces, les contrats de données et les décisions de conception que les agents d’implémentation doivent suivre.

L’ordre est important. Le manuel doit être rédigé avant l’inventaire des écarts, car ce dernier enregistre tout ce que les règles par défaut ne peuvent pas gérer en toute sécurité.

Cartographier les dépendances

Le travail en parallèle n’est sûr que si le flux de travail comprend quelles unités dépendent les unes des autres.

Le graphe de dépendances aide à déterminer :

• Quels modules doivent être migrés en premier.
• Quels fichiers appartiennent au même lot.
• Quelles interfaces doivent être stabilisées avant que le travail en aval ne commence.
• Quelles boucles nécessitent un traitement spécial.
• Quels agents parallèles pourraient entrer en conflit.

Certains langages exposent les informations de dépendance via des manifestes de paquets ou des métadonnées de modules. Les systèmes plus anciens en C, C++ et Python peuvent nécessiter des scripts d’analyse déterministes pour découvrir le graphe de dépendances.

Claude Code peut aider à créer et exécuter ce script, mais le graphe généré doit l’être par des moyens mécaniques, et non pas deviné à partir de la seule sortie du modèle.

Enregistrer les écarts de langage et d’architecture

L’inventaire des écarts capture les différences qui ne peuvent pas être traitées par traduction directe.

Pour une migration de Zig vers Rust, les écarts importants incluent la propriété et le cycle de vie de la mémoire. Zig permet que certaines responsabilités de nettoyage soient communiquées par convention ou annotations, tandis que Rust exige que les contraintes de propriété soient exprimées dans le système de types.

Pour un travail de migration de Python vers TypeScript, la définition des interfaces est un écart majeur. Python accepte souvent des objets en fonction de leur comportement à l’exécution, tandis que TypeScript nécessite des contrats explicites avant que le code ne compile en toute sécurité.

L’inventaire doit être considéré comme un artefact mis à jour dynamiquement. De nouveaux écarts apparaissent constamment pendant les phases de traduction, de compilation et de tests de conformité.

Étape 2 : Tester les règles sous pression avec une mini-migration unique

N’appliquez pas immédiatement le nouveau manuel de règles à des milliers de fichiers.

Effectuez d’abord une petite migration, puis jetez délibérément les résultats.

Pour Bun, le test a porté sur un petit nombre de fichiers :

1. Un agent traduit un fichier selon le manuel de règles.
2. Un autre agent traduit un fichier comparable comme le ferait un ingénieur Rust expérimenté.
3. Un troisième agent compare les résultats et propose des règles plus solides.
4. Un examinateur contradictoire recherche des problèmes de comportement ou de structure.

Avant d’être appliqué à l’ensemble des 1 448 fichiers Zig, ce travail a révélé deux problèmes graves.

Une migration qui conserve la structure rend cette comparaison relativement facile, car deux implémentations du même fichier peuvent être examinées côte à côte.

Pour une refonte, le test de résistance doit se concentrer sur le document d’architecture. Un agent contradictoire peut en attaquer les hypothèses, puis une exécution unique de bout en bout expose les interfaces manquantes et les ordonnancements irréalistes.

L’objectif est d’améliorer le manuel de règles, pas d’accumuler du code de production. Une fois les faiblesses détectées, jetez les fichiers générés.

Étape 3 : Traduire l’intégralité du code source

Une fois les règles validées par le test de résistance, le travail de traduction peut être déployé sur l’ensemble du dépôt.

com/cms-assets/image/2026/07/26354d74-9a83-4821-b425-a17b95bb4e0e-677c6dd7-8531-47f9-93ce-bf7d7df38679.jpeg)

Anthropic décrit une boucle répétitive à trois rôles :

1. L'implémenteur génère le code traduit.
2. Le vérificateur adversarial recherche les défauts et les violations des règles.
3. Le réparateur applique les retours de vérification acceptés.

Le travail d'implémentation peut souvent être effectué avec des modèles plus petits et moins coûteux. Les modèles les plus puissants doivent être réservés aux vérificateurs, aux rédacteurs de règles, aux décisions architecturales et aux litiges nécessitant un jugement plus large.

Maintenir la mécanique de la file d'attente

Les scripts par lots doivent décider de ce qui est terminé en vérifiant le système de fichiers ou un autre état déterministe.

Par exemple, un fichier source peut être considéré comme traduit lorsque le fichier cible correspondant existe dans le répertoire prévu et a passé les étapes de vérification requises.

Reconstruire la file d'attente à partir du disque rend le processus récupérable. Si un agent s'arrête, la machine redémarre ou un lot échoue, l'orchestrateur peut reconstruire le travail restant sans dépendre d'une mémoire de conversation volatile.

Marquer explicitement le travail incertain

Lorsqu'un agent d'implémentation ne peut pas terminer une traduction avec confiance, il doit laisser une marque de recherche explicite, par exemple :

TODO(port): expliquer pourquoi cette partie nécessite un traitement manuel ou ultérieur

La forme spécifique de la marque peut varier, mais elle doit inclure la raison. Cela crée une file d'attente structurée pour les phases de compilation et de correction.

Utiliser des contextes de vérification indépendants

L'agent d'implémentation ne doit pas être vérifié uniquement par lui-même.

Anthropic et Bun ont utilisé la vérification adversarial dans des fenêtres de contexte indépendantes. Le vérificateur reçoit le code modifié et est invité à supposer que l'implémentation contient des défauts.

Deux vérificateurs peuvent inspecter indépendamment le même lot. Si leurs conclusions sont en conflit, un troisième agent peut trancher.

Cette séparation réduit la tendance de l'agent rédacteur à maintenir ses propres choix et rend l'exécution autonome à long terme plus fiable.

Corriger le générateur, pas chaque sortie

Lorsqu'un vérificateur détecte le même défaut à plusieurs reprises, le manuel de règles doit être mis à jour et les lots affectés doivent être régénérés.

Corriger manuellement des centaines de fichiers générés entraîne des incohérences et laisse le mode de défaillance initial persister. Corriger la règle de génération empêche le problème de se reproduire dans les lots suivants.

Étapes 4, 5, 6 : Compiler, exécuter et faire correspondre le comportement

Les trois dernières phases partagent la même boucle de base : produire des défaillances objectives, les classer, assigner un réparateur, vérifier la correction et répéter.

Étape 4 : Compilation

La compilation transforme les erreurs de niveau linguistique en une file d'attente déterministe.

La compilation fait-elle partie de chaque boucle de traduction ? Cela dépend des coûts.

Le compilateur TypeScript de Mike Krieger vérifie une unité en quelques secondes, il est donc exécuté fréquemment pendant l'implémentation. La construction Rust de Bun prend plus de temps, donc Jarred Sumner garde Cargo en dehors de la boucle de traduction au niveau fichier et compile les lots plus volumineux séparément.

Pour les constructions coûteuses, utilisez un seul orchestrateur ou un démon de construction. Les agents de correction écrivent des correctifs et seul le démon est autorisé à reconstruire. Cela empêche des dizaines d'agents de lancer simultanément la même opération coûteuse.

Les défaillances du compilateur au niveau système méritent une attention particulière. Des milliers d'erreurs similaires peuvent indiquer une règle de dépendance manquante, une stratégie de frontière de module incorrecte ou un mappage de langage problématique, plutôt que des milliers d'erreurs indépendantes.

Étape 5 : Exécuter des tests de fumée

Une fois le code compilé, exécutez des tests minimaux qui révèlent les plantages et les défaillances graves à l'exécution.

Les résultats des tests de fumée fournissent une autre source de vérité mécanique. Regroupez les défaillances par cause racine plutôt que d'assigner un agent à chaque message d'erreur sans analyse.

Les catégories utiles peuvent inclure :

• Échec d'initialisation
• Ressource manquante
• Erreur de gestion de chemin
• Différence de sérialisation
• Défaut de cycle de vie mémoire
• Comportement spécifique à la plateforme
• Hypothèse de concurrence erronée
• Problème d'interface de fonction externe

Le vérificateur adversarial doit examiner les correctifs proposés pour la cause racine, surtout lorsqu'une seule modification affecte plusieurs fichiers.

Étape 6 : Faire correspondre le comportement original

La dernière étape consiste à comparer le nouveau programme avec l'original.

Exécutez une suite de tests portable ou un cadre de vérification d'équivalence sur les deux implémentations. Toute différence inexpliquée doit être considérée comme un défaut de migration, sauf si l'équipe l'accepte intentionnellement comme un changement de produit.

L'agent de correction peut examiner :

• Les cas de test échoués
• L'implémentation originale
• L'implémentation traduite
• Les règles de migration affectant le code
• Les cas de défaillance antérieurs pertinents

Pour les processus de reconstruction longs, utilisez un démon de construction qui traite les correctifs par lots, compile en une seule fois, ne réexécute que les tests affectés, et renvoie les résultats à la file d'attente.

Lorsque le même mode d'échec apparaît dans plusieurs tests, les corrections doivent être anticipées. Mettez à jour le manuel de règles et régénérez les fichiers sous la règle erronée.

Solution en l'absence de suite de tests portable

L'absence de suite de tests ne signifie pas que la migration est impossible.

L'application originale peut servir d'implémentation de référence, autour de scénarios utilisateur réels, pour construire un cadre de vérification d'équivalence comportementale.

Le flux de travail de Mike Krieger exécutait sept scénarios sur les versions Python et TypeScript, comparait les sorties, et assignait chaque échec à une boucle de correction dédiée. Ensuite, Claude a conçu des tests de bout en bout supplémentaires, exécutés en continu pendant quatre nuits.

Même si l'équipe doit construire de nouveaux mécanismes d'arbitrage autour du code original, ce dernier reste la seule référence.

Leçons pratiques applicables à travers les projets

Anthropic rappelle de ne pas considérer son processus comme un modèle universel. Chaque base de code a des coûts de construction, une sémantique de langage, une qualité de test, des contraintes de plateforme et des compromis acceptables différents.

Néanmoins, les pratiques suivantes sont cohérentes à travers plusieurs projets.

Se concentrer sur les modes, pas sur les échecs individuels

Les échecs individuels relèvent de la boucle de correction.

Les efforts humains doivent se concentrer sur les défauts récurrents, les règles manquantes, les limites de tâches inappropriées, les maillons faibles de vérification et les goulots d'étranglement du système d'orchestration.

Adopter la vérification adversarial

Le vérificateur doit activement tenter de prouver que le code est erroné.

Cela ne signifie pas être vague ou pessimiste. Les conclusions de vérification doivent indiquer des défauts spécifiques, des règles violées, des hypothèses non vérifiées ou des incompatibilités de comportement.

Automatiser la validation

Les compilateurs, cas de test, scripts déterministes, benchmarks et différences de sortie doivent devenir les critères d'acceptation des résultats.

Les points de vue des modèles sont utiles pour la recherche et la vérification, mais ne doivent pas remplacer la validation objective – chaque fois que celle-ci est possible.

Éviter d'utiliser le modèle le plus puissant partout

Le travail de traduction à grande échelle est souvent répétitif et peut être confié à des modèles plus petits.

Les modèles les plus puissants doivent être utilisés pour :

• Établir des règles
• Vérifier l'architecture
• Détecter des défauts systémiques
• Résoudre les divergences de vérification
• Concevoir des schémas de validation
• Traiter les cas limites difficiles

Cela réduit le coût des jetons sans retirer le raisonnement fort des décisions à plus haut risque.

Investir en amont du travail humain

Le manuel de règles, le graphe de dépendances, la stratégie de validation et les tests de résistance nécessitent la participation humaine la plus prudente.

Une fois ces bases solides établies, le gros du travail restant devient un traitement de file d'attente. Des bases faibles rendent chaque étape ultérieure plus coûteuse.

Assurer la récupérabilité du flux de travail

Le processus de migration doit pouvoir récupérer d'une interruption sans avoir à reconstruire l'état via l'historique de discussion.

Stockez la progression dans des fichiers, des commits, des listes, des bases de données ou d'autres artefacts déterministes. « Terminé » doit avoir une signification lisible par machine.

Séparer les opérations partagées coûteuses

La compilation, les tests d'intégration, la création de paquets et les benchmarks complets peuvent devenir des goulots d'étranglement.

Exécutez ces opérations via un service ou un démon contrôlé, afin que les agents parallèles ne gaspillent pas de ressources ni ne corrompent l'état partagé.

Résultats de la migration Rust de Bun

La version Rust de Bun est en production, bien que les résultats présentent encore des compromis d'ingénierie.

Anthropic rapporte qu'environ 4 % du code Rust reste dans des blocs unsafe, principalement des opérations de pointeur brèves aux frontières C et C++. Rust n'a pas éliminé tous les problèmes de bas niveau, mais les a davantage confinés à des zones explicites.

Les améliorations rapportées incluent :

Mesure	Résultat

| Utilisation mémoire lors de 2000 reconstructions | Réduction de 6745 Mo à 609 Mo |
| Taille des binaires sous Linux et Windows | Réduction de 19 % |
| Performances sur des charges de travail réelles sélectionnées | Amélioration de 2 à 5 % |
| Fuites mémoire détectables | Corrigées |
| Régressions signalées par Anthropic après fusion | 19, puis corrigées |

Ces résultats comptent davantage que le simple nombre de lignes de code. Une migration réussie ne se mesure pas à la vitesse à laquelle un agent génère du code, mais à la compatibilité, la maintenabilité, les améliorations opérationnelles, et la capacité à continuer à développer le produit par la suite.

Ce qu’il faut évaluer avant de lancer une équipe

Avant de lancer une migration assistée par IA à grande échelle, répondez aux questions suivantes.

L’implémentation source est-elle un point de référence stable ?

Si le système d’origine évolue rapidement, il sera difficile de mesurer la conformité. Envisagez de figer certaines interfaces, ou de migrer en priorité les modules stables.

Peut-on mesurer mécaniquement le succès ?

Définissez les vérifications du compilateur, les tests, les scénarios, les benchmarks et les comparaisons de résultats qui déterminent ce qu’est une réussite.

Des objectifs vagues comme « faire en sorte que le comportement soit cohérent » ne suffisent pas.

La migration préserve-t-elle la structure ou la repense-t-elle ?

Un portage direct est plus facile à comparer et à paralléliser. Une refonte peut donner une meilleure architecture, mais introduit davantage de décisions subjectives, nécessitant des revues de conception plus rigoureuses.

Quel est le goulot d’étranglement le plus coûteux ?

Évaluez les coûts suivants :

• Appels aux modèles
• Compilation
• Exécution des tests
• Concurrence CI
• Stockage dans le dépôt
• Exécution d’intégration complète
• Revue humaine

Concevez l’orchestrateur autour de la ressource partagée la plus coûteuse.

Quelles opérations nécessitent une validation humaine ?

Définissez les limites suivantes :

• Commandes Git destructrices
• Modifications de dépendances
• Changements architecturaux
• Code sensible à la sécurité
• Identifiants de production
• Opérations de publication
• Modifications d’API publique

Dans le workflow de Bun, des agents se sont perturbés mutuellement via des commandes comme git stash et git reset. Les règles d’orchestration ont été mises à jour pour interdire les opérations dangereuses sur le dépôt partagé, et les agents ont été limités à des commits au niveau fichier, sous contrôle.

Quelle est la stratégie de retour en arrière ?

Une migration doit rester jetable tant que les preuves ne justifient pas sa fusion.

Utilisez des branches isolées, des builds reproductibles, des points de contrôle, et un processus clair pour abandonner ou regénérer le travail en cas d’erreur de règle.

Questions fréquentes

Qu’est-ce que la migration de code assistée par IA ?

La migration de code assistée par IA utilise des agents de codage pour effectuer la traduction, la revue, la compilation, les tests et les corrections d’un code source dans un workflow contrôlé. Le modèle ne remplace pas la validation ; le compilateur, les tests, les vérifications de conformité et les règles définies par l’humain restent l’autorité.

Claude Code a-t-il vraiment réécrit Bun de Zig en Rust ?

Jarred Sumner a réalisé le portage en Rust en utilisant un workflow dynamique avec Claude Code, et la pull request GitHub correspondante a été fusionnée en mai 2026. Le compte officiel de Bun indique que ce travail a pris environ 11 jours, reposant sur une implémentation parallélisée, une relecture contradictoire, et la suite de tests déjà existante et indépendante du langage du projet.

Combien de lignes de code la migration de Bun a-t-elle concerné ?

La pull request fusionnée montre plus d’un million de nouvelles lignes de code, ainsi que des suppressions et des modifications. Le nombre de lignes ne permettant pas de mesurer la qualité, les indicateurs les plus importants sont le résultat de la compilation, les tests multiplateformes, le comportement, l’empreinte mémoire, la taille des binaires, et le traitement des régressions après fusion.

Quel a été le coût de la migration IA de Bun ?

Sur la base de 5,9 milliards de tokens d’entrée non mis en cache et de 690 millions de tokens de sortie, Anthropic estime le coût API à environ 165 000 dollars. Le coût réel pour une organisation peut varier selon les accords tarifaires, l’infrastructure interne, le temps de travail humain, l’utilisation de la CI, et les corrections post-fusion.

Qu’est-ce qu’un manuel de règles de migration ?

Un manuel de règles de migration est un ensemble de stratégies lisibles par machine ou par agent, décrivant comment les motifs du langage source correspondent à l’implémentation cible. Il couvre les types, la propriété, les erreurs, les interfaces, la nomenclature, les cas non pris en charge, les décisions architecturales, et toute autre règle que les agents d’implémentation doivent suivre de manière cohérente.

Pourquoi utiliser un relecteur contradictoire ?

Un agent d’implémentation dispose de contexte et d’inertie qui peuvent le pousser à accepter ses propres solutions. Un relecteur contradictoire travaille dans un contexte indépendant et a pour mission de trouver des défauts, des violations de règles et des différences de comportement, plutôt que d’aider à fusionner le code.

Cette méthode fonctionne-t-elle sans suite de tests existante ?

C’est possible, mais l’équipe doit établir un autre arbitre objectif. Une plateforme de tests de conformité peut exécuter des scénarios réels sur les deux implémentations et comparer les résultats, tandis que de nouveaux tests de bout en bout peuvent révéler des défaillances que les vérifications de traduction statique ne détectent pas.

Tous les codebases existants sont-ils aujourd’hui adaptés à une migration assistée par IA ?

Non. Une migration doit encore présenter des avantages mesurables, une implémentation de référence stable, une validation objective, un budget suffisant et un plan de retour en arrière acceptable. Les systèmes avec des tests faibles, un comportement non documenté, des exigences changeantes rapidement ou des contraintes de sécurité critiques peuvent nécessiter beaucoup de préparation, ou ne tout simplement pas être réalisables avec les capacités actuelles de l’IA.

Ce qui doit être préparé avant qu’un agent puisse aider de manière responsable.

Outils associés

• Claude Code : l’outil de codage agentique d’Anthropic pour comprendre les dépôts de code, éditer les fichiers, exécuter des commandes et coordonner le développement.
• Kit de migration de code Anthropic : invites, modèles et scripts officiels pour construire des workflows de migration de langage.
• Plugin de modernisation Claude Code : plugin officiel axé sur les mises à niveau de frameworks et la modernisation de systèmes existants (plutôt que des portages complets de langage).
• Bun : l’ensemble d’outils JavaScript et TypeScript utilisé dans l’étude de cas de migration d’un million de lignes de Zig vers Rust par Anthropic.
• Rust : le langage système à sécurité mémoire choisi pour la nouvelle implémentation de Bun.
• Zig : le langage de programmation système utilisé par Bun avant sa migration vers Rust.
• TypeScript : le langage JavaScript avec typage utilisé dans l’exemple de migration Python d’Anthropic.

Liens associés

• Guide de migration de code à grande échelle d’Anthropic : la méthodologie officielle en six étapes et deux études de cas de migration Anthropic.
• Réécriture de Bun en Rust : explication technique détaillée par Jarred Sumner des motivations, de la boucle d’orchestration, du processus de révision et des résultats.
• Pull request de réécriture Rust de Bun : pull request publique fusionnée contenant la migration Rust à grande échelle.
• Kit de migration de code pour Claude Code : kit de démarrage générique issu du processus de migration.
• Introduction aux workflows dynamiques : explication par Anthropic des workflows multi-agents adaptatifs et de longue durée dans Claude Code.
• Documentation Claude Code : installation officielle, workflows, configuration et documentation d’utilisation.
• Meilleures pratiques Claude Code : guide pratique sur le contexte du dépôt, les sessions parallèles, la validation et les workflows agentiques.

Résumé

Les récentes pratiques de migration d'Anthropic montrent qu'un projet de portage linguistique peut être réorganisé autour de flux de travail d'agents, plutôt que de reposer sur une seule réécriture manuelle longue. La migration de Bun de Zig vers Rust et le projet d'Anthropic de Python vers TypeScript reposent tous sur une implémentation parallèle, une révision antagoniste, une vérification déterministe et une régénération itérative.

La partie réutilisable est le processus : construire un évaluateur, définir des règles, cartographier les dépendances, tester les méthodes sous pression, traduire par lots récupérables, compiler, exécuter et comparer les comportements. Lorsqu'un même défaut apparaît à plusieurs reprises, corrigez la règle ou le flux de travail qui génère ce défaut, plutôt que de réparer manuellement chaque résultat.

Cette approche nécessite toujours un budget conséquent, des tests robustes, des autorisations contrôlées et un jugement humain au niveau architectural. Elle réduit les coûts de migration, mais n'élimine pas le travail d'ingénierie.

Responsabilité.

Le point central est simple : une migration fiable assistée par l'IA découle d'un cycle de production vérifiable, et non d'une simple invite demandant au modèle de réécrire l'intégralité de la base de code.