Fermeture de Deno Deploy : ce que votre migration doit démontrer

La fermeture de Deno Deploy impose deux décisions distinctes à une startup : où son application sera hébergée et qui assurera la maintenance de son environnement d’exécution. Deno a annoncé six mois supplémentaires de fonctionnement pour Deploy et une année de correctifs mensuels pour les bugs et la sécurité du runtime. Avant de basculer le trafic de production, démontrez que la solution de remplacement préserve les comportements dont dépendent vos clients. L’annonce de Deno du 9 octobre précise ces deux périodes distinctes.

Une page d’accueil qui s’affiche sur Workers constitue un premier résultat utile. Cela ne prouve pas qu’une session reste privée, que des écritures concurrentes restent correctes ou qu’une bascule ratée peut être annulée. Ce sont ces tests qui doivent déterminer si la migration est prête.

Cet article propose un cadre de validation aux responsables techniques dont l’application dépend déjà de Deno. Les exemples ci-dessous sont des tests proposés, pas des résultats de migrations clients ni la promesse que toutes les applications peuvent suivre le même parcours.

Quelle échéance de Deno concerne votre application ?

L’échéance d’hébergement concerne Deno Deploy ; celle de maintenance concerne le runtime Deno. Déterminez les dépendances réelles de l’application en production avant de planifier les travaux.

Dans son annonce du 9 octobre, Deno indique que toute son équipe rejoint Cloudflare. Deploy fonctionnera pendant six mois avant sa fermeture. Le runtime recevra des correctifs mensuels de bugs et de sécurité pendant encore un an, puis l’équipe cessera son développement ; il restera open source. JSR continuera, avec une infrastructure transférée chez Cloudflare. Une aide à la migration vers Workers est proposée aux clients payants. Ces engagements ne précisent ni une date et une heure de fermeture, ni le périmètre contractuel de l’aide pour un client donné, ni l’équipe qui reprendra la maintenance du runtime. Confirmez ces points directement lorsque vous préparez la bascule.

Une application peut utiliser le runtime sans utiliser Deploy. Une chaîne de compilation qui exécute deno task n’est pas exposée de la même manière qu’une API dont les requêtes sont traitées sur Deploy. Un service tiers peut aussi utiliser un runtime compatible avec Deno : Supabase décrit ainsi ses Edge Functions, auxquelles s’ajoutent sa propre passerelle et les intégrations de sa plateforme. Cela ne fait pas de Supabase un client de Deploy et ne lui impose pas l’échéance de fermeture de Deploy.

Pour chaque parcours de requête en production, notez l’hébergeur qui le prend en charge et le runtime qui l’exécute. Identifiez ensuite les données ou les tâches planifiées qui dépendent de Deploy. Il s’agit de retracer brièvement les dépendances de l’application examinée. La seule présence d’une configuration Deno dans un dépôt ne suffit pas.

La documentation peut aussi vous orienter vers la mauvaise échéance. Le guide de migration existant de Deno décrit le passage de Deploy Classic à Deno Deploy. Sa destination n’est pas Workers. La présentation de Deploy conserve également un ancien avis de fermeture de Classic. Ces deux pages documentent cette transition antérieure ; elles ne constituent pas les instructions complètes de migration liées à l’annonce d’octobre 2026.

Si les deux échéances vous concernent, validez la solution de remplacement pour l’hébergement avant la fermeture. Traitez séparément la décision sur la maintenance du runtime, y compris pour les exécutables Deno encore utilisés dans les compilations ou les tâches internes après le déplacement du service public.

Choisissez une destination selon les comportements qu’elle préserve

La bonne destination est celle qui réussit les tests de validation de l’application et que l’équipe sait exploiter. Une annonce d’acquisition ne tranche pas ce choix.

Le tableau suivant aide à choisir les premières pistes à examiner. Ses exigences sont des recommandations techniques ; les engagements des fournisseurs restent ceux de leurs annonces.

L’annonce de Cloudflare décrit des travaux futurs associant celld et workerd, ainsi que la prise en charge de l’auto-hébergement. Elle reconnaît aussi que l’implémentation actuelle des Durable Objects dans workerd est limitée à une seule instance et que l’outillage associé est incomplet. Cela limite les conclusions que l’on peut tirer de cette orientation.

Pour une équipe qui envisage sa propre infrastructure, la responsabilité de son exploitation constitue une question distincte. Notre article sur les effectifs et les responsabilités de l’auto-hébergement traite ce choix. Ici, la question immédiate est de savoir si la destination choisie réussit les tests de l’application.

Testez les parcours exécutés, l’authentification et les tâches en arrière-plan

Un test de migration doit solliciter les comportements susceptibles d’échouer sur la destination. Une compilation réussie et des codes HTTP identiques ne constituent qu’une partie des preuves.

Commencez par un petit dispositif de test en préproduction capable d’envoyer les mêmes requêtes représentatives à l’application actuelle et à la solution envisagée. Utilisez des données synthétiques et des identifiants de test distincts. Fixez l’état initial pour pouvoir interpréter les comparaisons, puis consignez les différences voulues, comme le nom d’hôte ou les identifiants générés.

La documentation Deno sur la compatibilité Node et npm concerne l’exécution d’applications Node dans Deno. Elle ne prouve pas qu’un code utilisant les API Deno peut s’exécuter ailleurs sans modification. Pour Workers, la documentation sur la compatibilité Node.js distingue les API implémentées, les fonctionnalités partiellement prises en charge et les implémentations factices non fonctionnelles. Un import peut réussir alors qu’un appel ultérieur échoue.

Recensez explicitement les parcours rarement utilisés : export de rapports, transformation de pièces jointes, fonction de rappel d’authentification ou tâche qui accède au système de fichiers ou lance un sous-processus. Ne retenez que les fonctionnalités utilisées par l’application. Exécutez l’opération réelle de la dépendance au lieu de vérifier uniquement que son module se charge. Consignez précisément la configuration de destination et la date de compatibilité pour qu’un résultat positif corresponde à un environnement reproductible.

Pour le comportement HTTP, comparez les corps des réponses, les en-têtes, les redirections et les cookies lorsqu’ils font partie du contrat. Incluez les entrées malformées, les sessions expirées et les requêtes non autorisées. Pour un service cloisonné par compte, attribuez à deux comptes synthétiques des données de structure similaire et tentez d’accéder aux données de l’autre compte. Une réponse qui contient la donnée attendue mais aussi celles d’un autre compte doit faire échouer le test.

Si l’application planifie des tâches ou les place dans une file, testez-les séparément. Par exemple, faites accepter une requête, interrompez le processus de traitement avant la fin, puis relancez la livraison de la tâche. Vérifiez l’état obtenu et l’effet externe, avec un destinataire de test plutôt que la boîte e-mail d’un vrai client. Vérifiez que la personne chargée d’intervenir peut détecter l’échec. Une requête réussie ne prouve pas que sa tâche différée s’est exécutée.

Consignez chaque résultat pour qu’un autre ingénieur puisse le remettre en question : état initial, action, résultat attendu, résultat observé et trace pertinente. Lorsqu’une fonctionnalité est absente, marquez le critère « non applicable » et expliquez pourquoi. Une longue liste de contrôles cochés sans explication apporte moins de preuves que quelques tests liés à de véritables modes de défaillance.

Deno KV et Workers KV exigent des tests de validation différents

Des noms de stockage proches ne garantissent pas des comportements équivalents pour les transactions ou les lectures. Si la justesse de l’état dépend de Deno KV, rendez cette dépendance explicite avant de choisir le stockage de remplacement.

La documentation sur les transactions Deno KV décrit un contrôle optimiste de la concurrence. Les lectures renvoient des marqueurs de version, ou versionstamps ; une opération atomique peut vérifier des paires clé/versionstamp en même temps qu’elle applique des modifications. La validation ne réussit que si les versions vérifiées correspondent encore. Les applications qui utilisent ces vérifications doivent gérer les conflits et décider s’il faut réessayer.

La documentation de Workers KV décrit un stockage à cohérence à terme dont les modifications peuvent mettre 60 secondes ou plus à apparaître ailleurs. Elle déconseille de compter sur une visibilité immédiate, même là où l’écriture a eu lieu, et indique que KV n’est pas idéal pour les opérations atomiques ni pour les lectures et écritures transactionnelles. Elle oriente les lecteurs ayant besoin d’une cohérence plus forte vers Durable Objects.

Il s’agit d’une limite de compatibilité précise, pas d’un jugement défavorable à Workers. Un cache et une contrainte d’unicité peuvent exiger des stockages différents, même au sein d’une seule application. Choisir un autre composant de stockage Cloudflare impose aussi de tester ses garanties réelles et votre implémentation ; son nom ne suffit pas à fournir le comportement manquant.

Supposons qu’une application Deno vérifie l’absence d’une clé d’invitation, puis crée atomiquement l’invitation et son entrée de correspondance associée. Un portage naïf qui effectue une lecture suivie d’écritures indépendantes peut réussir tous les tests séquentiels. Testez plutôt deux requêtes concurrentes pour la même invitation. Le résultat attendu pourrait être une invitation acceptée, un conflit et une entrée de correspondance cohérente. Définissez ce résultat à partir du contrat existant avant d’écrire la solution de remplacement.

Un deuxième scénario teste la visibilité. Créez une autorisation synthétique, révoquez-la, puis tentez immédiatement l’action protégée depuis une autre zone géographique. Précisez si la révocation doit s’appliquer immédiatement ou si le produit autorise un délai. Le résultat de validation porte sur cette exigence de sécurité, pas sur le succès renvoyé par l’API de stockage.

Pour l’expiration, créez une donnée de courte durée et vérifiez l’accès juste avant et juste après son échéance. Incluez une absence précédemment mise en cache si la visibilité d’une création compte. Pour les listes ordonnées, restaurez assez de clés synthétiques pour tester les hypothèses de pagination et de tri de l’application. Lorsque les versionstamps servent de curseurs ou de métadonnées applicatives, définissez le fonctionnement de ces références après conversion ; ne les remplacez pas discrètement par les horodatages de destination.

Repérez les tests trompeurs avant d’autoriser la bascule

Un test trompeur réussit sans avoir sollicité la condition qu’il prétend vérifier. Examinez la conception des tests avec autant de soin que le code de remplacement.

Un émulateur local peut valider la logique sans reproduire la distribution de production. Des requêtes envoyées depuis une seule machine peuvent manquer un problème de visibilité qui touche un autre emplacement. Des requêtes séquentielles ne démontrent pas la sûreté des accès concurrents. Une base vide ne révèle pas une erreur de conversion des anciennes données. Ajoutez la condition précise qui manque au lieu de répéter davantage le même test superficiel.

Surveillez aussi les erreurs masquées. Une erreur de dépendance peut être interceptée et transformée en résultat vide. Le point d’accès renvoie 200, mais l’export a perdu des lignes. Vérifiez le contenu de la sortie et le comportement attendu en cas d’erreur. Pour les tests de nouvelle tentative, comptez l’effet final, pas seulement les requêtes acceptées.

La duplication du trafic pour comparaison exige des précautions. Rejouez des requêtes expurgées avec des données isolées et remplacez les destinations des e-mails, paiements et webhooks par des récepteurs de test. Une écriture de production dupliquée peut produire un deuxième effet externe. Décidez à l’avance quelles comparaisons peuvent s’effectuer en lecture seule et lesquelles nécessitent un scénario de préproduction maîtrisé.

La validation doit aussi couvrir l’exploitation. Provoquez une panne reconnaissable en préproduction, puis demandez à quelqu’un de la diagnostiquer à partir des journaux et alertes de destination. Vérifiez que les identifiants appartiennent au bon environnement et que les instructions de reprise fonctionnent pour la personne appelée à intervenir. Même correcte, une application reste difficile à rétablir sous pression si les traces de ses pannes sont inaccessibles.

Démontrez le retour arrière avec des écritures et une réconciliation des données

Le retour arrière n’est terminé que lorsque l’ancienne application peut reprendre avec un état correct. Inverser le routage du trafic n’annule pas les écritures acceptées par la destination.

Deno documente les sauvegardes KV vers un stockage compatible S3 contrôlé par le client et leur utilisation avec l’outil denokv. C’est une possibilité d’export et de reprise à examiner. Elle ne convertit pas automatiquement les données vers Workers KV, D1 ou une autre destination.

Restaurez une sauvegarde représentative dans un environnement isolé. Comparez les données pertinentes, le comportement d’expiration et les relations, pas seulement le nombre d’objets. Consignez la date jusqu’à laquelle la sauvegarde couvre les données et identifiez les écritures acceptées ensuite. Une sauvegarde lisible à laquelle manquent des transactions récentes ne suffit pas pour le retour arrière prévu.

Simulez ensuite une panne après que la solution envisagée a accepté de nouvelles écritures. Suspendez les écritures suivantes ou maîtrisez-les autrement, capturez les modifications acceptées par la destination, puis réconciliez-les avec le système qui redeviendra la référence. Définissez le traitement des doublons, des modifications contradictoires, des suppressions et des tâches interrompues. Utilisez les identifiants applicatifs et des règles de réconciliation explicites ; « tout recopier dans l’ancien système » laisse ces questions sans réponse.

Pour un petit service, une suspension planifiée des écritures peut rendre l’opération maîtrisable. Un service qui ne peut pas suspendre les écritures a besoin d’un mécanisme testé de capture des modifications ou de réplication. Les doubles écritures introduisent leurs propres défaillances : un côté peut réussir alors que l’autre échoue. Simulez ce cas avant de considérer les doubles écritures comme une protection pour la reprise.

Enfin, précisez dans la décision de bascule à partir de quel moment le retour arrière exige une réconciliation. Avant les premières écritures sur la destination, rétablir le trafic peut être simple. Après, exigez la procédure de réconciliation et les preuves de son fonctionnement. Si l’équipe ne peut pas rétablir un état correct dans le délai de reprise choisi, la bascule n’est pas prête.

Utilisez Kit si la migration révèle un besoin de recrutement

Recrutez pour un besoin technique démontré, une fois que le travail de validation a révélé ce qui manque. Une échéance de fermeture ne suffit pas à justifier l’embauche d’un salarié permanent.

Le besoin peut porter sur une conversion temporaire de base de données, une expérience des questions de compatibilité entre runtimes ou une responsabilité durable d’exploitation. Définissez d’abord le résultat attendu et la durée du besoin. Un exercice d’entretien limité peut demander à un candidat d’expliquer une écriture conditionnelle qui a échoué, d’examiner un parcours de compatibilité réellement exécuté ou de raisonner sur un retour arrière après la création d’une nouvelle donnée. Utilisez des données synthétiques et un exercice court ; le travail réel de migration de production doit être rémunéré.

Conservez les preuves de migration et les décisions de bascule dans vos outils techniques. Kit intervient dans le processus de recrutement si vous décidez de recruter : il permet de gérer les candidatures et la revue d’équipe. Il ne migre pas votre runtime et ne réconcilie pas votre base de données.

Le livrable immédiat est une solution de remplacement qui réussit les tests de comportement, d’état et de reprise avant la fermeture de l’hébergement. Si ces tests révèlent un poste à pourvoir, découvrez Kit Hiring pour cette étape de recrutement.