Bun vs Deno vs Node.js en 2026 : ce que les benchmarks ne vous disent pas

Le 14 juillet 2026, une synthèse publiée sur ByteIota met des chiffres sur une intuition que beaucoup de développeurs backend partageaient déjà : les benchmarks de runtimes JavaScript qui circulent sur les réseaux racontent une histoire à moitié vraie. Sur un test HTTP synthétique, Bun revendique 52 000 requêtes par seconde, Deno 29 000, Node.js 14 000, soit un écart de 270 % entre le premier et le dernier. Sur une application de test réelle, avec routage, validation et accès à une base de données, les trois runtimes convergent tous autour de 12 000 à 12 400 RPS. L'écart tombe sous les 3 %.

Pour ceux qui découvrent le sujet : Node.js est le runtime JavaScript historique côté serveur, en place depuis 2009. Deno et Bun sont ses deux challengers les plus sérieux, nés pour corriger des irritants de Node : configuration TypeScript, gestion des dépendances, temps de démarrage. Le choix entre les trois façonne votre stack pour des années, de l'API au CI/CD en passant par les coûts d'hébergement. D'où l'intérêt de comprendre ce que les benchmarks mesurent réellement avant de trancher.

Pourquoi l'écart de performance s'effondre en conditions réelles

Le test qui a produit ces chiffres de convergence, mené par HackerNoon, portait sur un raccourcisseur d'URL de qualité production : routage HTTP, validation des entrées, écriture et lecture en base de données. Résultat : Bun à 12 400 RPS, Deno à 12 400 RPS, Node.js à 12 000 RPS. L'analyse qui accompagne ces résultats est sans ambiguïté : la performance seule ne justifie pas d'abandonner Node.js, les vrais avantages se trouvent ailleurs.

L'explication est architecturale. V8, le moteur de Node.js et Deno, est optimisé pour les processus longue durée et un débit soutenu. JavaScriptCore, le moteur de Bun, est optimisé pour un démarrage rapide. Dans une application réelle, où le routage, la validation, l'accès base de données et la logique métier dominent le temps d'exécution, ces différences de moteur deviennent du bruit de fond. Les benchmarks HTTP-only isolent justement la seule variable où le moteur fait une vraie différence : le traitement brut d'une requête vide.

Là où les runtimes se différencient vraiment

Les écarts réels existent, mais pas là où le marketing les affiche. Le démarrage à froid en est l'exemple le plus parlant : Bun démarre en 8 à 15 ms, Deno en 40 à 60 ms, Node.js en 60 à 120 ms. Sur AWS Lambda, cela se traduit par une latence moyenne de 156 ms pour Bun contre 245 ms pour Node.js, soit 35 % d'amélioration, un chiffre qui pèse directement sur la facture serverless.

La vitesse des outils compte aussi dans le quotidien d'une équipe. Installer 1 847 dépendances prend 47 secondes avec Bun, 4 minutes avec pnpm, et 28 minutes avec npm, soit 35 fois plus rapide que npm. Sur des pipelines CI/CD qui tournent des dizaines de fois par jour, cet écart se transforme en heures gagnées chaque semaine. Le test runner de Bun suit la même logique : 20 fois plus rapide que Jest, avec une syntaxe compatible qui ne demande aucune réécriture de code pour migrer.

« Production-ready » ne veut pas dire « enterprise-ready »

Les trois runtimes se revendiquent prêts pour la production en 2026, mais prêt pour la production ne veut pas dire prêt pour l'entreprise. Node.js a treize ans de rodage, Bun deux à trois ans de stabilité post-1.0. Les trackers d'issues le confirment : Bun compte 4 700 tickets ouverts contre 1 700 pour Node.js. Bun 1.1 a atteint 99 % de compatibilité npm et la version 1.3 continue d'améliorer la stabilité, mais les retours d'expérience en production restent prudents, avec des plantages ou des aspérités à prévoir. Une évaluation citée dans l'analyse résume la situation : Bun convient aux expérimentations et à certains cas d'usage en production, mais Node.js reste l'ossature des applications de niveau entreprise.

La tolérance au risque fait la différence. Une startup peut absorber quelques accrocs de runtime en échange d'un outillage plus rapide. Une entreprise qui gère des transactions financières ou des données de santé ne le peut pas : quand une minute d'indisponibilité coûte cher, la stabilité prime sur la vitesse.

Votre grille de lecture pour tout benchmark de runtime

Avant de partager ou de vous fier au prochain graphique viral comparant deux runtimes, posez-vous quatre questions :

• Synthétique ou applicatif ? Un test HTTP-only qui répond « Hello World » ne mesure que le moteur. Un test avec base de données et logique métier mesure votre vrai cas d'usage.
• Débit ou démarrage ? Un chiffre de RPS et un chiffre de cold start ne répondent pas à la même question. Le premier compte pour un serveur qui tourne en continu, le second pour du serverless.
• Quelle version, quel matériel ? Les runtimes publient des versions majeures plusieurs fois par an. Un benchmark ancien ne dit rien des versions actuelles.
• Qui publie le chiffre ? Un benchmark maison a intérêt à briller. Une comparaison indépendante avec méthodologie publique pèse davantage.

Quel runtime pour quel projet

Une fois ces réserves posées, le choix redevient simple parce qu'il dépend de vos contraintes, pas d'un chiffre de RPS :

• Node.js si la stabilité prime. Plus de deux millions de paquets npm, support natif sur AWS, Azure et GCP, écosystème de supervision mature comme New Relic ou Datadog : le choix par défaut pour une application d'entreprise.
• Deno si la sécurité est non négociable. Son modèle de permissions explicites (--allow-read, --allow-net) empêche toute une classe de vulnérabilités par défaut, et TypeScript fonctionne sans configuration. Deno Deploy propose un déploiement en périphérie sous 50 ms de latence globale. La contrepartie : un écosystème plus restreint sur les bindings natifs en C++.
• Bun si l'expérience développeur est le critère de départage. Les projets greenfield tirent le meilleur parti de sa vitesse : démarrage à froid réduit, installations en 47 secondes, outillage tout-en-un qui évite d'empiler des configurations. La migration depuis Node.js est pensée comme un remplacement direct.

Notre lecture chez CZSyn

Chez CZSyn, on choisit rarement un runtime sur un chiffre de benchmark : on le choisit sur l'infrastructure existante du client, son équipe et sa tolérance au risque. Pour une PME qui exploite déjà une stack Node.js avec du monitoring en place, migrer vers Bun pour gagner quelques milliers de requêtes par seconde sur un test synthétique n'a aucun sens économique. En revanche, sur un projet greenfield ou un outil interne, les 47 secondes d'installation de Bun face aux 28 minutes de npm changent réellement le confort de travail d'une équipe qui déploie plusieurs fois par jour.

Le point le plus utile de cette étude reste méthodologique : méfiez-vous de tout chiffre de performance qui ne précise pas s'il vient d'un test HTTP-only ou d'une application avec base de données. C'est la première question à poser avant de faire confiance à un benchmark, et c'est souvent celle que les titres accrocheurs évitent soigneusement de préciser.

Sources primaires

• ByteIota, « Bun vs Deno vs Node.js 2026: Real Benchmarks Mislead », 2026.
• Documentation officielle Bun, bun.sh/docs.
• Documentation officielle Deno, docs.deno.com.
• Documentation officielle Node.js, nodejs.org/en/docs.