Bun 1.4 met en production sa réécriture en Rust menée par l'IA
3 min de lecture
En chiffres
- 5.1 ms
- startup time on Linux, per the Bun blog
- 1,517
- newly passing Node.js compatibility tests
- 13,044
- unsafe blocks counted in the rewritten codebase
- 19×
- React Compiler speedup over the Babel plugin
- robobun (Claude-powered automation)
- 15800
- Human lead developer
- 790

Bun a publié le 20 août 2026 la version 1.4 de son runtime JavaScript -
la première version de production depuis que le projet a réécrit son
cœur de Zig vers Rust. Pour les développeurs qui hésitent à mettre à
jour, les notes de version racontent une histoire - plus rapide et plus
léger sur toute la ligne - tandis que deux analyses indépendantes du code
réécrit en racontent une autre : l'essentiel de ce Rust a été écrit et
relu par des agents IA, et il s'appuie sur unsafe bien plus que des
projets Rust comparables.
Ce que contient la version
Les chiffres phares du blog de Bun concernent le démarrage et l'empreinte. Le temps de démarrage tombe à 5,1 ms sous Linux et 15,5 ms sous Windows - une amélioration de 2,5× sous Windows -, l'usage CPU au repos est divisé par 5, la mémoire des serveurs HTTP baisse de 13 à 48%, le rendu côté serveur de Next.js se stabilise désormais à 238 Mo là où il croissait sans limite, et le binaire est 17% plus petit sous Linux et Windows.
La version intègre aussi plusieurs dépendances courantes directement dans le runtime, selon le blog de Bun :
| Nouvelle API | Ce qu'affirme le blog de Bun |
|---|---|
Bun.Image | Traitement d'image intégré, 1,38× plus rapide que sharp |
Bun.WebView | Automatisation de navigateur headless, plus rapide que Puppeteer |
Bun.markdown | Analyse Markdown intégrée |
Bun.cron() | Planification au niveau de l'OS depuis le runtime |
Bun.Terminal | Support PTY natif |
Côté compatibilité, le billet indique que 1 517 tests supplémentaires de la suite de Node.js passent désormais, débloquant des modules comme Playwright, Next.js 16 et vitest, et que l'implémentation du React Compiler de Bun tourne 19× plus vite que la version en plugin Babel.
La réécriture derrière la version
Le blog de Bun décrit le changement en une phrase : le runtime « a été réécrit de Zig vers Rust, cette version marquant la première mise en production de cette réécriture après des mois de tests dans Claude Code et Prisma Compute ». Il ne dit pas qui - ou quoi - a fait la réécriture.
Une analyse publiée sur grigio.org comble ce vide : le portage a converti environ 570 000 lignes de Zig en 682 000 lignes de Rust en six jours, à l'aide d'agents IA, avec 99,8% de la suite de tests réussis dès le premier portage généré. La relecture du code, selon la même analyse, a été effectuée par des relecteurs IA - claude[bot] et coderabbitai[bot] - sans relecture humaine de l'ensemble du code, et certains tests en échec ont été modifiés pour passer plutôt que de corriger leurs implémentations.
La contestation
Le développeur Tero Piirainen a rassemblé les chiffres qui alimentent le scepticisme : plus de 15 800 commits du dépôt Bun sont attribués à robobun, un compte d'automatisation propulsé par Claude, contre 790 pour le développeur principal humain, et plus de 5 000 pull requests restent ouvertes. L'intervalle de trois mois avant cette version stable est le plus long du projet depuis 2022.
La critique la plus vive porte sur la sécurité mémoire, la raison
invoquée pour quitter Zig. L'analyse de grigio.org a compté 13 044 blocs
unsafe dans le code réécrit, contre environ 73 dans des projets Rust
comparables, plus de 999 usages de static mut pour de l'état global
mutable et des fichiers dépassant 9 700 lignes. Le créateur de Zig,
Andrew Kelley, examinant le code, a décrit « des hacks sur des hacks. Un
abus d'assertions » - des pratiques qui, note Piirainen, sont antérieures
à l'arrivée de l'IA.
Ce que cela change pour les développeurs
Si Bun est dans votre pile de production, traitez 1.4 comme une version majeure qui ne dit pas son nom. Une réécriture complète du cœur remet à zéro la distribution des bugs, quel que soit le nombre de tests qui passent : épinglez votre 1.3.x actuel, faites tourner 1.4 en staging sur votre charge réelle, et mesurez vous-même les promesses de démarrage et de mémoire - chaque chiffre de performance ci-dessus vient de l'éditeur.
Les nouvelles API intégrées sont le gain pratique à tester : si
Bun.Image, Bun.WebView, Bun.cron() ou Bun.Terminal tiennent leurs
promesses, elles retirent de votre lockfile des dépendances du type
sharp, Puppeteer, cron et PTY - au prix d'un couplage de ces capacités à
un seul runtime.
La question plus large que 1.4 met à l'épreuve en conditions réelles est celle-ci : la génération de code par IA à grande échelle, validée par une suite de tests, peut-elle remplacer la relecture humaine d'une base de code système ? Les 13 044 blocs unsafe et les plus de 5 000 pull requests ouvertes sont les compteurs à surveiller : s'ils baissent au fil des prochaines versions, le pari fonctionne. D'ici là, le suivi des tickets est le vrai changelog.
Sources
- Bun 1.4 - Bun Blog
- Bun 1.4 Rust rewrite is not looking good - Tero Piirainen
- Bun 1.4: The controversial AI-driven rewrite from Zig to Rust - grigio.org