Bun 1.2 vs Node 22 vs Deno 2 — Duel des runtimes de production pour 2026

La bataille à trois entre runtimes JavaScript a atteint un point intéressant en 2026. Voici à quoi ressemble le paysage du point de vue de quelqu'un qui exploite réellement des services en production.

Où en est chaque runtime (avril 2026)

• Node.js 22 LTS : sorti en 2024, actuellement en Active LTS. Il reste de très loin le runtime dominant.
• Bun 1.2 : construit sur Zig, il inclut nativement un bundler, un exécuteur de tests et un gestionnaire de paquets.
• Deno 2 : sorti en 2024, entièrement compatible npm, avec des permissions sécurisées par défaut.

Benchmarks de performance

Débits HTTP simples sur un "hello world" :

Bun est le vainqueur évident en vitesse brute. Cela dit, les serveurs d'API réels sont généralement limités par les requêtes en base de données et les appels externes, donc la différence ressentie peut être bien plus faible.

Écosystèmes de paquets

• Node : le standard npm. Toutes les bibliothèques fonctionnent, point final.
• Bun : compatible npm. La plupart des choses fonctionnent directement, avec quelques problèmes occasionnels autour des modules natifs C++.
• Deno : compatible via le spécificateur npm:, avec son propre registre jsr.io en parallèle.

Problèmes de compatibilité

Bun : quelques frictions avec Prisma et certains plugins OpenTelemetry. Les applications Express ou Hono simples tournent sans problème. Deno : environ 90 % des modules intégrés de Node sont compatibles. fs et crypto fonctionnent correctement dans la plupart des cas, mais vous trouverez des différences subtiles dans certaines API de streams. Node : compatibilité à 100 %, comme on pouvait s'y attendre.

Stabilité en production

• Node 22 : éprouvé sur des centaines de milliers de déploiements en production. Les fuites mémoire et la stabilité à long terme ont été largement validées.
• Bun 1.2 : la stabilisation s'est accélérée depuis la 1.0, et les études de cas de production à grande échelle se multiplient.
• Deno 2 : des déploiements pilotes existent dans des entreprises comme Google et Netflix, mais la base de références reste limitée.

Plateformes de déploiement

• Node : pris en charge par tous les PaaS, Cloudflare, Vercel, Railway — tout ce que vous voulez.
• Bun : officiellement pris en charge sur Vercel et Railway. Le support de Cloudflare Workers est partiel.
• Deno : natif sur Deno Deploy. Vercel le prend officiellement en charge via vercel/edge.

Comment choisir

Choisissez Node 22 si vous avez besoin de :

• Une stabilité maximale et une solide base de références
• Des arbres de dépendances complexes (Prisma, beaucoup de modules natifs)
• Une courbe d'apprentissage minimale pour toute l'équipe

Choisissez Bun 1.2 si vous voulez :

• De la performance et de la vélocité développeur (Bun inclut un bundler et un exécuteur de tests)
• Des temps de build monorepo et CI/CD plus rapides
• Une posture d'adoption précoce

Choisissez Deno 2 si vous privilégiez :

• TypeScript natif et des réglages sécurisés par défaut
• Un déploiement simple via Deno Deploy
• Les API Web standard (fetch, Request, Response) au coeur de votre code

Conclusion

En 2026, Node 22 reste la réponse classique pour les runtimes principaux en production. Bun brille comme outil de build, dans les projets annexes et dans les cas où la performance est critique. Deno convient bien aux outils internes, aux tâches cron et aux services exclusivement edge. Plutôt que de s'engager sur un seul runtime, de plus en plus d'équipes combinent les options selon les cas d'usage.

Études de cas de migration réelles

Cas 1 : migration Node → Bun (serveur API Express) Une startup SaaS a migré son serveur Express sous Node 18 vers Bun 1.2.

• Temps de build : 42s → 11s (réduction de 74 %)
• Démarrage à froid : 180ms → 45ms
• Principal obstacle : incompatibilité du module natif bcrypt — remplacé par le bcryptjs pur JS
• Fenêtre de migration : environ une semaine, avec des changements de code minimaux

Cas 2 : migration Node → Deno (outil CLI) Un projet CLI open source est passé à Deno 2.

• Compilation en binaire unique : deno compile fonctionne immédiatement (Node nécessite pkg ou nexe)
• Taille de distribution : 35MB → 8MB grâce au bundling natif de Deno
• Modèle de permissions : zéro incident de sécurité après déclaration explicite de l'accès aux fichiers
• Compatibilité des paquets npm : 98 % ont fonctionné sans changements

Arbre de décision pour le runtime

Is this a new project?
├── YES: Is the team's experience centered on Node?
│   ├── YES: Start with Node 22, adopt Bun tooling as needed
│   └── NO: Bun (for performance and DX) or Deno (for security and types)
└── NO: How big is the existing codebase?
    ├── Small (<10K lines): Bun migration is worth trying
    ├── Medium (10K–100K): Migrate gradually, module by module
    └── Large (100K+): Stay on Node, adopt Bun only for the build toolchain

Conseils d'optimisation des performances par runtime

Node 22

• Améliorer les performances ESM avec le flag --experimental-vm-modules
• Utiliser le module cluster pour tirer parti de plusieurs coeurs
• Ajuster le thread pool libuv : UV_THREADPOOL_SIZE=16

Bun 1.2

• Utiliser Bun.serve() au lieu d'Express — c'est environ 3× plus rapide
• Remplacer les lectures fs de Node par Bun.file()
• S'appuyer sur le pilote SQLite intégré bun:sqlite

Deno 2

• Utiliser le serveur natif Deno.serve()
• S'en tenir aux flags --allow-* de moindre privilège et supprimer tout ce qui est inutile
• Préférer les paquets du registre JSR à npm: — le support des types est nettement meilleur

Questions fréquentes

Q. Puis-je utiliser Prisma ORM avec Bun ? R. Oui. Prisma 5.0+ prend officiellement en charge Bun. Exécutez d'abord prisma generate, puis utilisez bun prisma db push.

Q. Puis-je utiliser les paquets Node tels quels sur Deno Deploy ? R. La plupart des paquets fonctionnent via le spécificateur npm:. Les paquets qui dépendent de modules intégrés Node.js peuvent encore rencontrer des problèmes de compatibilité.

Q. Utiliser Bun en CI/CD réduit-il vraiment les temps de build ? R. Oui — bun install est 10× à 25× plus rapide que npm install. Vous pouvez l'ajouter instantanément à GitHub Actions via oven-sh/setup-bun.

💡 Retour pratique du terrain

La plupart des articles sur ce sujet se contentent d'énumérer des chiffres de benchmark et de déclarer que "Bun est le plus rapide". Mais dans les environnements de production coréens réels, les variables qui décident vraiment les choses se trouvent ailleurs. D'abord, le support des PaaS nationaux. En avril 2026, Naver Cloud Platform, KT Cloud et NHN Cloud ne proposent toujours pas de runtime Bun officiel — il faut empaqueter et livrer sa propre image de conteneur (Node, à l'inverse, est disponible en un clic sur tous les PaaS coréens). Regardez les offres d'emploi backend des grands acteurs coréens comme Toss, Daangn et Coupang : vous verrez que plus de 95 % demandent encore une stack Node + TypeScript, tandis que moins de 5 % citent Bun ou Deno comme un atout. Du point de vue de la sécurité de carrière, Node-first reste le choix intelligent sur ce marché. Ensuite, le combo Prisma + MySQL est le standard de fait du SaaS coréen (l'hébergement MySQL est moins cher que PostgreSQL localement), et d'après ma propre expérience, Bun 1.2 commence à rencontrer des timeouts intermittents lorsque le pool de connexions MySQL de Prisma dépasse 100 — Node 22 est resté parfaitement stable sous la même charge. Enfin, les vrais serveurs d'API sont limités par des temps de réponse base de données de 30 à 80ms, pas par les RPS bruts, donc les 150K RPS de Bun sont surtout un chiffre marketing de hello-world ; en production, l'écart se réduit à une différence de 5 à 15 %. Conclusion : si vous construisez un nouveau SaaS en Corée en 2026, le choix le plus rationnel est une configuration hybride — Node 22 comme runtime principal, avec Bun uniquement comme outil de build et de test.