À balles réelles

Un lourd rapport a été publié ce 15 juillet, suite aux travaux de la commission lancée en février pour analyser les dépendances structurelles et les vulnérabilités systémiques dans le secteur du numérique et les risques pour l’indépendance de la France. Cette commission, présidée par Philippe Latombe avec Cyrielle Chatelain comme rapporteure, pointe six grandes catégories de failles et liste de nombreuses recommandations, dont certaines radicales.

Cet épais rapport sur la souveraineté numérique de 453 pages est le fruit d’un travail ayant réuni 26 députés issus de l’ensemble des groupes politiques. Le rapport a été adopté le 8 juillet, à l’issue de 45 auditions, 112 personnes ayant été entendues. Une semaine plus tard, le rapport est en ligne et une conférence de presse a été organisée pour en brosser les grandes lignes.

Constats amers

Dès l’avant-propos, Philippe Latombe donne le ton. Lui qui est également président de la commission chargée d’examiner le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité situe le rapport dans la continuité d’une mission d’information qu’il avait déjà consacrée à la souveraineté numérique en 2021. Le propos se fait volontiers acide : « Mon principal regret reste sans doute qu’il ait fallu attendre l’ère MAGA pour qu’un plus grand nombre de politiques et de groupes parlementaires s’intéresse aux dépendances structurelles et aux vulnérabilités systémiques de la France dans le secteur du numérique, ainsi qu’aux risques pour l’indépendance et la souveraineté de notre pays ».

Le député dit avoir été « peu suivi » et « trop souvent cantonné au rôle de Cassandre ». À ceci près que le personnage mythologique « n’avait à alerter que sur un cheval de Troie, alors que nous devons faire face à une multitude de vulnérabilités : fournisseurs américains de cloud, systèmes d’exploitation étrangers, nombreux composants électroniques asiatiques, infrastructures internet mondiales… ».

L’introduction situe ensuite le périmètre retenu. D’une part, les administrations publiques et les entreprises d’intérêt vital, jugées prioritaires en raison de leur criticité. D’autre part une approche plus large des « dépendances systémiques », couvrant six familles de vulnérabilités. La commission indique explicitement ne pas avoir traité en détail la cybersécurité proprement dite ni les dépendances matérielles, qui font l’objet de travaux distincts.

Les six catégories de vulnérabilités sont les suivantes :

• les failles démocratiques à travers les ingérences et la désinformation. Les algorithmes de recommandation des plateformes privées sont pointés du doigt, dont celui de X au travers des travaux menés par Germain Gauthier, directeur de recherche au CNRS : jusqu’à 15 % des électeurs indépendants peuvent changer d’opinion après une exposition aux réseaux sociaux ;
• l’exploitation des failles techniques dans les administrations et les entreprises, et le torrent d’attaques cyber qui en découle, avec pour preuve les multiples fuites référencées ces dernières années ;
• la quantité croissante de données à stocker et à protéger, avec les trois thématiques liées : légalité des traitements opérés (RGPD), extraterritorialité du droit (tout particulièrement américain) et captation des données ;
• la primauté du profit sur les libertés individuelles, qui entraîne violation de la vie privée, exposition à des contenus nocifs et développement d’algorithmes addictifs ;
• le verrouillage et la dépendance des utilisateurs, pratique jugée comme étant « au cœur des stratégies des fournisseurs de logiciels » ;
• les vulnérabilités liées aux infrastructures et aux composants clés.

Où en sont les administrations françaises ?

C’est le chapitre le plus documenté du rapport. La méthodologie a reposé sur des questionnaires envoyés à l’ensemble des directions numériques ministérielles (annexe 2), complétés par des auditions des directeurs des systèmes d’information.

Il en est notamment ressorti que sur les 466 applications métiers recensées dans l’administration (liste non exhaustive), les deux tiers ont été développées spécifiquement pour les besoins associés, dont 57 % par des prestataires externes. L’analyse croisée par pays d’origine montre que les fournisseurs français dominent largement les applications les plus critiques : 69 % pour la catégorie 1 (atteinte à l’ordre public, sécurité, vie des personnes) et 83 % pour la catégorie 2 (interruption d’une mission de service public essentielle), soit respectivement 81 et 228 applications. Les États-Unis arrivant en deuxième position avec 7 et 12 applications respectivement.

La nouvelle version 1.3 de COSMIC Desktop vient de paraître. Cet environnement de bureau est pour rappel édité par l’entreprise System76, en plus de sa propre distribution Linux, Pop!_OS. D’abord réservé à cette dernière, COSMIC Desktop est devenu un projet indépendant, aussi open source et libre que le reste, développé intégralement en Rust et disponible sur d’autres systèmes. Fedora a par exemple son propre Spin.

Cette version 1.3 apporte surtout l’apparence « Frosted glass » aux éléments de l’interface. Les utilisateurs de Pop!_OS l’avaient eue il y a quelques jours, COSMIC Desktop 1.3 permet de l’activer sur toutes les autres distributions.

Le travail sur Frosted glass a duré plusieurs mois. Inspiré par le Liquid Glass, il fait davantage dans le verre givré/dépoli que dans le « verre liquide », avec un résultat plus sobre. Les réglages, désactivés par défaut, se trouvent dans Paramètres > Bureau. Sous le choix du type d’arrondi, une nouvelle entrée « Frosted glass » fait son apparition. Elle ouvre un panneau dans lequel on peut choisir les éléments sur lesquels on veut répercuter ce type d’affichage. On remarque d’ailleurs que tout est encore en anglais.

Le résultat final dépend largement du thème initialement choisi. Avec ceux par défaut pour le clair et le sombre, le verre givré apporte une touche de transparence, qui ne semble pas avoir les soucis de lisibilité qu’avait Liquid Glass dans la première proposition d’Apple (les versions 27 des systèmes travaillent d’ailleurs ce point). L’ajout de ces réglages reste optionnel et les personnes n’appréciant pas ce type d’affichage pourront passer leur chemin.

COSMIC Desktop 1.3 présente d’autres apports, comme l’affichage du GPU dédié dans le menu contextuel COSMIC, le support des fonds d’écran AVIF, le remplacement du backend personnalisé NetworkManager par nmrs (en Rust), un meilleur défilement pour la molette, ou encore des améliorations pour le nouveau COSMIC Monitor apparu dans la version 1.2 du Desktop, avec notamment le calcul de la consommation d’énergie pour les GPU AMD/Intel et la possibilité de suspendre les GPU NVIDIA.

En juin, Microsoft avait déjà battu son record avec 200 failles corrigées. Entre temps, l’éditeur a expliqué comment l’intelligence artificielle faisait désormais partie de ses processus de révision. Il fallait donc s’attendre à une déferlante de correctifs dans les mois qui suivraient, avant sans doute de retomber sur un rythme de croisière.

• Microsoft officialise son utilisation intensive de l’IA pour la découverte des failles

Le nouveau Patch Tuesday explose littéralement les compteurs : 570 vulnérabilités corrigées, dont 59 sont critiques. 48 d’entre elles sont de type exécution de code à distance, 9 d’élévation des privilèges, une permet un contournement de la sécurité et la dernière est de type spoofing.

Dans cet énorme lacher de correctifs, on en repère également trois pour des failles 0-day, dont deux activement exploitées : CVE-2026-56155 (Active Directory Federation Services) et CVE-2026-56164 (SharePoint). La troisième, CVE-2026-50661, permet un contournement de BitLocker si l’on réussit à obtenir un accès physique au stockage. Elle ne semble pas exploitée, mais ses détails sont publics.

Il est recommandé de se rendre dans Windows Update au plus vite pour télécharger et installer la mise à jour, qui réclamera un redémarrage. La dangerosité ne vient pas tant du nombre total de failles corrigées que du nombre de vulnérabilités critiques. Reste à voir maintenant si le Patch Tuesday d’août sera du même acabit.

Dans un billet d’actualités mensuel, publié le 8 juillet, Clément Lefebvre, fondateur et principal développeur de la distribution Linux Mint, a indiqué que le support de Wayland dans Cinnamon n’était plus expérimental.

La prochaine version majeure de Linux Mint, estampillée 23 et prévue pour la fin de l’année, proposera donc une « vraie » session Wayland, aux côtés de la session X11 classique, qui restera telle quelle. Le développeur ne dit pas en revanche si la session Wayland sera utilisée par défaut, ou si le choix sera plus conservateur. La décision sera probablement annoncée dans les mois qui viennent.

Clément Lefebvre indique que le travail sur le support de Wayland a été intense, avec de nombreux résultats positifs. On note ainsi des améliorations pour la stabilité générale, la gestion des fenêtres, le support du multi-écran, la prise en charge du HiDPI et de l’échelle fractionnaire ou encore des GPU NVIDIA.

Ces nouveautés étant prévues pour la prochaine version de Cinnamon, elles seront automatiquement reprises dans Linux Mint 23, qui doit arriver en décembre. S’agissant de la première mouture à sortir après la publication d’Ubuntu 26.04, elle en reprendra donc les bases, avec à la clé une vaste modernisation de la base technique.

Les améliorations citées ne seront pas les seules. Lefebvre évoque par exemple une cartographie correcte de la taille et de la position des fenêtres quand Cinnamon est utilisé avec Wayland. Même chose pour les applets et les menus de contenu. Le prochain Cinnamon intègrera aussi un mécanisme de prévention du vol de focus (« focus stealing » en VO), pour s’assurer que la saisie ou les clics ne se fassent pas dans une autre application sans interaction explicite de l’utilisateur. Nous avions souligné ce risque de sécurité dans notre dossier consacré à la transition de X11 vers Wayland.

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

D’autres apports sont prévus et seront probablement accueillis avec joie par les utilisateurs. Par exemple, l’accélération matérielle a été intégrée au compositeur, au bureau et aux clients Wayland et XWayland (mécanisme de compatibilité pour les applications X11 dans une session Wayland). On note aussi la prise en charge de la session graphique de systemd pour améliorer la compatibilité avec d’autres distributions (Cinnamon peut être installé sur d’autres systèmes, comme Ubuntu et Fedora)

Ça change tout, mais ça ne change rien

Ubuntu 26.10 remplace enfin dbus-daemon par dbus-broker comme implémentation par défaut de D-Bus, un changement essentiellement interne visant à améliorer les performances, la robustesse et l’extensibilité. Aucun impact particulier n’est attendu sur les applications.

D-bus est un bus de messages : grâce à lui, les processus Linux peuvent communiquer entre eux. Ce composant est crucial, car il permet aux fonctions d’avoir le résultat attendu. Par exemple, le gestionnaire de fichiers demande au système de monter une clé USB pour en afficher le contenu, le panneau de configuration modifie la luminosité de l’écran, une application demande l’ouverture du sélecteur de fichiers, etc.

Pour quoi faire ?

À compter d’Ubuntu 26.10, le composant chargé des messages internes sera changé. dbus-daemon sera remplacé par dbus-broker, avec à la clé de sérieux avantages techniques : traitement asynchrone des messages, meilleure gestion des ressources, comptabilisation plus précise des clients, ou encore meilleure résistance générale lors de pics de trafic D-bus.

Il ne devrait y avoir aucun changement visible dans la grande majorité des scénarios. Bien que dbus-broker soit plus moderne, il est davantage pensé pour éviter les goulets d’étranglement que pour fournir une accélération dans les opérations basiques.

Si Canonical a décidé ce remplacement, c’est que dbus-daemon a été créé il y a 22 ans. Malgré son âge vénérable, il a reçu de nombreuses évolutions. Cependant, il accuse le poids des années : son architecture a été conçue à une époque où le nombre de services système était bien plus faible qu’aujourd’hui, où les environnements de bureau étaient plus simples et les charges de travail beaucoup moins importantes.

Pourquoi pas avant ?

Cette décision n’a rien d’avant-garde. Fedora, souvent la première distribution à opérer des changements techniques d’envergure, a déjà réalisé cette bascule en 2019. Pourquoi Canonical a-t-elle attendu si longtemps ? L’entreprise cite deux raisons :

• Il a fallu attendre que GDM (le gestionnaire de connexion/bureau de GNOME) se débarrasse de ses dépendances à dbus-daemon, ce qui a fini par arriver avec GNOME 49
• et attendre que dbus-broker atteigne une compatibilité complète avec AppArmor, notamment pour certaines fonctions liées à la gestion des paquets Snap

La stratégie de Canonical face à la nouveauté ne change pas. Les bascules ne s’opèrent que lorsque l’entreprise estime que la situation s’y prête. On se souvient par exemple que le passage à Wayland s’était fait plusieurs années après d’autres distributions, un peu plus de cinq ans après celle de Fedora, par exemple. Le remplacement des composants historiques se fait progressivement, pour éviter une cassure chez les utilisateurs, Ubuntu étant la distribution Linux la plus utilisée au monde.

Des agents et de la rouille

Bun, un environnement d’exécution JavaScript et un gestionnaire de paquets, a annoncé le 8 juillet une conversion complète de son code vers Rust en un temps record. L’opération a été en grande partie menée grâce à l’utilisation de Claude Fable 5. Bien qu’il s’agisse d’un exemple concret en production, il ne peut pas être appliqué à tout type de projet.

Bun est un environnement et un gestionnaire de paquets pour JavaScript. Il est développé avec le langage Zig, est open source et sous licence MIT. Le projet est relativement récent sur la scène du développement, car la version 1.0 stable est sortie en septembre 2023. La dernière révision stable est la 1.3, publiée fin 2025. Elle a notamment ajouté le remplacement à chaud des modules (Bun est également un groupeur de modules, ou module bundler).

Les projecteurs se sont brusquement braqués sur Bun au même moment, quand Anthropic a annoncé son rachat. Une opération logique pour Anthropic, Bun étant déjà utilisé pour certains composants de Claude Code.

Et voilà que Bun vient d’annoncer la réécriture complète de son code Zig en Rust… en seulement 11 jours, entre les 3 et 14 mai.

• Retour sur 10 ans de Rust, un langage devenu incontournable
• Sylvestre Ledru (Mozilla) : de Firefox au noyau Linux, la fulgurante ascension du Rust

Direction Rust !

Dans son billet, Jarred Sumner, à la tête du développement de Bun, explique que la version initiale de Bun avait été écrite en un an et en Zig, avant l’apparition des LLM. Aujourd’hui, le CLI (interface en ligne de commande) de Bun est téléchargé 22 millions de fois par mois. Alors pourquoi une réécriture totale en Rust ?

Selon Sumner, le choix n’est pas idéologique, mais motivé par une liste précise de bugs récurrents dans la version Zig : des dizaines de bugs de type use-after-free (le noyau réutilise un pan de mémoire qu’il a déjà libéré), double-free (double utilisation de la fonction free() sur la même adresse mémoire) et fuites mémoire dans des modules critiques (node:zlib, node:http2, UDPSocket, crypto.scrypt, TLS…).

L’argument central de Sumner est que Zig, comme le C, ne gère pas la mémoire pour vous, et ne dispose pas de constructeurs/destructeurs. Le nettoyage repose sur le mot-clé explicite defer. Il est manuel et il faut donc penser à l’utiliser, rendant l’erreur humaine quasi inévitable à grande échelle.

« Chaque allocation mémoire doit être examinée avec minutie. Où ces octets sont-ils libérés ? Comment s’assurer qu’il ne soit libéré qu’une seule fois ? Avons-nous bien vérifié les exceptions JavaScript ? Ce pointeur collecté à la poubelle est-il visible pour le scanner de pile conservateur ? Est-ce de la mémoire récupérée ou de la mémoire gérée manuellement ? », liste Jarred Sumner, parmi les questions récurrentes.

Après avoir envisagé le C++, il se tourne finalement vers le Rust, car une bonne partie des problèmes rencontrés sont liés à la gestion de la mémoire. Avec le « nouveau » langage, loué pour la sécurité induite justement en mémoire, ces problèmes apparaissent à la compilation. Encore faut-il que le code soit en Rust « sûr » (safe).

Sumner aborde d’ailleurs ce point. 4 % du code Rust de Bun se trouvaient ainsi dans un bloc unsafe, soit environ 13 000 mots-clés unsafe dans environ 27 000 lignes sur un total d’environ 780 000. La totalité du code ne peut pas être en Rust safe, car Bun continue d’embarquer des dépendances C/C++ significatives, comme JavaScriptCore, uWebSockets, BoringSSL, SQLite et lshpack/lsquic.

Le rôle prépondérant de Claude Fable 5

Le billet détaille amplement les méthodes utilisées. Par exemple, le choix d’une réécriture complète (plutôt qu’incrémentale) a été motivé par la propre expérience de Jarred Sumner dans ce type d’opération, et par la disponibilité d’une suite de tests indépendante du langage d’implémentation. Selon Sumner, elle a permis de garder un filet de sécurité comportemental identique pour l’avant/après.

On apprend en outre que la « revue adversariale » a été faite par deux instances Claude en contexte séparé, chargées de débusquer les bugs et présentées comme le mécanisme central de contrôle qualité. Et c’est justement la présence de Fable 5 au cœur du mécanisme qui rend l’annonce si visible.

La version de test a été produite en 11 jours. Les chiffres associés sont impressionnants : 5,9 milliards de tokens d’entrée non mis en cache, 690 millions de tokens de sortie, et 72 milliards de tokens d’entrée lus en cache. Soit environ 165 000 dollars au tarif de l’API, contre une estimation d’environ un an de travail pour trois ingénieurs à temps plein sur le code existant pour les 535 496 lignes de code, selon Jarred Sumner.

Cette performance – en moyenne 1 300 lignes de code à la minute – concerne cependant la phase de génération brute, pas le code fonctionnel. Le billet précise qu’à ce stade, « absolument rien ne fonctionnait encore ». Une performance à relativiser également sur l’utilisation du LLM, car elle n’avait rien de « naïf ». L’orchestration humaine a été lourde, avec environ 50 flux de travail dynamiques et jusqu’à 64 instances de Claude en parallèle, réparties en quatre arbres de travail (worktrees). Sumner dit avoir lui-même surveillé manuellement les sorties pendant l’essentiel des 11 jours de travail.

Le billet documente aussi des échecs répétés du modèle dans des cas précis : interprétation erronée de consignes, ajout de commentaires justificatifs longs pour masquer des contournements… Un comportement suffisamment problématique pour que Sumner ait fini par ajouter une règle explicite aux réviseurs adversariaux : « Si vous avez besoin d’un paragraphe entier pour justifier qu’un contournement est correct, c’est que le code n’est pas bon – corrigez le code ».

Bon… et alors ?

Selon Jarred Sumner, les avantages de Rust sont évidents dans la préversion. Allègement des binaires, consommation de mémoire réduite, résolution de nombreux bugs liés à la mémoire existants dans la version actuelle 1.3.14… Sur le plan des performances, les gains sont plus mesurés, avec 2 à 5 % en moyenne selon les scénarios.

Jarred Sumner veut pour preuve de sa réussite que la version 2.1.181 de Claude Code, publiée le 17 juin, utilise la version de Bun réécrite en Rust. Cela signifie-t-il que tout est parfait et que tout le monde devrait se lancer dans le même type d’opération ? Pas du tout.

Le billet de Bun est assez transparent sur les défis restants. Bun 1.4.0 sera bien la première version intégralement en Rust et des corrections continueront pendant toute la phase de test. Mais plusieurs éléments méritent d’être soulignés, dont le caractère même du billet : intéressant dans le retour d’expérience qu’il rapporte, mais qui reste une communication d’entreprise puisque Jarred Sumner travaille pour Anthropic et a pu bénéficier de Fable 5 quand presque plus personne n’y avait droit en mai.

On pourrait souligner également que des régressions peuvent apparaître avant et après la version finale. 19 ont ainsi été détectées et corrigées, mais la suite de tests, malgré le grand nombre d’exercices (plus de 60 000) a été écrite avant la réécriture de Bun, son périmètre n’est donc pas optimal. En outre, Jarred Sumner ne dit rien des bugs qui ont pu échapper aux instances adversariales bâties sur Claude et qui ont pu être détectés avec d’autres méthodes. Faisons remarquer aussi que les 165 000 dollars présentés comme facture de la migration peuvent être trompeurs : ils n’incluent pas le lourd temps humain de supervision pendant les 11 jours, ni l’infrastructure de calcul, ni le travail de fusion et post-fusion du code.

Ce cas ne peut pas être généralisé. Même si la réécriture de Bun doit s’avérer une franche réussite, elle le devra en bonne partie à la suite de tests indépendants du langage d’implémentation, qui a permis la validation des opérations menées par les agents, en comparant les situations avant et après.

Le résultat ne sera pas non plus un code Rust « idiomatique ». Il sera loin d’être parfait et de répondre aux standards de sécurité auxquels un code dans ce langage peut prétendre, mais le billet est transparent sur la question. Sumner indique que l’objectif était bien la parité comportementale. Le code safe et profitant vraiment de tous les avantages de Rust viendra plus tard, lors de « refactorings ultérieurs ». Il ne donne pas plus de précisions.

Enfin, il ne s’agit clairement pas d’un scénario « lancer et oublier ». Le cas présenté est celui d’un ingénieur senior utilisant des agents comme amplificateurs, pas en remplacement de son expertise. Lancer Fable 5 et lui demander simplement de réécrire du code en Rust n’a aucune chance de donner un résultat approchant.

Le projet Bun disposait d’ailleurs de conditions favorables à la base, comme sa structure pensée pour la portabilité, l’absence de dépendance à des paradigmes très spécifiques au C/C++, ou même le fait que Jarred Sumner est l’auteur principal, travaillant seul sur une bonne partie des tâches.

Un projet C/C++ ancien, avec de multiples contributeurs, des conventions peu claires, des dépendances à des extensions spécifiques de compilateur, ou surtout une suite de tests incomplète ou couplée au langage source, rencontrerait des difficultés bien plus importantes avec cette même méthode. Et les coûts s’envoleraient d’autant.

Dans une note technique publiée le 7 juillet, Apple commence à informer d’un changement important à venir dans la mouture 28 de macOS, qui sortira l’année prochaine : la fin de la prise en charge des volumes en HFS+ chiffrés. Ces derniers ne pourront plus être montés dans le système : ils n’apparaitront tout simplement plus.

On y apprend que dès macOS 26 – la version actuelle – des avertissements vont être affichés pour les personnes concernées. Le système de fichiers HFS+ (aussi appelé HFS Extended ou Mac OS Étendu) a longtemps été utilisé sur les Mac. Il a depuis plusieurs années été remplacé par défaut par APFS, pensé pour la mémoire flash et disposant de fonctions plus modernes : schéma de partition GPT (GUID Partition Table), instruction TRIM, inodes 64 bits, instantanés (snapshots), ou encore chiffrement intégral ou par fichier.

• Systèmes de fichiers : de HFS et ses évolutions à APFS chez Apple

Les volumes HFS+ chiffrés sont donc anciens. Il peut s’agir de Mac dont la transition vers APFS n’a pas été faite, ou plus probablement de périphériques de stockage sur lesquels cette opération n’a pas eu lieu.

Apple précise que la notification émise par macOS pointera directement le volume concerné. On peut quand même vérifier manuellement quel système de fichiers est utilisé sur ses volumes via les manipulations suivantes :

• ouvrir l’Utilitaire de disque, dans Applications > Utilitaires ;
• dans le menu Affichage de la barre de menu, choisir « Afficher uniquement les volumes » ;
• dans la barre latérale de l’Utilitaire de disque, sélectionner le nom du volume ;
• chercher les informations affichées directement en-dessous du nom de volume à droite : si « Mac OS Extended » et « Encrypted » apparaissent tous deux, le volume sera concerné par la fin de prise en charge.

Pour s’éviter une rupture dans l’utilisation, il n’y a que deux solutions possibles : déchiffrer le disque ou reformater. Le déchiffrement est l’opération la plus rapide et Apple en donne la marche à suivre dans sa note. Car si le HFS+ chiffré n’est plus supporté, le HFS+ classique le sera encore. L’autre solution est de reformater le volume en APFS ou en HFS+, mais l’opération nécessite des déplacements de données. Pour les supports utilisés régulièrement, Apple recommande le reformatage en APFS.

S’agissant d’anciennes technologies, il est probable que peu de personnes soient concernées. L’avertissement devrait remplir son office, car il reste plus d’un an avant l’abandon de la version chiffrée du HFS+.

Déluge en perspective

En mai 2026, Microsoft avait indiqué brièvement que ses équipes d’ingénieurs utilisaient de plus en plus les LLM pour chercher les failles de sécurité. Cette fois, l’entreprise détaille sa façon de faire, en insistant sur l’importance que représentent désormais les grands modèles dans la sécurité de ses produits, Windows en tête.

Le « Patch Tuesday » est le nom que l’on donne au deuxième mardi de chaque mois, date retenue par Microsoft pour effectuer un lâcher de correctifs. Or, celui de juin a marqué une rupture : avec quasiment 200 failles colmatées au compteur, il établissait un nouveau record. Dans un billet en mai, la firme avait indiqué que ses ingénieurs utilisaient les LLM et le faisaient de plus en plus. On pouvait donc supposer que même si le Patch Tuesday de juin était un record, le rythme n’allait pas ralentir.

L’éditeur a justement publié un long billet de blog pour expliquer comment l’IA générative faisait désormais partie intégrante de ses processus.

De l’IA à presque tous les étages

Microsoft explique avoir fait évoluer ses systèmes d’ingénierie et de validation pour réduire le délai entre la découverte d’une vulnérabilité et la protection des clients, en priorisant les zones à plus fort risque. Concrètement, l’IA est intégrée plus tôt dans le cycle de développement, l’évaluation passant toujours par l’expertise humaine, de même que l’arbitrage sur les risques et la garantie que les correctifs respectent le niveau de qualité attendu, affirme l’entreprise.

Faut-il donc s’attendre à une déferlante chaque mois ? Il n’y a bien sûr aucune raison que l’IA utilisée pour débusquer autant de problèmes en mai et juin soit délaissée par la suite. Microsoft prévient ainsi que les clients verront un volume plus élevé de mises à jour de sécurité dans chaque publication. L’éditeur précise rapidement que ce changement est la preuve que les équipes de défense s’améliorent dans l’identification et le traitement des problèmes, pas un signe de dégradation de la sécurité de Windows.

Le macOS dans le macOS dans le macOS

Le prochain macOS, alias Golden Gate, fournira plusieurs améliorations à sa virtualisation. Parmi elles, le très demandé accès aux périphériques USB ou encore les images disque en calques.

macOS expose aujourd’hui deux couches de virtualisation. La couche basse, Hypervisor.framework, donne un accès quasi brut aux extensions de virtualisation matérielle du processeur (VT-x sur Intel, EL2 sur Apple Silicon) sans imposer de modèle de périphériques. Tout éditeur tiers peut choisir de construire une solution de virtualisation basée sur cet hyperviseur.

La couche haute, Virtualization.framework, fournit au contraire un ensemble complet et prêt à l’emploi de périphériques virtuels (disque, réseau, GPU paravirtualisé, etc.), pensé pour des applications qui veulent créer rapidement des VM macOS ou Linux sans réinventer tout le modèle matériel.

C’est sur cette seconde couche que les améliorations ont été annoncées durant une session technique de la dernière WWDC, même si ces informations étaient restées discrètes jusqu’ici. Les annonces autour de l’intelligence artificielle ont largement éclipsé le reste.

• Apple veut de nouveau sauver le soldat Siri, cette fois avec l’aide de Google

Enfin un accès aux périphériques USB

C’est la fonctionnalité la plus demandée par les utilisateurs de machines virtuelles. La prise en charge du stockage externe et d’autres périphériques USB connectés au Mac hôte fonctionne de façon simple : lorsqu’un périphérique compatible est branché pendant qu’une VM tourne, une icône apparaît dans la barre des menus pour autoriser l’affectation à la machine virtuelle. Si cette approbation est donnée, le périphérique devient accessible dans la VM presque immédiatement. Un fonctionnement que l’on retrouve dans de nombreux clients de virtualisation, comme Fusion et Workstation chez VMware ou VirtualBox chez Oracle, et que l’on nomme communément le « passthrough USB ».

Côté API, Apple expose cette fonctionnalité via le framework Accessory Access. Ce dernier permet de faire transiter directement des accessoires USB vers les machines virtuelles et donne à l’utilisateur un contrôle explicite sur les périphériques physiques transmis, comme des disques externes. L’entitlement associé est com.apple.developer.accessory-access.usb. Un entitlement est une paire clé-valeur signée numériquement qui accorde à une application une autorisation spécifique au-delà de ce que permet par défaut la sandbox de macOS ou iOS, comme l’explique Apple dans sa documentation.

Ce fonctionnement répond à un principe de moindre privilège très classique : par défaut, une application sandboxée (confinée) n’a accès qu’à son propre conteneur et ne peut pas, par exemple, lire des fichiers arbitraires sur le disque, ouvrir une connexion réseau brute ou accéder à des périphériques matériels.

Des images disque en calques

Voilà un autre changement important dans macOS 27. Jusqu’à présent, chaque VM reposait sur une image disque unique et autonome, au format brut (raw) ou ASIF (Apple Sparse Image Format, inauguré avec macOS 26). L’introduction de DiskImageKit change la donne car il permet de construire une pile d’images où les écritures vont dans une couche de superposition (overlay) sans modifier la couche de base. Il prend également en charge les images disque brutes.

Comme l’indique Apple, l’architecture distingue plusieurs types de couches : la couche de base peut être dans n’importe quel format pris en charge par DiskImageKit, tandis que les couches supérieures sont toujours au format ASIF et peuvent être soit des couches de cache, soit des couches de superposition. Une couche de cache fait ce qu’est toujours censé faire un cache : améliorer les performances. Dans le cas présent, elles peuvent être mises en place lorsque les couches sous-jacentes résident sur un support lent comme un système de fichiers réseau distant, en stockant une copie des données lues depuis les couches inférieures.

Concrètement, la couche de base contient un socle en lecture seule – comme le volume Système de macOS – qui peut être partagé entre plusieurs VM et stocké sur un support plus lent comme un disque dur. Au-dessus se greffe une couche de superposition en lecture-écriture qui stocke les fichiers additionnels et les modifications apportées aux données de la couche de base. On est clairement dans le fonctionnement général des instantanés (snapshots).

Ainsi, au lieu d’avoir plusieurs gros fichiers de 60 Go, on peut n’avoir qu’une seule base de 50 Go et autant de couches de superposition que nécessaire pour gérer les modifications, comme le pointe notamment MacGeneration. Un fonctionnement plus souple qui peut entrainer des gains conséquents sur le stockage. À noter que sur le site Eclectic Light, certains commentaires soulignent des carences dans l’implémentation actuelle. Par exemple, l’absence de mécanisme pour aplatir (« flatten ») les couches de superposition et les fusionner dans l’image de base.

Du provisionnage automatique pour les invités

Depuis que macOS fournit des capacités de virtualisation, la création du compte administrateur exige de passer manuellement par l’assistant de configuration à chaque nouvelle VM. Mais la nouvelle API VZMacGuestProvisioningOptions permet de définir des identifiants et d’activer des fonctions comme la connexion automatique et SSH dès le premier démarrage.

Le mécanisme technique consiste à construire un objet VZMacGuestProvisioningOptions, à l’attacher à un objet VZMacOSVirtualMachineStartOptions via sa propriété de « guest provisioning » (provisionnage d’invité), puis à démarrer la VM avec ces options. Au premier démarrage, ces paramètres sont automatiquement transmis à l’assistant de configuration, qui crée l’utilisateur avec les identifiants indiqués et active la connexion automatique et l’accès distant si demandé. D’après la documentation d’Apple, cela inclut le nom complet, le nom court, le mot de passe, l’activation ou non de la connexion automatique au démarrage, et l’activation de SSH. Cela ne fonctionne toutefois qu’au premier démarrage de la machine virtuelle.

Autres capacités

Plusieurs autres apports sont mentionnés dans la vidéo dédiée. Par exemple, il est possible désormais de configurer des topologies réseau complexes en intégrant le framework vmnet à Virtualization, pour définir précisément comment plusieurs machines virtuelles interagissent entre elles et avec l’hôte, avec également de la redirection de port.

On note aussi le framework Virtualization, qui permet d’implémenter ses propres périphériques Virtio (protocole standard de l’industrie pour la paravirtualisation), autorisant une communication personnalisée entre l’application hôte et les VM Linux. L’ajout devrait se montrer particulièrement utile pour les scénarios sensibles aux performances, nécessitant une communication à faible latence et fort débit, via la nouvelle classe VZCustomVirtioDevice. Ce point est abordé dans la dernière partie de la vidéo d’Apple.

Ces nouveautés requièrent la préversion de macOS 27 pour les tester. Le système n’est pour l’instant disponible qu’en bêta pour les développeurs (la troisième est sortie ce 6 juillet), mais la bêta publique est prévue pour ce mois-ci, probablement aux alentours du 20 juillet, en même temps que la bêta 4 pour les développeurs.

Ah oui quand même

La nouvelle mouture de TypeScript est annoncée avec des performances largement revues à la hausse. L’essentiel des nouveautés se concentre sur ces gains, le langage n’apportant rien de vraiment neuf sur les types et la syntaxe.

Ce n’est pas tous les jours que l’on peut annoncer des hausses majeures de performances sur des technologies. Microsoft vient pourtant de lancer la version 7.0 de son langage open source TypeScript, un surensemble de JavaScript sous licence Apache 2.0. Depuis sa sortie, le langage a rencontré un grand succès.

Hop, une division par 10

La plus grosse nouveauté de TypeScript 7.0 est son compilateur. Ce dernier était lui-même compilé en TypeScript/JavaScript jusqu’ici, mais c’est fini : le nouveau est écrit en Go. Le code produit est strictement le même, mais avec une différence de taille : le temps de compilation est en moyenne divisé par 10. En fonction des cas, ce facteur alterne entre 8 et 12, le gain de temps étant dans tous les cas énorme.

Ce gain de performances rejaillit sous de nombreux aspects. La compilation complète bien sûr, en passant de plusieurs dizaines de secondes à quelques secondes, mais aussi une réaction beaucoup plus rapide de tsc –watch, l’accélération de l’analyse des types ou encore une consommation de mémoire vive revue à la baisse, le plus souvent entre 5 et 25 % selon les cas.

Microsoft insiste également sur la solidité de cette version, car elle a bénéficié d’une année de tests. Ces derniers ont aussi bien lieu avec d’autres équipes de Microsoft (Loop, Office, PowerBI, Teams ou encore Xbox) qu’avec des entreprises tierces : Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero et autres. Les retours auraient été unanimes : des gains de temps conséquents et des économies de ressources.

La nouvelle version a en outre des conséquences positives sur Visual Studio Code. Dans un test, Microsoft a pu mesurer que le temps passé à ouvrir un fichier avec une erreur dans Visual Studio Code était réduit à 1,3 seconde, contre 17,5 auparavant, soit une division par 13. L’autocomplétion est aussi plus rapide, la fonction « Go to Definition » est presque instantanée, le renommage va plus vite, les diagnostics apparaissent plus rapidement, etc. Microsoft ajoute que plus les monorepos sont volumineux, plus la différence se sent. Une bonne part de ces améliorations vient d’une parallélisation beaucoup plus importante des instructions.

Une transition « transparente »

On aurait pu s’attendre à de nouvelles fonctions, des types et autres syntaxes, mais cette version 7.0 ne change pratiquement rien de ce côté. La plus grosse partie du travail s’étant concentrée sur les performances, TypeScript 7 reste donc compatible avec la version 6. La migration se veut la plus transparente possible, la nouvelle version n’étant livrée avec aucune API. Celle-ci arrivera avec TypeScript 7.1 mais, en attendant, Microsoft a fait le choix « de garantir que TypeScript puisse être exécuté parallèlement à TypeScript 6.0 pour les utilitaires nécessitant encore un certain accès programmatique au compilateur (comme typescript-eslint) ».

L’éditeur ajoute que dans le cadre de cette transition, un paquet de compatibilité a été publié. Il fournit un exécutable nommé pour que les développeurs puissent installer TypeScript 7.0 (qui publie son propre binaire) côte à côte, sans conflit de nommage. « Le nouveau package réexporte également l’API TypeScript 6.0, afin que vous puissiez l’utiliser pour TypeScript 7, tandis que d’autres outils peuvent continuer à s’appuyer sur la version 6.0 », précise Microsoft.

Maître en sa demeure

L’équipe de développement de Tuxedo OS a annoncé qu’elle abandonnait Ubuntu pour Debian comme base pour sa propre distribution. Parmi les raisons citées, des difficultés à adapter le code vieillissant (LTS), une feuille de route IA jugée « opaque » et surtout l’omniprésence des paquets Snap. Ce n’est pas la première fois que le système de Canonical crispe la scène de l’open source.

Tuxedo est une société allemande commercialisant des ordinateurs. À l’instar de System76 avec Pop!_OS aux États-Unis, l’entreprise a fini par créer sa propre distribution, baptisée Tuxedo OS. Elle est basée sur la branche LTS (Long Term Support) d’Ubuntu, à laquelle elle apporte des personnalisations, notamment pour s’assurer que le matériel de ses ordinateurs est correctement pris en charge. Comme pour System76 toutefois, la distribution est librement téléchargeable depuis le site officiel.

Et voilà que dans un communiqué daté du 7 juillet, l’entreprise annonce qu’elle n’utilisera plus Ubuntu LTS. Plutôt que de passer sur la branche classique de la distribution de Canonical, Tuxedo prend un virage plus radical : elle se basera désormais sur Debian Testing, avec une bêta prévue pour « bientôt ». Les raisons données et le choix dans la bascule ont provoqué de nouveaux débats.

Les raisons de Tuxedo

Dans son billet officiel, l’éditeur évoque son modèle hybride : base Ubuntu LTS stable et composants comme le noyau, les navigateurs, la pile graphique et KDE Plasma mis à jour en continu. Or, cette approche devient intenable à mesure qu’une version LTS vieillit : le rétroportage de logiciels modernes devient de plus en plus difficile, les dépendances plus récentes étant souvent indisponibles ou fournies uniquement dans des versions obsolètes. Tuxedo OS suit un modèle de publication hybride qui combine, selon l’entreprise, les points forts des versions continues et des versions ponctuelles.

La société allemande cite cependant trois autres facteurs, propres à la stratégie de Canonical. D’une part, la difficulté croissante à tenir le système de paquets Snap à l’écart du système, Canonical distribuant de plus en plus d’applications au format Snap exclusivement, tout en reléguant progressivement les paquets DEB traditionnels au second plan.

D’autre part, la feuille de route IA annoncée par Mark Shuttleworth lors du dernier Ubuntu Summit, dont la mise en œuvre concrète reste insuffisamment transparente. Enfin, des mises à jour de sécurité qui, selon Tuxedo, mettent parfois plus de temps que nécessaire à atteindre les utilisateurs.

L’entreprise a donc fait le choix de Debian dans sa branche Testing en continu. Ce qui veut dire qu’à la sortie de la version stable de Debian 14, Tuxedo OS restera sur la branche testing, Debian ayant une approche conservatrice des paquets. Outre la modernisation inhérente aux paquets plus récents, cette bascule permet à Tuxedo OS de récupérer des fonctions qui lui faisaient défaut selon elle, notamment le système de fichiers Btrfs – qui sera utilisé par défaut – et Snapper. L’un et l’autre permettront la création automatique d’instantanés (snapshots) et la restauration simplifiée du système. Ces fonctions ne seront disponibles qu’avec Btrfs.

Tuxedo indique dans son billet que le passage de la version actuelle à la prochaine basée sur Debian ne sera pas possible « pour des raisons techniques ». Elle précise cependant qu’un guide complet de migration sera fourni « bien avant la publication finale » du nouveau système, pour expliquer notamment comment transférer les données personnelles. En revanche, un chemin de migration existera vers Kubuntu 26.04. Lui aussi sera publié plus tard.

Les paquets Snap encore dans la ligne de mire

Hors de la stratégie propre à Canonical sur les versions LTS, les critiques de Tuxedo tournent essentiellement sur les paquets Snap et la feuille de route sur l’IA. Même si Mark Shuttleworth, CEO de Canonical, n’a pas été « assez clair » sur cette feuille lors de la conférence Ubuntu Summit, plusieurs points ont été éclaircis depuis. On sait par exemple que Canonical utilisera des modèles locaux pour renforcer certaines capacités « implicites », comme l’amélioration de l’image de la webcam ou la normalisation du son pour le microphone. L’accessibilité sera également aux premières loges, avec notamment une reconnaissance vocale pour tous les champs de saisie présents à l’écran.

👀👀👀

Valve a lancé la nouvelle version majeure de Proton le 7 juillet. Cette mouture 11 suit comme d’habitude les évolutions de la couche de compatibilité Wine 11, sortie récemment et sur laquelle repose Proton. Au-delà des améliorations pour les jeux, Proton fait également un grand pas vers l’architecture ARM.

Proton 11 commence par mettre à jour bon nombre de composants internes, en plus de Wine 11, avec des numéros de version qui paraissent vite exotiques aux profanes : vkd3d 1.19-139-g30b93dcea8b0, DXVK 2.7.1-467-g83e503b4ae6d, dxvk-nvapi 0.9.1, Wine Mono 11.0.0, ou encore vkd3d-proton 20260410. Wine 11 constitue cependant le plus gros apport, car Proton hérite des centaines de correctifs liés, d’une meilleure compatibilité générale avec Win32, d’une meilleure prise en charge des API modernes ou encore d’une réduction du nombre de patchs spécifiques que Valve devait maintenir.

Tous ces apports permettent aux jeux vidéo de mieux fonctionner sur Linux. Ils se traduisent ainsi par moins de bugs DirectX 12, de meilleurs shaders, des améliorations nettes pour la compilation pipeline, moins de saccades dans les jeux, une meilleure stabilité pour le GPU ainsi qu’une prise en charge des derniers pilotes Vulkan. On trouve de nombreuses corrections pour les vidéos, les lanceurs de jeux, les overlays (affichage superposé d’éléments graphiques), les contrôleurs, ou encore les casques VR.

En conséquence, les jeux sont mieux pris en charge. Par exemple, She Sees Red, Chambers, Pentiment, Grounded, Phasmophobia, Sea of Solitude, Idle Trillionaire, Crimson Desert, Rei and the Floating City, Brighter Shores, Space Engineers, Elder Scrolls IV: Oblivion Game of the Year Edition et Call of Duty 2. D’autres font leur entrée dans la liste de compatibilité : Don’t Die Dateless, Dummy!, METAL GEAR SURVIVE, Warhammer: Vermintide 2, Metal Fatigue, SHOGUN: Total War, Unknown Faces, Gothic 1 Classic, X-Plane 12, Breath of Fire IV et Deadly Premonition.

On note enfin la prise en charge de FEX-2605 pour l’architecture ARM64. Fex est un traducteur binaire pour le code x86-64 vers ARM64, signifiant qu’un jeu compilé pour Windows sur une base x86 peut s’exécuter en théorie sur une machine ARM.

L’importance de la couche Proton aujourd’hui

Avec Proton, Valve s’est taillé une place de choix dans l’univers des joueurs. En plus de Steam, qui est de loin la plus grosse boutique de jeux vidéo, la société a rencontré un joli succès avec sa console portable Steam Deck, équipée de SteamOS dans lequel Proton tient une place centrale. La certification Steam Deck est devenue un facteur de différenciation pour les titres, qui peuvent ainsi montrer qu’ils sont optimisés pour la console. Valve aurait pu réitérer ce succès avec la Steam Machine, mais la crise autour de la mémoire vive et des SSD a largement plombé son tarif de lancement.

• 90 % des jeux Windows compatibles Linux ? Oui, mais…

L’efficacité de Proton a entraîné sa popularité, au point qu’aujourd’hui la grande majorité des jeux peuvent fonctionner sur Linux. Proton est d’autant plus important que la plupart des jeux distribués par Steam sont conçus avant tout pour Windows. Avec cette couche de compatibilité, c’est la crédibilité de Linux lui-même qui s’en trouve renforcée, avec notamment des distributions spécialisées dans le jeu vidéo comme Bazzite, CachyOS ou encore la française GLF OS.

• Quasar, une mise à jour majeure pour GLF OS, Linux spécialisé dans le jeu vidéo

En outre, l’arrivée de Proton 11 avec une meilleure prise en charge d’ARM laisse entrevoir des ambitions plus larges que le seul Steam Deck. Si Valve poursuit cette direction, Proton pourrait devenir un composant essentiel pour exécuter des jeux Windows sur une diversité croissante de matériels Linux, qu’ils soient x86-64 ou ARM. Les améliorations de Wine, de DXVK, de VKD3D-Proton et de FEX convergent vers un objectif commun : rendre l’origine Windows d’un jeu de moins en moins perceptible pour l’utilisateur final. Le prochain Steam Deck pourrait-il être basé sur une puce ARM ?

L'espion qui m'a traqué

Le FBI a pu arrêter un pirate en se servant d’une information délivrée par Microsoft : le GDID. Il s’agit d’un identifiant généré par Windows, spécifique à la machine et ne pouvant pas être changé simplement. En revanche, cet identifiant n’est pas pensé initialement pour la surveillance. Explications.

Le département américain de la Justice (DoJ) a annoncé le 1ᵉʳ juillet qu’un membre du groupe de pirates Scattered Spider (aussi appelé Octo Tempest, UNC3944 ou Oktapus) avait été arrêté en Finlande et extradé aux États-Unis. Peter Stokes, 19 ans, citoyen américain et estonien, est poursuivi pour complot, intrusion informatique et fraude. Son arrestation remonte à avril dans le cadre d’une enquête impliquant notamment Interpol. Il a comparu mardi pour la première fois devant un tribunal fédéral à Chicago.

« La plainte pénale accuse Peter Stokes d’appartenance à Scattered Spider, un groupe de piratage impliqué dans plus de 100 intrusions sur le réseau, entraînant plus de 100 millions de dollars en rançons et des millions supplémentaires en dommages et intérêts aux victimes », indique le ministère :

« Les charges dévoilées aujourd’hui sont le fruit de plusieurs années de travail de la division pénale, du bureau du procureur des États-Unis pour le district nord de l’Illinois et du FBI. Nous continuerons à nous associer pour garantir que les cybercriminels ne puissent pas échapper à la justice des États-Unis. »

Le groupe Scattered Spider est connu, entre autres, pour avoir compromis le système informatique d’un détaillant de bijoux de luxe, exfiltré des données et fait une demande de rançon de 8 millions de dollars en cryptomonnaie en 2025.

« Le personnel de sécurité du détaillant a réussi à expulser les acteurs malveillants du réseau informatique de l’entreprise sans qu’aucune rançon n’ait été versée. Le détaillant a néanmoins subi une perte d’au moins 2 millions de dollars en raison de perturbations commerciales, d’enquêtes et de mesures d’atténuations de la menace », précise le DoJ.

Comment Peter Stokes a-t-il été retrouvé ?

La plainte, l’arrestation et l’extradition du pirate reposaient en partie sur la filature d’un identifiant présent dans Windows, signale notamment The Register. Dans la plainte (.pdf), on trouve page 34 la définition de cet identifiant GDID, pour Global Device Identifier :

« Selon un représentant de Microsoft, un Global Device Identifier dans l’écosystème Windows est un identifiant persistant au niveau de l’appareil, conçu pour identifier de manière unique une installation du système d’exploitation Windows sur un appareil, qu’il s’agisse d’un appareil physique (par exemple, un téléphone portable ou un ordinateur portable) ou d’une machine virtuelle, dans certains services et scénarios Microsoft. Un GDID est un identifiant unique mondial lié à l’installation de Windows sur un appareil. »

Les membres de Scattered Spider utilisent pourtant un outil de tunneling appelé ngrok, normalement conçu pour router et protéger le trafic vers des applications API et modèles d’IA. Les pirates s’en servent pour contourner les barrières réseau et maintenir un accès dans les serveurs compromis. Ils utilisent également un service VPN nommé Tzulo.

Les enquêteurs ont donc commencé par obtenir des enregistrements d’adresses IP auprès de ngrok et Tzulo, qui sont des entreprises et doivent donc se plier aux mandats. Ils se sont ensuite tournés vers Microsoft pour savoir si ces adresses IP pouvaient être associées avec des identifiants pour des appareils qui auraient été utilisés aux moments où les comptes auraient été configurés sur ces machines. C’est ce qu’a permis le GDID.

« Selon les archives Microsoft, vers le 12 mai 2025, à 19h21 UTC – lorsque, selon les archives ngrok, le compte ngrok a été créé – l’appareil avec le GDID a accédé, entre autres pages ngrok, à ‘https://dashboard.ngrok.com/signup’, la page ngrok pour créer un compte ngrok », indique le document. Ces mêmes archives ont montré que l’appareil utilisé avait aussi servi à contacter les serveurs de Tzulo. Le GDID a permis de relier cette masse d’informations à une adresse IP située en Estonie.

Windows nous surveille-t-il avec une donnée permanente ?

Oui et non. Comme toujours, la vérité est plus complexe. Pour comprendre, il faut entrer dans les éléments techniques.

Le Global Device Identifier n’est pas un identifiant matériel calculé à partir de numéros de série (contrairement à une rumeur qui a circulé). C’est un identifiant logiciel généré côté serveur par les services de comptes Microsoft : le service wlidsvc (Microsoft Account) provisionne l’appareil auprès de login.live.com et reçoit en retour un PUID d’appareil.

Cet identifiant est stocké dans le registre Windows, puis repris par le Connected Devices Platform (services CDPSvc/CDPUserSvc), qui l’enregistre dans le Device Directory Service, le graphe d’identité de Microsoft qui sert de fondation à des fonctions comme Phone Link, le presse-papier cloud ou « Continuer sur PC » sur plusieurs appareils liés.

Il est ensuite exposé sous le nom GlobalDeviceId (donc GDID) dans la table UCDOStatus de Delivery Optimization, documentée publiquement dans Azure Monitor. Le format est une chaîne « g:<chaine décimale> », ce qui correspond à celui cité dans la plainte : g:6755467234350028.

Sa persistance est quasi-totale : il ne change pas, quelles que soient les manipulations et opérations faites sur Windows, y compris les mises à jour, mineures comme majeures. En revanche, puisqu’il est attribué à la première connexion à un service de Microsoft, la réinstallation du système entraine la génération d’un nouveau GDID.

C’est, de manière générale, l’identifiant qui permet à plusieurs machines reliées par le même compte de donner une unicité à chacune d’elles. Il sert également pour des opérations comme la télémétrie pour les diagnostics, les rapports de bugs/plantages, la fréquence d’utilisation de certaines fonctions ou encore la vérification de la licence. Autant de services qui contactent les serveurs de Microsoft.

Mais contrairement à ce que l’on peut lire parfois, le GDID ne permet pas de « voir » directement une adresse IP malgré l’utilisation d’un VPN ou d’un réseau d’anonymisation comme Tor. C’est plus subtil : dans l’enquête, le GDID a servi de clé de corrélation stable entre des sessions dont l’IP change à chaque rotation de VPN. En revanche, tout n’est pas clair car les informations manquent : comment Microsoft a-t-il su que ce GDID avait visité une URL ngrok précise ? Au moins une technique complémentaire a probablement été utilisée.

Précision importante, le GDID n’est pas une information accessible publiquement. Elle ne peut notamment pas être repérée par les sites web lors des visites et servir par exemple à la construction d’une empreinte (fingerprint). Son obtention ne peut se faire qu’en le réclamant à Microsoft, avec un mandat.

Qu’en retenir ?

Le constat souvent fait dans la presse et chez les développeurs qui se sont penchés sur la question est que le GDID, même s’il est parfois mentionné dans la documentation de Microsoft, n’a pas de page dédiée. Les informations manquent à son sujet, expliquant une partie du « fantasme ». S’il s’agit bien d’une information pouvant être utilisée pour espionner, l’identifiant n’a pas été créé avec cet objectif.

Au-delà de cette information, on peut s’interroger sur le niveau pratique de certains pirates, qui n’appliquent pas le cloisonnement des identités. Un professionnel de l’anonymat « sérieux » n’utilise pas un Windows grand public avec ses comptes personnels pour des activités sensibles : il utilise des systèmes dédiés à usage unique (comme Tails ou Qubes OS) sans compte Microsoft associé ni mélange entre sessions identifiées et anonymes sur la même machine.

Sur son site, l’ingénieur Pasquale Pillitteri ajoute : « Quiconque croit que changer d’adresse IP équivaut à devenir invisible ignore le nombre d’identifiants stables que produit tout appareil moderne, du système d’exploitation au navigateur en passant par les comptes ».

Le GDID n’est pas un mouchard actif exploitable à distance par n’importe qui, mais c’est bien un identifiant réel, persistant, qui a démontré sa capacité à recouper des sessions VPN distinctes. Le « risque » est réel mais conditionnel : il suppose une machine Windows non cloisonnée, des services de télémétrie actifs et une coopération légale de Microsoft, pas une surveillance passive universelle.

C'est dingo

Windows propose depuis longtemps différents mécanismes pour réinitialiser la machine, mais l’utilisateur peut vouloir passer par une réinstallation complète du système. Microsoft prépare une nouvelle manière de procéder, via le cloud et sans nécessiter de périphérique USB.

Dans une note parue le 6 juillet, Microsoft indique que la dernière préversion de Windows 11 – estampillée 26300.8772 et distribuée dans le canal Expérimental – contient une nouvelle fonction baptisée « Cloud rebuild ».

Telle que décrite par l’éditeur, la fonction permet de restaurer un PC sous Windows 11 vers son dernier bon état connu en effectuant une réinstallation complète du système d’exploitation, y compris quand Windows n’arrive plus à démarrer.

Une méthode complémentaire

La réinstallation de Windows passe nécessairement par une clé USB aujourd’hui. Microsoft propose depuis Windows 10 un utilitaire très pratique, dont l’interface simple permet de préparer une clé USB, à condition qu’elle fasse au moins 8 Go. L’utilitaire la formate, télécharge l’ISO et l’installe ensuite sur la clé, rendue bootable (démarrable) pour l’occasion. Des outils comme Rufus et Ventoy permettent cependant d’aller plus loin, notamment en automatisant tout ou partie du processus, en faisant sauter certains prérequis (à ses risques et périls) et autres fonctions avancées.

Cloud rebuild permet donc de se débarrasser de cette contrainte physique dans son principe. Microsoft explique que l’opération se fait depuis l’environnement WinRE (Windows Recovery Environment), la fameuse « interface bleue » dans laquelle le système démarre de lui-même quand un évènement l’empêche d’accéder à la session, ou à partir de Paramètres > Système > Récupération, le bouton « Démarrage avancé ». WinRE donne accès ensuite à divers outils, dont une console pour la ligne de commande et l’éditeur de registre.

Comme le montre la capture fournie par Microsoft. On peut voir qu’une nouvelle section apparait dans la section Dépannage. La procédure, une fois lancée, récupère la dernière révision stable du système ainsi que tous les pilotes nécessaires, « sans support USB, sans image personnalisée, et sans dépendre de l’état de santé du système d’exploitation actuellement installé », précise l’éditeur. En revanche, et comme on s’en doute, une connexion internet est obligatoire, filaire ou Wi-Fi.

Quelle différence avec l’existant ?

On pourrait faire remarquer que la fonction de réinitialisation télécharge déjà Windows. Effectivement, mais elle ne s’en sert que pour remplacer les fichiers systèmes qui auraient pu être altérés. En outre, cette méthode nécessite un système en état de marche et ne s’occupe pas des pilotes. La nouvelle fonction s’occupe de tout le processus, quand tout le reste a échoué.

Autre différence majeure : Cloud rebuild aboutit à un Windows vierge, comme lors d’une installation via une clé USB sur un disque vierge. Les documents et les applications ne sont pas préservés localement. La réinitialisation, elle, permet de choisir ce que l’on garde. On parle donc bien d’une solution de dernier recours ou quand l’envie de repartir d’un système vierge se manifeste.

Notez également que ce type de fonctionnement n’a rien de nouveau dans le monde informatique. Apple propose cette manipulation depuis longtemps sur les Mac. La fonction est d’ailleurs assez connue pour être lente sur la partie téléchargement, mais elle a le mérite d’exister et d’être parfaitement fonctionnelle, en passant là aussi par une petite partition dédiée à la restauration.

Si vous testez actuellement Windows par son canal Expérimental, il vous faut la dernière préversion du 6 juillet (26300.8772) pour obtenir Cloud rebuild. Une condition nécessaire, mais pas toujours suffisante : comme de nombreuses capacités en test, Microsoft ne la diffuse pas à tous les ordinateurs. Elle n’est pas apparue sur notre machine de test, par exemple. On devrait cependant retrouver la fonction au plus tard dans la mise à jour majeure 26H2 prévue pour cet automne.

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

Ce que la communauté réclame...

Mozilla a indiqué récemment que ses plans sur l’offre Thunderbird Pro avaient changé. Les retours de la communauté sont clairs sur de nombreux points, tout comme la principale demande : la priorité devrait être donnée au webmail. Dont acte.

Dans un billet daté du 23 juin, Mozilla a fait le bilan des retours suite à la première vague d’invitations pour participer au test de Thundermail, le service de messagerie propre à la fondation.

Simplification générale

Mozilla indique que ces retours ont été très clairs sur plusieurs points, provoquant d’ailleurs des changements dans la communication récente : Mozilla parle plus régulièrement de Thundermail que de Thunderbird Pro. Pour rappel, Thunderbird Pro a été présenté comme un bouquet de services payant, comprenant divers services comme Thundermail, Appointment et Send, ces deux derniers s’occupant respectivement des rendez-vous et des envois de fichiers.

Mozilla explique que deux points ont été particulièrement remontés. D’une part, Thundermail semble intéresser beaucoup plus la communauté que les autres services. D’autre part, l’arrivée d’une version Pro créait une confusion autour du Thunderbird classique : allait-il devenir un produit payant ou limité ?

La fondation a donc choisi de simplifier le tout. Désormais, l’appellation Thunderbird Pro disparait et est remplacée par Thundermail, l’offre comprenant tous les services payants. En conséquence, Thunderbird reste à sa place et seul à porter ce nom, pour désigner les versions desktop et mobile de l’application, avec les mêmes attributs et toujours la gratuité.

• Avec Thunderbird Pro, Mozilla veut partir à l’assaut de Gmail et Microsoft 365

Ce que souhaite la communauté

Selon Mozilla, les retours de la communauté ont été riches, clairs et intéressants, nourrissant de nombreuses discussions en interne.

Les personnes ayant participé aux tests auraient apprécié l’ouverture de Thundermail et sa capacité à fonctionner dans toutes les applications de messagerie. De même, les testeurs ont loué la personnalisation des adresses par des domaines tiers, ainsi que la possibilité de créer des alias avec ces domaines, selon Mozilla.

Certaines demandes ont cependant été régulières. La principale semble être l’authentification à deux facteurs, que Mozilla est donc en train d’implémenter, avec une disponibilité fixée à « bientôt ».

Beaucoup demandent également la prise en charge des normes DNSEC et DANE. Le premier est un ensemble d’extensions du DNS pour garantir l’authenticité et l’intégrité des données liées. Le second se base sur DNSEC (DANE signifie « DNS – based Authentication of Named Entities »). Ce protocole ajoute une couche de sécurité au DNS pour la gestion des certificats attendus dans les communications entre client et serveur. Le support des deux normes a donc été intégré dans la feuille de route.

Donnez-nous un webmail !

Une partie de la communauté a en outre demandé des aménagements sur la tarification. Selon MacG, qui a participé au test, l’inscription proposait le tarif de 6 euros par mois pour 30 Go de stockage, une boîte de réception, 15 adresses, 3 noms de domaines personnalisés, ainsi que 60 Go pour les partages dans Send. Dans les retours, Mozilla indique que la communauté souhaite divers niveaux de tarification, voire une tarification à la carte en fonction des capacités souhaitées.

Toutefois, la plus grande demande est, de loin, l’ajout d’un webmail. Mozilla explique que le service est aujourd’hui son plus gros travail en cours et qu’une version alpha sortira avant fin juillet. La fondation prévient que, comme toute première préversion, elle aura des défauts. Avec l’authentification à deux facteurs et l’amélioration générale du code, ce sont donc les priorités de Mozilla désormais.

Première pierre

Le système libre ReactOS se lance à l’assaut de la compatibilité avec les noyaux Windows de la série NT6. Les développeurs ont annoncé avoir franchi une étape symbolique avec le support du premier appel système. La route sera cependant longue.

ReactOS est un système d’exploitation libre (dépôt GitHub) qui cherche à être compatible au niveau binaire avec Windows. Son objectif est de pouvoir exécuter les programmes et pilotes Windows sans utiliser le code source de Microsoft. Les développeurs réécrivent donc tout le système « depuis zéro » par rétro-ingénierie.

L’équipe a annoncé le 3 juillet avoir implémenté son premier appel système spécifique à NT6. Il s’agit davantage d’une étape symbolique que pratique. Pour comprendre, il faut rappeler quelques points.

NT6 ? Appel système ?

NT6 est le nom donné au noyau de Windows pour la série Vista, 7, 8 et 8.1. Pour Windows 10 et 11, Microsoft utilise la nomination NT10, mais elle n’est plus directement indiquée par le système. Un appel système est le mécanisme qui permet à un programme de demander un service au noyau. Parmi les services courants, on retrouve la création d’un fichier, l’allocation de la mémoire, la création d’un processus, l’interrogation du processeur pour savoir sur quel cœur logique le programme est exécuté, etc.

C’est d’ailleurs ce que fait l’appel système implémenté, comme le signale Phoronix. Nommé NtGetCurrentProcessorNumberEx, il est utilisé pour retourner le numéro de cœur du processeur logique sur lequel le programme appelant fonctionne.

Une étape symbolique

Pourquoi une étape symbolique alors ? Parce que l’appel existe bien, les programmes qui vérifient sa présence peuvent le trouver, mais toute l’infrastructure NT6 dont il dépend n’est pas encore présente. C’est la première pierre d’un édifice.

Le travail à accomplir est colossal, car Windows contient des milliers d’appels système et de comportements internes, dont beaucoup ne sont pas documentés. L’équipe de développement n’a pas accès au code source de Windows, nécessitant des tâtonnements et déductions, sans parler de l’absence générale d’informations sur la mécanique interne du noyau de Windows.

Il s’agit néanmoins d’une étape marquante, montrant que les développeurs s’attaquent désormais au tronçon suivant. À terme, la compatibilité de ReactOS s’étendra donc au-delà du tronçon « 2000/XP/2003 ». On ignore cependant combien de temps sera nécessaire, même si un travail de cette ampleur ne peut se chiffrer qu’en années.

Attendue au tournant

La prochaine grosse évolution de Windows 11 apparaitra cet automne. Comme la 25H2, la 26H2 sera diffusée sous forme d’un « package d’activation », mais la plupart des nouveautés auront été distribuées avant, selon les configurations.

Microsoft a fait un certain nombre de promesses depuis le début de l’année 2026 : une meilleure réactivité, un recul de l’IA et des composants basés sur des technologies web, une prochaine vague d’applications natives, le retour de fonctions supprimées et de paramètres historiquement présents… N’en jetez plus.

On attend donc la mise à jour 26H2 pour cet automne. Pas de 26H1 ? Eh bien… oui et non. Elle existe, mais elle est réservée aux toutes dernières machines Copilot+ lancées avec les puces Snapdragon X2 Series de Qualcomm. Il ne s’agissait pas d’offrir de nouvelles fonctions, mais d’apporter la prise en charge de nouveautés matérielles. Microsoft précisait toutefois que cette version comportait un noyau différent, sans préciser en quoi.

• Windows 11 : la drôle de mise à jour annuelle 25H2 est disponible

La version 26H2 sera différente, car elle concernera tous les appareils. Elle aura le même fonctionnement que l’actuelle 25H2, comme confirmé par Microsoft le 19 juin : un package d’activation (enablement package, eKB), qui se contentera surtout d’activer chez tout le monde des fonctions qui, en réalité, auront été diffusées dans les mois précédents ou au dernier moment. Depuis la 25H2, Microsoft semble préférer ce mode de distribution, qui évite de proposer une énorme mise à jour, au temps d’installation très long et souvent accompagnée d’une longue liste de problèmes. Le package d’installation s’installe le plus souvent en quelques minutes, le tout se comportant comme une mise à jour mensuelle ordinaire.

Le principe technique sous-jacent est que plusieurs versions de Windows 11 partagent une branche de service commune, la différence entre versions étant simplement liée aux fonctionnalités activées. Autrement dit, la quasi-totalité des nouveautés développées pendant le cycle de vie de la 25H2 sont déjà présentes en sommeil sur les machines existantes et la 26H2 se contentera de les « débloquer » officiellement.

Menu Démarrer et barre des tâches : l’épiphanie

Les critiques contre l’éditeur ont été nombreuses lors du passage de Windows 10 à 11. Elles ont largement touché la barre des tâches et le menu Démarrer, bien que certaines versions aient réintroduit depuis un peu de souplesse.

La 26H2 apportera plusieurs éléments réclamés à cor et à cri par la communauté. D’abord, la possibilité de basculer la barre des tâches sur n’importe quel côté de l’écran. Quel que soit le côté choisi, on pourra paramétrer les icônes pour qu’elles soient centrées ou alignées vers le début (comme actuellement centrées ou alignées à gauche). Tous les panneaux, menus et autres tiendront évidemment compte de cette position. En outre, l’option pour réduire l’épaisseur de la barre fera son grand retour. Microsoft indiquait en mai s’être rendu compte que la hauteur ajoutée à la barre d’origine pouvait « nuire à votre espace de travail utilisable » sur les petits écrans. Une révélation.

Le menu Démarrer sera nettement plus paramétrable. On pourra par exemple masquer complètement les sections Épinglé, Recommandations et Tout. Les recommandations de fichiers et ceux récemment utilisés seront décorrélés : on pourra désactiver les recommandations tout en laissant ceux récemment utilisés, ou masquer les deux. Il sera également possible de réduire la taille du menu Démarrer, avec l’apparition d’un réglage Petit/Grand. Enfin, on pourra masquer le nom et la photo de profil dans le menu, par exemple en cas de partage d’écran fréquent.

Comme Microsoft l’a précisé, tous ces réglages peuvent fonctionner de concert. Vous souhaitez uniquement une grille d’applications épinglées ? Désactivez tout le reste et le menu n’affichera que celles spécifiquement ajoutées dans la grille.

Une recherche L-O-C-A-L-E

C’est probablement l’un des changements les plus réclamés aussi : la possibilité d’obliger Windows à ne chercher des résultats que dans les contenus locaux. Ce changement a en fait été introduit dans la branche Expérimentale de Windows 11 dans une préversion sortie fin mai. Il y a en fait deux bonnes nouvelles.

D’une part, on peut désactiver dans les paramètres la recherche sur le web et dans le Windows Store, qui restent toutes deux actives par défaut. Mais au moins le choix est donné pour les personnes qui ne veulent que des fichiers ou applications présents localement. D’autre part, la recherche prend en charge les sous-chaînes de caractères, pour permettre de retrouver plus facilement un document ou autre à partir d’une portion du nom.

Microsoft introduit quand même un élément baptisé Ask Copilot. Il s’agit d’une zone de recherche optionnelle dans la barre des tâches qui remplace la recherche classique par une interface pilotée par Copilot. Microsoft précise qu’Ask Copilot utilise les API Windows existantes pour renvoyer des applications, fichiers et paramètres, exactement comme la recherche Windows, sans donner à Copilot un accès supplémentaire au contenu personnel. La fonction reste optionnelle : si elle est désactivée, l’utilisateur peut revenir à la recherche Windows classique. Elle est déjà en diffusion pour les comptes professionnels/entreprise, mais pas pour le grand public. La version 26H2 devrait la mettre à disposition, même si elle sera a priori désactivée par défaut.

Contrôle de Windows Update et protection administrateur

Le contrôle de Windows Update est un bon exemple de fonction prévue pour la 26H2, mais en fait déjà disponible sur une bonne partie du parc. Comme nous l’avons indiqué dans un article dédié, on peut maintenant choisir une date pour repousser les mises à jour de Windows Update. Cette date peut être jusqu’à 35 jours dans le futur, mais on peut la reculer indéfiniment. En cas de modification, le système prévient qu’il vaut mieux ne pas repousser trop longtemps la date, car les correctifs de sécurité mensuels sont importants.

Windows 11 26H2 introduira également une fonction de sécurité promise depuis longtemps : la Protection de l’administrateur. Elle permet d’activer l’accès juste-à-temps pour les actions nécessitant des privilèges administrateur. Cette fonction applique le principe du moindre privilège : l’utilisateur reçoit un jeton standard au démarrage, et lorsque des droits d’administration sont nécessaires, Windows crée un compte administrateur isolé et généré par le système, dont le jeton est détruit une fois la tâche terminée.

Cette arrivée est d’autant plus importante que ce système doit remplacer à terme l’UAC (User Account Control). Apparu avec Vista, ce dernier est toujours utilisé aujourd’hui et se présente sous forme d’une fenêtre accordant l’accès à des droits supplémentaires lorsqu’une tâche s’apprête à appliquer un changement nécessitant un accès administrateur.

Le virage Windows K2

Ces annonces s’inscrivent dans un recentrage assumé par Microsoft. Le président de la division Windows, Pavan Davuluri, a publiquement reconnu que Windows 11 s’était « égaré » avec une intégration excessive de l’IA, conduisant au retrait des boutons Copilot du Bloc-notes, de Photos et de l’Outil Capture dans le cadre d’une initiative interne baptisée « Windows K2 ».

Cela explique en partie pourquoi les nouveautés les plus mises en avant côté 26H2 concernent davantage le contrôle utilisateur (personnalisation, mises à jour, réactivité, sécurité…) que l’ajout de nouvelles fonctions IA, Ask Copilot restant explicitement optionnel et non activé par défaut.

Pour les personnes en mal d’aventures, la plupart de ces ajouts peuvent être testés dans la branche Expérimentale de Windows 11, via le programme Windows Insiders. Rappelons que le programme a été amplement modifié et qu’il ne reste que deux branches : Beta et Expérimentale, la seconde étant bien sûr moins testée et pouvant présenter plus de bugs.

Attention donc en cas d’installation, car le numéro de version fait un bond, ce qui peut toujours être vecteur d’incompatibilités et autres comportements étranges. En outre, l’installation est particulièrement longue sur une machine disposant de la dernière révision stable du système, même quand elle dispose d’un matériel correct – dans notre cas, un ordinateur portable équipé d’un Ryzen 7, de 16 Go de RAM et d’un SSD. Rien ne garantit non plus que toutes les fonctions seront là, car l’entreprise est facétieuse : elle active les nouveautés sur des groupes de machines, mais pas chez tout le monde.

Enfin, on ne sait pas si tous les éléments « promis » par Microsoft seront présents dans cette mise à jour 26H2, notamment tout ce qui touche à l’interface. Certains éléments ont évolué, comme le panneau Exécuter modernisé (Win + R), mais on reste dans l’attente d’une vraie homogénéité de l’interface, certaines fenêtres remontant à Windows 2000. On attend également de voir ce que donneront les performances du système à la sortie de la mise à jour, notamment grâce au mode « latence basse ».

Au cours de l’année écoulée, quelques utilisateurs ont remarqué que Windows 11 pouvait se mettre à consommer plusieurs centaines de gigaoctets, a priori sans raison valable, comme relevé par Windows Latest.

En creusant un peu, le problème se concentre sur un seul fichier : CapabilityAccessManager.db-wal. Ce comportement n’a guère de sens, car ce fichier sert uniquement à stocker des informations liées aux autorisations données aux applications pour accéder à des fonctions du système comme la géolocalisation, la capture d’écran, le microphone, la caméra et ainsi de suite. Il n’est pas censé dépasser quelques mégaoctets.

Quand ce fichier se met à atteindre des dizaines, voire des centaines de gigaoctets, c’est qu’un sérieux bug est à l’œuvre. Selon les témoignages, l’espace consommé peut atteindre jusqu’à 500 Go, posant alors un vrai problème.

Le bug est assez simple à repérer. On commence par se rendre dans les Paramètres, puis dans Système > Stockage. Là, on clique sur « Afficher plus de catégories » (texte en bleu) et on repère la ligne « Système et espace réservé », qui devrait être en première ou deuxième position, selon le nombre d’applications installées.

Cet espace réservé comprend les fichiers système à proprement parler (en général une vingtaine de Go), la mémoire virtuelle ou encore le fichier nécessaire à la mise en veille prolongée. La taille varie donc en fonction de votre quantité de mémoire vive et de vos paramètres. Si vous avez cependant quelques centaines de gigaoctets, il y a peut-être un problème.

Avec un outil comme WizTree, TreeSize ou WinDirStat, on peut facilement repérer le souci, notamment la taille précise du fichier incriminé quand son comportement déraille. On peut aussi exécuter une commande dans l’Invite de Windows avec des droits administrateurs pour obtenir ces informations :

robocopy "C:\ProgramData\Microsoft\Windows\CapabilityAccessManager" "%TEMP%\CAMCheck" /L /B /R:0 /W:0 /BYTES /NP

Microsoft est au courant de ce problème. Dans les notes de la mise à jour optionnelle KB5095093, on peut lire dans la partie « Change log » qu’un ajout a été fait le 29 juin pour régler le souci sur le fichier. Cette mise à jour optionnelle sera intégrée dans le prochain correctif mensuel (Patch Tuesday), prévu pour le 14 juillet.

Creepy Paste

Opera a introduit une nouvelle fonction de protection dans son navigateur le 2 juillet. Baptisée Paste Protect, elle veut sécuriser la navigation face aux copies masquées d’instructions dans le presse-papier de l’appareil en vue d’exécuter un script malveillant.

La fonctionnalité Paste Protect, tout juste introduite par Opera, est un mécanisme de sécurité conçu pour bloquer à la source les attaques dites « ClickFix ». Cette menace repose sur l’ingénierie sociale et le détournement du presse-papiers du système d’exploitation pour forcer l’exécution de code malveillant.

D’un simple lien au script malveillant ?

Mais qu’est-ce qu’une attaque ClickFix ? Une attaque qui n’exploite pas une faille de sécurité, mais bien la « crédulité » de l’internaute, en faisant appel – comme souvent – à ses émotions.

Elle manipule l’utilisateur pour qu’il devienne lui-même l’exécuteur de la charge utile (payload). Lorsqu’un internaute navigue sur un site web compromis ou frauduleux, une fausse invite s’affiche. Elle simule généralement une page de vérification CAPTCHA familière (vérification Cloudflare, Google reCAPTCHA…), un problème de lecture vidéo, une erreur de certificat système ou tout message pouvant faire « peur » et invitant à une action rapide.

Pour résoudre ce prétendu problème, le site invite l’internaute à cliquer sur un bouton pour copier une « clé de vérification » ou un correctif, puis à ouvrir la boîte de dialogue Exécuter de Windows (Win + R) ou un Terminal (sous macOS/Linux) pour y coller l’élément. En réalité, le clic déclenche une écriture masquée dans le presse-papiers contenant un script malveillant (souvent du PowerShell ou des commandes curl/msiexec fortement obscurcies). Dès que l’utilisateur valide le collage dans sa console, les commandes s’exécutent avec ses propres privilèges système, ce qui permet de contourner les solutions de détection traditionnelles (de type antivirus, solution de réponse aux points de terminaison…) et de déployer des logiciels malveillants de type infostealer (voleur d’informations).

Le détournement du presse-papiers via ClickFix est devenu l’un des vecteurs d’attaque par ingénierie sociale à la croissance la plus rapide dans l’écosystème cyber. D’après un rapport publié par l’éditeur de cybersécurité Huntress, les techniques basées sur le ClickFix représentaient plus de 53 % de l’ensemble de l’activité liée aux chargeurs de malwares (malware loaders) recensée sur l’année 2025. Cette explosion s’explique par l’efficacité de la ruse, l’absence de surveillance du presse-papiers par les outils de sécurité classiques, et le fait que la victime réalise elle-même l’action malveillante.

Ce que propose Opera

L’approche d’Opera consiste à intercepter la menace avant que la charge utile n’atteigne le presse-papiers du système d’exploitation. Paste Protect combine principalement deux briques logicielles : la Hijack Protection (introduite en 2021 pour empêcher le remplacement transparent de données sensibles comme des IBAN ou des adresses de portefeuilles de cryptomonnaies) et la nouvelle Injection Protection.

Cette dernière surveille en temps réel les événements d’écriture du presse-papiers initiés par les sites web ou des processus tiers. Elle utilise des règles heuristiques spécifiques à chaque plateforme (Windows, macOS et Linux) pour identifier les structures syntaxiques typiques des scripts malveillants. Si une anomalie est détectée, la copie est automatiquement bloquée.

Le navigateur affiche alors un avertissement montrant les 120 premiers caractères du script intercepté. Il impose également un délai d’attente de 5 secondes avant de permettre à l’utilisateur d’outrepasser manuellement le blocage s’il s’agit d’un faux positif, par exemple dans un contexte de développement de logiciels. Une attaque que l’on retrouve dans de nombreuses protections sur le web.

On attend les autres

Opera est le premier grand navigateur du marché à intégrer une telle atténuation de manière native au sein de son moteur. Les navigateurs concurrents basés sur Chromium (comme Google Chrome, Microsoft Edge, Brave, Vivaldi) ainsi que Mozilla Firefox et Apple Safari ne disposent pas actuellement d’un équivalent natif pour analyser et bloquer l’injection de scripts en ligne de commande dans le presse-papiers.

En revanche, il existe des solutions tierces, comme celle proposée par Eye Security ou de nombreux autres éditeurs de cybersécurité. Le mécanisme passe le plus souvent par l’installation d’une extension pour le navigateur. Du côté des systèmes d’exploitation, on peut citer le cas d’Apple, qui a récemment intégré un système d’alerte au sein même de l’application Terminal sous macOS afin de détecter les collages risqués. Cette protection n’intervient cependant qu’en fin de chaîne (à l’exécution) et non à la source (à la copie dans le navigateur).

Maintenant qu’Opera a dégainé ce mécanisme, il est probable que les autres navigateurs suivront tôt ou tard.

Toxicité politique

Depuis son retour, Fable 5 est la cible de critiques virulentes sur ses performances. Le modèle ne semble pas présenter les mêmes capacités qu’avant son blocage, suite à la directive de la Maison-Blanche. Même Mythos 5 semble perdre de sa superbe.

Rappelons rapidement quelques éléments chronologiques. Le 9 juin 2026, Anthropic lance Claude Fable 5, une version de Mythos 5 disposant de garde-fous et présenté alors comme le modèle le plus « capables » de l’histoire de l’entreprise. Trois jours plus tard, une directive de contrôle des exportations, signée par la Maison-Blanche et juridiquement contraignante, force Anthropic à suspendre l’accès aux deux modèles pour tout ressortissant étranger, y compris ses propres employés non-américains. Le décret conduit l’entreprise à un arrêt mondial pour tous les clients, Anthropic ayant jugé impossible de filtrer les utilisateurs par nationalité en temps réel.

Le déclencheur invoqué était un rapport de chercheurs d’Amazon selon lequel Fable 5 aurait pu être manipulé (jailbreaké) pour livrer des informations exploitables dans des cyberattaques. En toile de fond, des soupçons qu’un groupe lié à la Chine ait pu accéder à Mythos, ce qui faisait craindre une rétro-ingénierie ou une distillation par un adversaire étranger.

Fin juin, le Department of Commerce lève ces contrôles. L’accès à Fable 5 est restauré le 1ᵉʳ juillet sur Claude Platform, Claude.ai, Claude Code et Claude Cowork. Mythos 5, lui, reste réservé aux partenaires vérifiés du programme Glasswing, comme on l’a vu avec Mozilla.

Au-delà du temps perdu par Anthropic (environ trois semaines), le retour de Fable 5 ne s’est pas fait sous les cotillons. Ses performances, selon les cas d’utilisation, semblent en fort retrait. Pendant ce temps, l’utilisation des modèles chinois grimpe rapidement.

Kaboum !

Dans la plupart des résultats obtenus avant le retrait de Fable 5, de nombreux sites ont relevé les excellentes performances du modèle, notant souvent un saut générationnel significatif. Parmi les notes obtenues : 80,3 % sur SWE-Bench Pro (contre 69,2 % pour Opus 4.8), 64,5 % sur Humanity’s Last Exam avec outils (contre 57,9 % pour Opus 4.8 et 52,2 % pour GPT-5.5), et ainsi de suite pour tous les benchmarks majeurs (FrontierCode Diamond, OSWorld-Verified, GDPval-AA, Terminal-Bench 2.1), comme relevé notamment par Datacamp.

Pour Every, le résultat était encore plus tranché : Fable 5 était tout simplement « le meilleur modèle de programmation ». La société en tenait pour preuve le score de 91/100 obtenu sur leur propre benchmark « Senior Engineer », contre 63 pour Opus 4.8 et 62 pour GPT-5.5. Même son de cloche chez BenchLM.

C’est là que le tableau se complique singulièrement depuis le 1ᵉʳ juillet. Le retour de Fable 5 s’est accompagné d’un nouveau classificateur de cybersécurité, et selon des données publiées le 2 juillet par la plateforme de test BridgeMind, les scores de débogage TypeScript de Fable 5 se sont effondrés de 70 %, comme relevé par Tech Times.

Pourquoi une telle chute ? A priori, pas parce que le modèle en lui-même est devenu moins performant. La faute semble bien incomber au nouveau classificateur, qui redirige une part des requêtes liées à la programmation vers Opus 4.8, sans que les utilisateurs en soient toujours informés.