Cloudflare absorbe Deno : le runtime indépendant change de cap

Le 9 octobre 2026, l’annonce de Deno a officialisé l’arrivée de toute son équipe chez Cloudflare, avec un an de maintenance du runtime et six mois d’exploitation supplémentaires pour Deno Deploy avant sa fermeture. Le compte rendu de TechCrunch qualifie l’opération d’acquisition et indique que ses conditions financières n’ont pas été communiquées.

Le changement touche des produits distincts : le runtime JavaScript et TypeScript restera open source, le service hébergé Deno Deploy s’arrêtera, et l’équipe désormais chez Cloudflare travaillera sur le modèle de programmation de Workers. Pour les développeurs, cette réorientation promet surtout une meilleure exécution des Workers hors du réseau de Cloudflare ; elle ne livre pas encore une plateforme unifiée ni un calendrier de migration général.

Le runtime Deno entre dans une période de maintenance

Le runtime continuera de recevoir des versions mensuelles contenant des corrections de bugs et des mises à jour de sécurité durant la période annoncée. Ensuite, l’équipe qui l’a créé mettra fin à son propre développement de Deno. La portée de cet engagement est précise : il maintient l’outil existant pendant une transition, sans promettre une nouvelle feuille de route fonctionnelle pour ce runtime.

Le code restera librement accessible et d’autres contributeurs pourront poursuivre le projet. Cette possibilité laisse une issue à la communauté, mais elle ne garantit pas que celle-ci reprendra au même rythme les choix techniques et la maintenance assurés jusqu’ici par l’équipe Deno. Les applications qui exécutent directement le runtime et celles qui dépendent de l’hébergement Deploy ne sont donc pas exposées au même changement.

Cette distinction éclaire aussi le sort de deux projets voisins. Le registre de paquets JSR continuera de fonctionner, tandis que son infrastructure passera chez Cloudflare. La prise en charge de rusty_v8 se poursuivra également et son intégration à workerd fait partie des travaux prévus. Ni le maintien de JSR ni celui de rusty_v8 ne prolongent, à eux seuls, le développement du runtime Deno par son équipe fondatrice.

Deno Deploy fermera après sa période d’exploitation

Pour les applications hébergées sur Deno Deploy, la conséquence la plus directe est l’arrêt annoncé du service. Deno prévoit une période de fonctionnement avant la fermeture et propose une aide à la migration vers Cloudflare Workers aux clients payants. La promesse porte sur un accompagnement de cette clientèle ; elle ne décrit ni transfert automatique des applications ni service Deploy maintenu sous une autre marque.

Le changement d’hébergement mérite d’être séparé de la question du code open source. Un projet peut continuer d’utiliser le runtime Deno sur une infrastructure qu’il contrôle alors que son déploiement sur le service de Deno devra prendre fin. À l’inverse, rejoindre Workers implique d’utiliser l’environnement et les primitives de ce modèle. Ce ne sont pas des trajectoires identiques pour un outil web qui combine exécution JavaScript, dépendances et hébergement.

Cloudflare Workers est la destination nommée pour l’assistance aux clients payants, mais aucune procédure universelle n’est détaillée dans l’annonce. Les modalités dépendront des fonctions effectivement utilisées par chaque application Deploy et des possibilités offertes dans l’environnement choisi. C’est sur ce point que la différence entre continuité du code et continuité d’un service hébergé devient concrète pour les équipes concernées.

La convergence de celld et workerd reste à réaliser

Ryan Dahl résume le projet dans l’annonce commune de Cloudflare : « we're merging workerd and celld! ». Le verbe désigne un chantier : il s’agit de rapprocher le code et les idées de celld du runtime open source workerd, afin que le modèle Workers puisse être exécuté plus facilement sur une infrastructure administrée par ses utilisateurs.

Les composants partent de situations différentes. workerd permet déjà l’auto-hébergement de Workers, mais sa prise en charge autonome des Durable Objects reste limitée à une seule instance, une configuration utile aux essais locaux mais insuffisante pour une application distribuée. celld vise précisément le fonctionnement réparti : plusieurs instances peuvent être exploitées avec un stockage d’objets comme dépendance externe. Le rapprochement annoncé cherche à associer cette capacité à l’implémentation de workerd.

Les Durable Objects réunissent un état persistant, une base SQLite locale et la gestion de connexions WebSocket dans un composant adressable. Cette combinaison explique leur intérêt pour des services qui conservent une conversation ou coordonnent des échanges en temps réel, comme l’exemple de messagerie décrit par Ryan Dahl. L’enjeu technique dépasse l’exécution de JavaScript ailleurs : il concerne les primitives de calcul et d’état autour desquelles une application Workers peut être construite.

Ryan Dahl et Bert Belder doivent diriger l’effort d’intégration. Cloudflare veut faire de l’auto-hébergement de workerd une option pleinement prise en charge et annonce d’autres précisions dans les mois à venir. Pour l’heure, celld et workerd peuvent être exploités séparément ; la fusion du code, les conditions exactes de prise en charge et un éventuel parcours de migration restent à préciser. C’est la forme de cette intégration qui déterminera jusqu’où une même application Workers pourra circuler entre le réseau de Cloudflare et une infrastructure gérée par son développeur.

À lire aussi :

• Cloudflare laisse l’IA chercher les failles, sans lui confier le correctif
• Sage rachète Moovin’Cloud, mais laisse son conseil cloud indépendant
• Basware rachète Trustpair : l’indépendance promise devient le vrai test