Bun et Biome en 2026 : la nouvelle vague d'outils JavaScript natifs

# Bun et Biome : la nouvelle vague d'outils natifs qui transforme l'écosystème JavaScript

Pendant des années, l'outillage JavaScript a empilé les couches : Node.js comme runtime, npm/yarn/pnpm pour les paquets, Webpack/Vite pour le bundling, ESLint pour le lint, Prettier pour le format, Jest ou Vitest pour les tests. En 2026, deux projets écrits dans des langages systèmes — Bun (Zig) et Biome (Rust) — proposent une autre approche : tout regrouper dans des binaires uniques, ultra-rapides et natifs.

Bun : un runtime "tout-en-un"

Bun n'est pas qu'un runtime. C'est un toolkit qui inclut :

• un runtime basé sur JavaScriptCore (le moteur de Safari), pas V8
• un bundler natif comparable à esbuild
• un gestionnaire de paquets compatible avec le registry npm
• un test runner intégré (bun test)
• le support natif de TypeScript et JSX sans configuration
• depuis Bun 1.3, des APIs intégrées comme Bun.Image, Bun.cron(), ou encore Bun.WebView pour l'automatisation headless

Une histoire récente

Bun 1.0 est sorti en septembre 2023. Depuis, les versions s'enchaînent rapidement :

• Bun 1.1 (2024) — support Windows stable
• Bun 1.2 (2025) — compatibilité Node.js poussée à environ 95 % des packages npm
• Bun 1.3 — APIs natives (Image, cron, WebView), HTTP/2 et HTTP/3 expérimentaux, isolated linker avec store global (~7× plus rapide sur les installs "warm"), support Windows ARM64, décorateurs ES standard

⚠️ Note : il n'existe pas (encore) de version 2.0 officielle. Les annonces grand public parlent souvent de "Bun 2.0" par anticipation, mais la branche stable reste 1.x.

L'acquisition par Anthropic

En décembre 2025, Anthropic (éditeur de Claude) a annoncé l'acquisition de Bun. Cette opération oriente la roadmap vers des usages IA : intégration avec le Claude Agent SDK, le flag expérimental --metafile-md qui génère des visualisations de graphe de modules au format Markdown lisibles par des LLMs, et des optimisations pensées pour les workflows agentiques.

Performances : ce qu'on peut vraiment attendre

Les chiffres "marketing" promettent souvent 4× Node.js ou 25× npm. En conditions réelles, on observe plutôt :

• Démarrage à froid : 2 à 4× plus rapide que Node.js selon la complexité du module entrypoint
• HTTP brut (Bun.serve vs node:http) : facteur 2 à 3×, surtout sur des handlers très courts
• bun install : 5 à 25× plus rapide que npm install, l'écart variant fortement selon la présence d'un cache et de bindings natifs

Sur des charges réelles (frameworks lourds, accès DB, sérialisation JSON), l'écart se resserre — mais reste favorable à Bun.

Biome : un seul outil pour formater et linter

Côté qualité de code, l'écosystème historique repose sur deux outils écrits en JavaScript : ESLint (lint) et Prettier (formatage). Les configurer ensemble demande plusieurs fichiers, des plugins parfois redondants, et le temps d'exécution grimpe vite sur les gros monorepos.

Biome (fork de feu Rome Tools, repris par la communauté) propose une alternative écrite en Rust, en un seul binaire, avec une seule configuration biome.json.

Ce qu'apporte Biome 2.x

• Linter + formatter unifiés : biome check remplace eslint . && prettier --check .
• ~450 règles de lint dont la majorité issues d'ESLint et typescript-eslint
• 97 % de compatibilité avec Prettier sur la sortie du formatter
• Type-aware linting sans dépendance au compilateur TypeScript — Biome implémente sa propre analyse, ce qui le rend nettement plus rapide que typescript-eslint
• Plugins via GritQL : on peut écrire des règles personnalisées qui interrogent l'AST avec une syntaxe déclarative
• Support expérimental Vue, Svelte, Astro
• LSP intégré : un seul serveur pour l'IDE, plus besoin de gérer plusieurs extensions

Performances

Sur un benchmark interne Biome, 171 127 lignes de code réparties sur 2 104 fichiers sont formatées en quelques secondes — là où Prettier prend largement plus. Sur de gros monorepos, on parle souvent d'un facteur 10 à 20× sur le temps de lint complet.

Adoption

Biome est utilisé en production chez plusieurs acteurs majeurs (Vercel, Google sur certains projets) et a dépassé les 24 000 étoiles GitHub début 2026. La migration depuis ESLint/Prettier est facilitée par la commande biome migrate eslint et biome migrate prettier.

Bun + Biome : un combo cohérent

Utilisés ensemble, ces deux outils éliminent une grande partie de la complexité d'un projet Node.js classique :

Le package.json rétrécit, le nombre de devDependencies fond, et le CI s'accélère.

Faut-il migrer maintenant ?

Pour un nouveau projet, Bun + Biome est désormais une option crédible, surtout si la performance du tooling et la simplicité de configuration sont prioritaires.

Pour un projet existant, la décision dépend de plusieurs facteurs :

• Bindings natifs complexes (Sharp, node-canvas, drivers DB compilés) : à tester soigneusement, certains peuvent encore nécessiter des ajustements
• Workers et clustering : l'API node:cluster est partiellement supportée
• Frameworks : Next.js, Nuxt, Remix fonctionnent globalement, mais certains plugins reposent sur des APIs Node.js bas niveau encore en cours d'implémentation
• CI/CD : pensez à vérifier que vos images de base, GitLab runners, ou GitHub Actions disposent bien de Bun

Pour Biome, la migration est beaucoup plus indolore : c'est un outil dev-only, on peut le tester progressivement sans toucher au code de production.

Conclusion

Bun et Biome incarnent une tendance de fond : le retour à des outils natifs, en un seul binaire, conçus pour la vitesse. Aucun des deux ne tuera complètement l'écosystème historique à court terme — Node.js et ESLint restent des standards solides — mais ils redéfinissent les attentes en matière de performance et d'ergonomie. Pour qui démarre un projet en 2026, ne pas les évaluer serait une erreur.