L'arrivée de l'équipe Deno chez Cloudflare a été annoncée le 9 octobre 2026 par Ryan Dahl, fondateur de Deno, sur le blog officiel de Deno, et Cloudflare a confirmé le plan le même jour dans un article de son propre blog. Ce n'est pas un simple mouvement de talents : pendant que toute l'équipe change de maison, le service d'hébergement de Deno, Deno Deploy, entre dans un compte à rebours avant fermeture, et le runtime autonome entame sa dernière année de maintenance officielle.
Ce qui manque vraiment à Cloudflare : des Durable Objects auto-hébergeables
Cloudflare a décrit la lacune avec une franchise inhabituelle dans son article du même jour. Son runtime open source workerd partage son code avec la production, mais son implémentation des Durable Objects est limitée à une seule instance : suffisante pour des tests locaux, incapable de passer à l'échelle en auto-hébergement. Le système de routage d'objets que Cloudflare utilise en production dépend, lui, de centaines de points de présence et d'une pile de services externes, ce qui le rend mal adapté au centre de données d'un client. Celld, publié par l'équipe Deno en août 2026, comble précisément ce vide : c'est une implémentation open source de Workers et des Durable Objects, pensée dès le départ pour l'auto-hébergement et le passage à l'échelle horizontale. Ryan Dahl et Bert Belder vont désormais piloter l'intégration du code et des idées de celld dans workerd, afin de faire de l'auto-hébergement une voie de premier plan pour le modèle de programmation Workers ; d'autres détails sont promis dans les prochains mois.
Deux comptes à rebours : six mois pour Deploy, un an pour le runtime
Pour les équipes qui utilisent Deno aujourd'hui, le calendrier compte plus que la vision. Deno Deploy fonctionnera encore six mois, puis fermera, avec un accompagnement à la migration vers Cloudflare Workers pour les clients payants. Le runtime Deno recevra encore pendant un an des correctifs mensuels de bugs et de sécurité, après quoi l'équipe d'origine cessera son développement ; le code reste open source et la communauté pourra le reprendre. Le registre de paquets JSR continue de fonctionner, son infrastructure déménage chez Cloudflare, et le composant rusty_v8 sera maintenu, avec l'objectif de l'intégrer à workerd. En comptant six mois, les services encore sur Deploy vers avril 2027 devront avoir migré d'ici là, et cette fenêtre a commencé le jour de l'annonce.
Pourquoi les développeurs d'agents suivent aussi ce dossier
Dahl a explicitement visé le scénario des agents dans son annonce : les Durable Objects réunissent dans un seul objet une exécution serverless peu coûteuse, un état persistant et des connexions WebSocket, soit un socle proche de ce qu'exigent les harnais d'agents de longue durée, et il a invité les équipes qui construisent des agents à grande échelle à le contacter directement. L'endroit où se consolide la couche d'exécution détermine directement la structure de coûts et les frontières de déploiement des produits d'agents, alors que le trafic des agents a déjà dépassé celui des humains. Si Workers peut tourner à l'identique sur le réseau de Cloudflare et sur les serveurs d'un client, les éditeurs d'agents n'auront plus à choisir entre la commodité de la plateforme et le fait de garder leurs données dans leur propre réseau.
Tant que les promesses ne sont pas livrées, tout cela reste toutefois une feuille de route. L'outillage autour de workerd auto-hébergé est précisément ce que Cloudflare reconnaît avoir négligé, et la capacité de l'équipe Deno à combler ce retard dépendra de ce qui sortira réellement dans les prochains mois. Pour les utilisateurs de Deno, la décision est plus simple : préparer d'abord la migration en fonction de la date de fermeture de Deploy, puis juger si le workerd auto-hébergé mérite d'être suivi.
