Fin août 2026, Microsoft a achevé la dernière phase d’un plan annoncé en juillet 2025 : faire du développement de WinUI un processus véritablement public sur GitHub. Ce kit de développement, qui se focalise sur les interfaces des applications pour Windows, est considéré désormais comme pleinement open source.

Ce n’est pas un changement de licence, car le dépôt est sous licence MIT depuis décembre 2018. Le vrai changement vient du développement quotidien, qui se déroule entièrement dans le dépôt. Jusqu’à présent, ce dernier était seulement un miroir de code déjà écrit en interne. Autrement dit, le dépôt était secondaire, dans la mesure où l’éditeur ne faisait qu’y reverser ce qu’il élaborait, sans vraiment tenir compte des contributions extérieures.

Les ingénieurs de Microsoft compilent, valident et testent dorénavant leurs modifications directement dans le dépôt public, avec la traçabilité associée. On peut cependant formuler deux réserves. D’une part, les pull requests fusionnées proviennent exclusivement des développeurs Microsoft pour l’instant, a priori dans l’idée de valider complètement le pipeline de production avant de l’ouvrir aux contributions externes. D’autre part, le compilateur XAML – essentiel pour WinUI – reste fermé. Lors de la conférence Build, Microsoft a indiqué qu’elle souhaitait d’abord en moderniser le code, avant de l’ouvrir à la communauté. Aucune date n’a été donnée.

Microsoft semble sérieuse, mais…

Cette bascule s’inscrit dans un contexte plus large. Microsoft a affirmé, lors de la conférence Build 2026, un engagement fort envers WinUI comme plateforme native de Windows 11, au point d’abandonner l’appellation « WinUI 3 » pour éviter de laisser croire à une future « rupture » technologique. Depuis plusieurs mois, à travers l’initiative « K2 » pour Windows 11, Microsoft insiste largement sur les performances et les interfaces natives sur son système. L’éditeur semble décidé à utiliser ses propres technologies, notamment pour le menu Démarrer, jusqu’ici développé avec React Native.

La question du sérieux de Microsoft reste toutefois débattue dans la communauté de développeurs, qui garde un souvenir circonspect de l’historique WinRT/UWP. Des éléments plaident en faveur d’une vraie volonté, dont le respect (globalement) du calendrier fixé et la traçabilité du travail des ingénieurs sur le dépôt. Microsoft sait en outre qu’elle est attendue au tournant. Mais l’historique de l’entreprise sur les interfaces ne plaide pas en sa faveur, après avoir réinventé plusieurs fois la roue ces quinze dernières années.

… de nombreuses promesses n’ont pas été tenues

Si Microsoft renforce son propre usage de WinUI, le framework devrait rapidement évoluer. Les reproches sont tenaces, notamment des performances pas à la hauteur des prétentions « natives », mais de gros travaux sont en cours. Beaucoup reprochent également à l’éditeur son manque de suivi entre UWP, WinUI 2 et 3, avec une absence notable de parité fonctionnelle. Un écosystème souvent jugé incohérent et fragmenté.

Les tickets se sont aussi accumulés depuis deux ans et WinUI traine un certain nombre de casseroles techniques. Par exemple, un bug connu depuis longtemps provoque un plantage des applications utilisant à la fois WinUI 3 et le trimming, qui doit réduire la taille des exécutables en supprimant le code non utilisé. La faute à un conflit avec le fonctionnement de XAML, qui s’appuie lourdement sur la réflexion à l’exécution (résolution de types par nom, liaison de données, convertisseurs, gestionnaires d’événements déclarés en XAML).