Deno rejoint Cloudflare : deux échéances pour vos applications

Le 9 octobre 2026, l’équipe Deno a annoncé rejoindre Cloudflare. Pour une entreprise qui utilise ses outils, la nouvelle comporte deux échéances à distinguer. Dans son annonce signée Ryan Dahl, Deno prévoit encore six mois de fonctionnement pour Deno Deploy avant son arrêt, et une année de correctifs mensuels pour le runtime avant la fin de son développement par l’équipe. Le logiciel restera open source. Ces délais commencent avec l’annonce ; la page ne fournit pas de date de fermeture précise à l’heure près.

Le runtime est le logiciel qui exécute une application : la documentation Deno le présente pour JavaScript, TypeScript et WebAssembly. Deno Deploy fournit, lui, un service d’hébergement. Une application peut donc utiliser le logiciel Deno sur un serveur appartenant à un autre fournisseur. Quant à JSR, il s’agit d’un registre où sont distribués des composants logiciels. Son fonctionnement doit continuer, avec un transfert d’infrastructure vers Cloudflare annoncé par Deno. Ces trois éléments appellent des décisions différentes.

Retrouver la dépendance derrière la page

Votre nom de domaine indique l’adresse utilisée par vos visiteurs. Il ne révèle pas tous les services nécessaires au site. Un formulaire, un calcul ou un échange avec un catalogue peut appeler une application hébergée ailleurs. Pour savoir si vous êtes concerné, demandez à la personne qui maintient le site de localiser chaque usage de Deno : exécution sur votre hébergement, application sur Deploy ou composants récupérés depuis JSR. Une réponse écrite associant le service, son rôle et son responsable évite de confondre les échéances.

Prenons un exemple hypothétique : le site d’un distributeur présente ses produits dans WordPress, puis interroge une petite application sur Deno Deploy pour afficher un délai fournisseur. Les pages pourraient rester accessibles après l’arrêt de cette application, tout en perdant une information utile à la commande. Changer l’hébergement WordPress ne déplacerait pas automatiquement cette application. Il faudrait retrouver son code, son accès aux données et l’adresse appelée par le site, puis préparer sa reprise dans un environnement compatible.

Dans une autre configuration, le même calcul utilise le runtime Deno sur un serveur déjà administré pour l’entreprise. Le sujet porte alors sur le maintien du logiciel et sur les adaptations à prévoir, plutôt que sur la fermeture de Deploy. Garder le code disponible permet d’étudier une reprise ; continuer à recevoir des corrections suppose aussi un mainteneur identifié. Une future continuation communautaire doit être évaluée sur ce qu’elle propose effectivement.

Faire préciser la reprise avant de fixer la bascule

Deno annonce un accompagnement des clients payants de Deploy vers Cloudflare Workers. L’annonce ne détaille pas toutes ses modalités : faites confirmer votre éligibilité, les opérations couvertes et la part restant à votre prestataire. Un accès gratuit ne doit pas être traité comme la preuve du même accompagnement. Le texte commun de Cloudflare et Deno présente également un chantier pour faciliter l’auto-hébergement du modèle Workers. C’est une direction de développement ; elle ne démontre pas que votre application dispose déjà d’un transfert prêt à l’emploi.

Pour préparer la décision, faites décrire un parcours complet et son résultat attendu. Dans le cas du délai fournisseur, choisissez une référence fictive avec une donnée connue. Sur une copie de test, vérifiez que la nouvelle application renvoie cette donnée, que la page l’affiche au bon endroit et qu’une réponse absente produit un message compréhensible. Ce dernier cas compte : un délai manquant ne doit pas devenir silencieusement une disponibilité certaine.

Le calendrier de reprise doit prévoir la récupération des données, les essais et le changement de l’adresse appelée par le site. Demandez aussi quelle application répondrait si la bascule devait être annulée. Si des informations évoluent pendant la transition, précisez quelle copie fait référence et comment les différences seraient rapprochées. Une simple date de transfert laisse ces décisions ouvertes.

Gardez enfin une fiche courte par dépendance : usage concerné, responsable, échéance confirmée et prochain contrôle. Vous pourrez ainsi préparer en priorité le service qui doit changer d’hébergement, puis traiter le devenir du runtime dans son propre calendrier. Les durées annoncées donnent un temps de préparation ; attendre leur dernier jour réduirait les possibilités d’essai et de correction.