- L’écosystème du développement d’applications natives Windows n’offre toujours pas, en 2025, de réelle productivité aux développeurs en raison de décennies de ruptures de frameworks et de refontes répétées
- De Win32 à MFC, WinForms, WPF, WinRT, UWP puis WinUI 3, malgré 7 étapes d’évolution des frameworks UI, il existe encore de nombreux cas où il est impossible d’implémenter des fonctions de base avec les seules API les plus récentes
- Des fonctions courantes comme les icônes de zone de notification ou l’interception de raccourcis globaux dépendent toujours d’appels Win32 via P/Invoke, ce qui vide de son sens l’adoption des frameworks modernes
- Même en compilant une simple application utilitaire avec .NET AOT, on obtient un binaire de plus de 9 MiB, et les certificats de signature de code nécessaires à la distribution MSIX constituent une barrière bien réelle de 200 à 300 $ par an
- Le fait que les principales applications de Microsoft elles-mêmes (VS Code, Outlook, menu Démarrer) soient réalisées avec des technologies web montre que le développement natif Windows n’est plus une priorité, même en interne chez Microsoft
Contexte : qu’a-t-il été développé ?
- Les problèmes de l’environnement actuel de développement d’applications natives sont apparus lors du développement de « Display Blackout », un utilitaire exclusivement Windows
- Cette application permet, dans une configuration multi-écrans, d’éteindre visuellement les écrans latéraux avec un overlay noir pendant une partie
- Les fonctions nécessaires incluent l’énumération des écrans, le calcul des limites, la gestion de raccourcis globaux, l’affichage d’une icône dans la zone de notification, le lancement automatique au démarrage et la sauvegarde des paramètres
- Il existe déjà des scripts AutoHotkey et des applications du Microsoft Store, mais le développement a été entrepris directement pour des raisons d’apprentissage et pour améliorer l’UI
- Le constat final est que l’environnement de développement natif Windows est extrêmement complexe et inefficace
Histoire de la programmation sous Windows
- À l’origine, l’unique option était l’API Win32 en C, une API qui reste encore valable aujourd’hui
- MFC, basé sur C++, a ajouté au-dessus de Win32 des abstractions orientées objet comme les classes et les templates
- Avec l’arrivée de .NET 1.0 (2002) sont apparus le langage C#, une VM de bytecode JIT et la gestion automatique de la mémoire ; Windows Forms n’est qu’un wrapper autour des API Win32 de fenêtres et de contrôles
- WPF dans .NET 3.0 (2006) a introduit le langage de balisage XAML et constitue la première tentative d’émancipation vis-à-vis de Win32 grâce à un rendu GPU des contrôles
- WinRT dans Windows 8 (2012) a introduit un modèle d’applications sandboxées visant l’unification entre desktop, tablettes et téléphones, mais sa structure XAML, subtilement différente de celle de WPF, a créé de la confusion
- UWP dans Windows 10 (2015) a assoupli certaines restrictions du sandbox, sans atteindre le niveau de permissions desktop de WPF, tandis que certaines fonctions de l’OS (notifications push, live tiles, distribution via Microsoft Store) restaient limitées à WinRT/UWP
- C’est ce qui a conduit des applications existantes comme Chrome ou Microsoft Office à adopter une architecture bancale reliant des applications pont WinRT/UWP via IPC
- Le Windows App SDK de Windows 11 (2021) ouvre les fonctions auparavant réservées à WinRT/UWP aux applications C++ standard comme aux applications .NET, et inclut une nouvelle bibliothèque de contrôles basée sur XAML, WinUI 3
- Résumé de l’évolution des frameworks UI :
API C Win32 → MFC → WinForms → WPF → XAML WinRT → XAML UWP → WinUI 3
Le dilemme du choix technologique
- Il existe trois voies pour développer une application WinUI 3 :
- C++ : binaire léger, interop facile avec l’API C Win32 — mais sans sûreté mémoire
- C#/XAML + déploiement dépendant du framework : même sous Windows 11 récent, seul .NET 4.8.1 est préinstallé, ce qui entraîne à la première installation une médiocre expérience utilisateur avec une boîte de dialogue de téléchargement des bibliothèques .NET
- C#/XAML + .NET AOT : l’intégralité du runtime .NET (VM, GC, bibliothèque standard) est intégrée au binaire — même une application simple génère ainsi un binaire de plus de 9 MiB
- La tentative de maintenir des bindings Rust (
windows-app-rs) a été archivée - Le mode de distribution est lui aussi une source de souffrance :
- Le format MSIX exige un certificat de signature de code, soit 200 à 300 $ par an pour les résidents hors des États-Unis
- Le sideloading non signé requiert une obscure commande PowerShell utilisable uniquement dans un terminal administrateur
- L’inscription au Microsoft Store a été refusée au motif que l’application n’apportait pas de « valeur originale et durable »
Des fonctions impossibles même avec le SDK le plus récent
| Fonction | Prise en charge par Windows App SDK |
|---|---|
| Énumération des écrans | Partielle (foreach impossible, détection des changements nécessitant P/Invoke) |
| Placement de fenêtres noires non actives | Partielle (le mode non activant nécessite P/Invoke) |
| Interception de raccourcis clavier globaux | Impossible — nécessite P/Invoke |
| Lancement automatique au démarrage | Oui (API fournie avec intégration aux paramètres système) |
| Persistance des paramètres | Oui |
| Icône de zone de notification + menu | Impossible — nécessite P/Invoke, style de menu non standardisé |
- Le style des menus d’icône de zone de notification varie d’une application à l’autre, sans standard cohérent à l’échelle de l’OS
- Au passage de WPF à WinUI 3, même des fonctions de base comme l’ajustement automatique de la taille des fenêtres ont disparu
Les limites structurelles de l’interop C#/Win32
- CsWin32, l’outil moderne de P/Invoke, contient un bug l’empêchant d’encapsuler correctement les chaînes à l’intérieur des structures
- La documentation de CsWin32 précise que C# n’a pas de manière idiomatique d’exprimer le type de paramètre Win32 fondamental
[optional, out], et que l’outil génère donc deux versions de la même méthode - Près de 20 ans après la sortie de WPF (2006), le boilerplate pour écrire des classes de binding UI s’est à peine amélioré
- Il faut toujours convertir chaque propriété en paire getter/setter, ajouter une garde sur les valeurs identiques, appeler l’émission d’événements, etc.
- Aucune solution au niveau du langage comparable aux décorateurs ou proxies de JavaScript n’a été ajoutée à C# en 20 ans
- Le changelog de CsWin32 est pauvre et le projet reste en version pré-1.0, ce qui laisse penser qu’il pourrait être abandonné dans les prochaines années
Conclusion : pourquoi Electron est la réponse
- Aujourd’hui, Microsoft ne fait pas du développement natif une priorité
- Les trackers d’issues associés sont remplis de bugs et de signalements, mais les réponses des ingénieurs Microsoft sont rares
- Le changelog du Windows App SDK est surtout centré sur l’ajout d’API de machine learning
- Le fait que des applications majeures de Microsoft comme VS Code, Outlook ou le menu Démarrer soient réalisées avec des technologies web en est une preuve supplémentaire
- La communauté se tourne vers des frameworks UI tiers comme Avalonia et Uno Platform
- Ils reprennent la philosophie de WPF tout en renforçant le support cross-platform
- À l’heure actuelle, des frameworks web comme Electron ou Tauri constituent un choix plus réaliste
- La combinaison TypeScript/React/CSS est plus productive que C#/XAML
- L’accès à l’API Win32 reste possible
-
Tauri** utilise** la WebView système et n’a donc pas besoin d’embarquer Chromium
- Le runtime WebView2 est mis à jour toutes les 4 semaines, tandis que le .NET système reste bloqué en 4.8.1
- Il serait possible d’espérer un redressement si Microsoft travaillait à améliorer le Windows App SDK et à simplifier le système de distribution
- Mais à ce stade, la plupart des développeurs n’y croient plus
- La conclusion est donc : « je vais choisir la stack web »
- La récente annonce de Microsoft sur sa focalisation sur la qualité de Windows mentionne vouloir utiliser davantage WinUI 3 à l’échelle de l’OS, mais il reste difficile de savoir si cela se traduira par des améliorations concrètes
3 commentaires
Merci de normaliser ça avec Electron...
Je me demande quand le WYSIWYG de WinUI 3 sortira enfin.
Avis Hacker News
Moi aussi, comme d’autres, je pense qu’il est logique de rester sur Win32
Pour avoir développé avec Win32 pendant longtemps, les fonctionnalités nécessaires peuvent largement être implémentées dans un exécutable autonome de moins de 8 Ko
L’énumération des écrans, la création de fenêtres, le hook des raccourcis clavier, l’enregistrement au démarrage, la sauvegarde des paramètres, l’affichage d’une icône dans la zone de notification, etc., tout cela se fait avec quelques appels d’API de quelques centaines d’octets
En revanche, écrire un nouveau projet en langage non sûr pour la mémoire (C++) en 2026 est anachronique
Cela dit, pour une appli qui reçoit très peu d’entrées non fiables, pas besoin de se laisser influencer par la propagande
_UNICODE, vous pouvez faire la même chose en deux fois moins de temps avec .NET FrameworkJe pense qu’il faudrait relancer un mouvement « NoFramework » et revenir à l’époque du RAD
Mais il faut bien réfléchir avant de choisir C++ pour un nouveau projet
On peut aussi utiliser Win32 depuis des langages sûrs pour la mémoire — par exemple windows-rs
À l’époque, Borland Delphi était l’outil le plus populaire
Si ce n’est ni une appli WinRT, UAP ou UWP existante, il vaut mieux éviter WinUI 3.0 et WinAppSDK
Mieux vaut continuer à utiliser des technologies éprouvées comme Win32, MFC, WinForms ou WPF,
et hors de l’écosystème Microsoft, on peut envisager Qt, VCL, Firemonkey, Avalonia, Uno, ImGUI, etc.
WinUI 3.0 est tellement bancal que Microsoft essaie même de le confier à la communauté en open source
Ensuite, WinJS s’est transformé en framework web open source et le support officiel a cessé
Billet de blog lié
Je fais de l’embarqué, et il reste facile de créer des programmes GUI Win32 qui communiquent avec des appareils
Du code de l’époque XP tourne encore tel quel sur Windows 11, et un projet VC6 s’ouvre dans Visual Studio 2022 et se compile sans problème
Une telle rétrocompatibilité est rare sur d’autres plateformes
Le Cocoa d’Apple a une structure « élégante », mais en pratique c’est complexe et mal documenté
L’API Win32 pure reste un choix pratique
Si on construit soi-même en C++ un wrapper de type MFC, on peut le terminer en 2 à 3 semaines et ensuite garder un contrôle total
Grâce à la solide rétrocompatibilité de Microsoft, les applis basées sur Win32 restent stables sur le long terme
On peut voir un exemple mis à jour pendant plus de 10 ans ici
Les couleurs système et les contrôles sont codés en dur, ce qui entre en conflit avec les thèmes sombres
Seule une partie de l’UI, comme les menus, boîtes de dialogue de message ou sélecteurs de fichiers, prend en charge le mode sombre, ce qui casse la cohérence
Voir aussi ce billet
Aujourd’hui, le projet est maintenu en open source et en est à la version 10
D’après mon expérience à avoir créé plusieurs applis Windows,
(1) l’API Win32 est ancienne mais très stable, et
(2) il faut éviter les toolkits UI appartenant à Microsoft — on finit toujours par avoir besoin d’un contrôle au niveau Win32
La plupart des technologies UI créées par Microsoft ces 20 dernières années étaient des variantes de WPF
Si Microsoft avait continué à faire évoluer WPF, ce serait probablement aujourd’hui le standard du développement UI
Du point de vue des utilisateurs, les applis natives sont rapides et agréables, mais leur développement est vraiment un chaos complexe
C’est aussi pour cela que des applis comme Outlook et Teams empirent avec le temps
Il est difficile d’y reproduire une sensation native, notamment pour le focus ou la navigation au clavier
Voir le projet Electrobun
Je ne suis pas d’accord avec l’idée que « créer un nouveau projet en C++ est un crime »
Pour une GUI, les performances et le contrôle comptent plus que la sûreté, et C++ reste un langage éprouvé
Qt reste en 2026 l’un des meilleurs frameworks GUI, avec des mécanismes de sûreté mémoire intégrés
Je me demande pourquoi le runtime .NET le plus récent n’est pas inclus par défaut dans Windows 11
Cela ressemble à un nouvel exemple de Microsoft qui renonce à une expérience utilisateur cohérente
donc les distribuer toutes via Windows Update n’est pas réaliste
On peut à la place distribuer un exécutable autonome compilé en AOT (environ 9 MiB)
C’est bien plus petit et plus efficace qu’Electron
Aujourd’hui, il vaut mieux empaqueter les DLL avec l’application
ce qui rend son intégration directe dans l’OS difficile
Cela a été séparé des mises à jour de l’OS pour conserver un cycle de publication rapide
tandis que .NET Core doit être installé séparément
J’ai récemment refait une appli pour Windows et Mac avec Tauri après longtemps,
le développement et la compilation étaient simples, mais des problèmes de signature de code ont empêché mes collègues de l’installer
Sur Mac, une commande dans le terminal a suffi, mais sur Windows il a fallu désactiver Smart App Control,
et cette fonction ne peut pas être réactivée sans réinstallation
Je comprends l’objectif de sécurité, mais je ne pensais pas que l’installation serait aussi compliquée
La réponse à la question « pourquoi ne pas utiliser Electron ? » est simple —
les applis Electron offrent une mauvaise expérience utilisateur
Le développement est facile, mais au prix des performances et de la qualité
Si l’on veut faire un bon produit, il faut choisir le natif même si c’est plus difficile
Personnellement, je pense que C# est bien supérieur à TypeScript