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

Cascades effectuées par des professionnels

La publication de plusieurs rapports techniques sur l’incident ayant conduit des agents IA d’OpenAI à attaquer Hugging Face permet aujourd’hui de mieux comprendre ce qui s’est passé. La chronologie est surprenante et pointe vers de nombreuses défaillances internes, mais le marketing continue de battre son plein.

Le 22 juillet, on apprenait que l’attaque enregistrée par Hugging Face contre ses infrastructures provenait en réalité d’OpenAI. Celle-ci n’avait pas choisi de s’en prendre à l’hébergeur de modèles IA : la faute en revenait à des agents qui étaient sortis de leur cadre de test pour atteindre plus rapidement les objectifs qui leur avaient été fixés, en l’occurrence la résolution des épreuves posées par le benchmark de cybersécurité ExploitGym.

• L’attaque contre Hugging Face est venue… d’OpenAI

Le 26 août, deux rapports beaucoup plus complets sont cependant apparus. Le premier vient d’OpenAI (PDF) et est une analyse technique fouillée des évènements. L’autre (PDF) de l’organisme à but non lucratif METR (Model Evaluation and Threat Research), mandaté par OpenAI comme expert indépendant et assisté d’un chercheur de Redwood Research. La chronologie semble digne d’un scénario de science-fiction au premier abord.

Des signaux dès mai 2026

Les premiers couacs sont apparus environ deux mois avant l’attaque contre Hugging Face, selon le rapport technique d’OpenAI. Le 8 mai, un agent de l’entreprise s’est retrouvé bloqué sur une tâche rendue volontairement impossible : accéder à des liens vers Google Drive depuis un environnement dépourvu d’accès internet.

L’agent ne se démonte pas pour autant et cible Artifactory, le gestionnaire de paquets utilisé en interne par OpenAI pour donner à ses agents un accès contrôlé aux dépendances de développement. L’agent attaque le logiciel au moyen d’une faille SSRF (server-side request forgery), mais échoue dans sa mise en pratique. Le processus laisse une scorie : un fichier écrit par l’agent dans Artifactory.

Le 12 mai, toujours dans le cadre d’un test, un deuxième agent trouve le fichier et conclut qu’il peut laisser par ce biais des messages à l’attention d’autres agents qui seraient susceptibles de disposer des ressources manquantes. Le lendemain, un troisième agent – disposant cette fois d’un accès internet – trouve ces notes et commence à s’en servir. Dans les jours qui suivent, un nombre croissant d’agents se met à utiliser ces fichiers comme un « message board » pour échanger sur les problèmes à résoudre.

Le 26 mai, plusieurs agents utilisent une faille SSRF pour obtenir un accès internet, cette fois avec succès. Ils découvrent six jetons d’authentification Hugging Face (qui avaient été exposés publiquement) et les partagent sur Artifactory, au bénéfice des autres agents. Un dépôt est même créé sur Hugging Face, ainsi qu’une application de relais dans le service Space.

Cet incident a finalement été découvert par OpenAI, mais n’a pas été rapporté aux responsables de détection et réponse aux incidents. Dans son rapport, l’entreprise avoue un défaut de communication.

L’escalade vers Hugging Face

Un mois plus tard, le 26 juin, OpenAI lance un test sur plusieurs agents, dans l’objectif de leur faire obtenir le meilleur score au benchmark ExploitGym. Les conditions sont cette fois connues, car c’est le processus qui aboutira à l’attaque contre Hugging Face en juillet. Pour rappel, OpenAI testait à ce moment deux modèles : GPT-5.6 Sol (leur modèle commercial le plus avancé actuellement) et un modèle interne, sans nom officiel, mais que METR nomme HPIM (« highly-persistent internal model ») dans son rapport.

Entre le 26 juin et le 4 juillet, les actions s’enchainent. Les agents ont d’abord découvert une faille dans un point de terminaison d’Artifactory servant au rafraichissement des jetons d’authentification et s’en sont servi pour obtenir des droits administrateur. Ces derniers ont été utilisés pour installer des plug-ins dans Artifactory, avec à la clé des capacités persistantes d’exécution de commandes. Dans l’intervalle, une alerte remonte le 27 juin pour signaler un comportement imprévu, mais n’est pas jugée bloquante. L’activité est alors devenue assez intense sur le serveur pour provoquer l’indisponibilité d’Artifactory le 6 juillet, déclenchant en interne un incident de sécurité. OpenAI dit alors avoir coupé le service compromis, révoqué les accréditations des agents et reconstruit une nouvelle instance d’Artifactory le même jour, effaçant l’ensemble des messages échangés par les agents.

Apple a envoyé un e-mail aux développeurs tiers pour les avertir d’un changement : « Nous vous contactons pour vous informer que les apps universelles pour macOS proposées sur le Mac App Store et nécessitant macOS 13 ou une version ultérieure peuvent désormais abandonner la prise en charge des Mac à processeur Intel ».

Cette prise en charge était obligatoire pour toute application publiée sur le Mac App Store, mais ne l’était bien sûr pas pour celles distribuées autrement. Le passage à l’architecture Arm remontant aujourd’hui à six ans avec la puce M1, le signal est clair : il est temps de passer à autre chose.

Apple vante d’ailleurs les avantages d’un tel abandon. En ciblant uniquement « arm64 » dans les réglages de compilation de l’application, le développement n’en sera que plus simple. En outre, plus besoin de passer par des binaires universels embarquant toutes les données pour les deux architectures (x86_64 et arm64). L’application s’en retrouvera d’autant allégée. Reste une condition : elle doit viser macOS 13 au moins.

Il n’y a bien sûr pas d’obligation à suivre ce conseil, les développeurs pouvant toujours compiler pour Intel s’ils le souhaitent. Comme l’indiquent nos confrères de MacG, macOS 27 et son Xcode correspondant ne pourront s’installer que sur des Mac Apple Silicon, plantant un nouveau clou dans le cercueil. macOS 27, alias Golden Gate, sera également la dernière version à prendre en charge la couche d’émulation Rosetta 2. 2027 sonnera définitivement le glas de l’architecture Intel chez Apple.

L'IA à la sauce Mozilla

Mozilla vient de publier de nouvelles versions de son navigateur pour l’ensemble des plateformes. Certaines contiennent des nouveautés importantes, particulièrement sur ordinateur et iOS.

Nouvelle mouture pour le navigateur de Mozilla, avec comme principale nouveauté la disponibilité de la Smart Window pour l’ensemble des utilisateurs en France, au Canada et aux États-Unis. En français, elle prend d’ailleurs officiellement le nom de « Fenêtre intelligente ».

Cette fonction est toujours en bêta et reste optionnelle. On y accède par le bouton Firefox situé en haut à droite de la fenêtre, près du menu hamburger (trois traits). Son utilisation réclame un compte Firefox, ce mode de navigation permettant ensuite de résumer des pages, comparer plusieurs onglets, retrouver des informations dans des onglets ou l’historique, obtenir des recommandations et ainsi de suite. Une fois la fonction activée, on peut choisir de toujours lancer Firefox dans ce mode.

Notez que la prise en charge de l’historique ne se fait qu’au sein de cette fenêtre intelligente. En outre, les conversations et « souvenirs » sont stockés localement, mais les requêtes transitent par les serveurs de Mozilla puis éventuellement vers d’autres, selon le modèle utilisé. Par défaut, Mistral Small 4 est recommandé. On peut également choisir entre Gemini 3.1 Flash Lite, Qwen 3 235B ou un autre LLM, à condition de fournir le point de terminaison et la clé API (ou jeton d’authentification).

Firefox 155 améliore dans la foulée cette fonction. Mozilla ajoute par exemple sous la fenêtre de conversation des boutons pour retourner rapidement dans des recherches précédentes. Les recherches passant par Exa sont également décrites comme beaucoup plus rapides, et la fonction d’organisation intelligente des onglets se veut plus pertinente. Rappelons que Firefox propose un réglage pour désactiver toutes les fonctions IA.

Parmi les autres nouveautés, on peut citer un nouveau compteur de traqueurs bloqués apparaissant au début de la barre d’adresse. Les conteneurs, « apparus » avec Firefox 153, peuvent maintenant être réorganisés, l’ordre choisi apparaissant ensuite partout où cette liste est affichée. Firefox 155 corrige en outre de nombreux bugs, dont un gênant qui pouvait empêcher une machine sous Linux d’entrer en veille après une longue session de navigation. Enfin, la version colmate une trentaine de failles de sécurité, dont 13 de dangerosité élevée.

Firefox pour iOS a désormais son Ad Blocker

Aux côtés de cette version pour ordinateurs, Firefox pour iOS a lui aussi du neuf. Mozilla a annoncé très officiellement ce 1ᵉʳ septembre l’intégration d’un bloqueur de publicité, nommé Ad Blocker. Il est construit sur la base de l’API d’Apple pour bloquer les contenus et la liste de filtrage EasyList. Une technique qui n’est pas neuve, Vivaldi proposant une fonction équivalente.

Ce blocage publicitaire n’est pas activé par défaut. Il faut se rendre dans les réglages puis dans la partie Navigation. Dans son billet, Mozilla prévient que l’efficacité de sa fonction n’est pas garantie : « Le bloqueur de publicités ne bloquera pas toutes les annonces. Les publicités diffusées directement par le site que vous visitez et les annonces affichées dans les résultats de recherche apparaîtront toujours ». En outre, les raccourcis et autres contenus sponsorisés affichés par Firefox ne sont pas pris en charge, mais peuvent être désactivés via un réglage séparé.

Ce bloqueur de publicités est une fonction supplémentaire et peut donc fonctionner de concert avec la protection améliorée contre le suivi qui, elle, s’occupe de bloquer les traqueurs.

Mozilla en profite pour lancer une pique à Apple dans un billet séparé (en lien dans l’annonce) : il serait temps que l’entreprise propose une véritable architecture pour les extensions de navigateur. Safari en propose, mais leur récupération passe par l’App Store. Rien d’équivalent n’est prévu pour les autres, Mozilla fustigeant au passage (une nouvelle fois) l’obligation d’utiliser WebKit comme moteur de rendu. Sur Android, rien de tout cela : Firefox utilise son moteur Gecko et prend en charge les extensions depuis longtemps.

Comme toujours avec les versions LTS (Long Term Support) d’Ubuntu, la première mouture « .1 » est attendue. Ubuntu 26.04.1 vient ainsi d’être mise à disposition, simplifiant dans un premier temps les nouvelles installations du système.

Cette version ne comprend aucune nouveauté. Elle est là pour reprendre l’ensemble des correctifs (bugs généraux et sécurité) sortis depuis la publication d’Ubuntu 26.04 en avril dernier. Les images ISO proposées permettent l’installation d’un système à jour, avec moins de téléchargements lors de la première session. Pour les utilisateurs existants d’Ubuntu 26.04, il n’y a rien à faire.

• Ubuntu 26.04 LTS est disponible en version finale, avec cinq ans de mises à jour

Ces versions « .1 » sont cependant importantes pour la mouture LTS précédente. Canonical applique la même stratégie depuis longtemps : une LTS ne peut être mise à jour vers la suivante qu’une fois la version « .1 » de celle-ci disponible, qui débloque alors un chemin de migration. Un choix qui répond à des critères de fiabilité, ces versions permettant de gommer les erreurs de jeunesse. Un comportement déroutant de prime abord, car il s’écoule plusieurs mois entre l’arrivée d’une nouvelle LTS et la disponibilité de son chemin de migration.

Une partie des utilisateurs d’Ubuntu 24.04 attend donc la 26.04.1, mais il faudra être encore un peu patient. Oliver Reiche, développeur chez Canonical, a indiqué que même si la 26.04.1 était effectivement disponible, le chemin de migration avait du retard. Il faudra attendre quelques semaines de plus, la faute à des « régressions dans une version récente de rust-coreutils ».

Quand le chemin de migration sera disponible, le système signalera cette possibilité. Comme le rappelle OMGUbuntu, il est toujours possible de forcer le passage avec la commande « sudo do-release-upgrade -d », mais la procédure n’est pas recommandée pour des questions de fiabilité.

Démocratie

La communauté Debian devait voter sur la place que les grands modèles de langage (LLM) pouvaient tenir dans le développement de la distribution Linux. Parmi les axes proposés, elle a choisi un quasi-statu quo. La décision divise, ayant notamment provoqué le départ d’au moins un des développeurs.

Fin juillet, nous indiquions que la communauté Debian allait être amenée à se prononcer sur la place des LLM dans le développement de la distribution. Plusieurs propositions étaient mises en avant, de la plus radicale à la plus modérée. À l’époque où nous avions écrit ces lignes, on pouvait en lire quatre, mais la communauté a finalement dû voter parmi huit propositions.

• Proposition A : interdiction pure et simple des LLM dans les contributions au projet
• Proposition B : usage autorisé, mais avec un encadrement strict, avec garanties de licence et responsabilité totale des contributions
• Proposition C : rejet des LLM autant que possible, affichage obligatoire des usages et interdiction des LLM pour les communications entre contributeurs
• Proposition D : la plus pragmatique, avec acceptation des contributions par l’IA et responsabilité complète, en revanche pas d’IA distante pour les données sensibles
• Proposition E : le statu quo, chacun étant responsable de ses contributions, peu importe l’outil
• Proposition F : utilisation découragée des LLM quand c’est possible et mise en avant du travail humain, responsabilité complète des contributions, mais liberté pour les mainteneurs de refuser les contributions IA
• Proposition G : usage contrôlé des LLM pour les tâches périphériques (réflexion, analyse, recherche, critique de code…), mais interdiction dans les contributions
• Proposition H : l’impact environnemental des LLM est jugé rédhibitoire, leur utilisation doit être découragée autant que possible

Le choix de la communauté

Les participants se sont prononcés pour l’option E. De toutes celles mises en avant, la E est la plus consensuelle, car elle ne change presque rien à la situation qui existait avant.

Officiellement, la proposition E s’intitule « Usage responsable de l’IA générative ». On peut y lire notamment que Debian « n’encourage pas ni n’interdit l’utilisation d’outils d’IA générative dans le développement, la maintenance ou la documentation des logiciels, l’empaquetage, la documentation et les autres médias publiés dans le projet Debian ». Le texte reconnait que ces outils peuvent largement améliorer la productivité des contributeurs « s’ils sont utilisés de manière responsable ». Cela permettrait aux personnes de se libérer du temps pour des tâches plus intensives, notamment celles réclamant un jugement, une expertise ou une critique.

Techniquement, l’usage de l’IA ne change pas les exigences habituelles de qualité, d’exactitude et de maintenabilité. Toute personne soumettant un code, qu’il soit tout ou partiellement rédigé par une IA générative, est responsable de ce qu’elle propose. Elle doit être en mesure de comprendre, relire et tester ce code, dans l’idée de pouvoir expliquer ce qu’il fait avec précision. Tout envoi aveugle d’un contenu généré par IA est jugé incompatible avec les pratiques de Debian.

Dans la proposition, on peut lire qu’il est explicitement demandé aux personnes participantes de ne jamais envoyer d’informations personnelles à des services d’IA externes. Il peut aussi bien s’agir de données personnelles habituelles que de clés cryptographiques, communications privées, identifiants ou encore bugs de sécurité sous embargo.

Enfin, pour les opérations automatisées à grande échelle, comme la génération de nombreux rapports de bugs ou la modification en masse des paquets, un processus spécifique devra être mis en place.

« Les Contributeurs qui entendent effectuer des actions impactant tout le projet comme la soumission massive de bogues ou la soumission massive de correctifs, des modifications de code à grande échelle ou d’autres changements ou requêtes automatisés concernant de nombreux paquets ou de nombreux contributeurs, doivent d’abord lancer une discussion et rechercher un consensus à l’aide des canaux du projet avant d’agir. De tels projets automatisés doivent être validés par un humain qui demeure responsable de son comportement et du résultat », indique ainsi la proposition E.

En somme, Debian continue « de compter sur le jugement et la responsabilité de ses contributeurs individuels ». Point important : la mention de l’utilisation de l’IA dans un projet est recommandée, mais pas obligatoire.

Division et colère

La communauté a parlé. La proposition E ne change fondamentalement rien : chacun peut faire ce qu’il veut, tant que les pratiques habituelles de Debian sont respectées. La distribution s’appuie depuis longtemps sur la responsabilité individuelle et la relecture par les pairs. Pas question donc de changer de philosophie. Cependant, lorsque l’on parle de Debian, il n’est pas question d’une entité unique et mystique, mais bien d’un ensemble de personnes contribuant au projet. La consécration de ce quasi-statu quo n’est donc pas anodine.

Si la communauté a parlé, elle est également divisée, aussi bien chez les contributeurs que les utilisateurs. Sur X par exemple, la publication de la nouvelle sur le compte It’s FOSS montre des réactions très diverses, certains comprenant la position, mais la plupart affichent de la méfiance, voire de la déception. Même constant dans les commentaires de Phoronix.

Parmi les réactions négatives, l’une d’entre elles ressort particulièrement : celle d’Antoine le Gonidec, contributeur de longue date au projet Debian. Sur les huit propositions, il était parrain des options A, C, G et H. En somme, toutes celles cherchant à interdire ou limiter l’usage des IA. Face à la victoire de la proposition E, Antoine le Gonidec n’a pas caché sa colère. Sur la liste officielle de diffusion Debian, le développeur a pris une décision radicale :

« Je ne peux pas soutenir la décision actuelle de Debian concernant l’utilisation des LLM, et je ne suis plus prêt à être considéré comme faisant partie de Debian selon ces nouvelles règles. Prétendre avoir une « position neutre » face au fascisme n’est pas de la neutralité, c’est une collaboration active »

Il se retire donc du projet, expliquant que les LLM s’appuient en grande partie sur des entreprises « soutenues par des fascistes ». De toutes les propositions, la E était « la plus pro-LLM de toutes les options ». Il dit ne plus être intéressé par quoi que ce soit provenant de Debian, déclarant avec acidité qu’il peut être remplacé « par n’importe quelle IA agentique ». « Je pense n’avoir jamais autant été déçu par une communauté en qui j’avais confiance », affirme-t-il.

L’importance de Debian

Si ce vote était attendu, c’est que Debian est l’une des distributions Linux les plus importantes. En plus du système lui-même, connu pour sa fiabilité et sa rigueur, Debian sert de base à de nombreuses distributions, dont la plus connue est Ubuntu, celle-ci servant à son tour de socle à d’autres comme Linux Mint.

Comme l’indique It’s FOSS, plusieurs projets ont choisi des approches beaucoup plus radicales. OpenJDK par exemple, édité par Oracle, refuse toute contribution générée par IA. Même chose pour le compilateur GCC. D’autres ont choisi une approche plus souple, en particulier le noyau Linux. Au sujet des LLM, Linus Torvalds a adopté une approche pragmatique, estimant que l’aide procurée par l’IA ne peut plus être empêchée, mais que certaines situations sont problématiques, notamment l’automatisation des rapports des bugs (qu’il a fustigée).

• Linus Torvalds s’agace encore sur l’IA, cette fois pour la défendre

Deux pas en avant, un gros pas en arrière

Le système d’exploitation mobile GrapheneOS, connu pour ses positions franches sur la sécurité, fera très probablement l’impasse sur les Pixel 11. La faute, selon les développeurs, à un choix inopportun de Google : l’absence de prise en charge de la Memory Tagging Extension, une fonction de sécurité utilisée abondamment dans le système.

Le 29 août, la fondation GrapheneOS a annoncé sur X, Bluesky et Mastodon qu’elle avait en sa possession un portage partiel de son système sur les Pixel 11 de Google, les derniers smartphones de l’entreprise. La fondation explique que ce portage a été réalisé en une semaine, mais le travail s’était arrêté. Les développeurs ont indiqué être bloqués, faute de support de la Memory Tagging Extension, ou MTE.

Celle-ci est une fonction de marquage de la mémoire proposée par le jeu d’instructions ARM. Elle associe une étiquette aléatoire à chaque zone de mémoire allouée. Si un accès mémoire présente une étiquette qui ne correspond pas, le système détecte une violation. Dans ce cas, selon les choix faits dans le système, le processus est immédiatement interrompu. Cette fonction est utilisée pour bloquer les éventuelles attaques dirigées contre la mémoire, dans l’idée de renforcer l’intégrité du système.

Le cas des Pixel 11

Dans le cas de GrapheneOS, le système s’appuie lourdement sur la MTE. Une position très différente de Google. La firme a intégré la fonction dès la puce Tensor G3 du Pixel en octobre 2023, mais elle s’en sert peu. Sur les Pixel, la MTE n’est en effet utilisée que dans les fonctions de « protection avancée », optionnelles. Il s’agit pour rappel du fameux mode conseillé à certains profils spécifiques (activistes, personnalités politiques, journalistes, etc.) qui élève le niveau général de sécurité en réduisant la surface d’attaque, au prix de certaines fonctions. Ce mode est apparu dans Android 16 en réponse à Apple, qui avait dégainé la première dans ce domaine.

Dans GrapheneOS, l’emploi de la MTE est systémique, aussi bien dans le noyau que dans les processus. Apple possède ici aussi un équivalent, baptisé Memory Integrity Enforcement (MIE), mais l’ajout est plus récent (iPhone 17 et Mac équipés d’une puce M5 au moins). La fondation indique à ce sujet que le MIE d’Apple est une « implémentation de haute qualité de MTE », même si elle n’est pas utilisée par défaut par les applications installées par l’utilisateur, à moins qu’elles aient opté spécifiquement pour cette protection.

Le choix de Google interroge, d’autant que l’entreprise ne s’est pas exprimée publiquement sur le sujet. Les Pixel 11 ont pourtant plusieurs arguments sur la sécurité, dont la puce Titan M3 pour améliorer la protection contre l’extraction de données à l’état verrouillé avant premier déverrouillage. On y trouve aussi une vérification post-quantique du démarrage (basée sur ML-DSA) ou encore un remplacement du sous-système IMS Samsung Shannon par une implémentation AOSP (Android Open Source Project).

Plein les mirettes, sans les lésions

Dans deux jours aura lieu une éclipse totale du Soleil. Si elle ne sera pas totalement visible en France, son taux d’occultation sera élevé, surtout dans le sud-ouest, avec un maximum vers 20h30. Et avec ce genre d’évènement, mieux vaut rappeler quelques consignes pour ne pas finir en urgence chez l’ophtalmologue.

Le mercredi 12 août 2026 aura lieu une éclipse solaire totale, provoquée – vous le savez depuis longtemps – par l’interposition de la Lune entre la Terre et le Soleil.

La bande de totalité – la zone dans laquelle l’éclipse sera totale – traversera l’océan Arctique, le Groenland, l’Islande et l’Atlantique Nord et finira par atteindre les zones qui nous intéressent : le nord du Portugal, le nord de l’Espagne et les îles Baléares, où la totalité durera jusqu’à environ 1 min 48 s selon la localisation exacte sur la trajectoire.

Et la France ? Elle se situe en dehors de cette bande et n’observera donc qu’une éclipse partielle, mais avec un taux d’occultation très élevé, d’un minimum de 80 %. Voici quelques exemples :

• Biarritz : 99,5 %
• Pau : 99 %
• Toulouse : 97,8 %
• Bordeaux : 97,5 %
• Brest : 96 %
• Paris : 92 %
• Saint-Pierre-et-Miquelon : environ 45 %

Sans surprise, le sud-ouest est la région où l’occultation sera la plus importante, étant la zone la plus proche du nord de l’Espagne. Mais il n’y aura pas de mystère : pour un vrai contact avec la couronne solaire, il faudra passer la frontière. Les Asturies, la Cantabrie, la Galice ou les Baléares sont les zones d’occultation totale les plus accessibles depuis le territoire français.

Le phénomène se produira en fin de journée pour la France métropolitaine. Il débutera à 19h30 pour atteindre son maximum vers 20h26. Le soleil étant bas sur l’horizon et l’éclipse non totale, une ambiance « coucher de soleil » se mettra doucement en place. Au vu de l’heure, mieux vaut bénéficier d’un horizon ouest bien dégagé. À Saint-Pierre-et-Miquelon, l’évènement se produira entre le début et le milieu d’après-midi.

Notez que même avec des scores très élevés, l’ombre n’est vraiment maximale qu’à 100 %. Il suffit que le taux d’occultation soit de « seulement » 99 % pour que l’ombre ne soit plus qu’une pénombre. De nombreux sites permettent de suivre l’éclipse. C’est notamment le cas de l’observatoire de Paris avec Éclipseop.

Attention les yeux !

En France métropolitaine, puisque la totalité n’est atteinte nulle part, il ne faut jamais observer l’éclipse à l’œil nu. Le risque de lésion grave et irréversible est réel et ce type d’évènement est systématiquement suivi d’une hausse de fréquentation chez les ophtalmologues. La rétinopathie solaire (brûlure de la rétine par le soleil) s’installe sans douleur et les symptômes n’apparaissent que plusieurs heures après : baisse de l’acuité visuelle, déformation des lignes et apparition d’une tâche sombre centrale.

Seule solution : des lunettes de protection adaptées, qui bloquent 99,9 % de la lumière visible ainsi que la totalité des ultraviolets et infrarouges. Selon la Société astronomique de France (SAF), il faut être particulièrement vigilant lors de l’achat de ces lunettes. Elles doivent être conformes à la norme ISO 12312 - 2 de 2015, donc pleinement adaptées à l’observation directe du soleil sans grossissement. Ces lunettes doivent aussi porter au verso des instructions en français, ainsi que la date de fabrication, le lot, l’origine, le fabricant et le distributeur en France.

Un point de vigilance tout particulier : les micro-rayures et micro-perforations. Il faut bien vérifier leur absence avant chaque utilisation, sous peine de se blesser les yeux. Vous avez peut-être vu passer sur certains réseaux (Instagram en particulier) des vidéos d’ophtalmologues mettant en garde sur ce point. La recommandation est de ne pas ouvrir le sachet plastique ou la boite contenant les lunettes avant le moment d’observation, pour ne prendre aucun risque. Pour les mêmes raisons, toujours selon la SAF, « les lunettes utilisées lors de l’éclipse de 1999 ne doivent plus être employées aujourd’hui ».

Les règles de sécurité ne valent pas que pour le grand public. Toute personne souhaitant observer de plus près la couronne solaire avec un appareil quelconque doit faire attention : ne jamais utiliser de jumelles ou autre équipement grossissant sans filtre adapté. Les filtres oculaires placés derrière une optique grossissante peuvent en effet se fissurer sous la concentration de chaleur. Pour la photographie avec un appareil à objectif interchangeable, un filtre de densité optique d’au moins 5 est nécessaire devant l’objectif.

Si l’on en croit le lunetier Krys, un quart des Français se disent prêts à observer l’éclipse à l’œil nu, moyenne qui grimpe à 34 % chez les 18 - 34 ans.

À quand les prochaines ?

Les éclipses totales en Europe sont rares. La dernière remonte au 11 aout 1999 et celle du 12 aout est la première à concerner l’Europe depuis.

Et ensuite ? Au risque de casser la statistique de rareté, la prochaine éclipse totale touchant l’Europe aura lieu le 2 aout 2027. La bande de totalité passera cette fois par le sud de l’Espagne, le Maroc et l’Égypte. L’occultation à Paris sera nettement plus modeste, environ 51 %. On notera que l’Espagne aura été généreusement servie deux années de suite.

Quant à la prochaine éclipse totale en France, il faudra attendre… le 3 septembre 2081. L’immense majorité ne sera donc plus là pour la voir, mais beaucoup se régaleront puisque la bande de totalité passera par Paris. Et en dehors de l’Europe ? La prochaine éclipse totale se produira le 22 juillet 2028 et concernera surtout l’Australie et la Nouvelle-Zélande. Elle sera partielle en Nouvelle-Calédonie. Une autre aura lieu le 25 novembre 2030 et concernera surtout l’Afrique, l’océan Indien, l’Indonésie et l’Australie. Certains territoires ultramarins pourront en profiter partiellement, surtout la Réunion et Mayotte.

Des opérations promotionnelles chez des enseignes d’optique

Plusieurs entreprises françaises profitent de l’évènement pour proposer des lunettes de protection gratuites. Les conditions peuvent varier d’une enseigne à l’autre.

Chez Écouter Voir par exemple, 400 000 paires sont distribuées sur l’ensemble du territoire français. Elles sont à retirer gratuitement et sans obligation d’achat dans les boutiques de la chaîne, sous réserve bien sûr d’un stock disponible. L’offre est limitée à une paire par personne. L’opération étant lancée depuis mi-juin, il n’est pas certain que beaucoup de ces lunettes soient encore disponibles.

Chez Alain Afflelou, 452 magasins (sur les 1225 du réseau) participent à une opération similaire. En revanche, les conditions peuvent varier d’une boutique à l’autre. Certaines les donnent, d’autres les vendent pour un petit prix.

Chez Optic 2000, l’offre est conditionnée à l’achat d’un équipement optique complet pour enfant dans les boutiques physiques, ou à partir de 50 euros d’achat en ligne. Hors promotion, l’enseigne vend les lunettes de protection au prix de 3,90 euros l’unité ou 19 euros le lot de cinq.

Précisons que, de manière générale, ces lunettes ont un prix dépassant rarement quelques euros. Tant que la norme ISO 12312 - 2 est respectée, il n’est pas nécessaire de dépenser davantage. Enfin, comme signalé par Que Choisir, toutes les lunettes ne se valent pas : le contrôle des informations et la provenance sont primordiales.

Aux grands maux les grands mots

Plusieurs publications récentes montrent encore un peu plus la manière dont Microsoft négocie le virage actuel de Windows 11. Outre des explications sur la complexité d’une modernisation à marche forcée pour des raisons d’héritage, l’entreprise a lancé plusieurs composants dédiés aux performances.

L’initiative K2 de Microsoft bat son plein. Elle vise à redorer le blason d’un Windows 11 qui n’a jamais fait rêver et a été accusé de nombreux maux. Souvent considéré comme vorace en ressources (parfois à tort), le système s’est surtout signalé par une interface rigide, le retrait de fonctions, une personnalisation moindre et toujours plus de fonctions dopées à l’IA. Le système est aussi l’incarnation du retrait de Windows 10, même si l’Europe a droit à quelques facilités sur ce point.

• Le support de Windows 10 recule d’un an, au 12 octobre 2027

Depuis le début de l’année, Microsoft communique abondamment sur des améliorations en préparation pour son système. Personnalisation, performances, recul de l’IA, fiabilité, applications natives et autres sujets sont poussés depuis des mois, avec déjà certaines améliorations distribuées depuis peu. Dans ce domaine, la mise à jour 26H2 attendue cet automne devrait marquer un tournant, mais l’effort doit se prolonger au-delà.

• Windows 11 : la mise à jour 26H2 se dessine pour cet automne

Modernisation : c’est « compliqué »

Le plus gros problème de Microsoft est aussi la principale force de Windows depuis longtemps : sa compatibilité descendante. La possibilité de faire tourner un vieux logiciel est un point fort auquel l’entreprise ne veut pas renoncer. Malheureusement, pour cette même raison, Windows 11 se « coltine » encore aujourd’hui de nombreux pans de code hérité.

Marcus Ash, vice-président de Microsoft chargé de la conception et de la recherche au sein de la division Windows & Appareils, a abordé ce point dans une interview donnée à Windows Central. Le responsable s’est dit fier de la compatibilité générale de Windows avec les outils et flux de travail hérités, ce qui empêcherait l’entreprise de se précipiter pour tout moderniser, sans s’assurer d’abord que les remplaçants conservent le même niveau fonctionnel.

Difficile cependant d’accuser Microsoft de précipitation. Comme le rappellent nos confrères, la modernisation du panneau de configuration a commencé avec Windows 8 il y a 13 ans et n’est toujours pas terminée. Le panneau des Paramètres est pratiquement complet, mais l’ancien Panneau de configuration est toujours là, même si « planqué ».

Marcus Ash a répondu sur ce point : « C’est pour ça que des éléments comme le Panneau de configuration sont complexes, car si un client a un pilote ou possède quelque chose qui dépend de cette fonction héritée, il faut faire attention à ne pas rompre cette promesse de compatibilité ». Il explique que les zones de l’ancien panneau sont désactivées l’une après l’autre, au fur et à mesure que les versions « modernes » sont éprouvées. Comment les zones à moderniser sont-elles choisies ? Un mélange d’utilisation, de télémétrie et de retours des clients, selon Marcus Ash.

Le responsable indique que le travail actuel ne concerne pas que des éléments courants comme l’Explorateur. Des outils plus spécialisés comme l’Éditeur du Registre commencent à être examinés. Il laisse surtout entendre qu’une bonne partie de la démarche en cours passe aussi par la modernisation des outils et frameworks impliqués. L’entreprise a clairement indiqué que l’avenir des interfaces passait par WinUI 3, qui est d’ailleurs devenu WinUI « tout court » pour faire passer le message.

Un serveur MCP pour les performances ? Même pas peur

Autres annonces intéressantes ces derniers jours, l’apparition en préversions publiques de plusieurs composants dédiés aux performances. Microsoft semble décidée à simplifier l’analyse des performances sur Windows en partant d’un constat : le système ETW (Event Tracing for Windows) et l’outil WPA (Windows Performance Analyzer) sont peut-être puissants, mais ils ne peuvent être exploités que par des personnes ayant de très bonnes connaissances dans ce domaine.

ETW est un système intégré à Windows chargé de garder des traces de tout ce qui est accompli en matière de processus. Des journaux gardent ainsi les traces de nombreux évènements : quel programme démarre, quand un processus utilise le CPU, quand une application lit ou écrit sur le disque, quand un pilote intervient, etc. Si vous ouvrez l’Observateur d’évènements, ses informations proviennent de cette infrastructure. De son côté, WPA fait partie du Windows Performance Toolkit. Technique, il se destine surtout aux développeurs, ingénieurs, administrateurs système et spécialistes des performances.

Ce que propose Microsoft ? D’abord WPA MCP, un serveur MCP permettant de récolter les ressources générées par ETW pour les confier à un agent (Copilot ou tout autre agent compatible MCP). Puisque les traces peuvent contenir de grandes quantités de données, l’idée est de permettre à un plus grand nombre de personnes de se pencher sur les performances via des questions en langage naturel de type « Cette application me semble lente, pourquoi ? ».

L’outil se destine prioritairement aux développeurs, pour baisser le niveau exigé habituellement sur les questions de performances. Les questions peuvent donc être posées en langage naturel, avec un accès plus rapide à tout ce qui peut être pertinent, comme les tableaux WPA, des graphs ou des plages de temps. Les résultats peuvent également remonter les activités coûteuses en CPU, les délais dans les entrées, les régressions et autres. Selon Microsoft, l’idée générale est de pouvoir passer rapidement d’une exploration des traces à des actions concrètes.

Interface ou ligne de commande

Un autre serveur MCP est proposé, cette fois spécifique à ETW et décrit par Microsoft comme un « compagnon » du premier. Il en est le pendant headless : il ne propose pas d’interface graphique ni d’éléments visuels. Il est fait pour être utilisé depuis un terminal, avec des scripts et agents. Les deux serveurs utilisent la même couche de données, les résultats d’analyse étant largement les mêmes. La préversion publique de ce serveur MCP pour ETW est cependant limitée à GitHub Copilot CLI pour l’instant.

Les deux serveurs sont faits pour répondre à des questions précises ou plus générales comme « Pourquoi la machine est-elle lente ? ». Plus besoin de connaitre l’organisation interne de WPA pour lancer une enquête, l’intention étant – théoriquement – comprise par le LLM utilisé. L’IA sert donc dans un domaine où elle brille habituellement : la découverte de corrélations.

Microsoft avertit toutefois que les résultats renvoyés peuvent être erronés ou incomplets et doivent en conséquence être comparés aux données originales. L’entreprise indique d’ailleurs que les questions ont tout intérêt à se poursuivre après les résultats pour demander des preuves.

SOS pile fantôme

La prochaine version de la distribution Linux devrait activer par défaut un important mécanisme de sécurité, la Shadow Stack. L’équipe effectue actuellement un gros travail préparatoire, qui pourrait largement débroussailler le terrain pour les autres systèmes Linux. Accrochez-vous un peu, on vous explique.

D’abord, qu’est-ce que la Shadow Stack ? Il s’agit d’une protection initialement créée par Intel en 2016 mais qui n’est réellement arrivée sur le marché qu’en 2020 avec la génération Tiger Lake. Elle fait partie d’une architecture nommée Intel CET (Control-Flow Enforcement Technology), qu’AMD a également reprise à partir de la génération Zen 3 de ses processeurs.

Le principe de la Shadow Stack (ou pile fantôme) est assez technique. Le processeur dispose en permanence d’une seconde pile d’exécution (call stack) en mémoire. Elle est cachée, isolée et protégée en écriture. Lorsqu’une instruction d’appel (CALL) survient, l’adresse de retour est ajoutée sur les deux piles. Quand l’instruction RET (RETURN) – qui sert à terminer l’exécution d’une fonction – survient, le processeur compare les deux piles : s’il y a correspondance des deux adresses de retour, l’opération se poursuit, dans le cas contraire le processeur déclenche une erreur (exception de protection de flux de contrôle). Cette erreur interrompt immédiatement le processus.

Il s’agit d’une fonction de sécurité, car en interrompant brutalement l’opération, le processeur empêche un pirate d’avancer dans son attaque. La Shadow Stack a été créée pour combattre les attaques de type ROP (return-oriented programming), qui peuvent mener à la prise de contrôle de la pile d’exécution. Elles peuvent également contourner des protections plus anciennes comme ASLR (Address Space Layout Randomization).

Une activation par défaut dans Fedora 45

Ce que propose l’équipe de Fedora, c’est d’activer cette protection sur l’ensemble du système sur les configurations x86_64. Car il s’agit bien pour l’instant encore d’une proposition, même si elle a de très fortes chances d’être acceptée au vu de son statut avancé. Si elle ne passait finalement pas la validation, elle serait programmée pour Fedora 46 au printemps prochain.

Dans la fiche dédiée, on peut lire que le gros avantage de la Shadow Stack est son impact quasi nul sur les performances, contrairement aux solutions logicielles de contrôle d’intégrité du flux d’exécution. Le surcoût d’exécution est jugé négligeable et imperceptible sur la grande majorité des charges de travail, permettant en échange une élévation générale du niveau de sécurité.

Une activation générale de cette pile fantôme suppose toutefois des adaptations profondes. Il faut notamment que les compilateurs GCC, Clang et rustc soient prêts, ce qui est a priori le cas désormais. Le reste dépend surtout d’un long travail préparatoire commencé il y a des années, la majorité des paquets du dépôt principal possédant déjà les annotations ELF requises, en plus de certaines options compilées à la compilation depuis 2018. Le support de la bibliothèque glibc est également marqué comme prêt.

Ça existait déjà… mais !

Sur un plan purement technique, Fedora n’est pas la première distribution à supporter la Shadow Stack. Sa prise en charge dans le noyau Linux remonte à la version 6.6 de 2023. Plusieurs distributions – dont Arch Linux, Ubuntu et Debian – compilent déjà une grande partie de leurs paquets avec l’option liée (-fcf-protection) de GCC/Clang.

Alors, en quoi la démarche de Fedora est-elle novatrice ? Parce qu’elle renverse la vapeur : on parle cette fois d’une activation générale et par défaut. Tout processus éligible bascule automatiquement sur la pile fantôme à son lancement, sans intervention de l’utilisateur. Ce changement a notamment nécessité un travail d’audit et de correction pour les binaires incompatibles, comme les routines en assembleur manuscrit, la chaine d’outils Rust ou encore les moteurs de compilation Just-in-time dans les navigateurs.

Pour ces derniers justement, l’équipe de Fedora note que Chrome et Firefox ne sont pas encore compatibles. Cependant, le mécanisme d’activation a été pensé avec cette limitation en tête et contient un processus de « dégradation élégante » (graceful fallback). En clair, si une application charge au démarrage un objet ELF ne disposant pas du marquage SHSTK (pour Shadow Stack), la glibc désactive silencieusement la pile fantôme pour ce processus unique, sans interrompre son exécution.

Précisons enfin que la Shadow Stack n’est que la première moitié de l’architecture Intel CET. L’autre partie se nomme IBT, pour Indirect Branch Tracking. Sa mission est de contrer un autre type d’exploitation, basé sur la programmation orientée saut ou appel indirect (JOP/COP) et qui peut mener, là encore, à une attaque de type ROP. Le travail réalisé sur la Shadow Stack préparera donc le terrain pour la prise en charge d’IBT dans une version « ultérieure » de Fedora, l’équipe ne donnant pas plus de précisions pour l’instant. Le support d’IBT signifierait alors celui d’Intel CET au grand complet, pour les processeurs Intel et AMD compatibles.

Il est très probable que ce travail de fond serve largement la communauté open source une fois Fedora 45 (ou 46 ?) disponible. On peut s’attendre à ce que la plupart des distributions emboitent le pas à Fedora, mais le système est habitué à être un précurseur.

« Ce commentaire est-il un troll ? »

Mistral a lancé ce 4 aout un nouveau « petit » modèle. Nommé Shieldstral, il est dédié aux tâches de modération. Avec environ 4 milliards de paramètres, il est facilement installable sur un grand nombre de machines.

L’entreprise française continue sur sa lancée des modèles spécialisés et open source (sous licence Apache 2.0), dont les tailles contenues permettent assez aisément une utilisation locale. Par exemple, Mistral a lancé fin juin son modèle OCR 4 dans l’optique de bousculer la gestion des documents. Il s’agissait d’ailleurs d’un lancement important, avec un effort particulier sur la présentation et les explications sur les capacités du modèle.

Shieldstral : carte d’identité

Le modèle se nomme précisément Shieldstral-1.0-3B. L’appellation est un peu « trompeuse », car le modèle embarque en fait 3,8 milliards de paramètres. On est donc plus proche d’un « 4B » (« 4 billions », 4 milliards). Dans l’absolu, la différence reste cependant minime : Shieldstral est un petit modèle conçu pour fonctionner en local.

Dans son billet, Mistral indique que son nouveau bébé a été construit sur la base de Ministral-3-3B-Base-2512, associé à l’encodeur visuel Pixtral. De fait, Shieldstral est multimodal et accepte donc du texte et/ou des images en entrée. La fenêtre de contexte est « théoriquement » de 256k, mais Mistral conseille de se limiter à 32k.

Comme toujours avec les modèles de Mistral, on peut télécharger Shieldstral depuis Hugging Face. Il est « open source » avec des poids ouverts et sous licence Apache 2.0. On remarque que le modèle pèse 7,7 Go et est disponible en deux versions : Consolidate (le format utilisé par Mistral) et Model (le format habituel sur Hugging Face).

Pour cette taille, on obtient que le modèle « nu » (uniquement les poids) en bfloat16. Pour un fonctionnement en local, il faut donc un minimum de 8 Go en mémoire, ce qui laissera très peu de marge pour les caches, notamment d’inférence, avec à la clé de possibles soucis de fonctionnement. Mieux vaut viser 12 ou 16 Go si vous avez ce genre de matériel (Mistral recommande d’ailleurs 16 Go). Comme d’habitude, la mémoire unifiée des Mac permet de profiter plus facilement d’un fonctionnement local, si la machine embarque au moins 16 Go de RAM.

Mistral veut rendre la modération plus souple

Si l’on en croit l’entreprise, Shieldstral se différencie par son approche. La plupart des modèles « de garde » listent directement les catégories de préjudices dans leurs poids. Cette taxonomie oblige à réentraîner le modèle pour chaque nouveau contexte produit, affirme Mistral.

Shieldstral considère au contraire la politique de modération comme faisant partie de l’entrée. L’opérateur peut ainsi formuler une question binaire (oui ou non), fournir une instruction pour décrire le contexte d’évaluation et le niveau de sévérité attendu. Après quoi, le modèle renvoie un score de sécurité calibré à partir d’un seul jeton.

Concrètement, chaque requête contient une instruction, une question de sécurité et le contenu à vérifier. Le score renvoyé par Shieldstral se base sur les probabilités « oui » et « non », et c’est l’opérateur qui définit le seuil de déclenchement de l’action associée.

Mistral met largement en avant les performances de son nouveau modèle. Dans les résultats publiés dans le billet d’annonce, Shieldstral obtient un score F1 de 84,9, soit le même que GPT-OSS-Safeguard, un modèle 20B. Selon Mistral, il est plus performant que n’importe quel modèle concurrent, pour un poids inférieur. Tout du moins sur les tests de sécurité des textes et la sécurité multimodale, car il est dépassé par d’autres sur la détection des refus et l’adaptabilité des politiques.

Précisons que la modération à l’aide de l’IA n’a rien de nouveau en soi, elle est utilisée depuis des années pour simplifier le rôle des modérateurs humains (ou même pour les remplacer, avec tous les problèmes qui peuvent en découler). Dans ce domaine, Reddit vient d’ailleurs d’annoncer une modernisation de son infrastructure. Ce n’est pas non plus la première fois que Mistral propose un modèle dédié, avec par exemple Moderation 2 publié en mars dernier. Aucun de ces modèles n’avait cependant été mis en avant de cette manière, uniquement l’API commerciale lancée en novembre 2024.

Quelle modération ? Quelle sécurité ?

Mistral l’affirme : « un petit modèle peut battre des modèles beaucoup plus grands si les données sont correctes ». Mais de quoi parle-t-on exactement ?

Le modèle peut notamment servir à la modération de prompts, autrement dit de garde-fou à l’entrée d’un chatbot. Par exemple, avant de transmettre la question d’un utilisateur à votre LLM principal, vous pouvez interroger Shieldstral avec une politique du type « Ce message demande-t-il des instructions pour fabriquer une arme ? ». Si le score dépasse le seuil que vous avez fixé, vous bloquez l’appel au LLM et renvoyez un message de refus prédéfini. Le modèle principal n’est alors pas mis en contact avec le contenu problématique.

Shieldstral peut également servir pour la procédure inverse : un garde-fou en sortie du modèle principal, pour vérifier cette fois la réponse qui devrait être affichée à l’utilisateur. Par exemple, pour vérifier qu’un assistant médical n’a pas donné de posologie précise ou qu’un chatbot utilisé pour le support n’a pas halluciné une promesse commerciale ou un produit.

Mistral cite plusieurs autres cas de figure. Shieldstral peut aussi être utilisé dans un cas très spécifique : la détection de refus. Une question comme « L’assistant a-t-il refusé la demande ? » appliquée à la paire prompt-réponse permet de mesurer le taux de refus d’un modèle en production, même à grande échelle selon l’entreprise. L’indicateur obtenu peut servir à de la surveillance qualité ou à de la détection de faux positifs. Ces derniers peuvent en effet entrainer des « sur-refus », le modèle déboutant l’utilisateur sur des demandes qui devraient pourtant être légitimes.

Shieldstral peut aussi servir aux images. Le cas est classique et permet de répondre à des questions communes de modération comme « Cette image est-elle appropriée pour un public de moins de XX ans ? ».

L’entreprise française insiste sur la souplesse de son petit dernier, qui permet de traiter toutes ces demandes sans avoir à réentraîner le modèle selon le contexte visé.

Une précision cruciale des prompts

Attention toutefois, Mistral précise bien que son modèle ne peut traiter qu’une seule politique de modération par appel. On peut en appliquer plusieurs, mais il faut alors émettre une requête distincte par politique. Un exemple simple : si on veut appliquer les cinq critères « élémentaires » de modération (violence, contenu sexuel, haine, désinformation et automutilation) sur le même contenu, il faut cinq appels séparés. Un point mentionné dans la fiche du modèle sur Hugging Face. Dans tous les cas, le modèle ne répond que par un « oui » ou un « non » global.

En outre, la précision des prompts est cruciale. Une question générale telle que « Ce contenu est-il problématique ? » n’a aucun ancrage sémantique. En revanche, « Ce contenu incite-t-il à la haine contre une minorité ? » cible un préjudice et une cible spécifiques. Si l’on souhaite obtenir des réponses sur des questions plus vagues (ou plus rapides, tout simplement), il faut lister toutes les politiques désirées dans les instructions du modèle.

Shieldstral, dans cette première version, comporte aussi certaines limitations à connaitre. Par exemple, il ne prend pas en charge l’audio ni la vidéo. En outre, sa robustesse n’est pas caractérisée sur des documents très longs (équivalents à plusieurs milliers de tokens). Surtout, le modèle n’affiche aucune trace de raisonnement : il renvoie un score, pas une justification.

Enfin, si le billet d’annonce ne l’évoque pas, la fiche de Shieldstral sur Hugging Face mentionne toutefois qu’il s’agit d’une « public preview ». Prudence donc dans la mise en production : mieux vaut piloter le modèle en parallèle d’une couche de modération existante avant de remplacer quoi que ce soit.

Revoilà la sous-préfète

Un « nouveau » malware s’est propagé dans des centaines de paquets sur npm, dont plusieurs très populaires. Il s’agit une nouvelle fois d’une attaque contre la chaine d’approvisionnement ayant réussi à contourner toutes les mesures de sécurité. Dans le code, l’ombre de Shai-Hulud plane, tandis que le point de défaillance initial n’est pas clair.

Le nouveau venu se nomme ChainDrop. Selon les analyses faites sur son code, il est basé sur Shai-Hulud (en référence au ver des sables dans l’univers de Dune), qui avait déjà fait un carnage dans NPM en septembre 2025. Il en reprend les principales caractéristiques, dont son aspect auto-répliquant et le vol de nombreuses informations.

On pourrait croire que l’attaque de l’automne 2025 avait provoqué une vague d’actions pour verrouiller les comptes et inciter à la plus extrême prudence. C’est en fait le cas, mais le ou les pirates s’y sont pris autrement.

Que s’est-il passé ?

La compromission a été réalisée en poussant directement des fichiers malveillants sur la branche principale des dépôts, puis en créant immédiatement de nouvelles versions. Conséquence, ces versions vérolées ont été publiées sur NPM avec une provenance valide signée par GitHub Actions. Les contrôles de provenance npm, censés garantir qu’un package provient bien d’un flux légitime, n’ont ainsi rien pu détecter car les pirates ont justement réussi à le détourner.

868 paquets, répartis sur 1 381 versions, ont pu être contaminés par ce biais. Le pouvoir de nuisance est réel, car beaucoup d’entre eux sont populaires, l’ensemble de la liste cumulant en moyenne deux milliards de téléchargements par mois.

Tout est parti de la compromission du compte du mainteneur du paquet keyv (Jared Wray), qui représente à lui seul plus de 600 millions de téléchargements par mois. S’en sont suivies les contaminations de flat-cache, file-entry-cache, cacheable-request, cacheable ou encore cache-manager, autant de projets spécialisés dans la gestion des caches pour de multiples cas de figure.

Une fois les paquets contaminés, la propagation s’est faite rapidement, atteignant des entreprises comme Deliveroo, Ornikar, OneReach, Picsart, Qlik ou ServiceTitan.

La petite chimie de ChainDrop

Les chercheurs de l’entreprise de sécurité Aikido se sont penchés sur ChainDrop. Dans leur billet publié le 4 aout, ils décrivent ainsi deux composants retrouvés dans les paquets contaminés, comme c’est souvent le cas.

Le premier est un dropper nommé setup.mjs. Un dropper est un code chargé d’installer un ou plusieurs composants malveillants sur le système. Il sert de vecteur d’installation pour la charge utile (payload) et remplit plusieurs missions : déposer l’exécutable sur le disque, l’extraire depuis des données intégrées dans le programme ou le télécharger depuis un serveur distant, l’exécuter en mémoire ou encore mettre en place des mécanismes de persistance avant de lancer la charge utile. Selon les chercheurs, setup.mjs est un dropper fortement obfusqué récupérant le runtime JavaScript Bun depuis son dépôt GitHub pour pouvoir exécuter ensuite la charge.

C'était mieux avant

Pour la deuxième fois en deux mois, l’équipe de la distribution Arch Linux a dû intervenir dans le dépôt AUR (Arch User Repository). En cause, une nouvelle vague de prises de contrôle sur des paquets existants pour leur injecter du code malveillant.

La décision a été annoncée initialement le 30 juillet par le contributeur Robin Candau. Dans son message, il indiquait que la solution était temporaire, le temps qu’une solution soit trouvée.

Mais de quoi parle-t-on ? D’une désactivation de la fonction d’adoption, pour empêcher toute personne « d’adopter » un paquet plus ou moins abandonné du dépôt AUR pour contribuer à nouveau à son code. Ce processus avait été détourné en juin et avait abouti à l’insertion de code malveillant dans plus de 1 600 paquets du dépôt AUR.

• Atomic Arch : 1 600 paquets vérolés dans le dépôt AUR d’Arch Linux

Une ampleur moindre, un danger identique

Le gros problème dans la campagne malveillante de juin était le nombre élevé de paquets concernés. Même avec des actions rapides, il était impossible de s’assurer que personne n’avait reçu les versions contaminées via des mises à jour. Ce qui était tout l’intérêt pour les pirates et qui rend les attaques par compromission de la chaine d’approvisionnement aussi efficaces.

Dans la nouvelle attaque, comme relevé notamment par Bleeping Computer, l’ampleur semble nettement moindre, mais on ne connait pas encore le nombre exact de paquets compromis. Sur les listes officielles, on trouve des listes compilant une trentaine de paquets compromis, tandis que d’autres sur Reddit évoquent plus de 200 paquets.

Si l’on en croit l’analyse technique publiée par l’Independent Federated Intelligence Network (IFIN), la campagne a débuté le 29 juillet avec le paquet « openconnect-sso ». Les similitudes avec la campagne de juin sont évidentes, dont l’usage du réseau Tor pour l’hébergement de l’infrastructure ou l’emploi d’un fichier ELF précompilé et obscurci.

Petit pimousse

Un an après la version 8.0, l’équipe du projet FFmpeg passe à la mouture majeure suivante. Avec FFmpeg 9.0, Vulkan est particulièrement à l’honneur avec plusieurs améliorations importantes, notamment avec certains codecs orientés production et/ou post-production.

La nouvelle version, nommée « Lei », propose ainsi le décodage matériel d’APV (Advanced Professional Video) via Vulkan. APV est un codec royalties-free (sans redevance) créé par Samsung et pensé comme alternative ouverte à des formats comme le ProRes d’Apple. Comme toujours avec le décodage matériel, cela signifie que le travail est déchargé du CPU vers le GPU, indépendamment du constructeur, Vulkan étant une API multiplateforme.

Puisque l’on parle du ProRes, FFmpeg 9.0 a également du neuf sur le codec. Une accélération Vulkan est là aussi proposée, en complément d’un support ProRes RAW via VideoToolbox. Les flux ProRes RAW, très lourds et jusqu’ici majoritairement décodés au format logiciel ou via des chemins propriétaires Apple, obtiennent ainsi une voie d’accélération GPU générique, ce qui devrait là aussi avoir des répercussions importantes.

Ces deux ajouts, en plus du nouveau filtre v360_vulkan pour la reprojection vidéo 360° et/ou équirectangulaire, positionnent encore un peu plus FFmpeg comme pipeline GPU indépendant. Il fonctionne à l’identique sur les puces Intel, AMD ou encore NVIDIA, sur tous les systèmes d’exploitation, sans dépendre de SDK (kits de développement) propriétaires comme CUDA, NVENC, AMF ou encore VideoToolbox.

Invisible et omniprésent

Parmi les autres nouveautés, on peut noter la lecture native des WebP animés, des améliorations liées au cadre AMF d’AMD, l’arrivée d’un filtre transpose_cuda (rotation/retournement d’image accéléré CUDA, pour éviter les allers-retours GPU > CPU > GPU), le support et le passthrough des métadonnées dynamiques SMPTE 2094 - 50 pour améliorer la gestion des flux de travail HDR, le décodage HE-AAC 960 pour le contenu DAB+ côté audio, ou encore un nettoyage du code avec la suppression de plusieurs éléments obsolètes, dont le décodeur CELT et le parseur Ogg/CELT.

Comme toujours avec les nouvelles versions de FFmpeg, de nombreux composants sont mis à jour, comme libavutil 61.1.100, libavcodec 63.1.100, libavformat 63.1.100, libavdevice 63.1.100, libavfilter 12.1.100, libswscale 10.1.100 et libswresample 7.1.100.

L’importance de cette nouvelle version ne se révèlera, comme d’habitude, qu’une fois son intégration réalisée dans d’autres projets qui en exploiteront les capacités. Rappelons que FFmpeg, même s’il n’est pas connu généralement du grand public, est une brique d’infrastructure invisible mais omniprésente dans le traitement multimédia au sens large.

Si vous connaissez mal ce projet, il s’agit d’une boite à outil pour coder, décoder, transcoder, muxer, démuxer et filtrer à peu près tous les formats audio/vidéo existants. On le retrouve dans de nombreux logiciels et services connus, dont le plus célèbre est sans doute VLC. FFmpeg joue également un rôle essentiel dans YouTube, HandBrake, OBS Studio, des serveurs multimédia domestiques comme Plex et Jellyfin, Discord, Chrome, Blender ou encore WhatsApp. Certains services commerciaux ayant pignon sur rue, comme Netflix, s’en servent également, mais on ne connait pas la nature précise de cet usage.

Mince, ça marche bien en plus

Comment ? Un gestionnaire des tâches sur macOS ? Oui, et bien fait en plus. Il s’agit pour l’instant d’une bêta, mais le projet est prometteur. Et des versions pour Windows et Linux sont prévues.

Dave Plummer, ex-ingénieur de Microsoft (il a notamment travaillé sur NT 4.0), s’est lancé dans un drôle de projet : estimant que le moniteur d’activité de macOS n’était pas digne de la plateforme, il a attaqué le développement d’un authentique gestionnaire des tâches pour la plateforme d’Apple. Oui, un gestionnaire des tâches, comme sous Windows.

Du code neuf et natif

L’histoire est intéressante pour plusieurs raisons. D’abord, le moniteur de macOS, s’il remplit bien ses fonctions élémentaires, ne propose pas de vue de synthèse de ce qui se passe sur la machine : le taux d’occupation du CPU (avec séparation par cœur logique), le remplissage de la mémoire, l’activité réseau ou du stockage, etc.

Ensuite, Dave Plummer a apporté un soin particulier à son développement. Il raconte comment Microsoft l’a laissé examiner, « à titre gracieux », le code source du gestionnaire des tâches de Windows XP. Cependant, aucun pan de code n’a été repris, affirme le développeur. À la place, il a développé un nouveau moteur partagé en C++ ainsi qu’une interface en Swift. C’est d’ailleurs un autre point intéressant : l’interface est léchée, réactive et parfaitement intégrée à l’ambiance macOS. La filiation avec le composant de Windows est cependant assumée dans le nom : TMOG, pour Task Manager Original.

C’est un « oui » !

L’application réunit également plusieurs fonctions au sein de la même interface. On retrouve, comme dans le gestionnaire des tâches de Windows, des onglets avec la vue de synthèse de ce que fait la machine, la liste des processus (qui reprend la vue par défaut du moniteur de macOS) ou encore celle des services. TMOG y ajoute un onglet pour les informations système ou encore la liste des applications lancées au démarrage, avec possibilité de les désactiver.

L’ensemble est particulièrement fluide, surtout pour les jauges et les courbes d’occupation. Les paramètres de l’application permettent de modifier différents éléments d’interface, dont le thème (clair ou sombre), la police par défaut ou encore la fréquence de rafraichissement.

TMOG est fournie pour l’instant sous forme de bêta. Elle n’est pas distribuée sur le Mac App Store pour une raison très simple : la boutique d’Apple oblige les applications qui y sont distribuées à fonctionner dans une sandbox. Pour un projet comme TMOG, ce type d’isolation est impossible, car elle doit aller chercher des informations dont la sandbox n’autorise pas la récupération.

L’application est gratuite et doit le rester, du moins sous cette forme. Dave Plummer indique qu’une version Pro payante pourrait apparaître plus tard. Et si vous vous posez la question : oui, des versions Windows et Linux sont prévues (cette dernière vient tout juste d’être confirmée). Le développeur insiste sur le caractère natif de ces applications et leurs performances.

L'interdiction pour tous

Le 11 août, la liste Bloctel disparaitra. Un changement attendu de longue date, car au-delà d’une inefficacité croissante, cette suppression viendra acter un renversement complet de la situation : le démarchage téléphonique sera interdit, sauf consentement explicite préalable.. Du côté des usagers cependant, la tranquillité n’est pas pour demain.

La liste Bloctel date d’une « autre époque ». Créée en 2014 pour prendre la suite de la liste Pacitel, elle en gardait le fonctionnement général : en s’y inscrivant, on signalait son opposition à tout démarchage téléphonique. Avec les années, les évolutions technologiques et des techniques marketing toujours plus agressives, toutes ces listes ont fini par être caduques, cumulant les avis très critiques sur leur inefficacité.

Le 11 aout marquera donc un vrai tournant : Bloctel va disparaitre, remplacée par une interdiction de principe pour le démarchage téléphonique, plus précisément la « prospection commerciale téléphonique non consentie ». De fait, Bloctel n’a plus d’utilité et le cadre légal évolue pour répondre à l’obsolescence du cadre antérieur. Le tout sur fond d’explosion des fraudes aux numéros de téléphone et des usurpations d’identité téléphonique (spoofing).

• Une nouvelle loi interdit le démarchage téléphonique non consenti

Qu’est-ce qui change ?

Jusqu’à présent, le système français de régulation reposait sur une logique d’opt-out : il fallait soi-même se signaler pour repousser ces sollicitations commerciales. Les consommateurs passaient donc par une démarche active pour exprimer leur refus. Légalement, les professionnels de la prospection commerciale étaient tenus de confronter leurs fichiers à l’annuaire d’opposition avant tout lancement de campagne téléphonique.

Sur la page officielle du service, on peut ainsi lire que la loi nᵒ 2025 - 594 du 30 juin 2025 s’appliquera au 11 août : « À cette date, le service Bloctel deviendra obsolète. La nouvelle loi inverse en effet le principe actuel. Aujourd’hui, les consommateurs doivent s’inscrire sur Bloctel pour exprimer leur refus d’être démarchés, et les professionnels ont alors l’interdiction de les contacter. À compter du 11 août 2026, ce sera l’inverse : les professionnels ne pourront démarcher que les consommateurs pour lesquels ils auront recueilli un consentement explicite au préalable. Le service Bloctel devient donc inutile ».

• Qui m’appelle ? Petit guide pratique contre la fraude téléphonique

Les limites de Bloctel sont connues depuis longtemps. D’abord, son efficacité a été rabotée de manière chronique par une prolifération de clauses de consentement ambiguës ou dissimulées dans des contrats d’adhésion en ligne. Ensuite, l’explosion du nombre de plateformes d’appels hors des frontières nationales et l’usurpation des numéros de téléphone ont fini par enterrer ce qui restait d’efficacité.

Avec le nouveau régime juridique, le consentement préalable du consommateur devient une condition stricte (au sens du RGPD) à toute prospection commerciale téléphonique. Dans le décret nᵒ 2026 - 662 du 23 juillet 2026, qui complète la loi du 30 juin 2025, le consentement est décrit comme « une manifestation de volonté libre, spécifique, éclairée, univoque et révocable, par laquelle une personne accepte, par un acte positif clair, l’utilisation de ses données à caractère personnel à des fins de prospection commerciale par voie téléphonique ». En d’autres termes, une case à cocher ou un consentement perdu dans des conditions générales acceptées en bloc ne compte pas.

Précisons que cette interdiction générale est en fait l’extension d’une interdiction sectorielle. Le 24 juillet 2020, la prospection téléphonique est ainsi devenue illégale pour tout ce qui touche à la vente d’équipements ou la réalisation de travaux destinés aux économies d’énergie ou à la production d’énergies renouvelables. Travaux d’isolation, pompes à chaleur, panneaux photovoltaïques : tout le monde ou presque a reçu au moins un appel dans ce cadre (sans parler des tonnes de spams dans les e-mails).

Selon le cabinet Kohen Avocats, les jurisprudences dans ce secteur devraient d’ailleurs « éclairer la portée du futur régime », notamment sur deux points : la nullité de l’éventuel contrat alors souscrit et sur la charge de la preuve, qui pèse désormais sur le professionnel. En effet, en cas de conflit, c’est bien à ce dernier de prouver qu’il a recueilli le consentement clair de l’utilisateur. S’il ne le peut pas, tout contrat qui aurait été souscrit par ce biais sera déclaré nul.

Rappelons que depuis le 1ᵉʳ juillet 2025, l’interdiction sectorielle sur l’économie d’énergie a été étendue aux SMS, e-mails et réseaux sociaux. Dommage, ces extensions n’ont pas été reprises plus largement dans le changement de régime du 11 août.

• Démarchage téléphonique : comment bloquer et filtrer les appels sur les fixes et smartphones

Une interdiction universelle ?

Si le renversement de régime fonctionne dans l’immense majorité des cas, quelques points sont cependant à préciser.

Par exemple, les entreprises peuvent contacter leurs clients tant qu’un contrat est actif, mais il faut que l’appel concerne effectivement ce contrat. Là encore, si le contact est établi au sujet d’un tout autre produit, il est illégal.

BUF6 contre les vampires

Plasma 6.8 va intégrer un changement majeur dans la manière dont le travail graphique est effectué sur les configurations contenant plusieurs GPU. Les gains devraient être substantiels, particulièrement sur les ordinateurs portables ayant des configurations « hybrides ».

La prochaine mouture de l’environnement de bureau va embarquer un changement technique qui devrait faire les beaux jours de bon nombre de joueurs, relève Phoronix. Le développeur Xaver Hugl a annoncé en effet dans un billet de blog l’arrivée de DMA-BUF v6 pour KWin, qui est à la fois le gestionnaire de fenêtres dans KDE et un compositeur Wayland.

• X11, Wayland : pourquoi la transition est-elle aussi longue ?

Cascade d’opérations inutiles

Personne ne s'en plaindra

Pavan Davuluri, vice-président de Microsoft chargé de Windows et des services, a publié un important billet de blog le 31 juillet. Il y renouvelle les engagements de l’entreprise sur les améliorations portées ou à venir de Windows 11, dont les performances.

Le responsable commence par faire le tour des travaux déjà engagés et montrés. Ils sont soit disponibles depuis peu, soit vont arriver ou sont déjà présents dans les préversions de la branche expérimentale du système, accessible depuis le programme Windows Insider.

Il liste ainsi les possibilités de personnalisation de la barre des tâches, la réduction du périmètre des fonctions IA « là où elles ont le plus de sens », la réduction des frictions dans Windows Update, les performances et la fiabilité de l’Explorateur, un plus grand contrôle sur les widgets, un programme Windows Insider plus simple et transparent, ou encore les améliorations sur le Feedback Hub. Les performances, la fiabilité et les « expériences bien conçues » sont à considérer désormais comme la sainte trinité qui guiderait les équipes.

Pavan Davuluri liste également les apports à venir : une recherche plus rapide et efficace, le renforcement de WinUI et son utilisation plus intensive dans le système (dont la fenêtre des propriétés apparue récemment), les fonctions supplémentaires pour le menu Démarrer et la barre des tâches, une élévation générale de la qualité des pilotes via la Driver Quality Initiative, de meilleures performances pour de nombreux composants, le support des webcams ESS pour Windows Hello ou encore un effort général de réduction de l’empreinte mémoire.

• Windows 11 recevra en août des améliorations attendues de longue date

Certaines zones du système font l’objet d’une attention particulière, selon le responsable. D’abord, une expérience « out of the box » plus rapide et efficace. Ensuite, une mise en avant des contrôles parentaux (en particulier lors de la première configuration de l’ordinateur), ou encore des optimisations sur la mémoire consommée.

Un travail spécifique sur la consommation de mémoire

Ce dernier point a été copieusement repris sur X ces derniers jours. Pavan Davuluri pointe spécifiquement les configurations ayant 8 Go de mémoire : « Réduire l’empreinte mémoire Windows pour offrir une expérience Windows rapide et réactive sur tous les PC utilisés quotidiennement par les clients ».

Une phrase loin d’être anodine, pour deux raisons. D’abord, parce que le système de Microsoft a toujours été considéré comme gourmand. L’entreprise semble piquée au vif, particulièrement depuis que Linux apparait de plus en plus comme une alternative viable à Windows pour les jeux vidéo. Un domaine qui était jusque très récemment la chasse gardée de Microsoft, grâce notamment à l’abondance de pilotes (même si leur qualité peut fortement varier).

• Dis Next, ça sert à quoi un noyau et des pilotes dans un système ?

Ensuite parce que la situation mondiale l’exige probablement : la mémoire vive est beaucoup plus onéreuse. Le marché exerce sur les éditeurs logiciels une pression jamais vue, après des décennies de croissance presque linéaire sur la quantité toujours plus importante de RAM (ou de mémoire vidéo) dans les configurations. Ce n’est pas un hasard non plus si Apple a insisté pendant sa dernière WWDC sur les optimisations apportées à la fournée 27 de ses systèmes, particulièrement macOS.

« Les derniers mois nous ont redonné de l’énergie »

Plusieurs personnes de l’équipe Windows se sont exprimées dans le sillage de la publication de Pavan Davuluri, le plus souvent pour indiquer que la période était intéressante et qu’il restait beaucoup à venir. Plusieurs laissent penser que cette accélération était attendue de pied ferme. Davuluri l’indique à demi-mots à la fin de son billet :

« Les derniers mois nous ont redonné de l’énergie. Rencontrer des membres de Windows Insiders lors de nos rencontres mensuelles et entendre ce que vous en pensez a été l’un des meilleurs moments. C’est un travail que nos ingénieurs adorent et nous voulons que vous le ressentiez dans le produit. Nous savons que nous avons encore beaucoup à faire, et nous sommes reconnaissants de vivre ce voyage avec vous ».

Certains observateurs semblent y voir un changement fort de signal. Ewan Dalton, de Windows Latest, indique ainsi avoir travaillé plus de 25 ans chez Microsoft. Selon lui, Windows « reçoit de nouveau les soins qu’il mérite ». Il estime que Microsoft s’est développé dans trop de directions pour que le système reste un produit de qualité, notamment avec l’arrivée d’Azure et plus généralement du cloud.

Maintenant que le système est attaqué de toute part (Linux, MacBook Neo, performances, expérience utilisateur…), l’éditeur bougerait enfin dans la bonne direction. La situation sera probablement plus claire d’ici quelques mois et nous ferons le point sur les promesses et les résultats.