L'essentiel
Deno en tant que produit indépendant a désormais une date de fin. Le 9 octobre 2026, Ryan Dahl et Kenton Varda, de Cloudflare, ont annoncé que toute l'équipe Deno rejoint Cloudflare. Deno Deploy, la plateforme hébergée, fonctionnera encore six mois puis fermera. Le runtime Deno recevra pendant un an des versions mensuelles avec correctifs et mises à jour de sécurité, après quoi le développement officiel s'arrêtera. Le code reste open source : la communauté pourra le reprendre.
La nouvelle mission de l'équipe : faire tourner le modèle de programmation de Cloudflare Workers partout, y compris sur vos propres serveurs. Pour la plupart des clients de Deno Deploy, la voie pratique est une migration vers Workers, et Cloudflare promet d'accompagner les clients payants.
Qu'ont annoncé Cloudflare et Deno ?
Dans un billet commun, Dahl et Varda expliquent que l'équipe Deno travaillera à étendre le modèle Workers à davantage d'environnements. Le plan concret : intégrer le code et les idées de Celld dans workerd, le runtime open source qui fait déjà tourner Cloudflare Workers en production. Celld a été conçu comme un binaire Rust unique dont la seule dépendance externe est un stockage objet ; il peut donc être auto-hébergé sans le réseau de Cloudflare.
L'annonce de Deno précise le sort de ses produits. Deno Deploy dispose de six mois avant sa fermeture. Le runtime passe en maintenance : des versions mensuelles avec correctifs et patchs de sécurité pendant un an à compter de l'annonce, puis plus de développement officiel. JSR reste en ligne et migre vers l'infrastructure de Cloudflare. TechCrunch et The New Stack ont rapporté l'opération les 9 et 10 octobre, en notant que les conditions n'ont pas été dévoilées.
Pourquoi Cloudflare veut-il Deno ?
L'enjeu, c'est le modèle de programmation, pas la marque du runtime. Deno Deploy et Workers se disputaient les mêmes clients du serverless en périphérie, et Celld a montré que Deno pouvait proposer le modèle Workers sans Cloudflare. En internalisant ce travail, Cloudflare obtient une offre officielle d'auto-hébergement pour Workers et Durable Objects. C'est un argument pour les clients qui apprécient le modèle mais ne peuvent pas exécuter toutes leurs charges sur le réseau d'un tiers, par exemple à cause d'exigences de localisation des données ou d'hébergement sur site. Varda présente l'open source et une « porte de sortie » comme un bon calcul commercial ; Dahl veut faire du modèle Workers une manière standard de construire des serveurs.
Ce que cela change pour les équipes logicielles aux États-Unis et dans l'UE
D'abord, c'est une sortie de fournisseur avec une échéance. Tout ce qui tourne sur Deno Deploy doit trouver un nouvel hébergement en six mois : code, variables d'environnement, tâches planifiées, données KV, domaines personnalisés et TLS. Traitez-le comme toute fin de vie de plateforme : inventorier ce qui y tourne, choisir la cible et planifier une bascule avec plan de retour arrière, plutôt que d'attendre les dernières semaines.
Ensuite, un runtime en maintenance est une question de sécurité. Passé le délai d'un an, un runtime Deno sans correctifs officiels sera plus difficile à justifier lors d'audits SOC 2, ISO 27001 ou NIS2, où un logiciel non supporté est un écart classique. Les équipes qui auto-hébergent Deno devraient inscrire dès maintenant la date de fin de support dans leur registre des risques et décider si elles s'appuieront sur un fork communautaire, passeront à Workers via workerd ou porteront leur code vers Node.js, avec lequel Deno visait déjà la compatibilité.
Enfin, le modèle Workers auto-hébergé pourrait changer les choix d'architecture edge. Si workerd hérite de la simplicité d'auto-hébergement de Celld, le même code pourrait tourner sur le réseau de Cloudflare aux États-Unis et sur vos propres serveurs dans une région européenne. C'est intéressant pour les charges réglementées de la FinTech et de la HealthTech, mais il s'agit d'un projet, pas encore d'un produit livré. Ne bâtissez pas votre architecture dessus avant une version avec une exploitation documentée.
Quelles conséquences pour le marché français ?
En France, Deno Deploy servait surtout à des start-up, des agences et des équipes produit pour des fonctions edge, des webhooks et de petites API, souvent hors du contrat cloud principal. Le rachat relance aussi le débat sur la souveraineté : Workers reste une plateforme américaine, soumise au droit américain, alors que les données sensibles du secteur public et de la santé s'orientent vers des offres qualifiées SecNumCloud par l'ANSSI ou des hébergeurs HDS. Pour ces charges, la piste réaliste à court terme est Node.js en conteneurs chez un hébergeur européen ; la version auto-hébergée de Workers sera à réévaluer quand elle existera vraiment.
Le cas illustre surtout l'importance de la réversibilité, terme que les directions achats et juridiques françaises connaissent bien. Les entités financières soumises au règlement DORA doivent disposer de stratégies de sortie documentées et testées pour les prestataires TIC qui soutiennent des fonctions critiques ou importantes, et une fermeture annoncée avec six mois de préavis est précisément le scénario qu'elles doivent couvrir. Le règlement européen sur les données (Data Act), applicable depuis septembre 2025, encadre de son côté le changement de fournisseur de services cloud. Concrètement : inscrivez la migration dans votre plan de réversibilité et mettez à jour vos contrats de sous-traitance RGPD (article 28) avec le nouveau prestataire.
Que doivent faire les utilisateurs de Deno maintenant ?
- Inventorier les projets Deno Deploy. Lister chaque projet, ses domaines, ses variables d'environnement, ses tâches planifiées et les données stockées dans Deno KV, ainsi que son responsable.
- Choisir une cible par charge de travail. Le code de traitement des requêtes basé sur les API standard du web se porte généralement vers Workers avec des changements modestes. Le code qui dépend d'API propres à Deno ou de processus longs trouvera souvent mieux sa place sur Node.js en conteneurs.
- Planifier d'abord la migration des données. Déplacer les données KV et les fonctionnalités avec état prend plus de temps que déplacer le code. Exportez tôt et testez les restaurations.
- Figer et suivre le runtime. Pour un Deno auto-hébergé, figez une version, suivez les versions de sécurité mensuelles et inscrivez la date de fin de support dans votre registre des risques.
- Vérifier les dépendances JSR. JSR reste en ligne, mais assurez-vous que votre CI résout toujours les paquets après la migration d'infrastructure, et conservez un fichier de verrouillage (lockfile).
Questions fréquentes
Cloudflare rachète-t-il Deno ?
Oui. Le 9 octobre 2026, Deno et Cloudflare ont annoncé que toute l'équipe Deno, y compris les cofondateurs Ryan Dahl et Bert Belder, rejoint Cloudflare. Les conditions financières n'ont pas été communiquées.
Quand Deno Deploy va-t-il fermer ?
Selon Deno, Deno Deploy restera en service six mois à compter de l'annonce du 9 octobre 2026 avant de fermer, soit vers avril 2027. Les clients payants bénéficient d'une aide à la migration vers Cloudflare Workers.
Le runtime Deno est-il abandonné ?
Pas immédiatement. Deno publiera pendant un an des versions mensuelles avec correctifs et mises à jour de sécurité. Ensuite, le développement officiel s'arrêtera, mais le runtime reste open source et la communauté pourra le poursuivre.
Que devient JSR ?
JSR, le registre de paquets JavaScript créé par l'équipe Deno, reste en service. Son infrastructure migre chez Cloudflare.
Faut-il migrer vers Cloudflare Workers ou vers Node.js ?
Cela dépend de la charge. Le code de traitement des requêtes basé sur les API standard du web se porte généralement vers Workers avec des changements modestes. Le code qui repose sur des API propres à Deno, des processus longs ou beaucoup d'état local est souvent plus simple à migrer vers Node.js en conteneurs. Décidez service par service, pas pour toute l'entreprise.
Sources
Deno — Deno is joining Cloudflare
Cloudflare — Deno joins Cloudflare (Ryan Dahl and Kenton Varda)
TechCrunch — Cloudflare acquires Deno to improve its Workers programming model
The New Stack — Cloudflare acquires Node.js creator’s startup that copied its serverless playbook