L’essentiel
- Bun, l’outil JavaScript, a été entièrement réécrit de Zig vers Rust, l’essentiel du travail confié à une pré-version de Claude Fable 5.
- Environ 64 instances de Claude ont tourné en parallèle pendant 11 jours pour produire plus d’un million de lignes de code, contre près d’un an pour une équipe humaine selon Jarred Sumner.
- La facture d’API atteint environ 165 000 dollars ; la nouvelle version Bun v1.4.0 corrige 128 bugs et gagne 2 à 5 % de vitesse.
Jarred Sumner a pris une décision que peu d’ingénieurs auraient osée : confier la réécriture intégrale de Bun, l’un des outils phares de l’écosystème JavaScript, à une flotte d’agents IA. Le passage du langage Zig vers Rust, il l’a délégué à une pré-version de Claude Fable 5, lancée en environ 64 instances parallèles. Onze jours plus tard, le chantier était bouclé : plus d’un million de lignes de code réécrites, là où une équipe humaine aurait travaillé près d’un an, selon son estimation.
Mais cette prouesse technique dit surtout autre chose : le poste de travail du développeur est en train de se déplacer sous nos pieds.
Sumner a cadré, découpé et arbitré, sans taper une ligne
Regardons la mécanique de près. Sumner n’a pas écrit ce million de lignes. Il ne les a pas relues une par une non plus : personne ne relit un million de lignes en onze jours. Son travail a consisté à cadrer, à découper la migration en lots parallélisables, à définir les critères de correction, puis à arbitrer ce que produisaient les 64 agents. Le geste central n’est plus la frappe au clavier, c’est la supervision d’une production de code à une échelle qu’aucune main humaine ne peut suivre.
Le choix technique éclaire ce basculement. Zig laissait passer des erreurs mémoire et des crashes difficiles à corriger durablement. Rust en attrape une bonne partie dès la compilation. Autrement dit, Sumner a délégué la production à la machine et adossé le contrôle qualité à un langage qui vérifie mécaniquement une classe entière de fautes. Le développeur ne garantit plus la justesse ligne à ligne ; il conçoit le système qui, lui, la garantit.
Un an de travail humain contre 165 000 dollars d’API
La facture des appels d’API à Claude s’élève à environ 165 000 dollars. Le chiffre paraît lourd sorti de son contexte. Rapporté à une année d’ingénierie sur un projet de cette complexité, il change de nature : il devient un arbitrage budgétaire trivial. Sumner précise d’ailleurs ne pas avoir eu à s’en soucier, Bun et son équipe ayant été rachetés par Anthropic en décembre 2025.
C’est ce ratio qu’il faut fixer, car il annonce la trajectoire. Quand réécrire un socle logiciel entier coûte le prix de quelques semaines de salaire plutôt qu’une année-homme, la question de savoir s’il faut migrer, réécrire ou moderniser une base de code ne se pose plus dans les mêmes termes. Des chantiers jugés impensables hier, parce que trop coûteux en temps humain, redeviennent des décisions de routine.
Piloter une flotte d’agents deviendra un métier à part entière
Cette économie nouvelle dessine une trajectoire assez nette. D’ici douze à dix-huit mois, la migration de Bun ne sera plus une prouesse isolée mais un mode opératoire documenté. On verra apparaître des équipes qui pilotent des dizaines d’agents en parallèle sur des réécritures ou des portages massifs, avec des rôles nouveaux : celui qui découpe le travail en lots vérifiables, celui qui écrit les tests et les garde-fous, celui qui arbitre les diffs remontés par la flotte. Bun n’avance pas seul sur ce terrain : OpenAI, avec Codex, et Google, avec Jules, poussent eux aussi des agents autonomes à qui l’on confie une tâche et qui rendent une pull request une fois le travail fait. Ce qui distingue la migration de Bun, c’est l’échelle : des dizaines d’agents lancés en parallèle sur une seule et même réécriture.
Trois conditions décideront de la vitesse de ce mouvement. D’abord la vérifiabilité : cette approche ne tient que sur des projets où la justesse se contrôle mécaniquement, par un compilateur strict, une batterie de tests dense, des types explicites. Sur une base de code sans filet, lâcher 64 agents relève d’un pari dangereux. Ensuite le coût, qui continue de chuter et rendra l’arbitrage encore plus favorable. Enfin la confiance : accepter qu’une machine produise un socle qu’aucun humain n’a lu intégralement suppose un changement culturel réel dans les équipes.
Le développeur qui tape du code face à celui qui le supervise
Ce qui prend de la valeur, c’est la capacité à spécifier sans ambiguïté, à concevoir un système de vérification robuste et à juger vite la qualité d’un code qu’on n’a pas écrit. La vélocité de frappe et la maîtrise encyclopédique d’un langage, elles, se déprécient. Le développeur qui excelle demain est celui qui sait poser les bonnes contraintes et lire une trajectoire de projet, pas celui qui tape le plus de lignes.
Ce déplacement crée aussi une fracture. Entre ceux qui apprennent à orchestrer ces flottes d’agents et à en encadrer la production, et ceux qui restent sur le geste artisanal de la ligne écrite à la main. Bun v1.4.0, disponible en version canary (une pré-version de test), corrige 128 bugs et tourne 2 à 5 % plus vite : la preuve que le procédé livre du logiciel réel, pas une démonstration de laboratoire.
On saura que la bascule est consommée le jour où une entreprise annoncera avoir réécrit un produit critique de cette façon sans que personne n’y voie un exploit, tant ce sera devenu banal. Ce jour-là, programmer aura cessé de vouloir dire d’abord écrire.
Mon avis
Le métier ne disparaît pas, il change de centre de gravité, et bien plus vite qu’on ne l’admet. Je vois déjà les offres d’emploi se scinder : d’un côté ceux qui savent découper un problème pour une flotte d’agents et vérifier sa sortie, de l’autre ceux qui savent seulement écrire du code propre. Les seconds seront payés comme on paie aujourd’hui une compétence utile mais abondante. La vraie rareté, désormais, c’est le jugement : savoir ce qu’on veut, comment le prouver, et reconnaître quand la machine s’est trompée.
