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