Vivaldi 8.2 vient tout juste de paraître. À son bord, plusieurs nouvelles fonctions, dont la simplification de la calculatrice, qui peut désormais s’utiliser directement dans la barre d’adresse.

Les opérations y sont réalisées en temps réel, un appui sur Entrée envoyant les informations dans le presse-papier. Vivaldi précise que ces entrées ne sont pas enregistrées, même pas dans l’historique. Pour les personnes qui préféraient réserver cette fonction aux commandes rapides, une option permet de désactiver la calculatrice dans la barre d’adresse.

Vivaldi 8.2 renforce également la découverte des PWA (Progressive Web Apps). Le changement consiste surtout en un bouton apparaissant à droite de la barre d’adresse quand une application web compatible est découverte, par exemple WhatsApp. Après un clic sur le bouton, un petit panneau apparait pour confirmer l’installation. Une PWA profite, pour rappel, de certains comportements intégrés du système utilisé. Sur Windows par exemple, on peut l’épingler à la barre des tâches et dans le menu Démarrer. Chaque application a ses propres réglages.

Si les notes de version sont plus courtes que d’habitude, elles se finissent sur une annonce importante : Vivaldi travaille sur une version entreprise. L’éditeur dit viser « les organisations de toutes tailles – des entreprises et institutions publiques aux écoles ». Il donne peu d’informations pour l’instant, évoquant simplement une gestion de la vie privée, le déploiement centralisé et les mises à jour, ainsi que des personnalisations pour les organisations.

L’arrivée de cette version pourrait être significative pour Vivaldi. Viser le marché des entreprises implique notamment un cycle dédié de parution des mises à jour, pour pouvoir corriger les bugs et failles de sécurité, sans toucher au cycle fonctionnel. C’est ce que fait par exemple la version ESR de Firefox. Chrome et Edge disposent eux aussi d’une telle version, mais sur un délai bien plus court de huit semaines, via le canal Extended Stable.

L’Organisation européenne pour la recherche nucléaire utilise Linux pour ses besoins depuis longtemps. Dès les années 1990, le CERN s’était créé sa propre distribution en se basant sur Red Hat. En 2004, il s’était associé au Fermilab pour créer Scientific Linux (également basée sur Red Hat), avant d’entamer en 2015 une migration vers CentOS. En 2022, après l’annonce – très mal reçue – de Red Hat sur la fin de CentOS au profit de CentOS Stream, le CERN avait décidé de migrer vers AlmaLinux, autre distribution compatible Red Hat.

Le laboratoire a cependant décidé de se détourner de Red Hat, comme le rapporte Phoronix, qui a assisté à la conférence MiniDebConf, à laquelle participait le CERN. Les ingénieurs avaient bien, dans un premier temps, considéré un passage vers CentOS Stream, mais l’obligation du niveau d’instructions -march=x86-64-v2 par défaut à la compilation a été perçue par le CERN comme une forme d’« obsolescence forcée » pour le matériel ancien.

Le niveau d’instruction est un découpage artificiel permettant de cibler un lot de fonctionnalités au sein du processeur. Le niveau v2 mentionné correspond à une bascule effectuée par Red Hat Enterprise Linux 9, ce qui impliquait notamment les instructions SSE 4.2. RHEL 10 a imposé le niveau v3, qui nécessitait par exemple les instructions AVX2, FMA ou encore VEX. Ce découpage, nommé ISA (Instruction Set Architecture), a été violemment critiqué par Linus Torvalds fin 2024. Il estimait notamment la classification « stupide », car elle donnait l’impression erronée que la progression des jeux d’instruction était linéaire.

Le CERN avait, quoi qu’il en soit, pris bonne note des changements imposés par Red Hat. Lors de la conférence, le laboratoire a donc annoncé qu’une transition étant en préparation : d’ici la fin de l’année, l’intégralité du parc informatique fonctionnera sous Debian 13. Au total, 2 200 ordinateurs industriels et systèmes embarqués, utilisés pour le contrôle des accélérateurs de particules, seront concernés. En revanche, les centres de données et l’informatique expérimentale restent pour l’instant sur RHEL ou AlmaLinux.

Promis, cette fois c'est différent

WinUI est désormais un projet entièrement hébergé dans un dépôt GitHub, les ingénieurs de Microsoft y travaillant directement. Les travaux devraient donc accélérer et les prétentions de l’entreprise sont nombreuses, mais elle a souvent agacé les développeurs avec sa feuille de route incohérente.

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).