Cloudflare acquiert Deno : ce qui ferme, ce qui reste, et quand

Cloudflare acquiert Deno : le runtime passe en maintenance

Le 9 octobre 2026, Cloudflare a annoncé l’acquisition de Deno Land, la société derrière le runtime JavaScript/TypeScript Deno. L’objet réel de la transaction n’est pas le runtime : Cloudflare a acheté l’équipe et celld, une implémentation open source des Workers et Durable Objects publiée par Deno en août 2026. Le runtime lui-même passe en maintenance et Deno Deploy ferme dans six mois. JSR et rusty_v8 continuent.

Ce que Cloudflare a acheté – et pourquoi

Kenton Varda, ingénieur principal sur Cloudflare Workers, a expliqué l’intérêt de celld : cette bibliothèque rend le modèle de programmation Workers auto-hébergeable et scalable sur des infrastructures indépendantes, une capacité que Cloudflare voulait intégrer dans son propre runtime open source workerd sans l’avoir finalisée. Ryan Dahl et le cofondateur Bert Belder mèneront le travail de fusion de celld dans workerd.

Le runtime Deno n’est pas au cœur du deal. L’acquisition ne garantit pas sa continuité et n’engage pas Cloudflare à le faire évoluer. Ce point change la lecture de tout ce qui suit.

Les échéances produit par produit

Produit Statut actuel (oct. 2026) Avril 2027 Octobre 2027 Après octobre 2027
Runtime Deno Maintenance (bugs + sécurité) Maintenance Développement officiel arrêté Open source, repreneur incertain
Deno Deploy Actif, migration conseillée Fermeture vers le 9 avril 2027 Fermé Fermé
JSR Actif, infrastructure Cloudflare Actif Actif Actif (gouvernance indépendante)
rusty_v8 Maintenu, intégration workerd prévue Maintenu Maintenu Intégré à workerd
Fresh / Deno Subhosting Avenir non confirmé Inconnu Inconnu Inconnu

Ce que ça change selon votre usage

Vous utilisez Deno Deploy. L’échéance est dure : fermeture vers le 9 avril 2027. Cloudflare propose une assistance à la migration vers Workers, mais uniquement pour les clients payants – les utilisateurs sur un plan gratuit n’en bénéficient pas selon les annonces officielles. Si vous avez des charges de travail hébergées sur Deno Deploy, planifier la migration maintenant est la seule option qui laisse une marge confortable.

Vous utilisez le runtime seul, sans Deno Deploy. Vous avez jusqu’en octobre 2027 pour décider. Le runtime reçoit des correctifs de bugs et des mises à jour de sécurité mensuelles pendant cette période. Au-delà, voir la section suivante.

Vous dépendez de JSR. Aucune action requise. La gouvernance indépendante de JSR a été actée en février 2025 ; son infrastructure migre vers Cloudflare mais son fonctionnement n’est pas remis en cause.

Vous utilisez Fresh ou Deno Subhosting. Aucune des deux annonces officielles ne mentionne ces outils. Il vaut mieux ne pas planifier de migration avant d’avoir un signal concret, mais surveiller les communications de Deno Land et Cloudflare dans les prochaines semaines.

Après octobre 2027 : un runtime sans repreneur annoncé

Le projet Deno reste open source après la fin de la période de maintenance. L’équipe invite d’autres développeurs à en poursuivre la maintenance. À ce jour, aucune organisation ne s’est engagée publiquement à le faire – Forbes, Linuxiac et Heise convergent sur ce point.

Le contexte aide à comprendre pourquoi la situation est arrivée là. Ryan Dahl a expliqué que Deno avait été entraîné à répliquer le comportement de Node.js, au point de ne plus laisser de place aux nouvelles abstractions qu’il voulait construire. L’accord avec Cloudflare lui permet de travailler sur celld et workerd sans ce poids. Ce glissement vers la compatibilité Node.js explique aussi en partie pourquoi la base de contributeurs capables de reprendre le runtime dans sa forme actuelle reste incertaine.

Dépendre d’un projet open source sans mainteneur actif est un risque mesurable. Ce n’est pas une impossibilité – des projets survivent à leurs créateurs – mais ce n’est pas non plus une garantie, et aucun signal concret ne permet de trancher aujourd’hui.


Trois options restent ouvertes après lecture : migrer vers Cloudflare Workers maintenant pour sortir de l’incertitude, attendre octobre 2027 en restant sur le runtime avec des correctifs de sécurité, ou rester sur le runtime open source au-delà de cette date en acceptant consciemment l’absence de repreneur confirmé.