17 juillet 2026
•
G
Chez Streamfizz, notre plateforme repose sur un écosystème de services qui, depuis les débuts de l'aventure, parlaient tous le même langage : JavaScript (puis TypeScript), exécuté par Node.js. Ces trois derniers mois, nous avons migré la quasi-totalité de cette infrastructure vers un nouveau venu : Bun.js. Voici le récit de ce pari technologique - pourquoi nous l'avons pris, comment nous l'avons mené brique par brique, ce que nous y avons gagné, et ce qui reste perfectible.
Petit retour en arrière. Node.js est né en 2009, créé par Ryan Dahl. Son idée fondatrice : sortir JavaScript du navigateur et en faire un langage serveur, en s'appuyant sur le moteur V8 de Google et sur une architecture non-bloquante capable d'encaisser des dizaines de milliers de connexionas simultanées. Avec l'arrivée de npm en 2010 et de son gigantesque écosystème de paquets, Node.js est devenu en quelques années le runtime backend JavaScript - au point que la question ne se posait même plus.
Quand Streamfizz s'est construit, choisir Node.js n'était donc pas vraiment un choix : c'était l'évidence, faute d'alternative crédible. Et soyons honnêtes, Node.js nous a bien servis. Mais un runtime conçu en 2009 traîne aussi son histoire : un outillage éclaté (un gestionnaire de paquets par-ci, un bundler par-là, un test runner ailleurs) et TypeScript qui nécessite une étape de compilation.
La première alternative sérieuse est venue... du créateur de Node.js lui-même. En 2018, Ryan Dahl présente Deno dans une conférence devenue culte, « 10 Things I Regret About Node.js ». Sur le papier, Deno corrigeait tout ce qui nous agaçait : TypeScript exécuté nativement, sécurité par défaut, un seul exécutable pour tout faire.
Nous l'avons regardé de près. Deno assumait à ses débuts une rupture volontaire avec l'écosystème Node : pas de compatibilité npm ni de node_modules, des imports par URL façon navigateur. Deno 2 a depuis largement corrigé le tir en ajoutant la compatibilité npm - mais pour migrer des services Node.js existants, des frictions bien réelles demeurent : une couverture encore partielle des APIs node:*, des bibliothèques qui s'appuient sur les entrailles de Node à auditer (voire remplacer) une par une, des scripts d'installation npm bloqués par défaut, et un modèle de permissions à configurer pour chaque déploiement. Ce sont d'excellentes qualités pour démarrer un projet neuf orienté sécurité... et autant de coûts quand il s'agit de migrer une plateforme existante. Trop de contraintes, trop de refactoring, pour un gain incertain : notre regard s'est tourné ailleurs.
En septembre 2023, Bun.js 1.0 est annoncé. Créé par Jarred Sumner au sein de la société Oven, écrit en Zig et propulsé par JavaScriptCore (le moteur de Safari) plutôt que V8, Bun.js prenait le problème dans l'autre sens : compatibilité Node.js d'abord, performance ensuite, et un outil unique pour tout faire - runtime, gestionnaire de paquets, bundler, test runner.
Les chiffres annoncés donnaient le vertige : un démarrage jusqu'à 4 fois plus rapide que Node.js, un bun install qui installe les dépendances plus de 15 fois plus vite que Yarn, un test runner 13 fois plus rapide que Jest. Et surtout, la promesse de faire tourner notre code TypeScript existant sans le réécrire.
C'est cette combinaison - vitesse spectaculaire + migration indolore - qui nous a séduits. Miser sur un runtime aussi jeune pour une infrastructure de production restait néanmoins un pari : nous avons choisi de l'aborder prudemment, brique par brique.
Comme souvent, nous avons commencé par la brique la moins risquée : notre nouveau back-office client, une application Next.js. Ici, Bun.js remplace à la fois Yarn (installation des dépendances) et Node.js (exécution du build).
Le gain le plus immédiat, chronomètre en main : **yarn install** prenait 58 secondes, **bun install** en prend 17. Sur un projet où l'on installe les dépendances des dizaines de fois par semaine (CI, environnements de test, postes des développeurs), ce n'est pas anecdotique. Le build de production est lui environ deux fois plus rapide.
Et c'est tout - et c'est une bonne nouvelle. Aucune incidence sur l'application elle-même, ni positive ni négative : le site que voient nos utilisateurs est strictement identique. Cette première migration nous a surtout appris que la compatibilité promise était réelle, et nous a donné confiance pour attaquer des briques plus sensibles.
Au cœur de Streamfizz, deux services travaillent main dans la main pour encoder vos vidéos : l'orchestrateur, le cerveau qui reçoit les demandes et distribue le travail, et les transcodeurs, les bras armés qui convertissent chaque vidéo en multiples qualités via FFmpeg. Nous leur avons consacré un article complet si vous voulez plonger dans les détails.
Deux choses nous ont longtemps retenus de les migrer.
La première : ces services communiquent via des files d'attente BullMQ, et la compatibilité de BullMQ avec Bun.js a été un long feuilleton. L'issue GitHub ouverte à ce sujet - trois jours seulement après la sortie de Bun.js 1.0 - n'a été fermée qu'en janvier 2026, avec un laconique « All tests are passing perfectly with BunJs now ». Nous faisions partie de ceux qui suivaient (et relançaient discrètement) cette issue depuis des mois. Sa fermeture a été notre feu vert.
La seconde : le stockage. Une précision importante avant d'aller plus loin : nos vidéos sont hébergées en France chez Scaleway, pas chez Amazon. « S3 » désigne ici un protocole de stockage devenu un standard de l'industrie, que Scaleway implémente - la technologie vient d'AWS, pas vos données. Or pour dialoguer avec ce stockage, nos transcodeurs utilisaient historiquement l'AWS CLI, l'outil en ligne de commande officiel... écrit en Python. Notre image Docker devait donc embarquer Python, pip et toute une chaîne de dépendances juste pour uploader et télécharger des fichiers vidéo. Un extrait (abrégé) de notre ancien Dockerfile donne une idée du fardeau :
C'est là que Bun.js a abattu sa carte maîtresse : depuis la version 1.1.43 (janvier 2025), le runtime intègre un client S3 natif, annoncé jusqu'à 5 fois plus rapide que le SDK AWS officiel sur Node.js. Plus aucune dépendance à installer : uploader une vidéo de plusieurs gigaoctets tient en quelques lignes, multipart géré automatiquement, sans jamais charger le fichier en mémoire :
Au passage, la migration a fait tomber d'autres pans entiers : l'étape de compilation TypeScript a disparu (Bun.js exécute le TypeScript directement), la bibliothèque fluent-ffmpeg a été remplacée par Bun.spawn natif, et Express par Bun.serve.
Les gains :
node_modules, lui, est toujours là) ;Le revers, car il y en a un : la progression des transferts. L'AWS CLI affichait une progression détaillée ; le client S3 natif de Bun.js, lui, ne fournit aucun callback de progression sur write(). Nous avions d'abord contourné le problème avec une boucle manuelle qui streamait le fichier morceau par morceau pour compter les octets - mais elle créait de la pression mémoire sur les gros fichiers. Nous avons fini par trancher : sur le transcodeur, l'upload délègue tout à Bun.js (rapide, sobre en mémoire) et nous avons accepté de perdre la progression fine à l'envoi ; le téléchargement, lui, conserve sa progression par octets via un stream manuel.
Un signal de poids est d'ailleurs venu conforter ce choix : Anthropic, l'entreprise derrière Claude, a acquis Bun.js en décembre 2025 - Bun.js restant open source sous licence MIT, avec la même équipe aux commandes. Le runtime porté hier par une petite startup devenait la fondation d'un des outils de développement les plus utilisés au monde : de quoi lever les derniers doutes sur sa pérennité.
Restait le morceau le plus sensible : notre backend principal, celui qui porte toute la logique métier de la plateforme. Même recette, mêmes effets : exécution directe du TypeScript, disparition de l'étape de build, et une image Docker passée d'environ 400 Mo à environ 150 Mo - plus de Node, plus de Python, plus d'AWS CLI, plus de SDK AWS (quatre paquets @aws-sdk/* supprimés d'un coup). Même la suite de tests a profité du grand ménage : plus besoin de Jest ni de sa configuration, nous utilisons désormais bun test, le test runner intégré au runtime.
Le backend manipule lui aussi énormément de fichiers sur notre stockage Scaleway, et les gains sur les opérations S3 sont similaires à ceux du transcodeur. Mais il a une particularité : c'est lui qui orchestre les uploads multipart pilotés depuis votre navigateur - quand vous déposez une vidéo de plusieurs gigaoctets sur Streamfizz, elle est découpée en morceaux envoyés en parallèle directement vers le stockage. Et sur ce terrain, le client S3 natif de Bun.js ne suffit pas encore. Nous avons donc gardé le client MinIO pour une poignée d'opérations précises, chacune correspondant à une limitation connue et documentée de Bun.js :
partNumber/uploadId à une URL presignée (#16048), et pas d'API multipart manuelle (initier l'upload, envoyer les morceaux, finaliser) - Bun.js ne propose que le multipart automatique côté serveur ;CopyObject du protocole S3, qui duplique un fichier d'une clé à une autre sans jamais le faire transiter par nos serveurs - sans équivalent natif à ce jour ;Le tout est centralisé derrière une façade unique dans notre code : chaque opération S3 passe par le client le plus adapté, et le jour où Bun.js comblera ces manques, la bascule se fera en un point. Ici aussi, la progression d'upload a demandé un contournement : Bun.S3File.write() n'offrant aucun callback, nous pilotons manuellement un writer par morceaux quand une barre de progression est nécessaire.
Au-delà de nos services principaux, nous créons régulièrement des projets annexes - des POC, des outils de gestion interne, des expérimentations. Pour tous ces projets, le réflexe a changé : nous partons désormais sur Bun.js par défaut, et à ce jour aucune contrainte réelle ne nous a bloqués.
La meilleure illustration, c'est notre dernier-né : Streamfizz Roquette, notre moteur de streaming live construit sur nos serveurs en France, tourne entièrement sur Bun.js. Serveur HTTP, base de données SQLite embarquée, pilotage des processus FFmpeg, streaming de fichiers, S3 : tout est fourni nativement par le runtime, avec seulement cinq dépendances externes. Un projet de cette ambition avec si peu de dépendances, c'était tout simplement impensable dans le monde Node.js d'il y a trois ans.
Trois mois après le début de cette migration, le bilan est sans appel : des installations trois fois plus rapides, des builds deux fois plus rapides, des images Docker deux fois plus légères, des transferts de vidéos accélérés - et un outillage unifié qui simplifie la vie de l'équipe au quotidien. Le tout sans réécrire notre code, et sans le moindre impact négatif pour nos utilisateurs.
Et il faut bien l'avouer : nous sommes assez fiers d'avoir eu le nez creux. Miser sur une technologie encore jeune mais qui avait clairement le vent en poupe, et voir ce choix confirmé quelques mois plus tard par son adoption massive et par l'un des plus gros acteurs de l'IA, c'est le genre de validation qui ne se refuse pas.
Ce pari illustre notre façon de construire Streamfizz : adopter tôt les technologies qui servent concrètement la performance et la simplicité, sans jamais sacrifier la fiabilité - vos vidéos restent hébergées en France, sur une infrastructure que nous maîtrisons de bout en bout, et que nous rendons chaque année plus rapide et plus sobre.
GGeoffrey Signorato
Lead développeur
Publié le 17 juillet 2026
Mis à jour le 17 juillet 2026
Demandez une démonstration personnalisée dès aujourd'hui.
TTeam StreamfizzOBS Studio est le logiciel de streaming gratuit de référence. Puissant, flexible et open source, il permet de créer des diffusions en direct pro, sans dépenser un centime.
TTeam StreamfizzBien choisir son encodeur pour la diffusion en live streaming : Un match fou entre Logiciels et Matériels ( Spoiler : ça finit en match nul)