Introduction
Depuis le 17 juin 2026, chaque développeur qui lance Claude Code exécute sans le savoir du code Rust — là où tournait du Zig quelques semaines plus tôt. C'est Simon Willison qui l'a mis en lumière le 19 juillet en découvrant 563 fichiers source Rust embarqués dans le binaire de Claude Code v2.1.181. Derrière cette migration discrète se cache l'une des réécritures de code à grande échelle les plus spectaculaires de l'histoire du développement logiciel.
Une réécriture menée à marche forcée
Jarred Sumner, créateur de Bun et désormais employé d'Anthropic depuis l'acquisition en décembre 2025, a converti 535 496 lignes de Zig en Rust en onze jours. Non pas avec une équipe de développeurs, mais en orchestrant jusqu'à 64 instances de Claude en parallèle, regroupées en workflows dynamiques de 16 agents chacun. Le coût total de l'opération atteint environ 165 000 dollars en tokens d'API — une somme qui aurait représenté des mois de salaires d'ingénieurs pour un résultat équivalent par voie traditionnelle.
Les chiffres donnent le vertige : 6 502 commits générés, 128 bugs du code Zig original corrigés au passage, une réduction de 20 % de la taille du binaire, et un démarrage amélioré de 10 % sur Linux. Le tout en passant 100 % des tests de la suite Bun, soit plus d'un million d'assertions. Sumner résume lui-même la mise en production avec une formule lapidaire : « Boring is good. » Effectivement, presque personne ne l'a remarqué.
L'open source face au code généré par IA
Mais si les utilisateurs finaux n'ont rien vu, la communauté des développeurs, elle, a réagi. Andrew Kelley, créateur du langage Zig, n'a pas mâché ses mots dans une tribune publiée en juillet. Pour lui, le problème n'est pas le passage de Zig à Rust en tant que tel, mais la pratique de générer massivement du code sans revue humaine sérieuse — ce qu'il qualifie d'« unreviewed slop », littéralement du code non relu et bâclé. Kelley pointe une divergence de valeurs entre les deux projets : là où le projet Zig refuse explicitement les contributions générées par IA, Bun fait le pari inverse.
Cette tension révèle un débat plus profond que le simple choix d'un langage. Est-il raisonnable d'accepter en production des centaines de milliers de lignes de code qu'aucun ingénieur humain n'a relues ligne à ligne ? La réponse de Sumner est pragmatique : les tests automatisés valident le comportement, peu importe qui — ou quoi — a écrit le code.
Ce que ça change pour les équipes techniques
L'affaire Bun illustre une fracture qui s'élargit dans l'ingénierie logicielle. D'un côté, des équipes qui font confiance aux tests et à la couverture fonctionnelle pour garantir la qualité. De l'autre, celles qui considèrent que la lisibilité et la revue humaine restent des conditions non négociables d'un code maintenable sur le long terme.
Pour les DSI et les responsables techniques, la question n'est plus de savoir si les agents IA peuvent produire du code fonctionnel — la preuve est faite. Elle porte désormais sur les processus de gouvernance : quels critères d'acceptation, quels niveaux de test, quelle traçabilité appliquer à du code généré automatiquement avant qu'il ne se retrouve dans des outils critiques de la chaîne DevOps ?
Que Bun soit passé de Zig à Rust sans incident notable est remarquable. Que cette migration ait alimenté plusieurs semaines de polémique dans la communauté open source l'est tout autant. Le vrai sujet n'est pas le langage choisi — c'est la confiance accordée à des processus de développement où la revue humaine devient optionnelle.