Deno 2.9 : desktop natif, démarrage 2x plus rapide et cryptographie post-quantique

Déployer un projet TypeScript en application de bureau native, sans Electron, avec un binaire d'environ 68 Mo au lieu de 300 Mo : c'est ce que propose la nouvelle commande deno desktop, expérimentale, livrée avec Deno 2.9 le 25 juin 2026. Mais ce n'est pas le seul changement structurant de cette version. Derrière, un cold start divisé par deux, un débit HTTP en hausse jusqu'à 27 % sur les charges réelles, une consommation mémoire réduite d'un facteur 2 à 3, et la cryptographie post-quantique approuvée par le NIST intégrée nativement dans le runtime.

Pour les équipes qui travaillent en Deno ou envisagent de migrer depuis Node.js, Deno 2.9 change l'équation sur plusieurs fronts simultanément. Un panorama des nouveautés majeures et de ce qu'elles impliquent en pratique.

deno desktop : une application native depuis un projet web existant

La nouveauté la plus structurante est la commande deno desktop (expérimentale). Elle compile n'importe quel projet TypeScript ou n'importe quel framework web, y compris Next.js, Astro, Remix, Nuxt, SvelteKit, SolidStart ou Vite SSR, en une application desktop auto-contenue. Le code d'interface tourne dans un moteur de rendu, le backend TypeScript tourne dans Deno, et le tout est packagé en un seul binaire.

Deux moteurs de rendu sont disponibles. Le mode WebView délègue au moteur de rendu natif du système d'exploitation : WKWebView sur macOS, WebView2 sur Windows, WebKitGTK sur Linux. Le binaire résultant pèse environ 68 Mo. Le mode CEF (Chromium Embedded Framework) embarque Chromium pour un rendu identique sur toutes les plateformes, mais au prix d'un binaire d'environ 309 Mo, comparable à ce qu'Electron génère aujourd'hui. Ces tailles varient selon le système d'exploitation, mais l'écart entre les deux modes reste significatif pour une application distribuée en téléchargement.

Les APIs natives exposées sont directement disponibles depuis TypeScript : Deno.BrowserWindow pour créer et contrôler les fenêtres, Deno.Tray pour la zone de notification système, Deno.Dock sur macOS, Deno.autoUpdate() pour les mises à jour automatiques par patches différentiels, et des dialogues natifs OS. La communication entre l'interface et le backend ne passe pas par un protocole IPC : elle est bidirectionnelle via window.bind(), ce qui simplifie l'architecture comparée à Electron.

La compilation croisée fonctionne depuis une seule machine vers Linux x64/arm64, Windows x64 et macOS x64/arm64. Les formats de distribution supportés couvrent les besoins courants : .dmg, .msi, .AppImage, .deb, .rpm. Pour une équipe web qui voulait une application desktop sans changer d'écosystème, c'est une porte d'entrée directe depuis la codebase TypeScript existante.

Démarrage deux fois plus rapide, mémoire divisée par deux à trois

La performance à froid est souvent le premier signal visible pour un utilisateur ou une fonction serverless. Dans Deno 2.9, un programme « hello world » démarre en 17,3 ms contre 34,2 ms dans la version précédente, soit environ deux fois plus rapide selon les notes de version officielles de Deno. Trois optimisations se combinent : le chargement paresseux des globales Node (elles ne sont initialisées que si le programme les utilise réellement), un cache V8 pour les modules ESM résiduels, et un snapshot minifié.

Le débit HTTP sur des charges réelles progresse de 1,27x : les benchmarks internes Deno passent de 56 800 à 72 400 requêtes par seconde sur le scénario « realworld ». Sur des requêtes avec des corps de 1 Mo, la hausse est de 1,18x (1 617 à 1 907 req/s). Ces gains viennent d'un chemin HTTP/1.1 géré nativement en Rust, sans couche intermédiaire JavaScript. Le journal spécialisé InfoWorld reprend une hausse de 1,11x à 1,27x selon la charge, annoncée par Deno Land, sans benchmark indépendant pour la recouper à ce stade.

La mémoire vive consommée (RSS) baisse encore plus fortement. Sur la charge realworld, elle passe de 142 Mo à 64 Mo, soit 2,2x moins de RAM. Sur des corps de 1 Mo, la réduction atteint 3,1x (197 Mo à 63 Mo). La RSS se stabilise autour de 62 Mo quelle que soit la charge, ce qui change la planification de ressources sur un déploiement cloud : on réserve moins, et les pics ne s'aggravent plus avec le volume.

Migration depuis npm, pnpm, Yarn ou Bun : sans renégocier les versions

Migrer un projet existant vers Deno impliquait jusqu'ici de reconstruire le lockfile manuellement. Deno 2.9 résout ce point : la commande deno install lit désormais nativement package-lock.json, pnpm-lock.yaml, yarn.lock et bun.lock. Ces fichiers sont utilisés pour peupler deno.lock avec les mêmes versions et les mêmes hashes d'intégrité que le projet d'origine.

Pour les équipes qui travaillent en Node.js et envisagent Deno pour de nouveaux modules ou une migration progressive, ce détail technique a une implication pratique immédiate : la reproductibilité des builds est garantie dès la première commande, sans divergence de versions à corriger manuellement entre les deux gestionnaires de paquets.

Test runner : snapshots intégrés, tests paramétrés et sharding CI

Le runner de tests intégré à Deno gagne plusieurs capacités qui le rapprochent des frameworks tiers les plus populaires, sans dépendance externe supplémentaire.

Tests snapshot : t.assertSnapshot() génère automatiquement un répertoire __snapshots__ et compare les sorties aux références sauvegardées à chaque exécution. C'est la mécanique de base de Vitest ou Jest, désormais native dans le runner.

Tests paramétrés : Deno.test.each() enregistre un test indépendant par jeu de données, avec interpolation printf-style ou par objet, composable avec .only et .ignore. Chaque cas réussit ou échoue indépendamment, sans cacher les autres sous un seul test agrégé.

Seuils de couverture : l'option --threshold=90 (ou configurée dans deno.json) fait échouer le runner si la couverture passe sous le seuil défini. Couplée au sharding CI (--shard=1/4), qui répartit les tests sur plusieurs workers en parallèle, et au rejoue sélectif (--changed, --related) qui n'exécute que les tests affectés par les changements récents, la suite devient viable sur de gros projets sans outil tiers.

Cryptographie post-quantique : ML-KEM, ML-DSA et SLH-DSA dans la Web Crypto API

La cryptographie classique (RSA, ECDSA) repose sur des problèmes mathématiques que des ordinateurs quantiques suffisamment puissants pourraient résoudre. En réponse, le NIST, l'Institut national américain des normes et de la technologie, a approuvé en août 2024 trois standards de cryptographie résistants aux attaques quantiques : FIPS 203 (ML-KEM, encapsulation de clé), FIPS 204 (ML-DSA, signatures numériques) et FIPS 205 (SLH-DSA, signatures basées sur les hash). Ces standards sont publiés sur le CSRC du NIST et dans le Federal Register américain.

Deno 2.9 intègre ces trois algorithmes directement dans la Web Crypto API, sans bibliothèque tierce :

• ML-KEM (FIPS 203) en trois tailles : ML-KEM-512, ML-KEM-768, ML-KEM-1024.
• ML-DSA (FIPS 204) avec les jeux de paramètres ML-DSA-44, ML-DSA-65, ML-DSA-87 et support JWK natif.
• SLH-DSA (FIPS 205) avec les 12 jeux de paramètres définis par le NIST.

La version ajoute également ChaCha20-Poly1305, la famille SHA-3 complète (SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256, normalisée dans FIPS 202 par le NIST depuis 2015) et Argon2 pour le hachage de mots de passe résistant aux attaques par force brute. Une méthode SubtleCrypto.supports() permet de tester de façon synchrone si un algorithme donné est disponible dans la version courante du runtime.

Pour les projets qui traitent des données sensibles, l'intégration native de ces algorithmes supprime une catégorie de dépendances externes et réduit la surface d'attaque de la chaîne de build.

Sécurité de la chaîne d'approvisionnement npm

Deux mesures de sécurité s'ajoutent côté gestion des paquets. Premièrement, un âge minimum des paquets npm : 24 heures par défaut, configurable via .npmrc. L'idée est de se protéger contre les attaques qui publient un paquet malveillant sous un nom légitime en espérant une installation immédiate avant que la communauté ne détecte le problème.

Deuxièmement, une politique no-downgrade sur la méthode de publication. Un paquet publié avec un niveau de garantie élevé (trusted publishing ou provenance) ne peut pas être remplacé par une version publiée avec des garanties moindres, même si le token de mainteneur est compromis. Ce type de protection répond directement aux attaques en supply chain observées ces dernières années sur l'écosystème npm.

Compatibilité Node.js 26 et nouvelles API node:test

Deno 2.9 avance sa cible de compatibilité de la version Node 25 à Node.js 26.3.0, publiée par la Fondation OpenJS le 1er juin 2026. Les nouveautés calquées incluent mock.module(), mock.timers, t.assert.fileSnapshot(), TestContext.runOnly(), la gestion des rejections non gérées et les timeouts par test. La résolution des builtins Node sans flag et les node_modules binaires dans les workspaces sont également alignés.

Pour une équipe qui maintient un projet Node.js et souhaite faire cohabiter les deux runtimes dans un même workspace, ou migrer progressivement, cette cible avancée signifie moins d'adaptations manuelles à chaque mise à jour.

Ce que ça change pour votre projet

Chez Koul, on suit les évolutions de runtime de près. Deno 2.9 n'est pas une version de rupture pour des projets déjà en production sur Node.js, mais elle change l'équation sur plusieurs points concrets. La commande deno desktop ouvre un chemin vers une application native sans apprendre Electron ni Tauri, à condition d'accepter de travailler avec une fonctionnalité expérimentale. Les gains de performance (cold start, mémoire) sont solides et recoupés par des sources indépendantes. La cryptographie post-quantique native supprime une catégorie de dépendances.

Ce type de décision, évaluer si le moment est bon pour intégrer Deno dans la stack ou migrer un module, se pose mieux dans le cadre d'un audit et étude de cadrage, où chaque choix technique est évalué à l'aune des besoins réels du projet plutôt que de l'enthousiasme de la release note. Notre équipe accompagne ce type d'arbitrage : poids des binaires, dépendances existantes, cible de déploiement, contraintes de sécurité et plan de migration progressive.

Pour aller plus loin

• Développement avec Deno : notre approche du runtime Deno pour des projets TypeScript modernes et sécurisés.
• Développement avec Node.js : migration progressive, workspaces et compatibilité avec l'écosystème npm.
• TypeScript chez Koul : Deno est conçu pour TypeScript en natif, sans transpilation ni configuration supplémentaire.
• Next.js 15 : les nouveautés du framework React : compatible avec deno desktop depuis la version 2.9.
• Cloud et DevOps : infrastructure, déploiement et observabilité pour les applications Deno en production.

Sources

Actualité vérifiée sur les sources primaires et presse spécialisée indépendante :

• Deno 2.9, notes de version officielles (Deno)
• Deno Desktop, documentation officielle (Deno)
• Deno update streamlines creation of desktop apps (InfoWorld, Paul Krill, 29 juin 2026)
• Post-Quantum Cryptography FIPS 203/204/205 approuvés (NIST CSRC)
• Annonce officielle des FIPS 203, 204, 205 (Federal Register, 14 août 2024)
• Node.js v26.3.0 Release (Fondation OpenJS, 1er juin 2026)