Bun 1.3 : Node.js a-t-il vraiment du souci à se faire ?

Note de la rédaction (17 juillet 2026) : la version initiale de cet article évoquait une sortie « Bun 2.0 » et un taux de compatibilité de 99,7 %. Ces informations étaient erronées — Bun n’a jamais publié de version 2.0. L’article a été corrigé à partir des données du registre npm.

Bun avance vite. Au moment où nous écrivons ces lignes, le runtime de Jarred Sumner en est à la version 1.3.10, publiée fin février 2026, et enchaîne les livraisons à un rythme soutenu. La question mérite d’être posée sérieusement : peut-il détrôner Node.js sur les projets de production ?

Les chiffres, et ce qu’ils valent

Sur les benchmarks synthétiques, Bun affiche des écarts spectaculaires face à Node.js, en particulier sur les opérations d’entrée-sortie. Mais ces mesures portent le plus souvent sur un serveur minimal qui ne fait rien d’utile. Dès qu’une application parle à une base de données, sérialise du JSON réel et traverse plusieurs couches applicatives, l’écart se resserre nettement.

Là où le gain est incontestable, c’est ailleurs : le temps de démarrage d’un processus, et bun install. Grâce à un cache global et à des liens physiques entre fichiers, l’installation de dépendances est souvent plusieurs fois plus rapide que npm. Sur ce terrain précis, la différence n’est pas marginale.

La compatibilité : le nerf de la guerre

Bun vise la compatibilité avec les API de Node et passe la grande majorité de la suite de tests des modules cœur : node:events, node:fs, node:http, node:path. Pour beaucoup de projets récents et standards, ça fonctionne étonnamment bien.

Le point de friction historique reste les modules natifs compilés via node-gyp — pilotes de bases de données, processeurs d’images, enveloppes cryptographiques. C’est le premier endroit où une migration se casse les dents, et c’est donc là qu’il faut tester ses dépendances les plus sensibles avant de basculer.

Quand adopter Bun ?

Pour un nouveau projet, un prototype ou un outil en ligne de commande : oui, le confort est immédiat et le démarrage instantané se ressent au quotidien.

Pour un projet existant en production : ça dépend. Si vos mesures montrent que le runtime est votre goulot d’étranglement — c’est rare — la migration mérite l’étude. Sinon, la priorité reste la valeur métier, pas l’optimisation prématurée.

Une voie intermédiaire est souvent la plus raisonnable : adopter bun install comme gestionnaire de paquets sur un projet qui continue de tourner sous Node. Le gain est immédiat, le risque quasi nul.

Node.js n’est pas mort. Mais Bun a clairement prouvé qu’il avait sa place dans l’écosystème.