- Jusqu’à la fin des années 1980, le développement d’applications Windows reposait clairement sur un modèle unique centré sur les API Win16/Win32, mais les décennies suivantes ont été marquées par des changements de plateforme répétés et incohérents
- L’effondrement de la stratégie GUI de Windows ne provient pas de l’échec d’une technologie en particulier, mais de trois causes organisationnelles : la politique entre équipes, une culture d’annonces centrée sur les conférences développeurs, et des changements stratégiques sans préavis
- En 1988, Programming Windows de Charles Petzold donnait une réponse claire à la question « comment créer une application Windows ? » avec une API unique, Win32, et un seul modèle mental ; mais pendant les 30 années suivantes, Microsoft n’a jamais retrouvé cette clarté
- De MFC, OLE, COM, ActiveX, WPF, Silverlight, WinRT, UWP, WinUI 3 jusqu’à MAUI, des dizaines d’années de prolifération de frameworks GUI se sont enchaînées, et derrière chaque initiative échouée, la cause principale relevait davantage de défaillances décisionnelles internes que de défauts techniques
- Aujourd’hui, plus de 17 technologies GUI sont effectivement utilisées sur Windows, et parmi elles, la technologie GUI desktop la plus largement déployée, Electron, a été créée en dehors de Microsoft
- Le diagnostic central — « si une plateforme ne peut pas répondre en 10 secondes à la question “comment faut-il construire l’UI ?”, alors cette plateforme a échoué vis-à-vis des développeurs » — s’applique toujours tel quel à Microsoft en 2026
Microsoft après la disparition d’une stratégie GUI cohérente
- Depuis plus de 30 ans, la confusion autour de la stratégie GUI de Windows perdure, et il n’existe pas de réponse claire à la question : « quel framework faut-il utiliser pour créer une nouvelle application desktop Windows ? »
- En 1988, il existait un modèle unique, les API Win16/Win32, qui permettait aux développeurs d’écrire des applications selon une seule approche
- Au fil des décennies suivantes, Microsoft n’a pas réussi à maintenir une plateforme cohérente à cause de la politique interne, de décisions guidées par les démonstrations, et de changements de stratégie business
- Résultat : de Win32 à MAUI, 17 technologies GUI coexistent, et les développeurs évoluent dans une plateforme sans stratégie
- La cause fondamentale n’est pas un échec technique, mais un échec organisationnel
L’ère Petzold : la dernière période vraiment claire
- En 1988, Programming Windows de Charles Petzold (852 pages) constituait l’unique réponse de référence pour manipuler l’API Win16 en C ; c’était cela, la stratégie de développement Windows
- Win32 a ensuite gagné en ampleur, mais a conservé un modèle mental unique fondé sur la boucle de messages, la procédure de fenêtre et GDI ; Petzold l’expliquait, et les développeurs pouvaient l’apprendre puis l’utiliser immédiatement
- « Un OS, une API, un langage, un livre » — cette clarté était un signal de confiance pour la plateforme
La vague orientée objet (1992–2000) : le début de la complexité
- En 1992, MFC a encapsulé Win32 en C++, mais OLE, COM et ActiveX sont ensuite apparus, et des architectures de composants, plutôt que de véritables frameworks GUI, ont fini par envahir l’ensemble du développement Windows
- Au lieu de proposer une histoire cohérente, Microsoft a fourni seulement des primitives techniques à assembler soi-même ; cette situation s’explique par une culture d’annonce centrée sur les keynotes de conférences, où l’impression donnée aux dirigeants passait avant la réussite des développeurs
PDC 2003 Longhorn : quand la vision se dévore elle-même
- Présenté à la PDC 2003, Longhorn reposait sur une vision convaincante articulée autour de trois piliers : WinFS (système de fichiers relationnel), Indigo (communications unifiées) et Avalon (UI XAML accélérée par GPU)
- En janvier 2004, une note interne de Jim Allchin l’a qualifié de « cochon » ; en août de la même année, un reset complet du développement a été annoncé — retour à la base de code de Server 2003
- Après ce reset, la direction a imposé la consigne « pas de managed code dans Windows, tout nouveau code en C++ » ; WPF est bien sorti avec Vista, mais le shell lui-même n’utilisait pas WPF
- Cette décision a déclenché une guerre civile interne de 13 ans entre l’équipe Windows et l’équipe .NET, menant au final à l’abandon de WPF, à la mise au rebut de Silverlight et à l’échec d’UWP
Silverlight : l’établissement d’un schéma répétitif (2007–2010)
- WPF est sorti fin 2006, mais en 2007, Silverlight est apparu comme plugin navigateur pour répondre à Flash, fragmentant aussitôt les investissements de développement
- Lors de la conférence MIX 2010, un dirigeant de Microsoft a déclaré pendant la session de Q&A que « Silverlight n’était pas une stratégie cross-platform, mais une stratégie Windows Phone » — l’équipe Silverlight n’en avait pas été informée à l’avance, et les développeurs qui avaient investi leurs applications métier dans Silverlight l’ont appris pour la première fois pendant cette Q&A
- La fin de Silverlight n’a pas été causée par un échec technique, mais par un changement de stratégie business ; c’est aussi à ce moment que s’est installée la logique selon laquelle les développeurs sont toujours informés en dernier
Metro et la guerre des deux équipes (2012)
- En réponse aux 200 millions d’iPhone vendus par Apple et à l’empiètement de l’iPad sur le PC, Microsoft a lancé Windows 8 et Metro ; pourtant, WinRT a été conçu délibérément non pas comme un runtime .NET, mais comme un runtime natif C++ — reflet direct de l’hostilité de l’équipe Windows envers .NET
- À //Build 2012, les développeurs ont reçu simultanément des messages contradictoires : « l’avenir est WinRT, HTML+JS est citoyen de première classe, .NET fonctionne toujours, C++ est de retour, on peut écrire des apps Metro, et le code WPF continue aussi de fonctionner »
- Les développeurs d’entreprise ont immédiatement décroché après avoir constaté le sandboxing d’UWP, les exigences de distribution via le Store, et l’absence de certaines API Win32 — « l’app store pour tablettes ne s’est jamais concrétisé »
La confusion UWP et WinUI (2015–aujourd’hui)
- Avec Windows 10, UWP (Universal Windows Platform) portait la vision « écrire une fois, exécuter partout » sur PC, téléphone, Xbox et HoloLens ; mais avec le déclin de Windows Phone, puis le fait que les propres applications phares de Microsoft (Office, Visual Studio, le shell) n’utilisent pas UWP, le signal est devenu limpide
- La réponse officielle a fini par devenir « ça dépend » — entre UWP, le maintien de WPF, XAML Islands, l’attente de WinUI 3, la coexistence avec WinUI 2, la sortie de Project Reunion puis son renommage en Windows App SDK, la confusion n’a fait que croître
- Project Reunion / WinUI 3 représente un progrès technique, mais son existence même découle d’un problème organisationnel : les contrôles UWP étaient liés à l’OS, et l’équipe .NET comme l’équipe des outils de développement n’en avaient pas la maîtrise
- Le témoignage d’un développeur en 2024 : « UAP, UWP, le remplacement de C++/CX par C++/WinRT (sans support outillage), XAML Islands, XAML Direct, le redémarrage Project Reunion, WinAppSDK, la transition confuse entre WinUI 2.0 et 3.0… 14 ans, 14 pivots »
Un zoo sans gardien : l’inventaire actuel des technologies GUI sous Windows
Frameworks natifs Microsoft :
- Win32 (1985) — toujours utilisé, le livre de Petzold reste toujours valable
- MFC (1992) — en mode maintenance, encore présent dans l’entreprise et la CAO
- WinForms (2002) — « utilisable mais non recommandé », reste imbattable en vitesse pour les formulaires de saisie
- WPF (2006) — XAML, rendu DirectX, open source, sans nouvel investissement de Microsoft
- WinUI 3 / Windows App SDK (2021) — réponse « moderne » officielle, avec une roadmap incertaine
- MAUI (2022) — successeur cross-platform de Xamarin.Forms, pari actuel de l’équipe .NET
Hybrides web Microsoft :
- Blazor Hybrid — composants .NET Razor dans une WebView native
- WebView2 — Chromium embarqué dans des applications Win32/WinForms/WPF
Tiers :
- Electron — Chromium + Node.js, adopté par VS Code, Slack et Discord, actuellement la technologie GUI desktop la plus largement déployée sur Windows, mais sans lien avec Microsoft
- Flutter (Google), Tauri (basé sur Rust), Qt (C++/Python/JS), React Native for Windows (soutenu par Microsoft mais fondé sur une technologie Facebook)
- Avalonia — héritier open source spirituel de WPF, adopté par des développeurs qui n’ont pas attendu Microsoft comme JetBrains, GitHub ou Unity
- Uno Platform — plus engagé envers WinUI que Microsoft lui-même
- Delphi/RAD Studio, Java Swing/JavaFX — toujours présents dans certains marchés verticaux et en entreprise
→ 17 approches, 5 langages de programmation, 3 philosophies de rendu — ce n’est pas une « plateforme »
Diagnostic central
- Toutes les initiatives GUI ayant échoué se ramènent à l’une de ces trois causes : la politique entre équipes (Windows vs .NET), des paris de plateforme trop précoces guidés par les annonces en conférence (Metro, UWP), ou des changements de stratégie business sans information préalable des développeurs (Silverlight)
- Les technologies elles-mêmes étaient souvent excellentes — WPF excellent, Silverlight excellent, XAML excellent — l’échec organisationnel est devenu l’échec du produit
- Sans Plausible Theory of Success couvrant tout le cycle de vie « adoption–investissement–maintenance–migration », on n’a pas une stratégie, mais seulement une keynote de conférence
- Charles Petzold a révisé Programming Windows jusqu’à sa 6e édition pour suivre les nouveautés annoncées par Microsoft, mais a cessé d’écrire après cette 6e édition consacrée à WinRT (Windows 8)
2 commentaires
Encore Win32, du début à la fin ?!!
Réactions sur Hacker News
Le problème de fond, c’est que Microsoft essaie de régler la cohérence de l’interface graphique uniquement au niveau de la couche framework
Ils sortent sans arrêt de nouveaux frameworks comme WinForms, WPF, UWP, WinUI, puis finissent par les abandonner
Apple, au contraire, considère le système de design comme un produit en soi, et rend les frameworks invisibles, alors que Microsoft fait l’inverse à chaque fois
Tu veux aussi donner des exemples côté Apple ?
De nos jours, WPF essaie d’imiter l’apparence de WinUI, donc Microsoft fait quand même des efforts
Ça reste encore l’une des voies officielles dans la stack .NET actuelle
WinForms reste séduisant
Avec WebView2, développer des applis hybrides est devenu simple, et on peut aussi partir sur du tout-web, mais le ressenti du chrome natif est meilleur
Tous nos clients sont sur Windows, donc on ne se bat pas contre ça
En ce moment, je construis un assistant IA avec .NET10 + WinForms + WebView2
Je n’ai aucune envie d’itérer sans fin sur une interface d’historique de conversation en pur WinForms
Je ne suis pas d’accord avec l’idée que « WPF était bien »
À la fin des années 2000, les applis WPF étaient lentes sur le matériel grand public
Par exemple, Logos Bible Software était une simple appli de texte, mais demandait quand même des performances graphiques, au point de ramer sur de vieux portables
Plus tard, j’ai découvert que Logos 4 reposait sur WPF, et il y avait beaucoup des mêmes plaintes dans ce fil de forum
On a fini par réimplémenter la majeure partie du code en Direct3D/Direct2D
Le problème venait de l’architecture même de WPF
La raison invoquée était le texte flou et les problèmes de performances
Articles liés : edandersen.com / Reddit
Article lié : Ars Technica
Au fond, les débats sur les performances reviennent à chaque époque
Apple rencontre aussi des problèmes similaires en passant d’AppKit/UIKit à SwiftUI
Quand ChatGPT a explosé au départ, intégrer dans Bing une version capable d’accéder au web était une idée géniale
Mais Microsoft n’a pas bien géré les détails d’implémentation, comme la compression du contexte, donc les conversations se retrouvaient vite bloquées
OpenAI, Perplexity et d’autres l’ont bien implémenté, et c’est maintenant devenu la norme
Si Microsoft l’avait bien fait à l’époque, ils auraient peut-être pu remplacer Google
Au final, le problème venait d’un manque de finition dans l’UI/UX, que j’attribue à l’absence de cohérence dans la culture interne
Ça m’agaçait qu’Apple empêche le bundling de bibliothèques UI, mais c’est aussi ce qui a permis de préserver la cohérence de l’interface
La plupart des utilisateurs ne s’en soucient pas
Quelqu’un continue de copier-coller une histoire de dîner avec des dirigeants de Microsoft, selon laquelle Microsoft serait entièrement focalisé sur l’entreprise
Mais en réalité, même les entreprises s’éloignent à cause de la baisse de qualité de Windows et d’Azure
Dans notre boîte, on a subi des problèmes de SLA sur Azure, sans aucune compensation
Donc on réduit notre dépendance à Active Directory et à Windows
Au final, il n’existe pas de marché entreprise sans utilisateurs
Depuis Win32, Microsoft n’a jamais poussé une seule direction pendant plus de deux ans
WinRT était correct, puis Nadella est arrivé, a recentré l’entreprise sur Azure et a abandonné la plateforme Windows
En passant de Windows à Office puis à Azure, son identité est devenue floue
Office existe à la fois sur le web et sur desktop, ils ont aussi du matériel et un store
La vision de Satya Nadella n’est pas clairement communiquée
Le store était mauvais, et le projet ne servait qu’à faire avancer des carrières en interne
Le problème, c’est que Microsoft continue de sortir de nouveaux frameworks GUI, mais malgré tout, on peut toujours écrire des applis Win32
Microsoft s’est orienté vers le web depuis longtemps, et a aussi contribué aux progrès de technologies comme AJAX, Flexbox et Grid
Je développe surtout des systèmes multiplateformes en web, Java et Python
Je n’ai aucune raison particulière de créer une GUI réservée à Windows
Les applis web sont plus flexibles et plus accessibles
Le web fonctionne partout, et avec PWABuilder, on peut même publier sur les app stores
Je participe à ce projet, et on peut créer des applis rapides et légères sans Electron
Les documents sur Active Desktop montrent qu’à l’époque c’était assez expérimental
Le web reste un pis-aller ; les vraies bonnes expériences viennent du natif
Vers 2007, je suis passé de Delphi à WPF, mais en 2010 j’ai complètement quitté Windows
La politique interne de Microsoft et l’abandon fréquent des technologies étaient devenus excessifs
Rails montait à ce moment-là, donc changer était facile
C’est peut-être un syndrome de Stockholm, mais Visual Studio repose toujours sur WPF, donc ça ne m’inquiète pas
C’était en quelque sorte un avant-goût des problèmes des big tech actuelles
Steven Sinofsky a récemment publié un billet sur le même sujet
Lien x.com
Il était chez DevDiv à l’époque de WinRT, mais l’équipe Windows ne comprenait pas les besoins des développeurs
Il existait même un prototype Python/WinRT, mais il a été abandonné au motif que « les développeurs ne veulent que du JS »
Ils ont aussi imposé le style Metro jusqu’à mettre tous les menus de Visual Studio en majuscules
Windows RT a en plus cassé la compatibilité, donc il y avait très peu d’applis, et ça a fini par échouer
Même certaines affirmations techniques de Sinofsky sont fausses (.NET 3.0 était déjà inclus dans Vista)
xcancel.com ne prend pas encore cette fonction en charge
La réponse est simple : Qt
Ce n’est pas une blague : si on n’utilise pas Electron, Qt est une vraie alternative
Pour Qt, c’est le cœur de métier, donc ils ne changent pas souvent de direction