- 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
Aucun commentaire pour le moment.