Microsoft tente de reconstruire l’écosystème des applications Windows autour de WinUI au moyen d’agents d’intelligence artificielle, plutôt que de s’appuyer sur les processus traditionnels de développement et de migration, qui nécessitent l’écriture manuelle de grandes quantités de code. L’entreprise affirme qu’un nouveau guide rapide permet de créer une application WinUI 3 à partir d’un dossier vide, puis de la tester, de la conditionner au format MSIX et de l’envoyer au Microsoft Store en environ 30 minutes.
Le parcours proposé ne nécessite pas l’installation de Visual Studio et repose sur VS Code, .NET 10, Windows App Development CLI, des modèles de projets WinUI et une version gratuite de GitHub Copilot, ainsi que sur l’extension WinUI Agent. L’article précise que les outils utilisés sont gratuits et que l’intervention manuelle lors des étapes de création de l’application, d’ajout des fonctionnalités, de test et de conditionnement peut être considérablement limitée.
Qu’apporte l’outil WinUI Agent ?
Il ne faut pas confondre WinUI Agent avec Copilot en tant qu’assistant conversationnel généraliste. L’outil est conçu pour des tâches liées au développement d’applications WinUI, notamment la conception de l’interface, la révision du code, le test de l’interface utilisateur, le conditionnement des applications et la migration de projets fondés sur des frameworks plus anciens. Microsoft recommande également de relier l’agent au serveur Microsoft Learn MCP afin qu’il puisse consulter la documentation la plus récente de l’API WinUI pendant l’exécution des requêtes et des tâches.
Ce point est important, car WinUI 3 ne dispose pas, selon l’analyse de l’article, du même volume d’exemples d’entraînement disponibles pour les modèles d’intelligence artificielle que WPF et UWP. L’agent peut donc générer automatiquement des approches anciennes s’il ne reçoit pas d’instructions explicites concernant les alternatives modernes à utiliser.
La migration ne se résume pas à une recherche et un remplacement
Microsoft propose également des directives spécifiques pour migrer les applications WPF et UWP vers WinUI. Dans le cas de WPF, le processus ne se limite pas à remplacer les noms des espaces de noms : le passage de System.Windows.* à Microsoft.UI.Xaml.*, par exemple, implique de gérer des différences concernant les contrôles, la gestion des threads, la gestion des fenêtres, la prise en charge des écrans DPI et la liaison de données. L’entreprise fournit des tableaux de correspondance et des instructions initiales qui aident l’agent à examiner ces aspects.
Les directives concernant UWP expliquent quant à elles que la plateforme n’est plus activement développée et que WinUI 3 et Windows App SDK constituent la voie qui lui succède. Microsoft avertit que les modèles d’intelligence artificielle, entraînés sur un grand nombre d’exemples UWP accumulés au fil des années, peuvent continuer à générer les approches UWP traditionnelles si les compétences de migration ne précisent pas les alternatives à employer.
Pourquoi cette actualité est-elle importante ?
L’objectif plus large est de réduire le coût d’introduction de nouvelles applications natives dans Windows et d’alléger la charge liée à la migration d’un grand nombre d’applications WPF et UWP. Microsoft compte ainsi s’attaquer à l’une des raisons qui poussent les développeurs à privilégier les applications web et les frameworks multiplateformes : la possibilité de réutiliser le code sur différents systèmes, tout en évitant de dépendre d’un framework Windows susceptible d’évoluer radicalement à l’avenir.
Lors de la conférence Build 2026, Microsoft a décrit WinUI comme « la plateforme de production pour les applications Windows », et a supprimé le chiffre « 3 » du nom afin de faire passer le message que la plateforme ne fera plus l’objet d’une reconstruction complète à l’avenir. Parmi les autres promesses figurent une réduction de la consommation mémoire, l’ajout de la prise en charge de DataGrid et des graphiques, une meilleure compatibilité avec WPF, une extension de la participation open source, ainsi que l’indication que WinUI est désormais entièrement open source.
Microsoft utilise également WinUI 3 pour remplacer certains composants anciens de l’interface de Windows 11, notamment les fonctionnalités de lecture automatique et de gestion de l’impression, selon l’article. Cette utilisation interne fournit à l’entreprise un argument concret lorsqu’elle demande aux développeurs d’adopter la technologie, mais révèle en même temps une norme à laquelle Microsoft devra elle-même se conformer.
Les limites que la génération de code ne résout pas
Réduire le nombre de lignes écrites par le développeur ne signifie pas nécessairement améliorer la qualité de l’application. L’article indique que Microsoft a doté WinUI Agent de capacités de révision et de test précisément parce que le code généré doit être contrôlé. De plus, pousser les développeurs vers des applications natives ne suffira pas si cela aboutit à des applications gourmandes en mémoire ou lentes.
Un paradoxe apparaît ici dans la stratégie de Microsoft : l’entreprise encourage les développeurs à créer des applications natives plus légères, mais utilise WebView2 dans certaines de ses applications et dans les interfaces mêmes de Windows. L’article précise que l’application Météo de Windows 11, fondée sur WebView2, consomme environ 1,2 Go de mémoire au repos, soit près de cinq fois plus que l’application météo native de macOS, tout en exécutant neuf processus enfants Chromium. Des applications telles que WhatsApp, Discord et Teams font également l’objet de critiques liées aux performances ou à la consommation de ressources, selon les exemples cités dans la source.
Analyse de certi.news : le véritable changement ne consiste pas simplement à ajouter un assistant de programmation, mais à tenter de relier l’ensemble du cycle de développement de Windows à un agent capable de créer, migrer, tester et conditionner l’application. Le succès du plan dépendra de deux points que les outils n’ont pas encore démontrés : la précision de la migration dans les projets réels et la question de savoir si les applications WinUI générées par l’intelligence artificielle surpasseront effectivement, en matière de performances et de consommation de ressources, les applications web que Microsoft cherche à concurrencer. L’initiative semble donc prometteuse pour les développeurs Windows, mais elle ne supprime pas la nécessité d’une révision technique et de tests pratiques.