Si votre équipe produit veut vraiment livrer de l’IA qui s’exécute sur les machines des utilisateurs, vous revenez au desktop. Le bac à sable du web n’accède pas à la moitié du matériel dont vous avez besoin. Avec HN en effervescence autour de Deno Desktop et des éditeurs qui s’empressent d’exposer WebGPU, Vulkan 1.2, DirectML et Core ML, 2026 est l’année où « Electron vs Tauri » est devenu un choix à trois — désormais avec le runtime à permissions de Deno dans la balance.
Voici la vérité qui dérange : votre choix de stack desktop verrouillera l’essentiel de votre risque — sécurité, mécanismes de mise à jour, accès GPU, et vitesse de livraison. Ce billet vous propose un cadre de décision de niveau CTO, pas un verdict de club de fans.
Pourquoi cette décision est urgente
Trois évolutions ont rendu ce choix incontournable :
- Le centre de gravité s’est déplacé vers l’IA locale. Après un an de débats « passer à des modèles ouverts a peu d’inconvénients », de nombreuses équipes déploient désormais des poids ouverts de 3–7B en edge pour la latence, la confidentialité et la maîtrise des coûts. Cela signifie plusieurs gigaoctets, des liaisons GPU, et une vraie plomberie de mises à jour.
- Les API GPU ont mûri. Avec l’adoption généralisée de Vulkan 1.2 et la stabilisation de WebGPU sur les stacks basées sur Chromium, vous pouvez réellement décharger l’inférence et les pipelines d’images sur le GPU de l’utilisateur sans sorcellerie.
- La sécurité et la confiance se sont durcies. Utilisateurs, DSI et régulateurs sont pointilleux sur la signature de code, la notarisation et ce que votre app remonte. Votre système de mise à jour et les réglages de sandbox font désormais partie de la réputation de votre produit.
Les trois prétendants desktop en 2026
Electron (Chromium + Node)
- Empreinte : Les installateurs font couramment 80–150 Mo ; les mises à jour delta peuvent descendre à quelques Mo avec des stratégies de block‑map.
- Mémoire : Rendu + process principal au repos typiquement 150–300 Mo selon les extensions et la discipline vis‑à‑vis des devtools.
- Voie GPU : Meilleur support WebGPU à court terme (Chromium), plus un Node-API mature pour des backends ML natifs (llama.cpp, ONNX Runtime, liaisons TensorRT).
- Posture de sécurité : Surface d’attaque la plus large par défaut, mais durcie avec contextIsolation, remote désactivé, et un IPC strict. Renders sandboxés recommandés.
- Mises à jour : Mature. Signature de code + notarisation + mises à jour delta bien rodées.
Tauri (noyau Rust + WebView)
- Empreinte : Minuscule. Des installateurs de 5–20 Mo pour beaucoup d’apps grâce à la réutilisation du webview système.
- Mémoire : Souvent 50–120 Mo au repos ; arbre de processus plus petit qu’Electron.
- Voie GPU : Vous irez chercher des crates Rust et des runtimes ML natifs (llama.cpp, candle, ort) directement. WebGPU dans le webview système est plus inégal que dans Chromium, mais côté Rust le GPU est solide via wgpu/Vulkan/Metal/DirectX.
- Posture de sécurité : Surface minimale par conception. Listes d’autorisation de commandes, pas de Node, moins de pièces mobiles. Vous contrôlez les frontières natives en Rust.
- Mises à jour : Solides, signées sur toutes les plateformes, mais moins « batteries incluses » que l’écosystème d’Electron.
Deno Desktop (émergent, runtime Deno + coque UI)
- Empreinte : Les premiers retours suggèrent des dizaines de Mo pour le bundle runtime (plus petit qu’un Chromium complet, plus grand qu’une simple coque webview). Attendez‑vous à ce que cela évolue.
- Mémoire : Comparable aux autres coques webview pour des apps simples ; plus lourd avec une UI complexe et des tâches d’arrière‑plan.
- Voie GPU : Prometteuse via WebGPU dans le moteur sous‑jacent plus le FFI de Deno vers des bibliothèques natives. L’écosystème est encore en maturation.
- Posture de sécurité : Modèle de permissions fort hérité de Deno (allow-read, allow-net, etc. explicites). De bons défauts pour une posture de moindre privilège.
- Mises à jour : En amélioration mais pas encore aussi clé en main que l’outillage d’Electron. Validez l’updater et les éléments de signature dans un spike avant de vous engager.
D’abord, identifiez le profil de votre application
Ne choisissez pas un runtime avant d’avoir clarifié la nature réelle de l’application. La plupart des produits desktop IA que nous voyons entrent dans l’un de ces trois profils :
- Console d’agent : UI toujours en ligne qui orchestre de l’inférence cloud avec quelques outils locaux (capture d’écran, frappes, invites système). Faible usage de modèles locaux, surtout UI/IPC et mises à jour sécurisées.
- Studio hors ligne : Inférence locale lourde (modèles 3–7B, pipelines de vision, embeddings) avec synchronisation cloud optionnelle. Les modèles vivent sur disque ; l’accélération GPU est obligatoire.
- IDE/Notebook hybride : Expérience développeur avec plugins et outils locaux (formateurs, linter, petits modèles) et des appels cloud occasionnels.
Faites correspondre votre profil à vos contraintes :
- Critique côté sécurité ? Vous pourriez faire face à des politiques MDM, à des contrôles de signature d’entreprise et à des règles de sandbox d’app.
- Critique côté GPU ? Vous choisirez des backends ML natifs et les exposerez en toute sécurité via votre runtime.
- Sensible à l’empreinte ? La taille de distribution et la mémoire comptent pour le grand public et les parcs EDU/gouvernement.
- Compétences d’équipe ? Des équipes majoritairement JS/TS vs Rust vous orientent différemment.
Réalité terrain pour le GPU et les runtimes de modèles
L’enthousiasme autour de WebGPU est réel. Mérité, mais à cadrer correctement :
- Petits/moyens modèles et opérations d’image : WebGPU dans le Chromium d’Electron peut être excellent pour des effets à base de shaders et des charges tensor modestes. Attendez‑vous à des accélérations sensibles sur GPU intégrés.
- LLM 3–7B en 4 bits : La voie pratique aujourd’hui reste des backends natifs qui exploitent les accélérateurs de plateforme : DirectML sur Windows, Metal/Core ML sur macOS, CUDA sur NVIDIA, Vulkan via IREE ou le Vulkan de ggml pour Linux/AMD. WebGPU n’est pas encore une panacée pour les grands modèles.
- Bibliothèque d’inférence multiplateforme : llama.cpp (famille GGUF/ggml) demeure la base pragmatique. Il prend en charge Metal, CUDA, Vulkan et DirectML et se livre en bibliothèques statiques ou dynamiques que vous pouvez lier depuis Node-API (Electron) ou Rust (Tauri). Deno Desktop peut l’appeler via FFI, mais vous assumerez plus de code de liaison.
Conséquence : votre runtime doit rendre les liaisons natives ennuyeuses — construire, signer, précharger et mettre à jour sans rendre les machines des utilisateurs inutilisables.
Posture de sécurité : la réputation de votre app en dépend
Durcissement Electron
- Désactivez Node dans les renderers, activez contextIsolation, utilisez un IPC typé avec des allowlists de canaux strictes.
- Interdisez le module remote et les require dynamiques dans le renderer. Ne préchargez que le strict nécessaire via contextBridge.
- Appliquez une CSP et auditez tous les chargements d’URL. Considérez chaque package UI tiers comme non fiable.
Discipline Tauri
- Gardez la logique métier dans des commandes Rust ; l’UI reste bête. Listes d’autorisation de commandes au moindre privilège.
- Revoyez chaque crate que vous ajoutez ; une crate compromise équivaut à une compromission native.
- Isoler l’accès fichier et verrouillez les domaines de sortie réseau autant que possible.
Permissions Deno Desktop
- Exploitez les permissions explicites de Deno (--allow-read, --allow-net, --allow-ffi). Par défaut, refuser.
- Rendez les permissions visibles dans les réglages de votre app ; gagnez la confiance en exposant exactement ce que vous utilisez, et pourquoi.
Mises à jour : la source silencieuse d’incidents
La plupart des incidents desktop sont auto‑infligés par les updaters. Votre plan doit être explicite :
- Signature et notarisation : macOS exige une signature Developer ID + notarisation ; Windows requiert Authenticode et la réputation SmartScreen (un certificat EV accélère cela). Automatisez les deux chemins.
- Mises à jour delta avec rollback : La stratégie block‑map d’Electron ramène souvent les mises à jour à 5–20 Mo. L’updater de Tauri prend en charge des diffs signés. Quel que soit l’outil, implémentez un rollback automatique quand l’app ne redémarre pas après mise à jour.
- Les poids de modèles ne sont pas des mises à jour d’app : N’intégrez pas 3–7 Go de fichiers de modèles dans les installateurs. Téléchargez au premier lancement, supportez les requêtes HTTP Range avec reprise, vérifiez les checksums, et stockez dans les caches adaptés à l’OS. Throttlez et affichez la progression. Gardez des versions de modèles et un GC en place.
- Déploiements progressifs : Canarisez 5–10 % d’utilisateurs d’abord. Votre updater doit respecter des cohortes pour pouvoir stopper rapidement un mauvais build.
Ce qu’il faut mesurer (avant de s’engager)
Menez un spike de deux semaines sur chaque stack candidate avec les mêmes fonctionnalités minimales :
- Charger un modèle GGUF de 3–4 Go, exécuter une invite 60 secondes, streamer les jetons, puis décharger. Relever jetons/s et la latence de bout en bout.
- Mesurer le cold start sur boot frais et le RSS au repos après 60 secondes, avec et sans devtools.
- Livrer un build signé à un groupe test, puis pousser une mise à jour delta. Mesurer le taux d’échec, les performances de rollback et l’indisponibilité perçue.
- Faire crasher le worker d’inférence en cours d’exécution. Vérifier que l’app survit et récupère l’état du modèle sans corrompre le cache.
Des chiffres qui font bouger les décisions dans le réel :
- Taille de l’installateur et des deltas : Impacte les conversions de téléchargement et la friction en déploiement entreprise.
- Mémoire au repos : Prédit combien de fenêtres/onglets parallèles vous supportez avant que l’utilisateur ne vous tienne pour responsable du « syndrome de la machine lente ».
- Jetons par seconde sur un matériel représentatif : Sur un Mac 16 Go (puce série M), des modèles 7B en 4 bits peuvent passer de quelques jetons/s (CPU) à des dizaines de jetons/s (GPU) avec le bon backend. Validez‑le dans votre stack.
Cadre de décision : choisissez délibérément
Si votre app est une Console d’agent et que votre équipe est majoritairement TS
- Choisissez Electron pour les 12 prochains mois. WebGPU y est en avance, l’écosystème des mises à jour automatiques et de la signature est mature, et les bindings Node-API vers des backends natifs sont abondants.
- Garde‑fous : Traitez les renderers comme non fiables. Pas de Node dans le renderer, IPC strict. Utilisez des mises à jour delta avec rollback. Épinglez tous les endpoints d’update.
Si votre app est un Studio hors ligne et que vous pouvez staffer du Rust
- Choisissez Tauri si empreinte et moindre privilège comptent. Gardez l’inférence en Rust avec une crate stable (llama.cpp/candle/ort) et exposez des commandes minimales à l’UI.
- Garde‑fous : Budgétez 4–6 semaines pour fiabiliser les backends GPU, le packaging binaire par plateforme et un updater robuste. Traitez votre noyau Rust comme un service backend avec logging et crash reporting.
Si vous voulez un runtime à permissions et acceptez quelques bords coupants
- Pilotez Deno Desktop pour des outils internes et des rollouts contrôlés. Le modèle de permissions est excellent ; l’écosystème rattrape.
- Garde‑fous : Spikez tôt votre chemin de mise à jour, signature et notarisation. Ayez une porte de sortie vers Electron ou Tauri si une intégration manquante bloque votre date de sortie.
Architectures de référence qui tiennent la route
Référence Electron
- Processus principal : Minimal. Aucune logique métier. Gère le cycle de vie, les mises à jour et l’IPC sécurisé.
- Renderer : React/Svelte + WebGPU pour du calcul léger et de la visualisation. Le preload contextBridge n’expose qu’une surface d’API typée.
- Worker d’inférence : Module natif enveloppant llama.cpp ou ONNX Runtime avec une interface contrainte. Livrez des binaires précompilés par plateforme/arch avec signature de code.
- Mises à jour : Hébergement statique compatible S3 avec manifestes signés et deltas block‑map ; canary 10 %, rollback en 1 clic.
Référence Tauri
- Noyau : Rust orchestre l’inférence, le stockage et l’accès fichier. L’UI envoie des commandes ; zéro logique métier en JavaScript.
- GPU : Utilisez des backends ML côté Rust (llama.cpp via FFI C ou bindings Rust ; wgpu pour des kernels maison) et exposez des événements de streaming à l’UI.
- Mises à jour : Updater signé de Tauri avec cohortes par étapes. Modèles récupérés post‑install, checksummés, avec reprise.
Référence Deno Desktop
- Runtime : Les flags de permissions Deno sont votre politique par défaut. L’UI tourne dans un webview ; la logique métier se trouve derrière des allow-* explicites.
- Appels natifs : FFI vers une fine couche C qui enveloppe votre backend ML. Gardez la frontière minuscule et auditée.
- Mises à jour : Validez l’updater tôt ; s’il est immature, implémentez un bootstrapper externe signé qui remplace l’app de manière atomique.
Réalité d’équipe et de coûts
- POC Electron : 2–3 ingénieurs TS expérimentés peuvent livrer un POC crédible et signé en 2–3 semaines, incluant un updater basique et une démo de petit modèle local.
- POC Tauri : 1 Rust + 1 TS nécessitent typiquement 4–6 semaines pour intégrer un backend accéléré GPU, câbler un updater solide et livrer un build signé sur macOS et Windows.
- POC Deno Desktop : Comptez 3–5 semaines avec plus de risque côté updater et bindings. Pilotez d’abord auprès d’un public interne.
Note staffing : Brazil a de profonds viviers de talents en Rust et TypeScript. Un pod nearshore avec 6–8 heures de recouvrement horaire US et un coût chargé 20–30 % inférieur à des embauches US peut sécuriser votre POC sans le transformer en réécriture annuelle.
Risques à ne pas ignorer
- Chaîne d’approvisionnement : Votre plus grande vulnérabilité reste les dépendances. Figez les versions, utilisez des contrôles d’intégrité, et exécutez des builds signés et reproductibles. Auditez les crates natives et modules Node-API comme s’il s’agissait d’un driver noyau.
- Pression disque : Les caches de modèles vont gonfler. Fixez des plafonds explicites, une éviction LRU et une UI claire pour le pilotage du stockage. Limitez l’amplification d’écriture ; n’épuisez pas les SSD avec des logs incessants ou des réécritures en gros blocs.
- Confidentialité et frontières de données : L’inférence locale n’est pas une carte « hors conformité ». La télémétrie, les crash dumps et les invites en cache peuvent encore contenir des PII. Intégrez suppression et rédaction dans votre produit, pas dans votre backlog.
Ce que nous recommandons maintenant
- Si vous shippez ce trimestre avec une équipe majoritairement TS, choisissez Electron, durcissez‑le et livrez. Réévaluez dans 12 mois si l’empreinte devient votre plainte n°1.
- Si vous bâtissez un studio phare, offline‑first, très GPU et pouvez staffer du Rust, choisissez Tauri et investissez dans votre backend ML natif comme module de première classe.
- Si votre organisation valorise des permissions strictes et des API web standard et peut tolérer quelques aspérités, pilotez Deno Desktop maintenant sur des outils internes ; gardez un plan B.
Points clés
- Choisissez la stack qui correspond au profil de votre app : Console d’agent (Electron), Studio hors ligne (Tauri) ou Pilote à permissions (Deno Desktop).
- WebGPU aide, mais les grands modèles locaux exigent encore des backends ML natifs. Planifiez tôt vos bindings et votre stratégie de signature.
- Votre updater fait partie de la sécurité de votre produit. Deltas signés, rollouts par étapes et rollback instantané sont non négociables.
- Mesurez l’essentiel avant de vous engager : taille d’installateur, RSS au repos, jetons/s sur un matériel représentatif, et taux d’échec/rollback des mises à jour.
- L’empreinte et la sécurité poussent vers Tauri ; la vélocité et l’écosystème tirent vers Electron ; Deno Desktop est prometteur pour des apps à permissions mais encore en maturation.