Bun : Le runtime qui veut envoyer Node à la retraite (et qui a maintenant les moyens de le faire)

La nouvelle que personne n’avait vue venir

La semaine passée, pendant que vous et moi nous battions tranquillement avec le node_modules, Anthropic a lâché une bombe : ils ont acheté Bun.

Oui, l’entreprise derrière Claude a décidé que son avenir passe par un runtime JavaScript écrit en Zig par un type qui s’est dit “et si Node, mais rapide ?”. Claude Code vient d’atteindre un milliard de dollars de chiffre d’affaires, et apparemment la première chose qu’on fait quand on a de l’argent en trop, c’est acheter des outils de développement.

Pourquoi ? Parce que Claude Code exécute du JavaScript à tour de bras, et chaque milliseconde compte quand on a des millions d’utilisateurs. En d’autres termes : si votre business dépend de l’exécution rapide de code, vous achetez le runtime le plus rapide.

Mais assez de ragots d’entreprise. Passons à ce qui vous intéresse : ce qu’est Bun et pourquoi ça devrait vous importer.

Ce qu’est Bun (pour ceux qui viennent de Node)

Bun, c’est comme si quelqu’un avait regardé l’écosystème Node et s’était dit : “Et si au lieu d’avoir quinze outils, on en faisait un qui les remplace tous ?”

Là où avant vous aviez :

node          → runtime
npm/pnpm/yarn → gestionnaire de paquets
webpack/esbuild/vite → bundler
jest/vitest   → test runner
ts-node/tsx   → exécuter TypeScript

Maintenant vous avez :

bun           → tout ce qui précède

C’est la trottinette électrique face à la voiture avec remorque. Moins de pièces, moins de choses qui peuvent foirer, et curieusement plus rapide.

Les chiffres qui comptent

Je n’aime pas faire de benchmarks parce qu’on peut toujours les manipuler. Mais ces chiffres sont si brutaux qu’il vaut la peine de les mentionner :

Opération	Node + pnpm	Bun	Différence
`install` (projet moyen)	~25s	~3s	8x plus rapide
Démarrage du runtime	~50ms	~5ms	10x plus rapide
Exécuter les tests	baseline	2-3x plus rapide	Notable
Transpiler TypeScript	Nécessite un outil	Natif	∞

Pourquoi est-ce si rapide ? Parce que c’est écrit en Zig au lieu de C++, et parce que Jarred Sumner (le créateur) est un de ces programmeurs qui optimisent le code comme loisir. Le type travaillait chez Stripe et a décidé que le problème le plus important au monde était que npm install prenait trop de temps.

Et, bon, peut-être qu’il avait raison.

Ce qui fonctionne déjà (et ce qui ne fonctionne pas)

Bun est compatible avec la plupart des APIs de Node. Si votre code utilise fs, path, http, ou n’importe quel module standard, ça fonctionnera probablement sans changements.

Fonctionne bien

Next.js : Support officiel. bun run dev et c’est parti.
Express/Fastify : Sans problèmes.
La plupart des paquets npm : Bun lit package.json et node_modules comme Node.
TypeScript : Natif, sans configuration.
JSX : Également natif.

Peut poser problème

Paquets avec bindings natifs de Node : Certains nécessitent une recompilation.
Code qui dépend de spécificités de V8 : Bun utilise JavaScriptCore (le moteur de Safari).
Certaines APIs Node très spécifiques : Workers, certaines parties de cluster.

Ne fonctionne pas (encore)

Windows : Fonctionne, mais avec quelques limitations.
Yarn PnP : Non supporté.

Votre premier projet avec Bun

Si vous avez déjà Node, installer Bun se fait en une commande :

curl -fsSL https://bun.sh/install | bash

Ou si vous êtes sur macOS et utilisez Homebrew :

brew install oven-sh/bun/bun

Vérifiez que ça fonctionne :

bun --version

Créer un nouveau projet

mkdir mon-projet && cd mon-projet
bun init

Cela génère un package.json, un tsconfig.json, et un index.ts. Sans questions, sans assistants. J’aime ça.

Le fichier qu’il génère

// index.ts
console.log("Hello via Bun!");

Exécutez-le :

bun run index.ts

Oui, il exécute TypeScript directement. Sans transpiler. Sans ts-node. Sans rien.

Migration depuis pnpm

Si vous avez un projet avec pnpm, la migration est étonnamment simple :

# Option 1 : Régénérer le lockfile
rm -rf node_modules pnpm-lock.yaml
bun install

# Option 2 : Utiliser le lockfile existant (expérimental)
bun install

Bun génère son propre bun.lockb (binaire, plus rapide à parser). Vous pouvez garder les deux lockfiles pendant la transition si vous travaillez en équipe et que tout le monde n’a pas encore migré.

Le package.json ne change pas

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "test": "vitest"
  }
}

Vous continuez à exécuter bun run dev, bun run build, bun run test. Les scripts fonctionnent pareil.

Tests : de Vitest à Bun

Bun a son propre test runner qui est compatible avec l’API de Jest/Vitest :

// sum.test.ts
import { expect, test } from "bun:test";
import { sum } from "./sum";

test("2 + 2 = 4", () => {
  expect(sum(2, 2)).toBe(4);
});

Exécutez avec :

bun test

Et si je veux continuer avec Vitest ?

Ça fonctionne parfaitement. Bun peut exécuter Vitest comme runtime :

bun run vitest

Vous obtenez la vitesse de démarrage de Bun avec les fonctionnalités de Vitest. Le meilleur des deux mondes.

Le serveur HTTP le plus rapide que vous verrez

Bun inclut un serveur HTTP qui fait pleurer Express dans un coin :

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Salut depuis Bun !");
  },
});

console.log("Serveur sur http://localhost:3000");

Il utilise l’API standard de fetch (Request/Response), donc si vous venez de Cloudflare Workers ou Deno, vous vous sentirez comme chez vous.

Benchmark du hello world

Sur ma machine (M1 Pro), un serveur hello world :

Express : ~15'000 req/s
Fastify : ~45'000 req/s
Bun.serve : ~150'000 req/s

Oui, dix fois plus rapide qu’Express. Non, ce n’est pas une faute de frappe.

Variables d’environnement

Bun charge .env automatiquement. Sans dotenv. Sans configuration.

# .env
DATABASE_URL=postgres://localhost/mydb

// index.ts
console.log(Bun.env.DATABASE_URL);

C’est fini. Ça fonctionne, point.

SQLite intégré

Ça m’a époustouflé. Bun apporte SQLite intégré :

import { Database } from "bun:sqlite";

const db = new Database("mydb.sqlite");
db.run("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)");
db.run("INSERT INTO users (name) VALUES (?)", ["Fernando"]);

const users = db.query("SELECT * FROM users").all();
console.log(users);

Pas besoin d’installer better-sqlite3 ou sql.js. Ça fonctionne simplement.

Le bundler

Bun peut aussi empaqueter votre code pour la production :

bun build ./index.ts --outdir ./dist

C’est plus rapide qu’esbuild (qui était déjà ridiculement rapide). Pour la plupart des projets, il génère des bundles équivalents.

Si vous avez besoin de quelque chose de plus sophistiqué (code splitting, tree shaking avancé), vous aurez probablement encore besoin de Vite ou webpack. Mais pour beaucoup de cas, ceci suffit.

Quand NE PAS utiliser Bun

Parce que tout n’est pas arc-en-ciel et licornes :

Production critique où vous ne pouvez pas expérimenter : Bun est stable, mais Node a 15 ans de bugs résolus.
Paquets avec bindings natifs très spécifiques : Certains nécessitent du travail supplémentaire.
Windows comme plateforme principale : Ça fonctionne, mais le support de première classe est pour macOS/Linux.
Votre équipe ne veut rien apprendre de nouveau : Parfois le meilleur outil est celui que tout le monde sait utiliser.

Quand utiliser Bun

CI/CD : Le temps d’install réduit fait économiser de l’argent réel. Sérieusement, faites les calculs.
Scripts et outils internes : La vitesse de démarrage fait que les scripts semblent instantanés.
Nouveaux projets sans héritage : Commencer avec Bun est plus simple que commencer avec Node + npm + tsx + vitest + …
Serverless/Edge : Moins de temps de démarrage = moins de cold starts = moins de latence = utilisateurs plus contents.
Maintenant qu’Anthropic le soutient : Ce n’est pas rien. Ils ont de l’argent, ils ont des motivations, et ils ont un produit (Claude Code) qui dépend de la qualité de Bun.

Ma recommandation

Si vous commencez un nouveau projet et n’avez pas de contraintes d’équipe, essayez Bun. Le pire qui puisse arriver, c’est que vous retourniez à Node, et vous aurez appris quelque chose.

Si vous avez un projet existant en production, évaluez d’abord en CI/CD. C’est là que la différence se remarque le plus et où il y a le moins de risques. Si bun install fonctionne bien avec vos dépendances, vous avez déjà gagné.

Et si vous êtes de ceux qui aiment vivre dangereusement, mettez-le en production et racontez-moi comment ça se passe. Moi, je n’ose pas encore, mais je croise les doigts.

Ressources

Documentation officielle
Guide de migration depuis Node
Awesome Bun - Liste organisée de ressources

Conclusion

Bun, c’est ce qui arrive quand quelqu’un regarde l’écosystème JavaScript et décide qu’on peut faire mieux. Et ce qui est inquiétant, c’est que… il a raison.

Est-ce la fin de Node ? Probablement pas. Node ne va pas disparaître comme n’a pas disparu Java quand est sorti… bon, n’importe quoi d’autre. Mais c’est bien le premier concurrent sérieux depuis longtemps.

Et maintenant qu’Anthropic est derrière, avec ses milliards de dollars et son besoin que JavaScript vole, les choses deviennent intéressantes.

En attendant, je vais continuer à utiliser pnpm en production. Mais mes scripts locaux tournent déjà avec Bun, et ma CI est en cours de migration. Petit à petit.

TL;DR : Bun est un runtime JavaScript tout-en-un (runtime + gestionnaire de paquets + bundler + test runner) qui est considérablement plus rapide que Node. Anthropic vient de l’acheter. Il fonctionne avec la plupart des projets TypeScript existants. Testez-le d’abord en CI, c’est là que ça se remarque le plus.

Cet article a été rédigé en espagnol et traduit avec l’aide de l’IA.

La nouvelle que personne n’avait vue venir#

Ce qu’est Bun (pour ceux qui viennent de Node)#

Les chiffres qui comptent#

Ce qui fonctionne déjà (et ce qui ne fonctionne pas)#

Fonctionne bien#

Peut poser problème#

Ne fonctionne pas (encore)#

Votre premier projet avec Bun#

Créer un nouveau projet#

Le fichier qu’il génère#

Migration depuis pnpm#

Le package.json ne change pas#

Tests : de Vitest à Bun#

Et si je veux continuer avec Vitest ?#

Le serveur HTTP le plus rapide que vous verrez#

Benchmark du hello world#

Variables d’environnement#

SQLite intégré#

Le bundler#

Quand NE PAS utiliser Bun#

Quand utiliser Bun#

Ma recommandation#

Ressources#

Conclusion#