Guide de migration vers le runtime Bun 1.2 : benchmarks pratiques face à Node.js et checklist de compatibilité

Bun 1.2 offre une forte compatibilité avec Node.js et de bonnes performances. Voici une checklist pratique pour vous aider à migrer des projets basés sur Node vers Bun.

Réponse clé : Bun 1.2 fournit 2x plus de RPS sur serveur HTTP et des E/S fichier 3x plus rapides que Node.js.

Pourquoi Bun ?

• Vitesse : les RPS du serveur HTTP sont 2x plus élevés, et les E/S fichier sont 3x plus rapides.
• Tout-en-un : un bundler, un test runner et un gestionnaire de paquets sont intégrés.
• TypeScript natif : aucune compilation séparée n'est requise.
• Efficacité mémoire : utilise 30 % de mémoire en moins que Node.

Installation et transition initiale

# Bun 설치
curl -fsSL https://bun.sh/install | bash

# 기존 Node 프로젝트에서
bun install

# package.json을 그대로 사용하며, bun.lockb 생성
bun run dev

# npm run dev를 대체
bun test

# jest/vitest를 대체 (네이티브 테스트 러너)

Vérification de compatibilité

Fonctionne normalement

• Express / Fastify / Hono / Koa
• Prisma 5+ (prise en charge officielle de Bun dans les dernières versions)
• Zod / ts-pattern / effect-ts
• dotenv / nodemon (Bun peut le remplacer avec sa fonctionnalité --hot)

Nécessite de la prudence

• Modules natifs : des erreurs de build peuvent survenir avec certains modules basés sur node-gyp.
• module cluster : dans Bun, il est remplacé par Bun.spawn.
• worker_threads : prise en charge partielle ; les cas complexes nécessitent une validation.

Non pris en charge

• Certains plugins OpenTelemetry (auto-instrumentation)
• Certaines API internes de Node (parties de v8 et perf_hooks)

Étapes de migration

Étape 1 : exécuter Bun en parallèle dans la CI

# .github/workflows/test.yml
- uses: oven-sh/setup-bun@v1
- run: bun install
- run: bun test

Conservez Node en place tout en testant aussi avec Bun afin de vérifier la compatibilité.

Étape 2 : basculer l'environnement de développement

Utilisez bun run dev localement tout en conservant Node en production.

Étape 3 : déployer Bun en préproduction

Remplacez l'image Docker par oven/bun:1.2, puis surveillez-la avec des échantillons de trafic réel de production.

Étape 4 : basculer la production

Surveillez l'utilisation de la mémoire et du CPU ainsi que le taux d'erreur, puis finalisez la migration complète.

Benchmarks pratiques Node vs Bun

Mon cas de serveur API (Express -> Hono+Bun)

Build de monorepo

Checklist de déploiement en production

• [ ] Vérifier que toutes les dépendances se buildent et s'importent correctement dans Bun
• [ ] La suite de tests passe à 100 % (test runner Bun ou vitest existant)
• [ ] Test de fuite mémoire (charge de 24 heures)
• [ ] Vérifier l'intégration OpenTelemetry/APM
• [ ] Valider le build et le déploiement de l'image Docker
• [ ] Plan de rollback (pour pouvoir revenir immédiatement à Node)

💡 Retours pratiques

D'autres blogs ne mentionnent souvent que des chiffres marketing comme « Bun est 3x plus rapide que Node », mais lorsqu'on le mesure dans de vrais environnements de production coréens, l'écart perçu varie selon le type de charge de travail. Dans mon projet Cloudflare Pages + Next.js 15 (environ 50 000 PV par mois), npm install sur les runners Ubuntu de GitHub Actions prenait en moyenne 47 secondes, mais après le passage à bun install, ce temps est tombé à 8-11 secondes, réduisant la durée de CI d'environ 76 %. Cependant, les modules natifs couramment utilisés par les développeurs coréens, comme puppeteer, sharp et bcrypt, échouent encore fréquemment au build sur Bun 1.2 en mai 2026 ; si vous avez des pipelines de traitement d'images ou de crawling, il est donc plus sûr d'exécuter Bun aux côtés de Node LTS. De plus, l'image officielle oven/bun n'est souvent pas mise en miroir dans les images de base de conteneurs utilisées dans les environnements cloud coréens (NHN Cloud, NCP, KT Cloud), si bien qu'un FROM oven/bun:1.2 direct dans un Dockerfile peut ajouter un délai moyen de 40 à 60 secondes dans les régions coréennes. Pour cette raison, il vaut mieux la mettre en cache à l'avance dans un registre Harbor interne. Du point de vue des coûts, lorsque l'on utilise des offres facturées au temps de build comme Vercel ou Netlify, de nombreuses équipes réduisent leurs coûts mensuels de build de 20 à 30 % en passant à Bun ; il est donc plus important d'évaluer la migration sous l'angle du coût d'infrastructure que sous celui des seules performances.

Conclusion

Bun 1.2 a atteint un niveau de stabilité lui permettant d'apporter des bénéfices immédiats aux serveurs API simples, aux outils CLI et aux scripts CI/CD. Toutefois, Node LTS reste plus sûr pour les environnements avec des dépendances complexes à des modules natifs ou un APM d'entreprise obligatoire. Pour les nouveaux projets, Bun est un bon choix ; pour les projets existants, une migration progressive est recommandée.

Référence : Bank of Korea Economic Statistics

Questions fréquentes (FAQ)

Q1. Est-il acceptable de migrer un projet Node.js vers Bun 1.2 ?

A: Après avoir vérifié la compatibilité des tests et des outils de build, il est préférable de migrer progressivement, en commençant par les outils CLI ou les serveurs de développement.

Q2. À quel point Bun est-il plus rapide que Node.js ?

A: Il est plus rapide pour l'installation, les tests et certaines tâches d'exécution, mais les performances réelles de l'application doivent être mesurées pour chaque charge de travail.

Q3. Quelle est la vérification la plus importante lors d'une migration vers Bun ?

A: Vous devez d'abord vérifier la compatibilité des paquets, les modules natifs, les lockfiles, l'environnement CI et les résultats des tests.

Q4. Puis-je utiliser Bun et npm ensemble ?

A: C'est possible, mais si les lockfiles et les outils d'installation sont mélangés, la reproductibilité peut en souffrir ; des règles d'équipe sont donc nécessaires.

Q5. Le runtime Bun convient-il à la production ?

A: Il peut convenir à des API ou outils simples, mais les services centraux nécessitent une planification de la réponse aux incidents et une validation de compatibilité.

Q6. Quel est le meilleur domaine à migrer vers Bun en premier ?

A: Commencez par des workflows de développement faciles à annuler, comme l'exécution de scripts, les tests et l'installation de paquets.