Cloudflare récupère Deno : le runtime de Ryan Dahl entre dans sa dernière année officielle

Deno rejoint Cloudflare, mais le détail important est quelques lignes plus bas

L’annonce publiée le 9 octobre 2026 pourrait presque sembler réjouissante. Toute l’équipe Deno rejoint Cloudflare, Ryan Dahl compris, pour travailler sur une nouvelle génération d’infrastructure destinée aux applications distribuées.

Cloudflare range d’ailleurs officiellement l’annonce dans la rubrique « Acquisitions », et TechCrunch décrit l’opération comme un rachat de Deno dont les conditions financières n’ont pas été communiquées.

Mais pour les utilisateurs de Deno, la partie réellement importante se trouve un peu plus bas dans l’annonce de Ryan Dahl.

Le runtime Deno continuera à recevoir une version mensuelle pendant encore un an, uniquement pour les corrections de bugs et de sécurité. Ensuite, l’équipe actuelle cessera son développement. Deno restera open source et pourra être repris par la communauté, mais ses créateurs ne promettent pas de poursuivre eux-mêmes l’aventure au-delà de cette période. Aucune date calendaire exacte n’est annoncée ; en comptant depuis le 9 octobre 2026, cela place cette échéance quelque part autour d’octobre 2027.

Et ce n’est pas tout.

Deno Deploy, le service d’hébergement associé au runtime, n’a même pas droit à cette année supplémentaire : il continuera de fonctionner pendant six mois, puis fermera. Les clients payants se verront proposer une aide pour migrer vers Cloudflare Workers. Là encore, l’annonce parle d’une durée et non d’une date précise, soit approximativement le printemps 2027 si le calendrier ne change pas.

On a connu des annonces de partenariat plus rassurantes.

Petit rappel : Deno était censé être le « Node.js sans les regrets »

Pour comprendre pourquoi cette décision fait autant réagir dans le monde JavaScript, il faut revenir rapidement à Ryan Dahl.

Ryan Dahl est le créateur original de Node.js, l’environnement qui a largement contribué à faire de JavaScript un langage utilisable côté serveur. Quelques années plus tard, il expliquera publiquement regretter plusieurs décisions prises lors de sa conception : gestion des dépendances, système de modules, sécurité, organisation des outils…

Deno apparaît en 2018 comme une tentative de recommencer sur des bases différentes.

Le runtime adopte notamment TypeScript nativement, un modèle de permissions plus strict, des outils intégrés et une forte utilisation des API Web standards. Il cherche également à réduire le nombre de petites dépendances et d’outils que les développeurs doivent assembler autour de leur projet.

Avec le temps, la promesse s’est pourtant heurtée à une réalité assez robuste : l’écosystème Node.js est gigantesque.

Deno a progressivement amélioré sa compatibilité avec npm et avec les applications Node afin que les développeurs puissent conserver leurs bibliothèques existantes. Encore en juin 2026, Deno 2.9 annonçait notamment une meilleure compatibilité avec Node.js, ainsi que de nouveaux outils pour les applications desktop et les migrations depuis npm, pnpm, Yarn ou Bun.

Autrement dit, le projet conçu en partie pour s’éloigner de Node a fini par passer une bonne partie de son énergie à mieux fonctionner avec Node.

L’informatique possède parfois un sens de l’humour particulièrement sec.

Le vrai trésor de l’opération ne s’appelle probablement pas Deno

Si Cloudflare ne récupère pas l’équipe pour poursuivre indéfiniment le runtime Deno, qu’est-ce qui l’intéresse exactement ?

Une partie de la réponse tient en cinq lettres : celld.

Ce projet développé récemment par l’équipe Deno cherche à reprendre le modèle de programmation des Cloudflare Workers et Durable Objects dans un environnement pouvant être exécuté sur sa propre infrastructure.

Cloudflare dispose déjà de workerd, le moteur open source qui alimente Workers. Les deux équipes vont maintenant fusionner les travaux de workerd et celld afin que ce modèle puisse fonctionner plus facilement ailleurs que sur le réseau Cloudflare lui-même.

La nuance est assez intéressante.

Cloudflare pourrait évidemment chercher à enfermer tous les développeurs dans son cloud. Au contraire, Kenton Varda, l’un des responsables techniques de Workers, affirme que permettre aux utilisateurs d’exécuter ce modèle sur leurs propres machines constitue justement une stratégie intéressante : plus le modèle Workers devient standard, plus Cloudflare bénéficie de son adoption générale.

Le but n’est donc plus tellement de créer un concurrent de Node.js.

Le but est de créer une manière différente de construire et exécuter des serveurs.

Et cette ambition est probablement beaucoup plus grosse.

Les agents IA sont déjà assis au milieu de la pièce

Il y a aussi un mot que Ryan Dahl ne cherche pas particulièrement à cacher : IA.

Dans son billet, il explique que le besoin de nouvelles abstractions devient particulièrement important avec les applications d’intelligence artificielle. Il cite notamment les Durable Objects comme une combinaison intéressante pour les « agent harnesses » : exécution serverless peu coûteuse, état persistant, WebSockets et interface JavaScript de haut niveau.

Traduisons cela hors de la planète cloud.

Un agent IA moderne ne fait pas seulement une requête puis disparaît. Il peut devoir conserver un état, attendre des événements, maintenir une connexion avec un utilisateur, se réveiller plus tard, coordonner plusieurs opérations et reprendre son travail exactement où il l’avait laissé.

Bref, tout ce qui devient rapidement pénible lorsqu’on construit une application distribuée classique avec quinze services, quatre bases de données et un fichier YAML suffisamment long pour devenir une œuvre littéraire.

Cloudflare pense que son modèle Workers + Durable Objects peut devenir une réponse à ce problème.

Et l’équipe Deno semble désormais penser la même chose.

C’est probablement la vraie raison pour laquelle ce changement est plus important que la simple disparition progressive d’un runtime JavaScript.

Deno Deploy ferme, JSR reste debout

Tout ne disparaît toutefois pas.

JSR, le registre de paquets lancé par Deno, continuera de fonctionner. Son infrastructure sera simplement transférée chez Cloudflare. Le projet rusty_v8, qui fournit des bindings Rust autour du moteur JavaScript V8, continuera lui aussi d’être pris en charge avec l’objectif de l’intégrer davantage à workerd.

La découpe devient donc assez claire.

Le runtime Deno : encore un an de maintenance, puis l’équipe historique passe à autre chose

Deno Deploy : extinction dans six mois

JSR : continue

rusty_v8 : continue

celld : fusionne avec workerd et devient une pièce du futur modèle Cloudflare

Difficile de ne pas y voir un démantèlement méthodique de Deno tel qu’on le connaissait, où les briques jugées utiles continuent leur chemin tandis que le produit principal est rendu à la communauté.

« Open source » ne veut pas dire « impossible à abandonner »

L’annonce rappelle également une réalité parfois oubliée lorsqu’on parle de logiciels libres.

Deno ne va pas disparaître du disque dur le jour où ses développeurs historiques arrêteront de publier des versions. Son code restera disponible. Quelqu’un pourra créer un fork, organiser une nouvelle gouvernance et continuer à développer le runtime.

Techniquement, rien n’empêche donc un « Deno Community Edition » de devenir un projet actif pendant encore dix ans.

Mais un dépôt GitHub disponible n’est pas la même chose qu’un projet activement maintenu.

Il faut corriger les failles, suivre les évolutions de V8, maintenir la compatibilité avec les systèmes d’exploitation, examiner les pull requests, publier les versions, répondre aux régressions et prendre des décisions architecturales.

Bref, il faut des humains.

Les réactions sur Hacker News ont d’ailleurs immédiatement porté sur ce point : plusieurs développeurs s’interrogent sur l’avenir des applications ayant véritablement misé sur des API spécifiques à Deno, tandis que d’autres estiment que sa proximité croissante avec Node simplifiera certaines migrations.

Le logiciel est libre.

Le temps des mainteneurs, beaucoup moins.

Cloudflare est discrètement en train d’aspirer une bonne partie du Web moderne

L’arrivée de Deno ne sort pas complètement de nulle part.

En janvier 2026, Astro Technology Company, l’équipe derrière le framework Astro, rejoignait Cloudflare. En juin, c’était au tour de VoidZero, derrière notamment Vite, Vitest, Rolldown et Oxc. Puis Deno arrive en octobre. La propre page « Acquisitions » de Cloudflare aligne aujourd’hui très clairement ces opérations.

Pris individuellement, chacun de ces mouvements peut ressembler à une acquisition de talents.

Mis bout à bout, ils commencent à dessiner quelque chose.

Vite pour construire les applications.

Astro pour créer des sites et applications web.

Les outils de VoidZero pour compiler et transformer leur code.

Workers et workerd pour les exécuter.

Durable Objects pour gérer leur état.

Et maintenant l’équipe de Ryan Dahl pour rendre une partie de cette architecture plus portable et plus facilement auto-hébergeable.

Cloudflare ne se contente donc plus de placer un CDN devant les sites des autres.

L’entreprise cherche de plus en plus à posséder — ou au minimum à influencer fortement — toute la chaîne entre le développeur qui écrit son code et la machine qui l’exécute.

C’est beaucoup plus intéressant que « Cloudflare rachète encore une startup ».

Et probablement beaucoup plus stratégique.

Pour les utilisateurs de Deno, pas besoin de paniquer demain matin

Si vous utilisez actuellement Deno pour un petit script ou une application personnelle, votre ordinateur ne va évidemment pas prendre feu en octobre 2027.

Le runtime restera disponible et open source.

Pour des applications importantes ou des services de production, la situation mérite néanmoins d’être regardée sérieusement. Une année est suffisamment longue pour évaluer les dépendances spécifiques à Deno, déterminer si une migration vers Node, Bun ou une autre solution est nécessaire, ou attendre de voir si une véritable équipe communautaire reprend le projet.

Le problème est plus urgent pour Deno Deploy : les utilisateurs disposent ici de seulement six mois selon le calendrier annoncé.

Cloudflare propose explicitement d’accompagner ses clients payants vers Workers, ce qui indique assez clairement le chemin que l’entreprise préférerait leur voir emprunter.

Personne n’a encore annoncé qu’une fondation indépendante reprendrait officiellement le runtime après 2027. Et tant qu’une telle structure n’existe pas, considérer que « la communauté continuera forcément » serait aller beaucoup trop vite.

Open source ne signifie pas auto-régénérant.

Même avec JavaScript.

Deno perd peut-être sa bataille, mais certaines de ses idées ont déjà gagné

Il serait néanmoins un peu facile de conclure que Deno a simplement échoué.

Depuis son apparition, le projet a poussé toute une partie de l’écosystème JavaScript vers davantage d’outillage intégré, une meilleure prise en charge de TypeScript, des permissions plus explicites et une utilisation accrue des API Web standards.

Même Node.js a énormément évolué pendant cette période.

Bun est également arrivé avec la promesse d’un environnement plus intégré et plus rapide, signe que l’idée même d’un runtime JavaScript accompagné de son propre ensemble d’outils est désormais parfaitement normale.

Deno n’a peut-être pas réussi à remplacer Node.

Mais il a participé à modifier ce que l’on attend d’un runtime moderne.

Et Ryan Dahl change encore une fois de problème.

Après avoir essayé de réinventer le serveur JavaScript, il veut désormais participer à la construction d’un modèle où l’application, son état et son exécution peuvent se déplacer plus facilement entre le cloud et une infrastructure privée.

Le nom Deno pourrait donc progressivement disparaître des nouveautés.

Ses idées, elles, vont probablement continuer à circuler.

Simplement avec un petit nuage orange derrière.