Lorsque vous cliquez avec le bouton droit sur un fichier ou lancez une application de bureau traditionnelle dans Windows 11, vous avez en fait toujours affaire à un ancien code né avant l'Internet commercial : l'API Win32, qui remonte à l'ère Windows 95, est toujours une couche de base importante du système d'exploitation de bureau le plus populaire d'aujourd'hui et, selon les dirigeants de Microsoft, cela ne faisait pas initialement partie du plan à long terme de l'entreprise.
Dans une vidéo récente publiée par le compte officiel Dev Docs de Microsoft, Mark Russinovich, directeur de la technologie de Microsoft Azure et fondateur de la suite Sysinternals, a déclaré sans détour que Win32 peut encore être une API de niveau « citoyen de première classe » en 2026, ce qui est l'une des choses les plus inattendues de l'histoire de l'entreprise. Il a même plaisanté en disant que les gens de l'époque rêvaient de voitures volantes et de bases lunaires, plutôt que d'un ensemble d'API nées à l'époque de Windows 95 et qui peuvent encore être utilisées aujourd'hui.
La clé pour que cette API vieille de 30 ans puisse survivre jusqu'à ce jour et rester forte même après avoir été « déclarée terminée » à plusieurs reprises au sein de Microsoft réside dans l'énorme écosystème d'applications construit sur elle. Russinovich a décrit Win32 comme le « fondement » de Windows sur lequel d'innombrables applications sont construites, de sorte que tout remplacement pur et simple entraînerait un coût énorme. Il a cité en exemple les outils Sysinternals qu’il a fondés en 1996. S'il avait parié à l'époque, il aurait « parié un million de dollars » que ces outils n'auraient plus de valeur en 2026, mais la réalité est la suivante : non seulement ils ont survécu, mais ils sont plus importants que jamais. Par exemple, Sysmon a été intégré directement à Windows dans la mise à jour de mars 2026, tandis que ZoomIt, né au début des années 2000, reste aujourd'hui l'un des gadgets les plus populaires de PowerToys.
Cependant, la « vitalité » de Win32 ne signifie pas que Microsoft n’a jamais tenté de changer la donne. Au contraire, au cours des deux dernières décennies, Microsoft a presque construit un « cimetière de frameworks alternatifs ». Au sein de Microsoft, les efforts visant à « tuer Win32 » n'ont presque jamais cessé. Afin de résoudre les problèmes de modernisation visuelle et interactive des applications bureautiques traditionnelles, Microsoft a lancé successivement MFC (encapsulation C++) et WinForms pour les développeurs .NET. Bien qu'il s'agisse encore essentiellement d'encapsulations de Win32 plutôt que de remplacements, il s'agit des premières tentatives de Microsoft en matière d'abstraction de la couche application. Le véritable « projet de remplacement » a commencé avec l'introduction par WPF de XAML et du rendu accéléré par le matériel, suivi d'un bref pari sur le multiplateforme avec Silverlight - une approche qui a finalement été progressivement abandonnée à la suite de l'essor du HTML5.
La tentative alternative la plus radicale est apparue à l'ère de Windows 8 : Microsoft a lancé WinRT, dans l'espoir que les développeurs créeraient de nouvelles applications sûres, conviviales et fonctionnant en plein écran, et rénoveraient ainsi complètement la forme des applications Windows. Cependant, comme l'interface de Windows 8 a rencontré un accueil froid sur le marché, la société s'est tournée vers la plate-forme Windows universelle (UWP) sur Windows 10, mettant l'accent sur « une plate-forme d'applications unifiée sur les téléphones mobiles, la Xbox et les PC ».
UWP est trop fermé et impose des restrictions strictes en matière de sandbox, ce qui contraint sérieusement les développeurs de postes de travail traditionnels qui ont besoin d'un accès approfondi aux ressources système. Russinovich a également admis dans la vidéo que Microsoft avait tenté de « redémarrer » la surface de l'API Windows à plusieurs reprises dans l'histoire, comme WinRT, mais en raison de la séparation constante entre le client lourd et Win32, et le HTML et JavaScript du côté du navigateur, ces tentatives n'ont finalement pas abouti comme prévu.
De multiples défaillances du framework ont amené les développeurs à perdre progressivement confiance dans la plate-forme native de Microsoft. C'est l'une des raisons importantes pour lesquelles l'écosystème des applications de bureau Windows s'est déplacé vers le Web. Dans un rapport précédent, un développeur déclarait sans ambages qu'investir dans un framework natif dans l'écosystème de Microsoft commençait à devenir un « fardeau ». Personne n’est prêt à parier des années de développement sur une plateforme qui peut être abandonnée à tout moment. Ironiquement, c'est Microsoft lui-même qui a pris l'initiative d'adopter le Web : il a lancé le contrôle WebView2, intégré le moteur Microsoft Edge basé sur Chromium dans les applications de bureau, puis l'ensemble du système a été couvert d'applications Web - de Microsoft Teams, Clipchamp, la nouvelle version d'Outlook, OneDrive, au panneau de widgets de Windows 11, et même la dernière version de Copilot existe sous la forme d'applications Web.
Les avantages des applications Web en termes de coûts de développement et de maintenance multiplateforme sont évidents. Cependant, dans un environnement de bureau traditionnel, ce modèle est extrêmement inefficace en termes d'utilisation des ressources. Chaque application embarque un moteur de navigation complet, quasiment voué à provoquer un désastre mémoire. Les clients Web consomment également beaucoup de mémoire tout en « ne faisant presque rien », tandis que les premières implémentations natives basées sur UWP étaient beaucoup plus légères. Clipchamp, l'éditeur vidéo intégré de Microsoft, est également une application Web. Outre les problèmes de performances et de consommation de ressources, il était également lié de force à la synchronisation cloud OneDrive, ce qui l'a finalement incité à abandonner l'utilisation de cet outil. La comparaison de cette expérience avec macOS met en évidence l'écart : les utilisateurs Apple peuvent utiliser gratuitement des applications telles que iMovie et Pages qui sont hautement localisées et étroitement intégrées au système, tandis que de nombreux utilisateurs fidèles de Windows sont obligés de s'appuyer sur des solutions Web comme Clipchamp qui nécessitent une connexion réseau, manquent d'intégration système approfondie et ont une empreinte mémoire élevée.
Après qu'Apple ait lancé un ordinateur portable économique à moins de 600 dollars et connu du succès, Microsoft a commencé à réexaminer sa stratégie d'application et s'est rendu compte que transformer Windows en un « type Chrome OS » ne répondait pas aux attentes des gros utilisateurs et nuisait en réalité aux performances du système. Il y a quelques mois, l'architecte partenaire de Microsoft, Rudy Huyn, confirmait publiquement qu'il formait une équipe dédiée à la construction d'applications Windows 11 « 100 % natives ». L'entreprise se concentre de plus en plus sur WinUI 3, le dernier framework d'interface utilisateur natif basé sur le SDK d'application Windows. WinUI 3 a le potentiel d'être la clé de Microsoft pour regagner la confiance des développeurs : il peut non seulement fournir une expérience d'interface moderne conçue par Fluent, mais également permettre aux applications d'avoir un accès complet et sans entrave au « fondement » sous-jacent de Win32. Microsoft a également récemment publié une mise à jour majeure du SDK Windows App 2.0, qui apporte une gestion des versions sémantiques, une pile Windows ML restructurée et une meilleure prise en charge du glisser-déposer aux développeurs pour intégrer de manière transparente le contenu WebView2 dans le shell WinUI 3 natif.
Au niveau du système lui-même, Microsoft a également commencé à remplacer rythmiquement le plus ancien lot d'éléments d'interface Win32 par WinUI 3, au lieu d'adopter la stratégie de « redémarrage dur » de WinRT. La boîte de dialogue des propriétés de l'Explorateur de fichiers qui date de l'ère Windows 95 a été remplacée par l'interface WinUI 3 qui prend en charge le mode sombre complet.
La boîte de dialogue classique "Exécuter" (Win + R) a également été réécrite dans WinUI 3. La nouvelle version est clairement en avance en termes d'esthétique et n'est pas inférieure en termes d'expérience d'utilisation. Selon les données de test, cette nouvelle boîte de dialogue d'exécution compilée avec .NET AOT a un temps d'affichage médian de 94 millisecondes, ce qui est plus rapide que l'ancienne version qu'elle remplace, ce qui est considéré comme un signe que l'architecture WinUI 3 moderne est plus que capable d'égaler ou même de surpasser les performances du code Win32 traditionnel en termes de vitesse et d'efficacité.
À mesure que Microsoft remplace l'interface Web enveloppée dans WebView2 par des composants natifs WinUI 3 dans davantage de scénarios, la consommation inutile de ressources mémoire de Windows 11 diminuera progressivement et le système global devrait revenir à une direction légère, unifiée et native. Nous ne verrons peut-être pas de voitures volantes ou de bases lunaires en 2026, mais après des années d'expérimentation de framework et de changement de cap, Windows a une chance de devenir un système d'exploitation de bureau qui respecte son héritage Win32 tout en étant véritablement moderne.