Bun 2.0, Deno 3 et Node.js en 2026 : Benchmarks, compatibilité et quel runtime utiliser

Trois runtimes, un écosystème, de vrais compromis

Le paysage des runtimes JavaScript a radicalement changé depuis 2023. Bun a lancé la version 1.0 cette année-là et a revendiqué des victoires dans les benchmarks difficiles à ignorer. Deno s'est éloigné de sa position initiale anti-npm pour adopter la couche de compatibilité Node.js. Node.js a publié des versions majeures culminant avec Node 24. À la mi-2026, la question n'est plus de savoir quel runtime est théoriquement le meilleur — c'est lequel offre des avantages mesurables pour des charges de travail spécifiques, et lequel vous pouvez réellement déployer sans réécrire votre stack.

La réponse courte : Bun 2.0 est le plus rapide pour les charges de travail serveur liées aux I/O et les tâches de script. Node.js reste l'option la plus compatible et la plus éprouvée. Deno 3 est le meilleur choix pour les déploiements axés sur la sécurité et les équipes qui veulent des valeurs par défaut modernes prêtes à l'emploi. Aucun n'est universellement supérieur.

Bun 2.0 : Ce qui a vraiment changé

Bun 2.0, sorti début 2026, s'est appuyé sur JavaScriptCore (le moteur derrière Safari) et un runtime natif basé sur Zig. Les chiffres clés des benchmarks officiels de Bun :

Temps de démarrage : Bun 2.0 démarre un serveur HTTP basique en ~6ms contre ~45ms pour Node 24 et ~22ms pour Deno 3
Débit HTTP : Le Bun.serve() intégré gère ~120 000 requêtes/seconde sur un seul cœur (M2 MacBook Pro) contre ~75 000 pour Node avec uWS et ~90 000 pour Deno
E/S de fichiers : Les lectures Bun.file() sont 2 à 3 fois plus rapides que le module fs de Node grâce à des appels directs au niveau du système d'exploitation
Exécution de TypeScript : Bun transpile et exécute les fichiers .ts nativement — pas de surcharge de tsc ou ts-node

Bun 2.0 a également livré un gestionnaire de paquets réécrit. L'installation de 1 000 paquets npm prend ~800ms dans Bun contre ~4s dans npm 10 et ~2,5s dans pnpm. Le format du fichier de verrouillage a changé dans la 2.0 et est désormais binaire pour la vitesse, ce qui a cassé certains Pipelines CI qui analysaient l'ancien format texte.

Le revers : la compatibilité de Bun avec Node.js est d'environ 95 % selon leurs propres estimations. Ce fossé de 5 % couvre les cas limites dans node:cluster, certains comportements de node:vm et des modèles spécifiques d'addons natifs (napi). Pour la plupart des applications construites avec Express, Fastify ou Hono, le fossé est invisible. Pour les applications d'entreprise avec des dépendances de modules natifs profondes, cela peut être un obstacle à la migration.

Deno 3 : Le virage pragmatique

Deno 3, sorti fin 2025, a achevé le passage d'une alternative dogmatique à un remplacement pragmatique de Node.js. Les changements les plus importants :

Compatibilité npm : Deno 3 exécute la plupart des paquets npm sans indicateur de compatibilité, résolvant un point de friction majeur de Deno 1.x
Deno Deploy v2 : Intégration plus étroite avec la plateforme de déploiement en périphérie, avec des démarrages à froid d'isolats V8 sous les 5ms à l'échelle mondiale
Linter et formateur intégrés : deno lint et deno fmt sont désormais nettement plus rapides (3 à 5 fois) grâce à une réécriture en Rust
Modèle de permissions : Le système de permissions explicites (--allow-net, --allow-read) a mûri avec des contrôles plus granulaires et est devenu opt-out plutôt qu'opt-in pour les scripts de confiance

Le débit HTTP de Deno 3 se situe entre Bun et Node. Ce qu'il perd en vitesse brute, il le regagne en posture de sécurité : par défaut, un processus Deno ne peut pas lire votre système de fichiers ni effectuer d'appels réseau à moins que vous ne l'y autorisiez explicitement. Pour les environnements sensibles à la conformité — santé, fintech, gouvernement — ce n'est pas un luxe, c'est une exigence de déploiement.

La bibliothèque standard de Deno (deno.land/std) a atteint la stabilité 1.0 en 2025, ce qui signifie que les API ne changent plus entre les versions mineures. C'était la dernière plainte majeure de fiabilité des utilisateurs en production.

Node.js en 2026 : Toujours le choix par défaut

Node 24 (LTS à partir de 2026) a introduit plusieurs fonctionnalités qui réduisent l'écart avec les concurrents :

fetch natif : Stable, plus derrière un indicateur
Exécuteur de tests intégré : node:test est assez mature pour remplacer Jest dans la plupart des cas d'utilisation
Modèle de permissions (expérimental) : Node a emprunté l'idée de Deno avec les indicateurs --experimental-permission
Suppression des types TypeScript : Node 24 peut exécuter des fichiers .ts en supprimant les annotations de type (pas la vérification complète des types), similaire à Bun mais sans transpilation

Node.js détient environ 72 % des déploiements de serveurs JavaScript en production selon l'enquête Stack Overflow 2026 auprès des développeurs. La profondeur de l'écosystème en est la raison : 2,3 millions de paquets sur npm, des intégrations de surveillance matures (Datadog, New Relic, OpenTelemetry) et une décennie de modèles de production documentés. Passer de Node à Bun pour un monolithe fintech vieux de 10 ans est un calcul risque-récompense qui favorise rarement le changement.

Compatibilité de l'écosystème en pratique

La matrice de compatibilité qui compte vraiment pour les décisions de production :

Express.js : Fonctionne sur les trois ; Bun est le plus rapide
Next.js : Node uniquement (Vercel contrôle le runtime) ; le support de Bun est expérimental
Prisma ORM : Node et Bun supportés ; support de Deno via la couche de compatibilité npm
Vitest : Les trois, mais Bun fournit son propre exécuteur de tests (bun:test) compatible avec l'API de Jest
Addons natifs (fichiers .node) : Node uniquement de manière fiable ; Bun 2.0 a amélioré napi mais des lacunes subsistent ; Deno a un support limité
AWS Lambda : Node 22 est le runtime officiel ; Bun fonctionne via une couche personnalisée ; Deno fonctionne via une couche personnalisée

Quel runtime utiliser en 2026

Utilisez Bun 2.0 si : vous construisez de nouvelles APIs greenfield, des outils CLI ou des scripts où la vitesse de démarrage compte ; votre équipe écrit du TypeScript et veut un développement local sans étape de build ; vous ne dépendez pas d'addons natifs ou de Next.js.

Utilisez Deno 3 si : la sécurité et l'auditabilité sont des préoccupations de premier ordre ; vous voulez un runtime complet (formateur, linter, exécuteur de tests, plateforme de déploiement) sans taxe de configuration ; vous ciblez les déploiements en périphérie via Deno Deploy.

Restez sur Node.js si : votre application a des chaînes de dépendances npm profondes avec des modules natifs ; vous avez besoin d'une stabilité LTS certifiée pour les industries réglementées ; les outils de votre équipe (CI, APM, plateforme de déploiement) sont spécifiques à Node et les coûts de migration dépassent les gains de performance.

Le piège des benchmarks : La plupart des benchmarks synthétiques mesurent le débit du gestionnaire HTTP sur une route vide. Les applications réelles passent la majeure partie de leur temps à attendre des bases de données, des API externes et du stockage — des domaines où le runtime importe bien moins que les modèles de requêtes et la topologie réseau. Un démarrage 4 fois plus rapide économise des millisecondes sur les démarrages à froid Lambda, pas des secondes sur un temps de réponse dominé par une requête Postgres de 200ms.

Que faire concrètement

Exécutez vos propres benchmarks sur votre charge de travail réelle avant de migrer. La compatibilité bun run de Bun signifie que vous pouvez le glisser dans la plupart des projets Node et exécuter bun install && bun run start en moins de cinq minutes pour voir si votre suite de tests passe. Le mode --compat de Deno réduit également le coût d'essai. Les deux sont devenus suffisamment bons en compatibilité Node pour que le coût de découverte de les essayer soit faible. Le coût de migration lié au changement réel de l'infrastructure de production ne l'est pas.