Le 9 octobre 2026, Ryan Dahl a publié un billet court au titre sans détour : « Deno is joining Cloudflare ». Toute l’équipe Deno rejoint Cloudflare. Le runtime lancé en 2018 par le créateur de Node.js entre donc en fin de vie programmée. Si vous avez du Deno en production, un script interne ou un projet publié sur JSR, voici ce que l’annonce change concrètement et ce qu’elle ne change pas.
Plan de l'article
Ce qui a été annoncé #
Le billet officiel de Deno pose le cadre en une phrase : « Today we’re announcing that the entire Deno team is joining Cloudflare to take that work further. » L’équipe explique avoir décidé de mettre tout son développement futur dans une plateforme commune avec Cloudflare, au lieu de maintenir son propre runtime et son propre service d’hébergement.
Côté Cloudflare, le billet cosigné par Ryan Dahl et Kenton Varda résume l’objectif : « radically simplify self-hosting Workers and Durable Objects ». Autrement dit, rendre simple le fait de faire tourner le modèle de programmation Workers sur sa propre infrastructure, et plus seulement sur le réseau de Cloudflare.
À lire Windows 10 : non, l’ESU ne s’arrête pas ce 13 octobre 2026 — vous êtes couverts jusqu’en 2027
Le runtime Deno : un an de correctifs, puis l’arrêt #
C’est le point qui concerne le plus de monde. Deno ne disparaît pas du jour au lendemain. Le runtime reçoit encore un an de versions mensuelles, limitées aux corrections de bugs et aux mises à jour de sécurité. Ensuite, le développement officiel s’arrête.
Le code reste ouvert. L’équipe l’écrit noir sur blanc : « Deno will remain open source, and we welcome others who want to continue its development. » Un fork communautaire est donc possible, mais rien n’est annoncé à ce stade. En pratique, il faut considérer Deno comme une techno en maintenance : plus de nouvelles fonctionnalités, plus d’alignement sur les nouveautés du langage au-delà de ce qui est déjà livré.
Ce que ça implique pour un projet existant
Un an, c’est confortable pour un script ou un outil interne. C’est court pour une application en production avec des dépendances qui vont continuer d’évoluer. Le bon réflexe est de faire l’inventaire maintenant : quels services tournent sur Deno, lesquels utilisent des API propres à Deno (Deno.serve, Deno.Kv, les permissions), et lesquels se contentent d’API web standard.
Les seconds migrent bien plus facilement. Un handler qui reçoit une Request et renvoie une Response tourne déjà, à peu de choses près, sur Node.js récent, Bun ou Workers. Ce qui coûte, ce sont les spécificités : les permissions en ligne de commande, le stockage clé-valeur intégré, ou les imports par URL sans gestionnaire de paquets.
À lire Installer Git : Guide Complet 2026 – Tutoriel
Deno Deploy : six mois avant la fermeture #
Le service d’hébergement Deno Deploy a un délai plus serré. Selon le billet de Deno, il reste en service six mois, puis il ferme. Les clients payants auront un accompagnement pour migrer vers Cloudflare Workers. Aucune date d’arrêt précise n’est donnée au-delà de ce délai.
Si vous avez une fonction ou un petit site sur Deploy, c’est le chantier prioritaire. Deux voies existent : passer sur Workers, puisque c’est la destination prévue, ou rapatrier le code sur un runtime auto-hébergé. Le choix dépend surtout de l’usage du stockage intégré et de votre envie de rester chez un hébergeur unique.
JSR continue #
Bonne nouvelle pour les auteurs de paquets : le registre JSR n’est pas concerné par l’arrêt. Il continue de fonctionner et son infrastructure passe chez Cloudflare. Les paquets publiés restent accessibles et le flux de publication ne change pas.
celld et workerd : le vrai sujet technique #
Pour comprendre le rachat, il faut regarder celld. Deno a publié cet été une plateforme open source bâtie sur le modèle de Cloudflare Workers, avec un accent sur les Durable Objects. Cloudflare a de son côté workerd, le runtime open source de Workers.
À lire VCS Version Control : Guide Développeur 2026
Le plan annoncé est de fusionner les deux : le code et les idées de celld seront réintégrés dans workerd. Ryan Dahl et Bert Belder, les deux cofondateurs de Deno, pilotent un chantier pour faire de l’auto-hébergement de workerd une option pleinement supportée.
Le point technique précis concerne les Durable Objects. Le billet de Cloudflare reconnaît que workerd ne les gère aujourd’hui que sur une seule instance, ce qui limite la montée en charge. La version distribuée issue de celld doit combler ce manque. Cloudflare promet d’autres détails « dans les prochains mois ».
Notre lecture #
Ryan Dahl avait créé Deno pour corriger les choix de Node.js qu’il regrettait. Huit ans plus tard, il range son runtime pour pousser un autre modèle : des serveurs écrits comme des Workers, avec un état distribué géré par la plateforme. C’est un pari sur le modèle de programmation plutôt que sur le runtime.
Pour les équipes, la conséquence est simple. Le paysage des runtimes JavaScript serveur se resserre autour de Node.js, de Bun et de workerd. Ceux qui misaient sur Deno pour sa sécurité par permissions ou son outillage tout-en-un vont devoir retrouver ces garanties ailleurs. Ceux qui l’utilisaient pour ses API web standard s’en tirent à bon compte : leur code est déjà portable.
À lire Docker prune : Guide nettoyage complet
Notre conseil pratique : migrer en premier ce qui tourne sur Deno Deploy, à cause des six mois, puis traiter le runtime avant la fin de l’année de correctifs. Les deux annonces officielles, côté Deno et côté Cloudflare, restent les références à surveiller pour les dates exactes.
