Couvrez votre runtime JavaScript : le guide du CTO après le repli de Bun

La prise en charge de Bun est limitée et dépréciée à certains endroits. Deno vient de livrer une nouvelle grosse version. Les fournisseurs edge resserrent puis desserrent sans cesse les limites de ressources. Si votre backend part du principe qu’un seul runtime JavaScript restera stable des années, vous pratiquez le verrouillage fournisseur à la dure. Vous avez besoin d’une couverture côté runtime — non pas parce que vous voulez changer, mais parce que vous voulez le droit de changer sans un trimestre de reprise.

Pourquoi c’est crucial maintenant

Trois manchettes des dernières semaines devraient recalibrer votre modèle de risque :

• La volatilité des runtimes est réelle. Deno 2.8 est sorti ; belle vélocité et rappel utile que les écosystèmes non‑Node évoluent vite et changent leurs valeurs par défaut.
• Le support peut disparaître. La prise en charge de Bun est désormais limitée ou dépréciée dans plusieurs outils : votre CI ou votre hébergeur peuvent tout simplement cesser de garantir la compatibilité.
• Les fournisseurs changent de cap. L’annulation par Microsoft de certaines licences d’outils d’IA est un autre domaine, mais la même leçon : quand vous louez des capacités, votre feuille de route hérite du risque de politique externe.

Vous pouvez garder la vitesse du JavaScript moderne tout en isolant votre cœur de métier de la volatilité des runtimes. L’astuce : adopter une stratégie sous‑ensemble portable + adaptateur, mesurer le surcoût (il existe), et acheter une option : la capacité de pivoter en semaines, pas en trimestres.

Le registre des risques runtime du CTO

Mettez des chiffres en face de ces modes de défaillance avant de choisir un runtime (ou de doubler la mise sur un seul) :

• Dérive d’API : ESM vs. CommonJS, Web APIs standard vs. modules uniquement Node, différences subtiles sur streams, crypto et timers.
• Limites d’exécution : isolats edge avec plafonds mémoire de 128–256 Mo vs. conteneurs Node avec 512 Mo–1 Go ; quotas de temps CPU et horloges murales par requête qui varient selon le fournisseur.
• Addons natifs : tout ce qui requiert Node-API ou des variantes libc spécifiques (glibc vs. musl) vous ancre. Passer entre AWS Lambda, conteneurs et isolats devient un exercice de rebuild.
• Verrouillage de la chaîne d’outillage : un test runner, un bundler ou un package manager spécifiques au runtime peuvent transformer une « petite » migration en réécriture complète du pipeline.
• Pièges liés aux licences : embarquer des dépendances transitives AGPL dans des composants serveur peut vous contraindre à divulguer le code source — surface distincte mais adjacente à surveiller quand vous expérimentez de nouveaux runtimes et forks.

Notez la probabilité et le rayon d’impact de chacun pour vos workloads principaux. Si le rayon d’impact est « API paiements à l’arrêt » ou « impossible de déployer un correctif sécu », couvrez‑vous.

Le cadre de décision : choisissez par charge de travail, pas par effet de mode

Un seul runtime ne conviendra pas à tout. Faites correspondre vos types de workloads au bon modèle d’exécution, puis appliquez une discipline de portabilité là où cela compte.

1) Requête/réponse sans état, critique en latence

• Exemples typiques : rendu edge, A/B routing, personnalisation, frappe de jetons d’auth, adaptateurs simples.
• Cible : isolats edge ou serverless léger qui implémentent le jeu d’APIs Web WinterCG (fetch, Request/Response, Web Crypto, URL, Web Streams).
• Discipline : ESM‑only, pas de modules intégrés Node (http, net, tls), éviter fs, pas d’addons natifs ; garder le code pur et avec peu de dépendances.
• Pourquoi : les démarrages à froid sont souvent de quelques millisecondes sur des isolats ; latence plus faible pour l’utilisateur ; efficacité de mise à l’échelle supérieure. Vous sacrifierez les sockets et l’I/O fichier — acceptez‑le.

2) Tâches avec état ou traitements par lots avec E/S

• Exemples typiques : ETL, traitement média, génération de PDF, workers de file, webhooks longue durée, intermédiation de modèles d’IA.
• Cible : Node.js LTS dans des conteneurs ou en serverless avec des ressources généreuses (et idéalement des sidecars GPU si besoin).
• Discipline : placer toutes les pièces non portables (fs, addons natifs, Headless Chrome) derrière une interface étroite pour pouvoir les extraire en service plus tard.
• Pourquoi : vous avez besoin de sémantiques stables pour fichiers/réseau, d’une mémoire prévisible et d’un debugging mûr. Ici, le débit prime sur la latence de queue.

3) Outils développeur et CLIs

• Exemples typiques : générateurs de projets, scaffolding interne, scripts de migration.
• Cible : Deno ou Bun peuvent être excellents, notamment pour la facilité de distribution et la vitesse.
• Discipline : ne laissez pas les choix de runtime des outils fuir vers vos bibliothèques de production. Gardez les libs de prod agnostiques au runtime.
• Pourquoi : vous pouvez changer le runtime d’un CLI avec peu d’impact client ; c’est un terrain sûr pour exploiter des ergonomies à la pointe.

Le sous‑ensemble portable : partez d’abord des standards Web

L’essentiel de la couverture vient de l’appui sur les APIs vers lesquelles tous les runtimes modernes convergent. Priorisez ceci :

• fetch / Request / Response : primitives universelles client/serveur HTTP. Dans Node 18+, fetch est intégré ; ailleurs il est de première classe. Évitez les modules http/https de Node.
• Web Crypto (SubtleCrypto) : utilisez digest, sign, verify et génération de clés standard ; évitez les polyfills crypto liés à des sémantiques propres à Node.
• URL et URLSearchParams : n’utilisez pas de parseurs maison.
• TextEncoder / TextDecoder et Web Streams : préférez les transform streams aux types de streams spécifiques à Node ; l’interop s’améliore entre runtimes.
• ESM‑only : pas de CommonJS. Exports conditionnels si nécessaire, mais n’introduisez pas de require dynamique.

Chaque fois que vous êtes tenté d’importer un builtin Node, arrêtez‑vous et demandez : existe‑t‑il une voie compatible WinterCG ? Sinon, cela peut‑il vivre derrière une frontière ?

Anti‑patterns qui tuent la portabilité

• S’appuyer sur fs pour du stockage temporaire dans du code destiné à l’edge/serverless. Utilisez du stockage objet via fetch ; ou un cache en mémoire avec taille bornée.
• Addons natifs pour compression, opérations image ou crypto quand il existe des alternatives WASM ou JS de haute qualité. Si vous devez utiliser du natif, isolez‑le.
• Des Node Streams partout. Migrez vers Web Streams pour les pipelines requête/réponse.
• Polyfiller Buffer globalement ou d’autres globals Node. Préférez des imports explicites et des utilitaires portables.
• SSR qui suppose des APIs Node pour les lectures de fichiers, la résolution de chemins ou les sockets réseau. Gardez le rendu pur ; alimentez‑le en données via fetch.

Votre couche d’adaptation : le plus petit périmètre pour le plus grand retour

Créez un unique package interne qui exprime vos besoins étroits et spécifiques au runtime. Surface typique :

• kv.get/set/delete : adossé à Redis dans Node, à un KV provider à l’edge, ou à un stockage d’objets durable.
• secrets.get(name) : se mappe à process.env dans Node, aux bindings d’environnement à l’edge, et à un magasin chiffré en local.
• scheduler.delay(fn, ms) : utilise setTimeout dans Node, les alarmes du fournisseur en edge, et une solution de repli no‑op en tests locaux.
• storage.put/get : client fetch compatible S3 ; jamais de fs brut pour des chemins portables.

Écrivez ensuite deux à quatre implémentations concrètes : Node, Edge, et tout hébergeur spécial dont vous dépendez. Votre code applicatif importe l’interface, pas l’hôte.

Tests de conformité : rendez la dérive visible

La portabilité sans matrice de tests, c’est du théâtre. Ajoutez un job qui exécute vos tests unitaires et d’intégration sur ces cibles :

• Node.js : LTS courant et précédent (pour 2026, pensez 20.x et 22.x).
• Deno : stable courant (2.x). N’utilisez son mode de compat Node que dans les tests d’adaptateur, pas dans le code applicatif.
• Bun : épinglez une version reconnue comme bonne pour l’outillage dev et les adaptateurs ; échouez rapidement si les sémantiques diffèrent.
• Émulateur edge : émulateur d’isolats local (type Miniflare) pour valider vos hypothèses Web API.

Conditionnez les fusions à cette matrice pour les bibliothèques qui doivent rester portables. Attendez‑vous à un surcoût de 10–15 % sur le temps de build et à des refactors occasionnels. C’est moins cher qu’une migration forcée sous la pression d’un incident.

Réalité des performances

Les chiffres varient selon le fournisseur et l’app, mais la forme du compromis est fiable :

• Démarrage à froid : l’edge à base d’isolats se réveille souvent en quelques millisecondes ; les fonctions Node serverless génériques sont typiquement à quelques dizaines à centaines de millisecondes selon runtime et mémoire.
• Mémoire : les isolats edge sont souvent limités à ~128–256 Mo par requête ; les conteneurs/fonctions Node offrent 512 Mo et plus.
• Temps CPU : l’edge impose des plafonds serrés par requête ; les conteneurs vous donnent un CPU stable, plus favorable aux transforms en streaming et tâches CPU‑bound.

Ne choisissez pas un runtime pour « gagner des benchmarks ». Choisissez‑le pour respecter un SLO clair : latence P95, débit, et coût par 1 000 requêtes. Puis utilisez votre adaptateur pour placer chaque fonction dans le bon tiers d’exécution.

Sécurité et conformité : elles n’attendent pas vos runtimes

La couverture runtime est aussi un jeu de sécurité :

• SBOM prêts pour SSA/CSA : générez et stockez des SBOM par build et par runtime. Si un CVE touche une transitive propre à Node, vous pouvez basculer plus vite vers une variante sûre pour l’edge.
• Analyse de licences : ajoutez une étape qui signale AGPL, SSPL ou des licences non validées dans le code exécuté côté serveur. Les controverses publiques récentes autour de violations AGPL sont des avertissements, pas des notes de bas de page.
• Discipline des secrets : pas de bricolages dotenv‑only ; votre adaptateur doit centraliser l’accès aux secrets et rendre explicites local vs. prod.

Équipes et processus : préserver la vélocité tout en vous couvrant

Brazil compte 750 k+ développeurs et un vivier profond de talents Node/TypeScript. La plupart n’ont pas encore livré Deno ou Bun en prod — et c’est très bien. Les compétences de portabilité dont vous avez besoin s’enseignent en quelques semaines :

• Semaines 1–2 : formez‑vous aux Web APIs (fetch, Web Crypto, Web Streams) et aux pratiques ESM‑only ; éliminez CommonJS dans le nouveau code.
• Semaines 3–4 : introduisez le pattern d’adaptateur ; migrez un service non critique pour l’utiliser.
• En continu : maintenez un profil de lint « agnostique au runtime » et imposez‑le en PR sur les packages portables.

Le coût : tablez sur une baisse de 5–10 % de la vélocité brute des features pour les équipes qui possèdent des modules portables. Le bénéfice : quand vous devez pivoter de runtime, vous économisez typiquement 4–6 semaines de travail de migration ponctuel et évitez un gel risqué.

Votre plan de couverture runtime sur 90 jours

Jours 0–30 : inventaire et frontières

• Inventoriez tous les appels spécifiques au runtime (builtins Node, addons natifs, polyfills globaux). Étiquetez par criticité et remplaçabilité.
• Définissez votre sous‑ensemble portable et codifiez‑le dans des règles de lint. ESM‑only pour tout nouveau code.
• Montez un petit package adaptateur et implémentez les versions Node et Edge pour kv, secrets, scheduler, storage.
• Ajoutez un job de tests de conformité au CI sur Node LTS et un runtime alternatif. Faites échouer les modules neufs (greenfield) qui dérivent.

Jours 31–60 : premier portage et observabilité

• Migrez un endpoint sensible à la latence vers le sous‑ensemble portable et déployez‑le sur un runtime edge en parallèle de votre chemin Node. Basculez 1–5 % du trafic et mesurez.
• Migrez un worker batch pour isoler les deps natives derrière l’adaptateur. Si impossible, consignez‑le comme dette technique délibérée avec plan de sortie.
• Instrumentez des tags runtime/version/région dans chaque ligne de log et trace. Bâtissez des dashboards SLO par runtime.

Jours 61–90 : étendre et faire respecter

• Porter 30–50 % de vos endpoints requête/réponse qui respectent les contraintes edge ; laissez le reste sur Node.
• Durcissez l’adaptateur (tests de chaos entre implémentations, timeouts, backoffs). Documentez‑le comme une API publique.
• Faites de la matrice de conformité un garde‑fou de merge pour toute bibliothèque destinée à être réutilisée entre services.

Arbitrages et quand dire non

Se couvrir n’est pas gratuit. Dites non à la portabilité quand :

• Vous avez réellement besoin de fonctionnalités propres à Node ou au natif et qu’il n’existe pas d’alternative réaliste (ex. : rendu PDF haute fidélité avec Headless Chrome). Gardez‑le dans un service borné.
• Le code est jetable (script de migration ponctuel). Préférez la vitesse et supprimez‑le après usage.
• Votre équipe est sous forte pression de livraison. Limitez la couverture à l’adaptateur et au linting ; planifiez le reste au cycle suivant.

Sinon, achetez l’option. Aujourd’hui c’est le support Bun qui vacille ; demain ce peut être un changement de facturation ou une capacité de plateforme dont vous avez soudain besoin et que votre runtime actuel ne peut pas offrir.

À quoi ressemble un bon résultat dans six mois

• Vous pouvez exécuter des bibliothèques critiques sur Node LTS et au moins un runtime alternatif sans autre changement de code que le binding d’adaptateur.
• Vos SLO sont par runtime, et vous avez des graphes prouvant où l’edge gagne et où Node gagne.
• Vous avez zéro colle runtime non différenciée en dehors de l’adaptateur ; tout le reste est de la logique métier.
• Les développeurs privilégient d’abord les Web APIs. La revue de code capte instantanément les imports uniquement Node.

Cette posture vous donne du levier face aux fournisseurs, moins de surprises à 2 h du matin, et un vivier de recrutement qui puise dans l’énorme marché TypeScript (dont 6–8 heures de chevauchement US/Brazil) sans enfermer les ingénieurs dans un coin.

Points clés

• Ne misez pas votre backend sur la seule bienveillance d’un runtime JavaScript. Achetez l’option de changer avec un sous‑ensemble portable et une couche d’adaptation.
• Choisissez les runtimes par workload : edge pour les chemins stateless purs en latence, Node LTS pour l’I/O intensif et les tâches longue durée, runtimes à la pointe pour les outils/CLIs.
• Appuyez‑vous sur les standards Web (fetch, Web Crypto, Web Streams, URL) et l’ESM‑only ; évitez les modules propres à Node dans le code portable.
• Faites tourner une matrice de conformité sur Node LTS et au moins un runtime alternatif ; bloquez les merges des bibliothèques partagées qui dérivent.
• Attendez‑vous à une taxe de vélocité de 5–10 % pour la portabilité ; elle rembourse 4–6 semaines de migration quand un pivot devient nécessaire.
• Centralisez secrets, storage, kv et scheduling dans un petit adaptateur ; traitez‑le comme un produit avec tests et docs.

Auteur : Diogo Hudson Dias