L’acquisition de Deno par Cloudflare signifie que les utilisateurs de Deno Deploy doivent déplacer leurs charges de travail de production avant la fermeture du service d’hébergement, prévue vers avril 2027. Cloudflare Workers est la destination prise en charge pour les clients payants, mais la migration n’est pas automatique : les équipes doivent auditer les API de Deno, les dépendances, les variables d’environnement, la sémantique du stockage et les tests. Le runtime Deno autonome bénéficiera d’un délai plus long, tandis que JSR restera en ligne.
Qu’est-ce que Cloudflare a acquis auprès de Deno ?
Cloudflare et Deno ont annoncé le 9 octobre 2026 que toute l’équipe de Deno rejoindrait Cloudflare, sans divulguer les modalités financières. Cloudflare a qualifié l’opération d’acquisition. Les ingénieurs travailleront avec les équipes de Cloudflare Workers et de Durable Objects, notamment sur les efforts visant à combiner les projets workerd et celld.
L’acquisition de Deno par Cloudflare est avant tout une opération concernant une équipe et des technologies, et non une promesse de préserver chaque produit de Deno. Cloudflare souhaite étendre le modèle de programmation de Workers, notamment aux déploiements auto-hébergés, tandis que Deno a cité l’état persistant, les WebSockets et l’exécution serverless à faible coût pour les agents d’IA parmi ses domaines prioritaires.
Deno a également déclaré dans son annonce du 9 octobre 2026 qu’il continuerait à prendre en charge rusty_v8 et travaillerait à l’intégration du projet au runtime workerd de Cloudflare. Ces projets pourraient façonner les futurs outils pour développeurs, mais Cloudflare n’avait pas publié de calendrier d’intégration détaillé au 13 octobre 2026.
Cette distinction est importante. Les développeurs disposent d’une orientation stratégique, et non d’une garantie générale de compatibilité. Les équipes qui utilisent des dépendances générées devraient également examiner les risques de sécurité plus larges créés par les chaînes de dépendances écrites par l’IA tout en dressant l’inventaire des paquets à transférer.
Quand Deno Deploy et le runtime Deno seront-ils arrêtés ?
Deno Deploy fonctionnera pendant six mois après l’annonce du 9 octobre 2026, ce qui laisse supposer une fermeture autour du 9 avril 2027. Deno n’a pas annoncé de date d’arrêt exacte. Le runtime Deno autonome bénéficiera en revanche de mises à jour mensuelles de sécurité et de corrections de bogues pendant un an, ce qui implique un développement assuré par l’équipe actuelle jusqu’à environ le 9 octobre 2027.
Deno Deploy est la plateforme d’hébergement gérée qui exécute les applications Deno sans que les équipes aient à administrer leurs propres serveurs. Son échéance est la plus urgente : le trafic de production, les tâches planifiées, le stockage et les secrets doivent être transférés vers une solution de remplacement avant la disparition du service.
Le runtime autonome est différent. Son code source reste ouvert, et l’autohébergement sur une machine virtuelle ou dans un conteneur reste techniquement possible pendant la période de prise en charge. Après cet engagement d’un an, toutefois, l’équipe actuelle de Deno cessera de développer le runtime. Un fork communautaire pourrait voir le jour, mais aucun plan de production ne devrait miser sur cette éventualité.
| Produit | Engagement publié | Échéance pratique | Action requise |
|---|---|---|---|
| Deno Deploy | Six mois supplémentaires à compter du 9 octobre 2026 | Autour du 9 avril 2027 ; date exacte non annoncée | Transférer l’hébergement, les données, la configuration et le trafic |
| Runtime Deno | Un an de corrections mensuelles à compter du 9 octobre 2026 | Autour du 9 octobre 2027 ; dernière version exacte non annoncée | Choisir un runtime maintenu ou accepter d’en assurer soi-même la maintenance |
| Registre JSR | Continue de fonctionner après le 9 octobre 2026 | Aucune fermeture prévue en 2026 | Tester les consommateurs sur les runtimes cibles |
Un simple calcul de calendrier met le risque en évidence : une équipe qui commencerait en janvier 2027 ne disposerait que d’environ trois mois avant la date limite implicite de Deno Deploy. Prévoyez du temps pour une répétition de la migration des données et une fenêtre de retour arrière, plutôt que de considérer avril 2027 comme le début de la migration.
Vers quoi les utilisateurs de Deno Deploy doivent-ils migrer sur Cloudflare Workers ?
Les utilisateurs de Deno Deploy doivent migrer le code de l’application, la configuration, les secrets, les tâches planifiées, les connexions aux services et les données persistantes avant avril 2027 environ. Selon l’annonce de Deno en 2026, les clients payants bénéficieront d’une assistance à la migration vers Cloudflare Workers, mais aucun utilitaire public ni aucune garantie générale de conversion des charges de travail n’avaient été annoncés au 13 octobre 2026.
Commencez par un inventaire, et non par une réécriture. Le code utilisant Fetch, Request, Response, Web Crypto et les modules ECMAScript standard se transfère plus facilement. Les appels via l’ Deno.* espace de noms, l’accès au système de fichiers, les sous-processus et le modèle d’autorisations de Deno nécessitent un examen plus approfondi, car Cloudflare Workers suit un modèle d’exécution et de sécurité différent.
L’acquisition de Deno par Cloudflare modifie également la manière dont les applications reçoivent leur configuration. Le code Deno Deploy appelle généralement Deno.env.get(). Workers transmet normalement les variables, les secrets et les ressources des services via la liaison env du gestionnaire de requêtes ; process.env est disponible dans les scénarios applicables de compatibilité avec Node.js.
La documentation 2026 de Cloudflare indique que chaque environnement Wrangler doit disposer de ses propres variables et liaisons, car celles-ci ne sont pas héritées. Cette règle facile à manquer peut produire un déploiement de préproduction qui fonctionne et un déploiement de production dépourvu de ressources nécessaires.
Utilisez la séquence de migration suivante afin de conserver une visibilité sur les changements applicatifs, de données et opérationnels :
- Inventaire
Deno.*API, autorisations, appels au système de fichiers et aux sous-processus, paquets npm et JSR, variables d’environnement, secrets, tâches cron, files d’attente, bases de données et stockage d’objets. - Remplacez les appels propres à la plateforme par des interfaces contrôlées par l’application avant de choisir les services Workers équivalents.
- Créez des variables Workers pour la configuration non secrète, téléversez les valeurs sensibles en tant que secrets et déclarez séparément les liaisons dans chaque environnement Wrangler.
- Exportez les données de production, répétez les importations transformées et conservez des exports de retour arrière avant de modifier le DNS ou d’acheminer le trafic.
- Exécutez les tests unitaires, d’intégration et de dépendances dans le runtime Workers, puis utilisez du trafic miroir ou des lectures doubles lorsque la charge de travail le permet.
Cloudflare recommande son intégration Workers Vitest pour les tests unitaires et createTestHarness() pour les tests d’intégration en 2026. Les tests peuvent s’exécuter dans l’environnement Workers et solliciter directement les bindings configurés. C’est plus utile qu’une suite de tests uniquement Node.js qui ne touche jamais l’environnement cible.
Le code Deno peut-il s’exécuter sans modification sur Cloudflare Workers ?
Le code Deno peut s’exécuter sans modification sur Cloudflare Workers uniquement s’il reste conforme aux standards web compatibles et utilise des dépendances prises en charge. La documentation 2026 de Cloudflare décrit la prise en charge de Node.js par Workers comme un sous-ensemble : certaines API sont entièrement prises en charge, d’autres partiellement, et certains shims de bundler peuvent lever une exception lorsqu’ils sont appelés. Les tests au niveau des API sont donc obligatoires.
L’installation des packages mérite une attention particulière. Les packages JSR peuvent s’exécuter sur Workers grâce à la couche de compatibilité npm de JSR, mais les jsr: spécificateurs d’importation doivent généralement être convertis en dépendances installées par un gestionnaire de packages. La documentation 2026 de JSR indique que vous devez valider le fichier généré .npmrc.
La couche de compatibilité installe du JavaScript transpilé plutôt que du TypeScript natif et ne prend pas en charge la publication avec npm publish. Les mainteneurs de packages doivent continuer à utiliser jsr publish ou deno publish. JSR lui-même ne doit pas fermer ; son infrastructure sera transférée à Cloudflare.
La compatibilité des dépendances représente un risque plus important que la syntaxe. Une bibliothèque peut s’installer correctement tout en appelant une API Node.js partiellement prise en charge uniquement sous charge ou lors d’un chemin d’erreur inhabituel. Les équipes qui adoptent des assistants générant du code doivent appliquer le même examen des packages que celui présenté dans notre guide sur la manière dont les agents de programmation IA transforment le développement logiciel.
À mon avis, réécrire du code portable conforme aux standards web serait une perte de temps. Isolez d’abord les points spécifiques à l’environnement d’exécution, puis migrez une frontière à la fois. Cette approche préserve également une solution de repli si les tarifs, les limites ou l’orientation produit de Workers ne conviennent plus au service.
Comment les données Deno KV doivent-elles être transférées vers le stockage Cloudflare ?
Selon les recommandations de migration 2026 de Deno, Deno KV n’a pas de destination automatique équivalente dans Cloudflare Workers. Les équipes doivent choisir le stockage en fonction du comportement recherché : Workers KV pour les données à forte proportion de lectures et à cohérence éventuelle, Durable Objects pour l’état transactionnel fortement cohérent, D1 pour les données relationnelles basées sur SQLite, ou R2 pour les objets compatibles avec S3.
Les noms peuvent être trompeurs ici. Workers KV ne constitue pas un remplacement sémantique direct simplement parce que les deux produits contiennent « KV ». Déplacer des verrous de coordination, des compteurs ou des contrôles d’unicité vers un stockage à cohérence éventuelle peut provoquer des erreurs de correction que les tests ordinaires du parcours nominal ne révéleront pas.
Durable Objects convient davantage lorsque les données et la coordination doivent être fortement cohérentes, mais cette solution introduit des bindings propres à Cloudflare et un modèle d’état orienté objet. D1 convient aux requêtes relationnelles. R2 gère le stockage d’objets, tandis que Hyperdrive peut connecter Workers aux bases de données externes prises en charge.
Exportez d’abord. Transformez ensuite. Comparez enfin le nombre de lignes, le nombre de clés, les valeurs échantillonnées et les invariants au niveau de l’application après l’importation. Pour un stockage de 10 millions d’enregistrements en 2026, même une erreur de conversion de 0.01% signifie 1 000 enregistrements incorrects, raison pour laquelle une validation uniquement en pourcentage peut dissimuler des dommages importants.
L’auto-hébergement fondé sur des conteneurs évite une réécriture immédiate de l’application, mais transfère à votre équipe les tâches de mise à jour, de supervision et de sécurisation de l’hôte. Cet arbitrage opérationnel est particulièrement pertinent lors de l’évaluation de menaces telles que les agents malveillants ciblant les hôtes Docker.
Quelle voie de migration convient à chaque type de projet Deno ?
La réponse appropriée à l’acquisition de Deno par Cloudflare dépend du type de déploiement. Les utilisateurs de Deno Deploy ont besoin d’un hébergement de remplacement avant environ avril 2027 ; les équipes utilisant le runtime autonome disposent approximativement d’un délai jusqu’en octobre 2027 pour choisir une voie maintenue ; les éditeurs publiant uniquement sur JSR peuvent rester, mais devraient tester séparément la compatibilité avec Cloudflare Workers, Node.js et les navigateurs.
Applications Deno Deploy
Cloudflare Workers est la voie prise en charge pour les clients payants et probablement le chemin opérationnel le plus court. Toutefois, recensez chaque binding et chaque garantie de stockage avant de vous engager. L’auto-hébergement de Deno peut faire gagner du temps, mais il transforme une migration de plateforme en problème d’infrastructure et, à terme, de maintenance du runtime.
Services Deno autonomes
Figez une version connue de Deno, appliquez les versions mensuelles promises pendant la période de maintenance 2026–2027 et choisissez rapidement entre Node.js, Bun, un autre runtime maintenu ou une maintenance volontaire en interne. Placez les fonctionnalités propres à Deno derrière des adaptateurs afin que la logique métier ne dépende pas directement d’un espace de noms donné.
Éditeurs de packages JSR
Les éditeurs JSR n’ont pas besoin d’abandonner le registre. Ils doivent en revanche prévoir des tests de compatibilité distincts pour Workers, Node.js et les navigateurs, car une publication JSR réussie ne dit rien de la prise en charge des API exclusives à Deno dans un autre runtime.
La dépendance à un fournisseur n’est pas automatiquement mauvaise. Durable Objects, D1 et R2 peuvent supprimer une part importante du travail d’infrastructure. Une intégration étroite avec Cloudflare est pertinente lorsque les économies d’exploitation dépassent le coût futur du remplacement de ces bindings ; sinon, conservez le code métier central fondé sur les standards web et limitez les appels à la plateforme à des adaptateurs restreints.
Questions fréquemment posées
Cloudflare ferme-t-il JSR ?
Cloudflare ne ferme pas JSR selon les plans annoncés le 9 octobre 2026. Deno a indiqué que le registre de packages continuerait de fonctionner et que son infrastructure serait transférée à Cloudflare.
Cloudflare migrera-t-il automatiquement les projets Deno Deploy ?
Aucune migration automatique n’avait été garantie publiquement au 13 octobre 2026. Deno a promis une assistance à la migration pour les clients payants de Deno Deploy passant à Cloudflare Workers, mais les équipes doivent tout de même valider le code, les bindings, les dépendances et les données.
Les développeurs peuvent-ils continuer à auto-héberger Deno après 2027 ?
Les développeurs pourront continuer à exécuter le code open source de Deno après la fin de la période de maintenance annoncée, prévue vers octobre 2027. L’équipe actuelle de Deno ne s’est pas engagée à poursuivre le développement au-delà de cette période ; la maintenance de sécurité et la compatibilité pourraient donc dépendre de contributeurs externes.
Cloudflare Workers prend-il en charge toutes les API Node.js ?
Cloudflare Workers ne prend pas entièrement en charge toutes les API Node.js en 2026. Cloudflare documente des implémentations complètes, des implémentations partielles et des shims de bundler susceptibles de lever une exception lorsqu’ils sont appelés ; les dépendances de production nécessitent donc des tests dans le runtime.