Microsoft n'a plus de stratégie cohérente en matière d'interface graphique depuis Charles Petzold il y a plus de trente ans
l'écosystème actuel est fragmenté et qualifié de « zoo sans gardien »
Windows 11 n'a toujours pas trouvé sa stabilité cinq ans après son lancement. Le système d'exploitation se montre capricieux malgré des exigences matérielles élevées. Le pari de Microsoft sur l'IA tourne lui aussi aussi au cauchemar. Microsoft ne semble plus capable de concevoir un logiciel qui fonctionne. L'ingénieur logiciel Jeffrey Snover souligne l'absence critique de stratégie cohérente de Microsoft concernant les interfaces graphiques (GUI) depuis plus de trente ans. Il soutient que la société a délaissé la clarté de l'ère Win32 au profit d'une succession chaotique de frameworks incompatibles. Microsoft vient de connaître son pire trimestre à Wall Street depuis 2008.
Jeffrey Snover est ingénieur logiciel à la retraite. Avant de se retirer en 2026, il était ingénieur émérite chez Google et Technical Fellow chez Microsoft, où il occupait les fonctions d'architecte IA pour Office et d'architecte en chef pour Windows Server Azure Stack. Jeffrey Snover est également connu comme l'inventeur de Windows PowerShell, un moteur d'automatisation distribué basé sur les objets, un langage de script et un Shell en ligne de commande.
Jeffrey Snover a rejoint Microsoft en 1999 en tant qu'architecte de division au sein de la division Gestion et services, où il a assuré la direction technique de l'ensemble des technologies et des produits de gestion de Microsoft. Il a récemment publié une analyse sur l'évolution des interfaces graphiques chez Microsoft.
Selon Jeffrey Snover, la stratégie GUI de Microsoft a connu un déclin au cours des trente dernières années. Ce déclin est attribué à des conflits internes entre les équipes Windows et .NET, ainsi qu'à des décisions marketing privilégiant les effets d'annonce des conférences. Jeffrey Snover note qu'aujourd'hui, les développeurs font face à une multitude d'options fragmentées comme WPF, WinUI 3 ou Electron, sans directive claire de la part de l'éditeur.
En fin de compte, « l'instabilité chronique de ces technologies » a poussé de nombreux professionnels à abandonner les solutions natives de Microsoft. Les développeurs ont désormais du mal à répondre à une question simple : « quel est le framework approprié pour une nouvelle application de bureau Windows ? » Jeffrey Snover a souligné que cette confusion technique témoigne d'un échec organisationnel majeur au sein de la firme de Redmond.
L'âge d'or de la clarté chez Microsoft et le modèle Petzold
Dans les années 1980 et au début des années 1990, le développement sous Windows reposait sur une vision unique et faisant autorité. Charles Petzold, avec son ouvrage de référence sur l'API Win16 puis Win32, représentait cette époque où un seul système d'exploitation, une seule API et un seul langage (le C) définissaient la norme. Les développeurs réussissaient en apprenant un ensemble de règles stables, comparables aux lois de la physique.
Bien que le modèle mental de Win32 puisse paraître complexe, il était cohérent. Jeffrey Snover explique que cette période marque la dernière fois où Microsoft a pu répondre instantanément et de manière unique à la question de savoir comment construire une application Windows. « Lorsqu'une plateforme ne peut pas répondre à « Comment construire une interface utilisateur ? » en moins de dix secondes, elle a échoué. Point », a écrit un critique.
La clarté est votre alliée ! Il n'y avait pas de comité débattant des alternatives au code géré. Il n'y avait que Win32 et Charles Petzold, et ça marchait. D'après Jeffrey Snover, ce qui s'est passé ensuite est une véritable leçon de maître sur la façon dont une société dotée de personnes brillantes et d'énormes ressources peut produire 30 ans de gaffes en optimisant les mauvaises choses. Autrement dit : « des gens brillants qui font des choses stupides ».
Win32 avait des limitations réelles, donc Microsoft a fait ce que Microsoft sait faire : il a sorti quelque chose de nouveau pour la conférence des développeurs. Cependant, les nouveautés n'ont pas répondu aux attentes. Au contraire, elles ont progressivement contribué à fragmenter l'écosystème Windows.
Microsoft a progressivement installé le chaos au fil des ans
Pour répondre aux limites de Win32, la firme de Redmond a dévoilé plusieurs nouveautés. MFC (1992) a encapsulé Win32 en C++. Dans un son analyse, Jeffrey Snover explique notamment : « si Win32 manquait d’élégance, MFC était un Win32 vêtu d’un smoking fait d’autres smokings ». Microsoft a lancé ensuite OLE, COM et ActiveX. Aucun d’entre eux n’était vraiment un framework d’interface graphique ; il s’agissait d’architectures de composants.
Mais ils ont envahi tous les recoins du développement Windows et introduit un grand niveau de complexité cognitive. Selon l'ingénieur, Microsoft ne vendait pas un récit cohérent. Il vendait des primitives technologiques et disait aux développeurs de se débrouiller pour comprendre le récit par eux-mêmes.
En 2003, l'entreprise a dévoilé Longhorn. Trois piliers : WinFS (un système de fichiers relationnel), Indigo (communications unifiées) et Avalon, un sous-système d'interface utilisateur vectoriel accéléré par GPU, piloté par un langage XML déclaratif appelé XAML. Les développeurs ont vu les démos d'Avalon et étaient sidérés. C'était la grande vision. Selon les termes de la note interne de Jim Allchin datant de janvier 2004, c'était aussi « une merde ».
En août 2004, Microsoft a annoncé une remise à zéro complète du développement. Abandonné. Recommencer à partir du code source de Server 2003. Et après cette remise à zéro, la direction de Microsoft a émis une directive discrète : pas de code géré dans Windows. Tout le nouveau code en C++. WPF serait livré avec Vista, mais le Shell lui-même ne l’utiliserait pas. L’amertume de l’équipe Windows envers la plateforme .NET ne s’est jamais dissipée.
De leur point de vue, parier sur un nouveau framework de code géré avait entraîné l’échec le plus embarrassant de l’histoire de l’entreprise. Selon Jeffrey Snover, cette amertume a donné lieu à une guerre civile institutionnelle de treize ans entre l’équipe Windows et l’équipe .NET, qui allait finalement abandonner WPF, tuer Silverlight, condamner UWP et livrer le chaos d’écosystèmes d’interface graphique que toute la communauté connaît aujourd’hui.
L'impasse de la plateforme UWP et l'éparpillement actuel
Le WPF a été lancé fin 2006 : XAML, rendu accéléré par le matériel, liaison de données réelle. Si Microsoft en avait fait la solution définitive et y avait investi sans relâche, l'histoire aurait peut-être pris une autre tournure. Au lieu de cela, en 2007, il a lancé Silverlight : un plug-in de navigateur allégé destiné à concurrencer Flash, multiplateforme et qui allait servir de base à Windows Phone. Vers 2010, cela semblait être l'avenir des applications riches.
Puis, lors de la conférence MIX 2010, un dirigeant de Microsoft a déclaré lors d'une interview que Silverlight ne s'inscrivait pas dans une stratégie multiplateforme, mais concernait Windows Phone. HTML5 était désormais la ligne directrice. L'équipe Silverlight n'avait pas été prévenue de ce changement. Les développeurs qui avaient misé leurs applications métiers sur Silverlight l'ont appris lors d'une séance de questions-réponses lors d'une conférence.
Silverlight n'a pas été tué par un échec technique. Selon Jeffrey Snover, la technologie était bonne. Elle a été tuée par une décision de stratégie commerciale, et les développeurs ont été les derniers à le savoir. L'introduction d'UWP (Universal Windows Platform) avec Windows 10 n'a pas réussi à redresser la barre.
Même les applications phares de Microsoft comme Office ou Visual Studio n'utilisaient pas la plateforme de développement UWP. Les contraintes techniques de l'UWP, comme le sandboxing et l'obligation de passer par le Store, ont fini par décourager les développeurs d'entreprise. Aujourd'hui, l'écosystème UWP est devenu ce que Jeffrey Snover qualifie de « zoo sans gardien », avec dix-sept approches différentes coexistant sans une direction claire.
Il s'agit d'une faillite organisationnelle plutôt que technique
Windows ne propose plus un écosystème de développement cohérent aux développeurs. Cette fragmentation extrême a permis à des solutions tierces comme Electron de dominer le marché du bureau Windows, simplement parce que Microsoft n'a pas su offrir une alternative fiable et pérenne. Pour Jeffrey Snover les échecs successifs ne sont pas dus à des carences techniques, car des technologies comme WPF ou XAML étaient intrinsèquement bonnes.
Dans son analyse, Jeffrey Snover laisse entendre que la racine du mal réside dans la politique interne, les décisions de gestion précipitées par des annonces marketing et des pivots stratégiques brutaux qui ont laissé les développeurs orphelins à plusieurs reprises. Pour qu'une stratégie soit viable, elle doit couvrir tout le cycle de vie d'un produit, de l'adoption à la migration, plutôt que de se limiter à un effet d'annonce lors d'une présentation magistrale.
« Des gens brillants qui font des choses stupides. Un mouvement brownien technologique », a déclaré Jeffrey Snover. Ce qui considère comme un « zoo sans gardien » comporte une myriade de technologies. Voici toutes les technologies d'interface graphique actuellement disponibles sous Windows :
Frameworks natifs de Microsoft
- Win32 (1985) – Toujours présent. Toujours utilisé. Le livre de Charles Petzold reste d'actualité ;
- MFC (1992) – Enveloppe C++ sur Win32. En mode maintenance. Utilisé dans les environnements d'entreprise et la CAO ;
- WinForms (2002) – Enveloppe .NET sur Win32. « Disponible, mais déconseillé. » Toujours le plus rapide pour les formulaires de saisie de données ;
- WPF (2006) – XAML, rendu par DirectX, open source. Aucun nouvel investissement de Microsoft ;
- WinUI 3 / Windows App SDK (2021) : la réponse « moderne », mais avec une feuille de route incertaine ;
- MAUI (2022) : successeur multiplateforme de Xamarin.Forms. Le pari actuel de l'équipe .NET.
Hybride Web Microsoft
- Blazor Hybrid : composants .NET Razor dans une WebView native ;
- WebView2 : intégration de Chromium dans une application Win32/WinForms/WPF.
Solutions tierces
- Electron (Chromium + Node.js. VS Code, Slack, Discord) : la technologie d'interface graphique de bureau la plus répandue sous Windows à l'heure actuelle et Microsoft n'y est pour rien ;
- Flutter (Google) - Dart, moteur de rendu personnalisé, multiplateforme ;
- Tauri : Backend Rust, alternative légère à Electron ;
- Qt - C++/Python/JavaScript : l'option multiplateforme sérieuse ;
- React Native pour Windows : portage du framework mobile de Facebook soutenu par Microsoft ;
- Avalonia : successeur spirituel open source de WPF. Utilisé par JetBrains, GitHub, Unity (des développeurs qui ont cessé d’attendre Microsoft) ;
- Uno Platform - API WinUI sur toutes les plateformes : plus engagé envers WinUI que Microsoft lui-même ;
- Delphi / RAD Studio – Toujours vivant : toujours rapide, toujours présent dans les logiciels destinés aux marchés verticaux ;
- Java Swing / JavaFX.
Conclusion
L'échec de Microsoft à proposer une stratégie d'interface graphique cohérente depuis l'époque de Charles Petzold n'est pas dû à des lacunes techniques, mais à une faillite organisationnelle et politique durable. Selon Jeffrey Snover, les conflits internes entre les équipes Windows et .NET, couplés à des pivots stratégiques brutaux dictés par le marketing, ont fragmenté l'écosystème en un « zoo sans gardien » comptant dix-sept approches différentes.
Cette instabilité a fini par rompre la confiance des développeurs, les poussant vers des solutions tierces comme Electron pour pallier l'absence de direction claire de la part de Microsoft. Dans la communauté, cet état de choses est vivement critiqué. Pour redevenir une plateforme de choix, Microsoft doit désormais privilégier une vision stable couvrant tout le cycle de vie des applications plutôt que de multiplier les annonces éphémères lors de conférences.
Microsoft dépense des milliards de dollars pour imposer une IA que personne ne veut, pendant que ses équipes courent après des bogues qui empêchent Windows de fonctionner correctement. Les failles de sécurité sont multipliées dans Windows 11, y compris dans les utilitaires les plus légers tels que le Bloc-notes. Une faille a été récemment découverte dans Bloc-notes, causée par ses dernières fonctionnalités « innovantes », notamment Markdown.
En face, Apple fait quelque chose de plus simple : l'entreprise lance un ordinateur qui fonctionne, à un prix que personne n'attendait d'elle. Apple n'a pas gagné cette bataille à coups d'innovation fracassante. Il l'a gagnée par contraste, en faisant simplement ce que Microsoft ne fait plus : livrer un produit fini.
Source : billet de blogue
Et vous ?
Quel est votre avis sur le sujet ?
Que pensez-vous de l'état de l'écosystème de développement sur Windows ?
L'ingénieur Jeffrey Snover qualifie cet état de choses de « zoo sans gardien ». Qu'en pensez-vous ?
Microsoft ne semble plus capable de concevoir un logiciel qui fonctionne. Qu'en pensez-vous ?
Microsoft peut-il encore proposer une meilleure solution unifiée que les alternatives tierces telles que le projet Electron ?
Voir aussi
Macbook Neo : Apple lance un ordinateur portable bas de gamme à 599 dollars, tandis que Microsoft s'enlise avec un Windows 11 bogué et défectueux, ainsi qu'une IA très coûteuse dont personne ne veut
Microsoft enregistre son pire trimestre à Wall Street depuis 2008 en raison des inquiétudes liées à l'IA : l'action chute de 23 % au premier trimestre, effaçant près d'un quart de sa valeur
Microsoft reconnaît que Windows 11 souffre d'un problème de confiance et promet de se concentrer sur les corrections en 2026, donnant la priorité absolue aux performances, fiabilité et expérience de l'OS








Quel est votre avis sur le sujet ?
Répondre avec citation









Partager