Cloudflare rachèterait Deno : le runtime n'a plus qu'un an de support

Une annonce, une seule source pour l’instant

Le 9 octobre 2026, Simon Willison a relayé sur son blog une nouvelle qui a dû faire tousser quelques fichiers deno.json : Cloudflare rachèterait Deno dans sa totalité. Son billet renvoie à l’annonce publiée par Cloudflare sur son propre blog. À l’heure où nous écrivons, c’est pourtant la seule source dont nous disposons, d’où le conditionnel dans la suite.

Cloudflare ne viserait pas Deno lui-même, mais celld. L’équipe de Deno a sorti la première version de ce projet en août : c’est une implémentation open source du modèle des Durable Objects de Cloudflare Workers. Cloudflare voudrait s’en servir pour faire de l’auto-hébergement de workerd une façon pleinement prise en charge de construire et de faire tourner des applications avec le modèle de programmation des Workers.

Un an de maintenance, puis le rideau

C’est là que ça pique. D’après l’annonce reprise par Willison, Cloudflare maintiendrait le runtime Deno encore un an, avec une version par mois limitée aux corrections de bugs et aux mises à jour de sécurité. Ensuite, Cloudflare arrêterait son développement. Deno resterait open source, et l’entreprise dit accueillir volontiers ceux qui voudraient le poursuivre.

Pour les équipes qui font tourner Deno en production hors de Cloudflare, cela veut dire douze mois de correctifs, rien d’autre d’annoncé, puis un dépôt dont l’avenir dépendra d’une communauté qui ne s’est pas encore déclarée. Le moment est venu de vérifier si votre code s’appuie sur des spécificités de Deno ou s’il tournerait ailleurs sans drame. Une migration prévue sur un an, c’est confortable. La même migration découverte à cause d’une faille que personne ne corrige, beaucoup moins.

Le pourquoi, vu par le créateur

Ryan Dahl, qui a créé Deno puis Node.js, a expliqué dans un commentaire sur Hacker News que la décision a été prise en commun et qu’il la soutient. Son constat est franc : Deno est bien conçu et porte de bonnes idées, mais il ne résout pas de gros problèmes. Le projet aurait été happé par la compatibilité avec Node, qui l’oblige à se comporter exactement comme lui. Sa phrase, en version originale : « Why reimplement Node? It works. » Selon lui, de petits gains en performance, en ergonomie ou en sécurité ne suffisent pas.

Ce qui l’intéresse désormais, c’est celld. D’après lui, le projet fonctionne remarquablement bien en ne s’appuyant que sur un stockage objet pour la coordination et la persistance. Il y voit un modèle entièrement nouveau de développement serveur, pas une API à peine différente pour parler au disque ou au réseau. L’ironie se passe d’explication : le runtime né pour faire mieux que Node a fini par devoir l’imiter trait pour trait.

Ce que vous perdez vraiment

Willison cite la fonctionnalité qu’il regrettera : le système de permissions de Deno. Il permet de lancer un script en indiquant précisément les fichiers et dossiers qu’il peut lire ou écrire, et les hôtes réseau qu’il peut contacter.

Node.js a un modèle comparable. Il est arrivé avec la v20.0.0 en avril 2023 et a été déclaré stable avec la v22.13.0 en janvier 2025. Il ne sait toutefois pas encore autoriser des hôtes réseau précis : chez Node, le réseau est soit ouvert, soit fermé. Si vous isoliez vos scripts au nom de domaine près, un passage à Node vous fera perdre ce niveau de précision.

Deno voulait être un Node mieux conçu, et il lui reste un an pour trouver une communauté prête à le prouver. Les autres peuvent déjà inscrire la date dans leur calendrier de migration.