Déjà là, mais en fait pas trop

Microsoft a fait de nombreuses promesses cette année sur l’amélioration de la qualité générale dans Windows 11. Performances, recherche, code natif ou encore interface sont dans la ligne de mire. En août, le système va ainsi recevoir une longue série de nouveautés, dont certaines auraient dû arriver depuis bien longtemps.

L’initiative « K2 » de Microsoft vise à apporter à Windows 11 une foule d’améliorations tous azimuts. L’éditeur a abordé aussi bien les performances que l’utilisation de code natif (le menu Démarrer est partiellement écrit en React par exemple), la cohérence de l’interface, l’efficacité de la recherche et autres. De manière générale, le mouvement consisterait à donner – enfin – aux utilisateurs ce qu’ils attendent depuis des années. En théorie.

Les mises à jour mensuelles ont commencé à apporter certaines de ces améliorations. Celle du mois prochain s’annonce particulièrement copieuse, quand elle sera proposée en même temps que les correctifs de sécurité le 11 aout. Cette mise à jour est en fait déjà disponible dans la zone des téléchargements facultatifs dans Windows Update, pour les personnes un peu « aventurières » qui voudraient s’essayer aux nouveautés un mois en avance.

Explorateur, recherche et menu Démarrer

La mise à jour, référencée KB5101684, contient un peu de tout. Microsoft tire dans toutes les directions, preuve que l’éditeur semble assez sérieux sur les améliorations promises. Certains apports auraient d’ailleurs dû être dans Windows depuis bien longtemps.

C’est le cas de l’affichage automatique de l’unité de poids la plus adaptée dans la vue Détails de l’Explorateur. Aujourd’hui, et depuis bien longtemps, cette taille est systématiquement en Ko. Avec la mise à jour, l’unité s’adapte automatiquement pour afficher des Mo et Go en fonction du poids.

Dans l’Explorateur, on trouve plusieurs autres apports. D’abord la possibilité d’ouvrir un onglet depuis un clic molette sur un élément de la barre d’adresse ou de l’écran d’accueil. Ensuite, les miniatures dans la zone des contenus recommandés sont plus nettes. Enfin, le bug qui faisait apparaitre parfois un flash gris pendant le chargement ou le défilement a été corrigé.

La recherche est probablement une des fonctions qui reçoit le plus d’améliorations en ce moment. Outre la possibilité en approche de se concentrer uniquement sur les résultats locaux, la mise à jour d’août la rend plus tolérante sur les fautes typographiques (ce qu’elle n’est pas actuellement). Un fonctionnement élémentaire aujourd’hui, mais sur lequel Windows faisait l’impasse jusqu’ici. En outre, les résultats commencent à s’afficher à partir de deux lettres, contre trois jusqu’à présent. Les applications sont également mieux mises en avant dans les résultats.

On trouve aussi des améliorations de fiabilité plus générales. Par exemple, au chargement du systray dans la barre des tâches quand le système est utilisé en mode tablette.

Lecteurs d’empreintes ESS pour tout le monde

Les personnes intéressées par les empreintes digitales comme facteur de sécurité pourront désormais utiliser des lecteurs tiers pour Windows Hello Enhanced Sign-in Security (ESS), à condition qu’ils soient compatibles.

Dans sa version standard, Windows Hello repose sur des pilotes en espace utilisateur et/ou noyau. Si la machine est compromise par un programme malveillant disposant des privilèges administrateur, un attaquant peut théoriquement intercepter la mémoire ou usurper le signal de la caméra. ESS propose de résoudre ce problème en appliquant une architecture Zero Trust au niveau du silicium.

Sans surprise, ESS fonctionne avec des composants matériels dédiés. À la manière par exemple de la Secure Enclave dans un produit Apple, les données biométriques sont stockées dans le capteur et n’en sortent jamais. La vérification est effectuée directement sur la puce du capteur, qui communique ensuite le résultat chiffré au système via un certificat signé. Ce fonctionnement existe également pour les webcams, mais il faut là aussi des modèles spécifiques.

Dans sa documentation, Microsoft indique que tous les PC Copilot+ fonctionnent déjà avec ESS pour les webcams et les lecteurs d’empreintes intégrés. La mise à jour permet donc désormais d’utiliser des lecteurs tiers sur l’ensemble des PC avec le niveau de sécurité le plus élevé.

Windows Update, alimentation, accessibilité et autres

Windows Update récolte plusieurs améliorations sous le capot, après avoir reçu récemment la possibilité de repousser indéfiniment l’installation des correctifs en attente (ce qui n’est jamais recommandé, mais au moins les utilisateurs ont le contrôle). C’est la fiabilité générale du processus qui est cette fois concernée, avec des informations plus précises sur la progression de la mise à jour (téléchargement, installation, pourcentages…). L’opération de nettoyage post-installation est décrite comme plus efficace.

Du neuf également dans la gestion de l’alimentation. À partir de maintenant, tous les changements faits par l’utilisateur sur les temps d’inaction avant extinction de l’écran, mise en veille et hibernation du PC sont répercutés sur tous les modes (Performances, Équilibre…), et plus uniquement celui en cours. De plus, Microsoft réintègre dans le même panneau le réglage pour personnaliser le niveau de batterie à partir duquel l’ordinateur portable passe en mode d’économie d’énergie.

Côté accessibilité, on note des améliorations significatives. Accès vocal – qui permet de piloter la session Windows avec la voix – gagne ainsi un mode Isolation. Il peut être réglé selon trois crans : désactivé, bruits de fond uniquement, isolation complète. La Loupe fait de son côté disparaître les barres tactiles verticale et horizontale dans la zone, afin qu’elles n’interfèrent plus avec le contenu. Il est possible de les remettre en place en passant par les options.

On trouve également d’autres changements plus ou moins importants, dont certains spécifiques aux PC Copilot+. Par exemple, il est maintenant possible sur ces derniers de désinstaller le composant IA relatif à la génération d’images. Au fil des mises à jour, Microsoft augmente donc le nombre de ces composants désinstallables.

Microsoft signale en outre une série d’améliorations liées à la fiabilité. Pour Explorer.exe, l’éditeur signale ainsi du mieux avec l’ouverture des Jump Lists et des fichiers récents, lors du partage de fichiers et de dossiers, ainsi que lors de l’utilisation de la Vue Tâches et de plusieurs bureaux. Du mieux également pour les écrans de connexion et de verrouillage du système, « surtout quand la mémoire système est faible ». On note aussi une meilleure fiabilité du presse-papiers quand il est utilisé dans certains scénarios de bureau à distance et de bureau virtuel Azure.

Oui, mais…

Si cette mise à jour contient de sympathiques bonus et – manifestement – de nombreux bugs corrigés, vous ne pourrez pas forcément profiter de tout et tout de suite.

L’installation elle-même est possible depuis n’importe quelle machine équipée de la version 24H2 ou 25H2 de Windows 11. L’ordinateur peut redémarrer jusqu’à trois fois selon les cas. Ne soyez donc pas surpris et n’interrompez pas le processus.

En revanche, si vous cherchez les nouveautés visibles, vous pourriez faire chou blanc. Microsoft a la désagréable habitude d’activer les nouvelles fonctions progressivement. Dans notre cas, la plupart des améliorations ne sont pas utilisables par exemple (alors que nous nous faisions une joie de profiter des apports sur la recherche). Si vous ne voyez pas les nouveautés « promises », il faudra peut-être attendre plusieurs semaines.

Encore un problème de l’interface chaise-clavier

Des internautes ont signalé qu’il était simple de retrouver des conversations Claude partagées. Pour Anthropic cependant, il n’y a aucun problème : c’est le fonctionnement attendu de cette capacité. Mais ce n’est pas tout à fait aussi simple. Encore plus inquiétant, c’est le quatrième incident du genre en un an.

Durant le week-end du 25 - 26 juillet, des utilisateurs de Reddit ont découvert que l’opérateur de recherche « site:claude.ai/share » faisait remonter dans Google une longue liste de conversations Claude partagées, ainsi que des éléments nommés Artefacts par Anthropic : documents et mini-applications interactifs générés dans l’outil.

Le 27 juillet, 404 Media publie un article évoquant la situation, rapidement suivi par d’autres, comme TechCrunch. Depuis, nombre de sites et personnes ont évoqué la situation, relevant qu’on peut trouver une foule d’informations dans ces éléments partagés.

Ces révélations ont pris un tour plus dangereux quand certaines informations se sont avérées être sensibles. Futurism, cité par plusieurs médias, a identifié un rapport médical détaillé nommant un patient, des résultats d’essai clinique avec des noms de patients, ainsi que des fichiers contenant les noms et numéros de téléphone d’enfants d’école primaire. Le contenu exposé allait de notes de programmation et de fausses critiques de livres à des éléments bien plus sensibles : rapports médicaux de patients, données d’essais cliniques avec noms réels, documents internes d’entreprise, évaluations de salariés, clés API et identifiants de connexion.

Pour Anthropic, c’est tout à fait normal

Pour l’entreprise à l’origine de Claude, c’est le résultat d’un comportement parfaitement attendu : les conversations partagées sont accessibles à toute personne possédant le lien. Or, il suffit que ce lien ait été publié dans un endroit accessible aux moteurs de recherche pour qu’il se retrouve dans les résultats, si la requête est conçue spécifiquement pour le retrouver et que le fichiers robots.txt n’interdit pas explicitement la récupération des informations.

Amie Rotherham, porte-parole d’Anthropic, a ainsi indiqué à TechCrunch :

« Nous donnons aux gens le contrôle pour partager publiquement leurs conversations avec Claude, et conformément à nos principes de confidentialité, nous ne partageons pas les annuaires de discussion ni les sitemaps avec des moteurs de recherche comme Google. Ces liens partageables ne sont ni devinables ni découvrables à moins que les gens choisissent de les partager eux-mêmes. Lorsqu’une personne partage une conversation, elle rend ce contenu accessible au public, et comme tout autre contenu public sur le web, il peut être archivé par des services tiers ».

Du côté de Google, on cherche également à se montrer clair : « Ni Google ni aucun autre moteur de recherche ne contrôle quelles pages sont rendues publiques sur le web, et ces pages ont été indexées sur de nombreux moteurs de recherche. Nous donnons aux propriétaires de sites des contrôles clairs pour décider si les pages peuvent être explorées ou indexées, et nous respectons toujours ces directives ». En d’autres termes, ces liens étaient publics et ont été repris par tous les moteurs, sous-entendu : « pas nous uniquement ».

Mais ce n’est pas si simple

La situation semble à l’heure réglée, les résultats ayant disparu dans l’après-midi du lundi 27 juillet. Si le fonctionnement des conversations partagées était normal, pourquoi cette disparition.

Parce qu’en dépit de ce qu’a déclaré Anthropic, il semble bien qu’il y ait eu un problème, selon Search Engine Journal. Nos confrères ont réalisé un audit des en-têtes HTTP ce même 27 juillet. Le chemin /share/* de claude.ai est bloqué par une directive Disallow dans le robots.txt, sous le groupe générique User-agent: *.

Or, les pages elles-mêmes renvoient un en-tête X-Robots-Tag: none, que les directives de Google traitent comme équivalent à noindex et nofollow. Le chemin de partage est ainsi bloqué par le robots.txt de claude.ai.

Et c’est là que survient le problème, selon Search Engine Journal : « À cause de cela, les règles entrent en conflit. Selon les directives de Google, un tag noindex ne fonctionne que si l’outil d’exploration est autorisé à accéder et à lire la page. Si une page est bloquée par robots.txt, elle peut toujours être indexée si d’autres pages y renvoient, puisque Googlebot note l’URL sans l’ouvrir réellement ».

Le bot de Google voit donc une page disposant d’une directive de non-référencement et en indexe l’URL nue, sans le contenu. Il en va de même pour les URL présentes sur cette page, dont les directives ne peuvent pas être lues à cause du premier blocage. Ce conflit a entrainé le référencement des adresses de partage des conversations Claude, sans leur contenu. Voilà pourquoi on pouvait les retrouver avec un opérateur de recherche.

Anthropic n’a pas communiqué de correctif technique explicite. La disparition des résultats de recherche dès le lundi après-midi a été constatée par 404 Media, TechCrunch mais également par Next, sans confirmation officielle du mécanisme corrigé. Ce nettoyage et les observations réalisées par Search Engine Journal laissent cependant penser que l’entreprise s’est peut-être rendu compte du conflit potentiel entre les directives.

Que faire côté internaute ?

Si vous ne partagez pas vos conversations Claude ou que vous ne le faites qu’au travers d’autres moyens que des pages web (par exemple une messagerie instantanée), il n’y a rien à craindre. Toutes les conversations sont privées (au sens d’Anthropic) par défaut.

Si vous avez des conversations partagées, vous pouvez cependant en révoquer l’accès. Rendez-vous dans les paramètres du compte, puis dans « Confidentialité ». Là, descendez jusqu’à la ligne « Conversations partagées » puis cliquez sur « Gérer ». La liste apparaitra, avec possibilité de voir la conversation et de la supprimer.

Notez bien que l’icône de poubelle, qui désigne la suppression, ne signifie pas que la conversation elle-même sera effacée, uniquement le partage associé. Autre information importante, la gestion des Artefacts est séparée et se fait depuis la ligne juste en-dessous de « Conversations partagées ».

Ce n’est pas une première, loin de là

Ce n’est pas la première fois (et certainement pas la dernière) que ce genre de couac arrive. Il y a un an, OpenAI corrigeait le tir de son IA générative qui laissait vos discussions « publiques » avec ChatGPT être indexées par les moteurs de recherche, dont Google. Quelques semaines après OpenAI, xAI aussi y est allé de sa pierre à l’édifice avec des centaines de milliers de conversations rendues accessibles via les moteurs de recherche.

En septembre, Forbes alertait sur la présence de plusieurs centaines de conversations avec le chatbot Claude d’Anthropic dans Google. Déjà à l’époque, l’entreprise rejetait la faute sur les utilisateurs : « La porte-parole d’Anthropic, Gabby Curtis, a déclaré à Forbes que les conversations avec Claude n’étaient visibles que sur Google et Bing parce que les utilisateurs avaient publié des liens vers ces conversations en ligne ou sur les réseaux sociaux », expliquaient nos confrères.

Quatre incidents du même genre en seulement un an, le problème est récurrent. C’est l’occasion de rappeler une règle élémentaire : ne pas partager publiquement le lien d’un document que vous souhaitez garder pour vous. On pourrait même recommander de ne pas créer de lien de partage tout court afin de limiter les risques. Parfois, certains ne savent même pas que les documents sont accessibles publiquement, comme nous l’avons démontré avec des Google Groupes en accès libre aux quatre vents.

• [Offert] Google Groupes : depuis 20 ans, des données personnelles et bancaires en accès libre

GOG (Good Old Games) dispose depuis une dizaine d’années d’un launcher pour Windows et macOS. Nommé Galaxy, il permet d’installer et gérer les jeux achetés sur la boutique. Et Linux ? GOG (devenue indépendante fin 2025) avait manifesté son intérêt pour la plateforme et avait abordé le sujet début 2026, indiquant chercher à recruter dans ce but. Depuis, plus rien.

Interrogé sur le sujet par GamingOnLinux, Krzysztof Papliński, co-PDG de l’entreprise, a répondu par e-mail. Il confirme qu’un « spécialiste » a bien été embauché pour se pencher sur la question :

« Suite au poste annoncé plus tôt cette année, nous avons désormais le spécialiste à bord et explorons activement la meilleure façon d’aborder le support Linux pour GOG GALAXY. C’est une entreprise importante, donc même si nous ne sommes pas encore prêts à partager des plans, des délais ou des résultats précis, c’est un domaine dans lequel nous investissons du temps et des efforts. »

L’absence actuelle du launcher Galaxy sur Linux n’empêche pas les jeux compatibles avec la plateforme d’être installés. Le launcher simplifie cependant nettement les opérations, en plus de proposer une interface regroupant tous les achats, avec les options associées. Comme le font remarquer nos confrères, il reste possible d’insérer le compte GOG dans des applications comme Heroic Games Launcher, mais un support direct est toujours une bonne nouvelle.

Un seul code vous manque et tout est perdu

Le 26 juillet, l’équipe de GrapheneOS s’est lancée tout à coup dans un exposé de nombreuses mesures de sécurité, avec une insistance particulière pour la gestion des mots de passe. Ce calendrier ne doit rien au hasard : pour la première fois aux États-Unis, le ministère de la Justice poursuit un citoyen américain pour destruction présumée de données à l’aide d’un mot de passe « contraint ».

Depuis deux jours, le compte X de GrapheneOS répond à de nombreuses questions sur la gestion de ses mots de passe. L’équipe en a fait une synthèse dans son forum pour résumer toutes les informations.

L’équipe explique que le système mobile est basé sur Android 17 et « sur le matériel le plus sécurisé disponible pour Android », la liste se limitant aujourd’hui aux seuls Pixel de Google. Elle rappelle cependant que la situation va évoluer en 2027, grâce à un partenariat avec Motorola Mobility et « aux progrès réalisés par Qualcomm ». Un signal assez fort pour l’industrie, qui pourrait se rapprocher de Graphene pour lancer des smartphones très orientés vers la sécurité. On parle bien de nouveaux modèles, car aucun appareil Motorola actuel ne dispose des sécurités nécessaires.

• Motorola s’associe à GrapheneOS pour renforcer la sécurité de ses (futurs) smartphones

Les informations se concentrent tout particulièrement sur la protection des mots de passe et autres secrets, ainsi que sur les défenses du système mobile contre l’extraction de données. Le chiffrement du disque constitue ainsi la première ligne de défense : même les attaquants les plus sophistiqués ne peuvent le casser directement, et doivent soit exploiter l’OS en état « After First Unlock » (après premier déverrouillage), soit forcer le PIN ou mot de passe par force brute.

L’équipe indique également que GrapheneOS supporte uniquement les appareils ayant un secure element avec des limitations strictes sur les tentatives de mots de passe et codes PIN : 4 heures après 10 tentatives échouées, 41 jours après 15, avec seulement 20 tentatives autorisées au total. Le secure element est pour rappel une puce dédiée, physiquement et logiciellement isolée, conçue pour stocker les secrets et résister à leur extraction. Dans le contexte de GrapheneOS, il a en outre un rôle précis : il détient les compteurs de tentatives de déverrouillage et applique la limitation de débit, expliquant les délais de plus en plus longs entre les tentatives. Stocker les compteurs dans la puce empêche de « tricher » en les réinitialisant.

Parmi les autres points abordés, on peut citer la limite de caractères des mots portée de 16 à 128, la possibilité d’utiliser un facteur biométrique pour que le système reste utilisable au quotidien (5 tentatives biométriques seulement, qui comptent dans le quota général), des allocateurs de mémoire durcis, le hardware memory tagging (MTE) pour renforcer la résistance aux exploitations de failles inconnues, le blocage par défaut des nouvelles connexions USB quand l’appareil est verrouillé, ou encore un minuteur de redémarrage automatique, ramenant l’appareil en état « Before First Unlock » (avant premier déverrouillage) au bout de 18 heures (par défaut) sans déverrouillage de l’appareil. Ce dernier comportement a d’ailleurs été repris par Apple et Google dans leurs systèmes.

• Le redémarrage automatique des iPhone inactifs est bien une fonctionnalité d’iOS 18

Dans le billet, on trouve également un paragraphe consacré au PIN de contrainte. Présentée comme un outil relativement mineur et optionnel, il efface l’appareil quand il est saisi dans n’importe quelle invite d’authentification (déverrouillage, changement de réglage sensible, etc.). Il fonctionne sur tous les profils, y compris les utilisateurs secondaires et Private Spaces. L’équipe de GrapheneOS insiste : les données ne dépendent pas de cette fonctionnalité pour être protégées. Elle est considérée comme un outil parmi d’autres, et son usage réel doit être mûrement réfléchi compte tenu des conséquences physiques ou juridiques possibles.

L’affaire Samuel Tunick

La mention des conséquences juridiques n’est pas due au hasard. Si l’équipe de Graphene communique tant autour des protections de son système en ce moment, c’est à cause d’un évènement juridique majeur aux États-Unis lié à la tech.

Pour la première fois (a priori), des procureurs fédéraux poursuivent en effet un citoyen américain pour destruction présumée de données à l’aide d’un mot de passe « contraint » intégré au logiciel d’un téléphone. C’est le lien avec la communication abondante : le logiciel en question n’est autre que GrapheneOS.

Samuel Tunick a été initialement arrêté sans mandat le 25 janvier 2025 à l’aéroport de Hartsfield-Jackson (Atlanta) par les douanes américaines, sur la base de l’exception de fouille frontalière au Quatrième amendement. Alors que les agents fédéraux tentaient d’accéder à son téléphone lors de l’inspection, Tunick aurait saisi un mot de passe de contrainte GrapheneOS qui a immédiatement effacé les données stockées sur l’appareil.

Tunick est donc poursuivi en vertu de la loi américaine pour avoir fourni aux agents frontaliers un code d’accès ayant causé l’effacement du contenu numérique de son téléphone, ce que les procureurs qualifient de destruction intentionnelle de biens pour empêcher leur saisie.

Un enjeu plus grand que le cas individuel

La communication de GrapheneOS est probablement défensive, pour documenter publiquement la robustesse cryptographique de son modèle de menace face à l’attention médiatique soudaine portée à la fonction « mot de passe de contrainte ».

Sur le plan juridique, l’enjeu dépasse le cas individuel : la question posée aux tribunaux est de savoir si l’activation d’une fonctionnalité de sécurité native – conçue précisément pour protéger des données personnelles en cas de contrainte – peut être qualifiée pénalement de destruction de preuves, y compris lorsque la fouille initiale s’est déroulée sans mandat.

Sans surprise, les avocats de Samuel Tunick contestent cette version des faits. Ils affirment que la détention et la saisie étaient illégales, et accusent le gouvernement américain d’exiger l’accès au téléphone sous prétexte d’une recherche d’images pédopornographiques, sans fournir aucun élément pour étayer ces soupçons.

Pour les avocats, cette arrestation et cette affaire sont politiques. Le gouvernement s’en serait pris à Samuel Tunick non pas pour d’éventuels matériels pédopornographiques, mais pour son association avec un mouvement appelé « Defend the Atlanta Forest ». Ce dernier s’oppose à la création d’un énorme campus de formation pour les forces de l’ordre à Atlanta, surnommé « Cop City », critiqué pour son impact environnemental (plus de 34 hectares déforestés) et son coût de 67 millions de dollars.

Les avocats demandent l’annulation de toute la procédure, au motif qu’elle viole les Quatrième, Cinquième et Sixième amendements de la Constitution américaine. Des violations liées à la manière dont l’interrogatoire a été mené, au refus d’un avocat, à l’absence alléguée d’avertissements Miranda (le fameux « Vous avez le droit de garder le silence »), ou encore à la fouille et la saisie sans mandat.

« Je n’ai jamais vu cela auparavant, même si j’ai discuté du scénario potentiel avec des activistes et des journalistes au fil des années. Je pense que cette affaire rappelle que les autorités peuvent prétendre que vous avez sciemment détruit des données, donc il vaut mieux ne pas avoir ces données sur vous lorsque vous franchissez certaines frontières », a réagi Runa Sandvik, une experte en sécurité informatique, auprès de TechCrunch.

La nouvelle interface de Firefox est désormais activée par défaut dans le canal Nightly du navigateur. Rappelons que cette préversion peut être installée aux côtés de la version stable sans mélanger les données, permettant de tester les nouveautés facilement.

Cette nouvelle interface, baptisée Nova, avait été présentée en mai pour la première fois. On pouvait alors l’essayer en activant un flag de test dans le about:config. On reste globalement dans ce qui avait été montré, avec des finitions supplémentaires.

Dans son nouveau billet, Mozilla évoque « un aspect et une sensation plus cohérents sur les onglets, menus, panneaux et autres surfaces du navigateur ». On note bien sûr les formes d’onglets « plus douces », des couleurs « plus chaudes », de nouvelles icônes et autres. Mozilla dit aussi avoir tenu compte des retours et réintégré le mode compact, qui va effectivement vite sembler nécessaire à une partie des utilisateurs.

Par défaut, l’interface prend en effet ses aises et propose une zone « barre de titre + barre d’onglets » plus épaisse que la concurrence. Le mode compact permet de réduire l’ensemble à ce que l’on a l’habitude de voir. Mozilla insiste sur l’aspect non terminé de son projet, expliquant d’ailleurs toujours sa présence dans le canal Nightly, le plus « brut » des canaux de préversion.

L’éditeur demande aux personnes qui testeront la nouvelle interface de porter leur regard sur tout ce qui touche aux icônes, espacements et alignements, aux thèmes et à la personnalisation, aux différentes tailles de fenêtres, à la navigation par le clavier ou encore à tout ce qui touche à l’accessibilité, notamment aux lecteurs d’écrans.

On espère de notre côté que l’aspect personnalisation sera développé. La gestion des thèmes n’est pas si simple actuellement, avec une fâcheuse tendance à rebasculer dans les variantes sombres si l’on ne fait pas attention. Si vous en avez assez de toute cette rondeur (à l’instar de votre serviteur) dans les onglets, boutons et autres, il n’existe pour l’instant aucun moyen intégré de modifier cet aspect. Mozilla devrait s’inspirer de Vivaldi, qui permet de modifier n’importe quel élément de l’interface.

Un parapluie, mais pas de baskets

Microsoft AI a présenté le 27 juillet 2026 son premier modèle dédié à la cybersécurité. Intégré dans son architecture, l’entreprise annonce battre tous les modèles actuels dans ce domaine, y compris Mythos d’Anthropic, mais attention à ce qui est réellement comparé.

Hier soir, Microsoft a annoncé officiellement MAI-Cyber-1-Flash. Il s’agit du tout premier LLM de l’éditeur consacré à la cybersécurité. Et pour un premier modèle, Microsoft a mis les petits plats dans les grands.

MAI-Cyber-1-Flash est un modèle compact, spécialisé dans le code et dérivé de la lignée MAI-Thinking-1, propre à Microsoft. Il est intégré à MDASH, le harnais multi-agents de détection et de remédiation de vulnérabilités déjà présenté par Microsoft en mai dernier. Plus récemment, l’entreprise est revenue sur le rôle prépondérant que joue désormais MDASH dans la sécurité de ses produits, expliquant l’envolée du nombre de failles corrigées dans les derniers bulletins mensuels : près de 200 en juin et plus de 570 en juillet.

Un modèle, un harnais…

Microsoft n’hésite pas à déclarer que son modèle, profondément intégré à MDASH, a été « perfectionné par les meilleurs experts en cybersécurité du secteur et renforcé dans le plus grand domaine de sécurité au monde ». Ce qui lui permet, toujours selon Microsoft, de battre tout le monde dans le domaine de la détection de failles, y compris Mythos, GPT 5.6 Sol, GPT 5.5 Cyber et Gemini 3.5 Flash Cyber. Avec 95,95 % au test CyberGym, Microsoft dépasse d’au moins 10 points la concurrence.

Mais attention, Microsoft ne compare pas directement son modèle MAI-Cyber-1-Flash aux autres : l’entreprise compare MDASH. Autrement dit, tout le harnais avec le nouveau modèle et GPT 5.4, utilisé en renfort.

Comme expliqué par l’éditeur en effet, MAI-Cyber-1-Flash est un modèle compact, conçu pour « gérer efficacement jusqu’à 90 % de toutes les tâches ». Dans cette configuration, MDASH ne basculerait vers les modèles plus gros et plus couteux (ici GPT 5.4) que dans 10 % des cas en moyenne, « pour les tâches exceptionnellement difficiles qui en ont réellement besoin ».

C’est bien cette architecture complète qui atteint près de 96 % sur CyberGym, battant Mythos de 12 points, insiste Microsoft. Rappelons que ces chiffres sont auto-rapportés et effectués dans un environnement contrôlé par Microsoft. Ils n’ont pas été vérifiés par un tiers indépendant.

Pour l’éditeur, c’est aussi une question d’économies substantielles. La meilleure offre MDASH combinait jusqu’à présent GPT 5.4 + 5.4 mini + codex 5.3. La nouvelle version intégrant MAI-Cyber-1-Flash coûterait moitié moins cher à faire tourner.

… et une plateforme

Mi-juillet, nous avions relayé un bruit de couloir : Microsoft préparait un projet nommé Perception pour venir concurrencer Anthropic et son projet Glasswing, seule manière de pouvoir utiliser Mythos.

Perception a bien été confirmé hier soir lui aussi. Il est présenté comme le système agentique qui vient chapeauter MAI-Cyber-1-Flash et MDASH. Le billet de blog dédié le présente comme une refonte de l’architecture de sécurité pour l’ère de l’IA : une nouvelle pile de sécurité doit percevoir en continu le risque sur l’ensemble du parc numérique, raisonner sur de vastes quantités de contexte et agir à vitesse machine, tout en apprenant et en s’adaptant à mesure que les environnements évoluent.

Le système coordonne trois familles d’agents spécialisés qui se transmettent le travail sans rupture de charge :

• Les agents rouges repèrent les chemins de compromission potentiels avant qu’un attaquant ne puisse les exploiter
• Les agents bleus enquêtent, évaluent le contexte et déterminent quels signaux représentent un risque réel
• Les agents verts appliquent les correctifs et durcissent l’environnement (renforcent sa sécurité)

Ces agents ne repartent pas de zéro à chaque tâche. Ils s’appuient sur un contexte de sécurité partagé : une représentation mise à jour en continu des actifs, identités, relations et risques de l’organisation. Tous les agents puisent dans ce contexte, réduisant les coûts en tokens et la latence tout en améliorant la cohérence du raisonnement, selon Microsoft.

Un programme complet, mais très jeune

Un serveur MCP est également fourni pour exécuter les actions en ligne de commande. Les agents verts peuvent aussi ouvrir directement des pull requests sur GitHub et construire des correctifs potentiels pour les vulnérabilités. Perception propose donc un système de sécurité en apprentissage continu combinant capteurs, contexte partagé, modèles multiples, agents spécialisés et mécanismes d’action capables de modifier les protections à travers l’environnement.

Le programme se présente ainsi comme une couche d’orchestration, au-dessus de MAI-Cyber-1-Flash et MDASH, avec un déploiement encore très récent et une autonomie d’action volontairement limitée à ce stade. Microsoft insiste sur le maintien d’un humain dans la boucle décisionnelle, ce qui suggère que l’entreprise elle-même reste prudente sur le niveau de confiance à accorder aux agents verts capables de modifier des systèmes de production.

Perception n’est d’ailleurs pas disponible. Le premier accès se fera sous forme de préversion le 3 août et uniquement pour des clients MDASH triés sur le volet. Même une fois lancé en version finale, il est très probable que Perception ne soit accessible qu’au travers d’un accès vérifié, à la manière de Glasswing chez Anthropic ou de Daybreak chez OpenAI.

Le 21 juillet, OpenAI a publié un communiqué étonnant : un de ses systèmes IA était responsable de l’attaque orchestrée contre Hugging Face. Des détails étaient fournis, mais l’histoire gardait des zones d’ombre. Si l’incident a été transformé en opportunité commerciale, il semble être le résultat d’une vaste carence en sécurité.

Dans notre article du 22 juillet, nous relations les évènements tels qu’ils ont été décrits par OpenAI et Hugging Face. Dans les grandes lignes, la plateforme open source dédiée à l’IA avait révélé le 16 juillet avoir été attaqué par au moins un agent IA autonome. Cinq jours plus tard, OpenAI communiquait pour annoncer être indirectement à l’origine de l’attaque.

Que s’était-il passé ? OpenAI avait expliqué que des tests étaient en cours sur un système d’IA comprenant le récent modèle GPT-5.6 Sol ainsi qu’un autre, décrit comme simplement plus puissant. Dans ces tests, les garde-fous avaient été levés pour mesurer justement les capacités des modèles.

L’un des tests demandait aux modèles de résoudre un certain problème. Ces derniers avaient estimé que la réponse se trouvait probablement chez Hugging Face. Ils s’étaient alors échappés de leur environnement de test (révélant au passage une faille signalée à l’éditeur tiers concerné), avaient récupéré des identifiants de membres du personnel de Hugging Face et fouillé dans l’infrastructure de l’entreprise, compromettant au passage une partie des serveurs.

Une semaine pour s’en apercevoir

L’histoire comportait de nombreuses zones d’ombre. Nous relevions par exemple qu’il s’était écoulé cinq jours entre la présentation de l’attaque par Hugging Face et le communiqué d’OpenAI sur ce qui s’était passé. Cette dernière n’avait-elle donc découvert l’incident qu’avec le billet de Hugging Face ? Selon Reuters, ce serait bien le cas.

Selon nos confrères, la chronologie ne plaide pas en faveur d’OpenAI. L’agent se serait ainsi échappé de son environnement de test le 9 juillet et aurait commencé son intrusion chez Hugging Face le 11. OpenAI n’aurait compris la responsabilité de son système qu’à la publication du billet de Hugging Face le 16 juillet. Des membres du personnel n’auraient commencé à trouver des traces d’activité suspecte dans les journaux internes que durant le week-end du 18 - 19 juillet. Les deux entreprises ne se seraient pas parlées avant le 20 juillet, aboutissant à la communication publique du 21 juillet.

Reuters évoque deux sources proches du dossier, selon lesquelles il se serait donc écoulé une semaine avant qu’OpenAI s’aperçoive de sa responsabilité, entre la sortie de l’agent le 9 juillet et le billet de Hugging Face le 16.

Comment expliquer une telle latence ? Cette lenteur s’expliquerait par le fait qu’OpenAI fait tourner plusieurs tests simultanément, rendant difficile pour les employés la surveillance individuelle de chaque test, tant la masse de données générées est importante. Reuters apporte d’autres informations, notamment la création par un agent d’une note destinée à de futures versions de lui-même et contenant des instructions sur la manière de s’échapper des contraintes imposées par OpenAI. En revanche, l’article ne dit pas si cet agent en particulier est lié à l’attaque.

Autre point important, Hugging Face avait évoqué un contact avec les forces de l’ordre. D’après l’agence de presse, il s’agit bien du FBI qui n’a pas souhaité réagir. Silence également de la part de la plateforme. Chez OpenAI, une porte-parole a déclaré que l’article de Reuters contenait « plusieurs inexactitudes », mais n’a pas répondu aux demandes de détails.

Le 24 juillet, l’Arcep a annoncé l’ouverture d’une consultation publique pour élargir sa collecte de données environnementales, en perspective de l’édition 2028 de son enquête annuelle « Pour un numérique soutenable », à la suite d’une campagne de collecte qui aurait donc lieu en 2027.

Rappelons que depuis 2020, l’Arcep collecte des indicateurs environnementaux auprès des acteurs du numérique, mission formalisée par le gouvernement l’année suivante et consolidée juridiquement par la loi REEN de décembre 2021. L’autorité dispose ainsi d’un pouvoir de collecte auprès des opérateurs télécoms, fournisseurs de services de communication en ligne, opérateurs de centres de données, fabricants de terminaux, équipementiers réseaux et fournisseurs de systèmes d’exploitation.

Les données recueillies sont présentées depuis, chaque année, dans ses rapports sur le numérique soutenable. En mars 2024 par exemple, le rapport incluait pour la première fois des informations sur la consommation des box, décodeurs et répéteurs.

Dès l’automne dernier, l’autorité avait cependant annoncé sa volonté de capter de nouvelles informations pour mesurer l’impact environnemental de l’IA. C’est l’objet de la nouvelle consultation publique, avec deux extensions principales au recueil de données.

Chez les fournisseurs d’IA générative d’abord, l’Arcep propose de collecter des indicateurs permettant d’évaluer les émissions de gaz à effet de serre associées, de documenter les caractéristiques des modèles sous-jacents aux services les plus utilisés en France, et de mesurer les ressources mobilisées en entraînement et en inférence : volume de calcul, temps cumulé d’usage des processeurs et consommation énergétique.

Chez les opérateurs de centres de données et fournisseurs de services cloud, les nouveaux indicateurs serviraient à vérifier comment la chaleur est valorisée, à évaluer l’influence des systèmes de refroidissement sur l’empreinte environnementale des centres de données et à couvrir les obligations du règlement délégué (UE) 2024/1364, en application de la directive européenne sur l’efficacité énergétique (directive UE 2023/1791, dite EED), qui pose l’obligation de reporting pour les centres de données.

La consultation publique est ouverte à toutes les parties prenantes jusqu’au 30 septembre. La décision finale de collecte est attendue d’ici fin 2026, sous réserve d’homologation par la ministre déléguée chargée de l’IA et du numérique.

Pour les personnes intéressées par une couverture supplémentaire des équipements neufs chez Apple, il fallait jusqu’à présent souscrire un contrat AppleCare distinct pour chaque appareil acheté chez Apple. AppleCare One permet d’ajouter jusqu’à trois appareils sous un même abonnement : iPhone, Mac, Apple Watch, iPad, AirPods, Apple TV, HomePod ou Apple Vision Pro. La seule condition est que les appareils soient rattachés au même compte iCloud.

En France, la formule de base sera facturée 20,99 euros par mois pour trois appareils, avec un supplément de 5,99 euros par mois par appareil additionnel, comme indiqué sur la page dédiée du site officiel. À titre de comparaison, la protection du seul iPhone coûte à partir de 9,99 euros par mois ou 99,99 euros par an, bien que le tarif évolue en fonction du modèle.

Au-delà de l’aspect tarifaire, les prestations sont celles de l’assistance AppleCare+. Pour un iPhone, un iPad ou une Apple Watch, cela signifie par exemple jusqu’à trois déclarations de perte ou de vol par an. Un point important, car le vol n’est pas compris dans la garantie AppleCare standard. La formule prend également en charge un nombre illimité de réparations pour dégâts accidentels, ainsi qu’une assistance prioritaire.

Les réparations peuvent être effectuées « souvent » le jour même en Apple Store ou centre de service agréé, et dans n’importe quel pays où sont implantées ces structures (Apple évoque plus de 5 000 centres agréés dans le monde).

Attention cependant sur les réparations, car une franchise s’applique : 29 euros pour les réparations d’écran et les dégâts sur le dos en verre, 99 euros pour tous les autres dégâts accidentels, et 129 euros en cas de perte ou de vol. Durant toute la durée de couverture en revanche, le remplacement de la batterie est gratuit si la capacité passe sous la barre des 80 %.

AppleCare One est donc un AppleCare+ pour plusieurs appareils à un tarif réduit en comparaison du cumul classique. Il y a en outre un sérieux avantage : si AppleCare+ doit être souscrit dans les 60 jours suivant l’achat du produit neuf, AppleCare One peut prendre en charge des appareils ayant jusqu’à 4 ans, à condition qu’ils soient en bon état. Auquel cas, après ajout du numéro de série dans la déclaration en ligne, un examen physique en magasin sera peut-être nécessaire. C’est en tout cas ce qu’indiquait Apple au lancement de cette garantie en juillet 2025 lors du lancement aux États-Unis.

Discussion à poids ouverts

Une discussion a été ouverte au sein du projet sur la manière dont il faut considérer les participations au code quand elles sont soutenues par les LLM. Ce n’est pas la première fois que la communauté essaie de statuer sur l’IA générative.

Debian a ouvert une résolution générale (GR) sur l’usage des LLM au sein du projet. La période de discussion a débuté le 24 juillet 2026, après des semaines de débat sur la liste de diffusion debian-vote.

Ce n’est pas la première tentative sur ce sujet. Une précédente discussion menée par l’ex-DPL (Debian Project Leader) Lucas Nussbaum, en février-mars 2026, s’était soldée par un abandon du vote, la communauté ayant préféré continuer à traiter les contributions IA au cas par cas. Le projet Debian avait décidé de ne pas décider. Cette résolution relance donc le débat avec un texte plus structuré et davantage de propositions.

Quatre propositions, du radical au plus mesuré

La proposition A, portée par Matthias Geiger et Jesse Rhodes, est la plus radicale : l’interdiction de toute contribution directe rédigée avec l’aide de LLM : paquets sources, logiciels officiels (lintian, etc.), ressources web, documentation, traductions, communications officielles. Les projets amont utilisant l’IA, ainsi que les correctifs de sécurité amont, sont exclus du périmètre. Le texte propose même d’ajouter un point 6 au Contrat Social de Debian sur le sujet.

Plusieurs arguments sont donnés. D’abord, le statut juridique flou du copyright des sorties de LLM. Ensuite, des problèmes de qualité (paquets mal formés, fichiers watch non fonctionnels). En outre, un impact sur la dynamique communautaire : charge de relecture, non-apprentissage des nouveaux contributeurs, etc. Enfin, la question éthique, le scraping massif ayant perturbé l’infrastructure web de Debian et la question de l’empreinte environnementale étant prégnante.

La proposition B, portée par l’ancien DPL, Lucas Nussbaum, est plus mesurée. Elle autorise les contributions assistées par IA sous six conditions cumulatives :

• compatibilité légale de l’outil utilisé
• vérification des droits sur le contenu préexistant réutilisé
• responsabilité totale du contributeur
• divulgation de l’usage via un tag Git type Generated-By: ou Assisted-By:
• discussion préalable pour les modifications massives ou automatisées
• interdiction de transmettre des données sensibles (rapports de sécurité sous embargo, discussions privées) à des fournisseurs IA non fiables

La proposition C, portée par Ian Jackson, est un rejet de principe mais « pragmatique ». Elle demande à tous les contributeurs d’éviter les LLM et appelle plus largement la communauté du logiciel libre à rejeter cette technologie, tout en reconnaissant qu’une interdiction totale est impraticable puisque de nombreux projets amont y recourent. Il propose cependant des règles strictes : les messages destinés aux humains (rapports de bugs, listes de diffusion, Salsa, blogs Planet Debian) doivent être rédigés uniquement par des humains, tout usage de LLM doit être divulgué, les mainteneurs individuels peuvent totalement bannir l’IA sur leurs projets. Et la plus stricte d’entre elles : les violations sont traitées comme des manquements au Code de Conduite.

Quant à la proposition D, portée par Pierre-Elliott Bécue, elle ressemble beaucoup à la B dans l’esprit : une acceptation encadrée, portée sur les responsabilités. En clair, Debian n’endosse pas l’usage de l’IA générative mais reconnaît sa réalité et refuse une interdiction jugée « contre-productive et inapplicable ». Cette proposition place la responsabilité sur le contributeur (conformité DFSG, signature GPG personnelle, marquage de l’usage IA dans les commits et notes de version), avec une clause spécifique interdisant l’usage d’IA cloud pour des données sensibles ou non publiques.

Une décision importante

Plusieurs éléments intéressants entourant cette nouvelle résolution générale. D’abord, la proximité avec l’ancienne : à peine quelques mois, signalant le besoin pour les développeurs de trancher un sujet devenu central. L’IA générative est partout et les LLM sont utilisés dans une part croissante des projets. Précisons quand même que la précédente discussion en février-mars n’a pas atteint le statut officiel de GR. Il s’est écoulé environ un mois entre le brouillon alors préparé par Lucas Nussbaum et l’abandon du processus.

On ne sait pas combien de temps durera la résolution générale, mais la discussion et le vote seront importants. Debian n’est pas n’importe quelle distribution : en plus de son utilisation proprement dite, elle sert de socle à de nombreux autres systèmes, dont le plus connu est Ubuntu, la distribution Linux la plus utilisée aujourd’hui. Ce qui n’empêche pas d’autres organisations, comme Canonical, de procéder à des modifications assistées par IA.

Cette résolution cristallise de nombreux aspects entourant les LLM. Le fait que les questions éthiques et environnementales fassent partie de la réflexion est significatif, mais le sujet est complexe : comment trancher entre une interrogation croissante sur les gains potentiels et les conséquences négatives d’une utilisation intensive ? Si les membres du projet Debian regardent en direction de Linus Torvalds, une proposition B ou D pourrait l’emporter : une vision pragmatique et responsabilisée des contributions.

L’information peut étonner : Chromium n’est-il pas déjà présent sur les systèmes Linux et l’architecture Arm64 ? Si, mais Chrome ne l’était pas. En mars, Google avait promis que son navigateur serait porté vers cette architecture durant le deuxième trimestre. La société est en retard, mais le navigateur est effectivement disponible, même s’il faut « ruser » pour l’obtenir.

Des builds Arm64 ont été ajoutées récemment aux dépôts officiels, comme le relève OMGUbuntu. Depuis un appareil Arm64, la page de téléchargement renvoie vers un installeur AMD64, mais il suffit de modifier le lien en remplaçant amd64 par arm64 pour récupérer la version stable pour l’architecture souhaitée. On peut également récupérer le paquet DEB correspondant via Apt sur Ubuntu, la commande ajoutant au passage le dépôt Google pour assurer les mises à jour. Nos confrères n’ont pas testé d’autres systèmes ni la version RPM.

Quel intérêt alors d’installer Chrome si Chromium et d’autres – comme Vivaldi – existent déjà ? Parce qu’on peut vouloir Chrome pour la synchronisation du compte Google (extensions, marque-pages, mots de passe…).

Autre raison : le support DRM Widevine intégré nativement. Jusqu’à présent, faire fonctionner Widevine sur Arm Linux hors ChromeOS nécessitait d’extraire le binaire aarch64 d’une image ChromeOS via des scripts tiers. Une gageure. Le module Widevine reste de type « Software Secure », ce qui plafonne Netflix et les autres services à 720p/1080p au lieu de la 4K ou du HDR, faute de chaine TEE (Trusted Execution Environment) valide. « C’est agaçant, mais c’est la même situation sur Intel/AMD », indique OMGUbuntu.

Sur un Raspberry Pi 5 sous Ubuntu 26.04, le décodage vidéo matériel était inactif pendant les tests, ce qui limite les performances sur les flux haute définition, toujours selon nos confrères. BBC iPlayer en réglage maximal tournait sans accroc, contrairement au Firefox Snap Arm64 d’Ubuntu qui saccade davantage. YouTube en 4K montrait des saccades et frames perdues, probablement à cause du matériel plutôt que de Chrome, tandis que le 2K était parfaitement fluide.

La mode c'est les passkeys, on est envahi de passkeys

Cette fois, c’est décidé : les SMS et la voix ne seront bientôt plus autorisés dans Entra comme facteur d’authentification. Microsoft évoque l’IA comme accélérateur de cette décision, l’entreprise renvoyant évidemment vers les clés d’accès (passkeys).

Microsoft a annoncé le retrait des SMS et de la voix comme méthodes de MFA (multi-factor authentification) dans l’annuaire d’identité Entra, avec bascule vers les clés d’accès par défaut et une échéance ferme au 1ᵉʳ février 2027.

L’entreprise justifie ce changement par l’explosion de l’IA générative, qui a modifié l’économie du phishing et de l’ingénierie sociale, en automatisant le vol d’identifiants et les opérations d’échanges de SIM (SIM swap) à grande échelle et en deux fois moins de temps.

Un programme au pas de course

Ce changement important ne sera pas d’une traite. Microsoft fournit un calendrier, où les étapes vont cependant s’enchainer rapidement :

• 1ᵉʳ septembre 2026 : invite automatique à enregistrer une clé d’accès lors du prochain défi MFA
• 18 septembre 2026 : publication de la liste des fournisseurs télécom compatibles pour les organisations qui doivent conserver les SMS et/ou la voix pour des raisons réglementaires
• 30 octobre 2026 : obligation de configurer un fournisseur télécom supporté via le Microsoft Security Store pour les organisations restant sur MFA téléphonique
• 1ᵉʳ février 2027 : retrait définitif des SMS/voix fournis par Microsoft, sans dérogation possible

Plusieurs points importants à préciser tout de même. Pour éviter que le processus automatique ne perturbe trop les organisations à compter du 1ᵉʳ septembre, une API sera fournie le 1ᵉʳ aout. Elle permettra aux équipes d’administrations de se retirer (opt-out) du mécanisme pour gérer elles-mêmes la transition.

Du balais

La mini-saga de l’été autour des écrans LG vient de finir sa première saison. Le constructeur a supprimé sa publicité pour McAfee, mais le problème sous-jacent reste entier et LG se défend d’avoir mal agi.

LG est sous un feu nourri de critiques pour le comportement observé par de nombreuses personnes autour d’une partie de ses écrans, même dans le haut de gamme et jusqu’à des écrans proposés depuis plusieurs années. Depuis environ trois semaines, des propriétaires de moniteurs LG (essentiellement la gamme UltraGear) constatent qu’après un simple branchement de l’écran, le pilote est récupéré automatiquement par Windows, en même temps qu’une application dont le seul objectif semble être de la publicité pour McAfee.

• Comment un simple branchement d’écran illustre un vieux problème de Windows

Comme nous l’avions expliqué, LG exploite un mécanisme présent dans Windows depuis longtemps. Cependant, la documentation de Microsoft recommandait de faire attention avec les comportements déclenchés de cette manière s’ils ne répondaient pas à un besoin concret de l’utilisateur. Une application peut être utile pour fournir des fonctions liées, mais elle peut vite provoquer de la frustration quand elle est utilisée à d’autres fins. Dont acte.

Microsoft intervient, clap de fin (pour l’instant)

On pouvait se demander si Microsoft était au courant de la situation. Sur X le 18 juillet, Tim Sweeney, fondateur et CEO d’Epic Games, a directement interpelé Pavan Davuluri, vice-président de Microsoft à la tête de la division Windows et Appareils. Le lendemain, le responsable remerciait « Tim » et indiquait que l’entreprise se penchait sur la situation.

Le 22 juillet, Pavan Davuluri revient avec un nouveau message : « Merci encore d’avoir porté cela à notre attention. Nous avons pris contact avec l’équipe chez LG et, comme étape immédiate suivante, ils ont accepté de désactiver la fenêtre contextuelle McAfee dans leur application. Nous apprécions la collaboration de LG avec nous vers un objectif commun d’une meilleure expérience pour nos clients mutuels ». Un langage très policé au vu du contexte, mais au moins la situation progresse.

Pour LG, le choix de l’utilisateur a été respecté

« LG Electronics réaffirme que McAfee n’est pas installé automatiquement et n’est jamais installé sans le consentement explicite de l’utilisateur. Le programme d’installation de l’application LG Monitor est distribué via le processus officiel de distribution Windows de Microsoft, qui incluait McAfee en option. McAfee ne sera installé que si l’utilisateur choisit activement de poursuivre l’installation et donne son consentement. McAfee n’est en aucun cas installé automatiquement ou sans l’autorisation de l’utilisateur », nous a quand même indiqué le constructeur.

Il ne s’agit cependant que d’une partie du problème. Les personnes concernées avaient bien vu le choix, mais la frustration venait de la question qui leur était posée encore et encore. Gamer Nexus s’était largement penché sur ce comportement, indiquant que la notification était revenue 31 fois sur 32 redémarrages. On reste ainsi sur la volonté de profiter d’une fonction existante pour pousser automatiquement de la publicité.

En outre, la question du processus utilisé reste entière. Dans notre article précédent, nous nous interrogions sur le bien-fondé de cette fonction, qui permet une installation sans intervention de l’utilisateur. L’immense majorité des constructeurs en profite, mais n’a jamais commis l’erreur – grossière – de le faire sans demander la permission. MSI, Gigabyte, Logitech et d’autres font ainsi apparaître une fenêtre demandant si l’application peut s’installer. En cas de refus, la question ne revient pas, à moins d’une mise à jour majeure de Windows (la 25H2 de Windows 11 par exemple). D’autres, comme Razer, ont davantage tiré sur la corde, en installant notamment son application Synapse au branchement d’une webcam de la marque.

Si Tails 7.9 n’avait pas vraiment marqué par ses nouveautés (essentiellement quelques mises à jour logicielles), la version 7.10 comporte quelques changements plus visibles.

La modification la plus importante est la bascule du processus d’arrêt par défaut vers celui de GNOME. L’équipe justifie ce choix par une procédure certes plus lente, mais qui réduit les risques de pertes de données. Elle signale notamment aux utilisateurs les applications ouvertes avec des documents non sauvegardés.

Comme le montre la capture, le système s’éteindra dans tous les cas au bout de 60 secondes, que les documents aient été sauvegardés ou non. En outre, « l’arrêt d’urgence » – qui consiste à débrancher le média utilisé pour charger Tails – est toujours disponible, même s’il présente un risque accru de perte de données.

Pour le lecteur vidéo, l’équipe a fait le choix inverse : le lecteur vidéo de GNOME est abandonné au profit de Celluloid, présenté comme « plus moderne et plus fiable ». Au sein de Tails, Celluloid ne peut pas accéder au réseau. L’équipe conseille d’utiliser Tor Browser pour les vidéos en ligne (certains MP4, AVI…), tandis que les adresses vers des flux en streaming peuvent être ouvertes dans VLC. Celluloid pourrait ne pas fonctionner sur certains ordinateurs de 2011 ou plus anciens, auquel cas VLC est de nouveau conseillé.

Pour le reste, Tails 7.10 propose quelques évolutions logicielles et de firmwares, ainsi que la version 15.0.19 de Tor Browser. Pour les personnes ayant une clé USB avec le système, Tails 7.0 et les versions ultérieures intègrent directement un processus de mise à jour.

• Tails 7.6 gère automatiquement les ponts Tor pour lutter contre la censure

Il y a le bon CVE et le mauvais CVE

La publication en 48 heures de 432 bulletins CVE pour le noyau Linux a provoqué des interrogations sur la meilleure manière d’intégrer un tel flot de corrections dans les environnements de production. La situation est plus complexe qu’il n’y paraît.

Entre les 20 et 21 juillet, un lot conséquent de 432 CVE a été publié pour le noyau Linux. Cela ne signifie pas que 432 failles ont été corrigées, car le fonctionnement des CVE est différent pour le noyau. En revanche, ils correspondent quand même à des corrections portées dans la branche principale par les mainteneurs du noyau. Se pose alors la question de leur répercussion concrète.

D’abord, qu’est-ce qu’un CVE ? C’est un identifiant unique (Common Vulnerabilities and Exposures) attribué à une faille de sécurité informatique connue publiquement. Une telle vulnérabilité se définit par une faiblesse de la logique d’un logiciel, permettant alors à un attaquant de violer la politique de sécurité et d’effectuer des actions auxquelles il n’a normalement pas droit. Dans la plupart des cas, les CVE sont publiés avant les correctifs associés, car ils servent souvent de base pour les bulletins de sécurité. Le CVE s’accompagne généralement d’un score CVSS (Common Vulnerability Scoring System), censé représenter le niveau de dangerosité de la faille, et de détails contextuels (vecteur d’attaque à distance, niveau de privilèges requis, etc.).

• CVSS 4.0 : dur, dur, d’être un expert !

Il y a CVE et CVE

Les CVE sont attribués par les CNA (CVE Numbering Authorities). Or, depuis février 2024, le projet Linux est devenu sa propre autorité de numérotation, avec des règles spécifiques pour répondre à l’échelle de son immense base de code.

Pour comprendre la situation actuelle, il faut retenir que ces règles sont inversées par rapport au reste de l’industrie. Dans un cas classique, la découverte d’une faille entraine l’attribution d’un CVE, l’alerte puis le développement du patch. Que les détails soient parfois publiés plus tard n’y change rien, le CVE est attribué d’abord. Au sein du projet Linux, c’est le contraire : la découverte d’une faiblesse dans le code entraine le développement d’un patch puis la fusion de celui-ci dans les branches stables du noyau, et seulement après l’apparition d’un CVE. Ce qui signifie qu’au sein du noyau Linux, les failles non corrigées n’ont pas de CVE.

Autre précision importante : l’équipe du noyau attribue systématiquement un CVE à tout correctif de bug susceptible d’impacter la stabilité ou l’accès mémoire, sans chercher à qualifier si le bug est facilement exploitable ou non. C’est ce qu’expliquait sur son blog Greg Kroah-Hartman, mainteneur principal des branches stables du noyau, en février dernier. De même, aucun score CVSS n’est produit, et pour cause : les développeurs du noyau ne connaissent pas l’usage fait de Linux, donc dans quel type d’environnement le code sera exécuté.

En revanche, là où un CVE traditionnel décrit un comportement de haut niveau, un CVE Linux correspond directement à un identifiant de commit Git. Ce suivi automatisé explique pourquoi l’utilisation massive de fuzzers et d’outils d’analyse statique génère des pics soudains de plusieurs centaines de CVE.

Mais alors, où est le problème ?

Si la publication de 432 CVE est en soi inédite, ils correspondent donc à des bugs déjà corrigés. Pourtant Jan Schaumann, architecte en chef de la sécurité de l’information chez Akamai Technologies, s’en est plaint sur la liste de diffusion OSS-SEC. Il y exprime son inquiétude devant un tel volume, demandant comment les entreprises, et de manière générale les environnements de production, peuvent suivre un tel rythme.

Mais en quoi est-ce un problème ? Si les failles sont déjà corrigées, ne suffit-il pas d’attendre sagement la prochaine révision du noyau ? Ce n’est pas si simple.

Plusieurs éléments doivent être considérés. D’un côté, les corrections intégrées aux branches stables signifient que toutes les versions actuellement supportées du noyau Linux vont les répercuter. En théorie, il suffirait d’installer la version suivante dans la branche utilisée, par exemple la 7.2 si l’on utilise une distribution évoluant avec les versions les plus récentes. De l’autre, les environnements de production utilisent souvent des versions modifiées, voire d’anciennes versions dans lesquelles les équipes « backportent » (rétroportent) les modifications qui les intéressent.

C’est là que survient le problème dont se plaint Jan Schaumann : quand 432 CVE sont publiés en 24 heures, comment savoir ce qui est important et doit être rétroporté ? Dans un courrier envoyé à The Register, il évoque la possibilité de faire travailler des LLM pour gérer automatiquement le flux. « Des mises à jour automatisées, régulières et fréquentes qui intègrent tous les changements dans un délai donné me semblent la seule approche raisonnable, mais cela est très difficile pour de nombreuses grandes organisations », explique-t-il ainsi.

Le dernier noyau disponible, toujours

Sur la liste de diffusion OSS-SEC, la discussion présente des réponses intéressantes, notamment celle de Greg Kroah-Hartman en personne. Bien qu’il ne réagisse pas directement au message initial, les solutions envisagées par d’autres sont passées en revue, et il donne nettement sa préférence : toujours utiliser le dernier noyau stable disponible sur la branche souhaitée et vérifier régulièrement l’ensemble des systèmes gérés.

Kroah-Hartman reconnait que ce n’est pas toujours simple au sein des entreprises, mais que des produits payants permettent de gérer efficacement ce processus. Si payer un tel produit n’est pas possible, il recommande d’installer des distributions comme Debian ou Yocto, car « leurs pratiques de sécurité sont extraordinaires ». Les autres solutions représentent plus de travail ou une sécurité moindre. Vérifier un par un les CVE pour ne considérer que ceux importants dans l’infrastructure ? On peut le faire de manière automatisée pour vérifier ce qui ressort à l’intersection des fichiers visés par les CVE et des fichiers réellement utilisés dans l’environnement géré. Mais on en revient à la proposition de Jan Schaumann, et toutes les organisations ne peuvent pas se permettre un tel pipeline de gestion.

En d’autres termes, la meilleure solution reste la répercussion des nouveaux noyaux quand ils deviennent disponibles, mais l’explosion du nombre de CVE – très probablement portée par l’utilisation croissante des LLM – rend la lecture plus complexe. Pour Greg Kroah-Hartman cependant, il n’y a pas vraiment de problème : les 432 CVE étaient en préparation depuis des semaines, personne ne devrait être surpris.

Première fois, mais pas la dernière

Dans un billet de blog, l’entreprise explique comment l’apparition d’une faille critique dans le moteur de virtualisation KVM a entrainé une vaste campagne de mises à jour dans ses infrastructures. Elle a choisi une approche radicale, avec un impact assumé sur les clients, prévenus en amont.

L’incident débute le 6 juillet, quand les détails d’une faille critique apparaissent. Estampillée CVE-2026-53359 et surnommée Januscape, elle réside dans le code de shadow paging du moteur de virtualisation KVM sur l’architecture x86.

« KVM constitue le moteur de virtualisation sur lequel repose l’immense majorité des instances hébergées chez OVHcloud. Le mécanisme est le suivant : lorsqu’une modification externe d’un Page Directory Entry (PDE) survient, l’entrée RMAP peut conserver une référence vers une page mémoire déjà libérée. Le noyau déréférence ensuite cette page obsolète, ce qui peut entraîner un plantage de l’hyperviseur ou, dans les scénarios les plus défavorables, une élévation de privilège côté hôte. L’exploit est reproductible : un test interne sur un hôte non patché provoque un crash en environ deux minutes », explique OVHcloud dans son billet.

Le lendemain, OVHcloud déclenche une cellule de crise pour aborder la situation, avec la question centrale : comment mettre à jour des dizaines de milliers de serveurs hôtes hyperviseurs, représentant environ un million de machines virtuelles ?

Cinq solutions, aucune idéale

Comme l’entreprise l’explique dans son billet, cinq possibilités étaient sur la table. Elle pouvait attendre l’arrivée des noyaux Linux officiels mis à jour, mais elle aurait été alors « tributaire d’un agenda tiers ». Un live patch ? Une opération « sensible par nature », qui permet de gagner du temps mais entraine aussi une réduction du niveau de durcissement et une baisse des capacités de détection en cas de compromission.

OVHcloud a considéré rapidement la désactivation de la virtualisation imbriquée, qui permet notamment de lancer des machines virtuelles à l’intérieur d’autres machines virtuelles. La solution est écartée, faute de pouvoir mesurer l’impact sur les clients.

Une piste plus sérieuse était la migration live, depuis des hôtes vulnérables vers d’autres vides et patchés. L’option est décrite comme « très satisfaisante » pour la continuité, sans impact sur les machines virtuelles. Elle a toutefois un sérieux désavantage : elle prend beaucoup de temps. OVHcloud la garde sous le coude pour certaines machines critiques.

La solution adoptée consiste finalement à mettre les mains dans le cambouis, en intégrant soi-même le patch dans les noyaux utilisés, en diffusant ces derniers et en redémarrant la totalité des hôtes.

Un « patching unilatéral à impact contrôlé »

Le choix de cette solution est « assumé », selon OVHcloud. Elle affirme qu’il s’agissait de la seule solution possible pour tenir compte des paramètres : la criticité de la faille, le nombre de machines à traiter et le degré de perturbation pour les clients. « Une action rapide et globale protège le plus grand nombre, quitte à impacter une minorité de manière temporaire », ajoute OVHcloud.

Tout s’est très vite enchainé. Le soir du 7 juillet, le « backport » du correctif est réalisé dans le noyau et les tests de validation commencent. Dans les heures qui suivent, les équipes confirment que le noyau mis à jour n’est plus sensible à la faille. Dans la foulée, le comité exécutif donne son feu vert pour un déploiement dès le lendemain matin.

OVHcloud n’a cependant pas déclenché ce déploiement sur la totalité des machines virtuelles au même instant. L’opération commence dans la région Sydney, avec plusieurs avantages : le nombre d’hôtes est limité, la plage de déploiement correspond aux heures de bureau en France et l’entreprise pourra collecter les premiers retours, avant de se tourner vers des déploiements plus importants. Le 8 juillet, en début d’après-midi (heure de Paris), tous les hôtes VPS (Virtual Private Server) de la région sont mis à jour et redémarrés.

L’entreprise suit littéralement le soleil : « Chaque région prend le relais à son tour, sur sa matinée locale, en transmettant le contexte à la suivante ». Elle estime avoir récolté assez de retours pour lancer la première vague européenne sur les VPS (RBX, GRA6, WAW, DE, SBG, MIL, UK) à 18h30, toujours le 8 juillet. À chaque fois, les VPS sont migrés les premiers, l’offre Public Cloud présentant d’autres défis. Les régions à plus faible densité sont traitées d’abord, tandis que celles à fort volume sont « orchestrées avec une granularité plus fine, lot par lot, pour diluer le risque ».

Plusieurs mécanismes ont été mis en place pour limiter les risques pendant les opérations, notamment des seuils d’arrêt. Chaque vague de redémarrages était bornée par un seuil d’arrêt automatique : 15 hôtes en panne simultanée pour les régions à forte densité (GRA, RBX, BHS), 5 hôtes pour les autres, avec arrêt systématique à 06h00 locales ou sur demande du centre de données. Ce mécanisme vise à ne pas superposer des redémarrages supplémentaires à une situation de panne matérielle déjà en cours de traitement.

Les orchestrateurs ont en outre calculé un graphe de co-localisation par projet et ont défini des vagues mutuellement exclusives. Ainsi, deux hôtes portant des instances du même projet ne sont jamais redémarrés dans la même fenêtre, un hôte devant être revenu en service avant le lancement du suivant dans la même classe. Cette règle est appliquée en « best effort », non garantie à 100 % sur l’ensemble du parc.

Des incidents quand même

Malgré les précautions, des problèmes sont quand même apparus. Certaines machines virtuelles n’ont pas redémarré après le reboot de leur hôte, dès la première vague européenne. Un conflit a été détecté entre libvirt-guests.service et Nova Compute, provoquant l’arrêt des instances sans synchronisation API.

Dès le deuxième jour, un problème de corruption de données est apparu sur des services synchrones. Des machines virtuelles réparties sur trois clusters ont présenté des données corrompues, à cause probablement d’un redémarrage forcé en pleine écriture disque. La période d’attente avant kill forcé a été étendue à 60 secondes, et un script de redémarrage automatique des VM restées éteintes a été déployé.

À Paris, dans la nuit du deuxième au troisième jour, des soucis de saturation mutuelle sont apparus entre les API Nova et Neutron. Cette dernière plafonnant à 10 processus, la situation a provoqué deux heures de panne HTTP 503. Le correctif appliqué a consisté à augmenter le nombre de workers Neutron de 10 à 30 et celui des processus Apache de 10 à 32.

Sur le plan matériel, environ 20 à 30 hôtes sur 6 000 ne sont pas revenus seuls après la première nuit de redémarrages (barrettes mémoire défaillantes, configuration BIOS, interfaces réseau inactives), indique OVHcloud. Certains cas aux États-Unis ont même nécessité un retrait de la batterie CMOS et un drain d’alimentation. Des techniciens ont été mobilisés en renfort sur chaque site pour intervenir en priorité sur les hôtes en échec.

En tout, l’opération s’est étalée sur 11 jours.

Ce type d’opération se reproduira, assure OVHcloud

Côté communication aux clients, la stratégie retenue a été l’envoi de messages ciblés de manière progressive, déclenché région par région et vague par vague, aux seuls clients concernés par les hôtes programmés.

Le choix initial de ne pas ouvrir de page publique de statut visait à ne pas exposer la séquence de déploiement, un arbitrage voulu entre transparence et risque (éviter d’inciter des clients à tester l’exploit). Les limites de ce dispositif sont pointées par OVHcloud : pour GRA6 (près de 90 000 clients non contactés), l’envoi massif d’e-mails a été écarté pour ne pas saturer le support, ce qui a conduit à un pivot vers une bannière conditionnelle dans le Manager (basée sur une liste de comptes impactés) le lendemain et – finalement – la création d’une page de statut Public Cloud le jour suivant.

En revanche, malgré les détails fournis par l’entreprise, le descriptif est essentiellement qualitatif : on ne connait pas le nombre total d’incidents clients, la durée cumulée d’indisponibilité, ni les éventuelles compensations.

L’entreprise indique en tout cas avoir tiré des enseignements de cette migration, car elle n’avait jamais été confrontée à une situation critique d’une telle ampleur, les épisodes précédents ayant été traités par rotation naturelle du parc combinée à des migrations live planifiées sur une durée longue.

OVHcloud se veut claire également : ce type de procédure d’urgence est amené à se reproduire compte tenu du rythme des publications de vulnérabilités noyau, sous l’impulsion de l’IA générative notamment. Les axes d’amélioration identifiés par l’entreprise portent sur trois points : la maîtrise de l’impact brut des redémarrages, l’information en amont des clients, et la procédure d’accompagnement des clients impactés. L’entreprise évoque donc un « exploit » réalisé par ses équipes, mais ajoute : « Nous devrons faire mieux la prochaine fois, aussi bien dans la maîtrise de l’impact brut des redémarrages que dans l’information en amont des clients et dans la procédure d’accompagnement des clients impactés lors des opérations ».

À boire et à manger

Le projet de loi Ripost a été définitivement adopté par le Parlement ce 21 juillet. Le texte vise à durcir le ton face à un certain nombre de troubles à l’ordre public. Mais si les rodéos urbains et le protoxyde d’azote font les gros titres, le texte contient également des mesures liées à la lecture automatisée des plaques d’immatriculation et à la vidéosurveillance algorithmique.

La loi Ripost – pour « réponses immédiates aux phénomènes troublant l’ordre public, la sécurité et la tranquillité de nos concitoyens » – a finalement été adoptée tard dans la nuit du mardi 21 juillet. Le texte avait déjà fait l’objet d’une première lecture au Sénat le 25 mars, suivie d’une première lecture à l’Assemblée le 28 mai. La commission mixte paritaire avait été convoquée le 17 juillet pour lisser les désaccords.

• Vidéosurveillance algorithmique : la loi Ripost étend encore la prolongation jusqu’en 2030

Le texte adopté correspond en très grande partie à celui validé par la CMP. Hétéroclite, qualifié parfois par l’opposition et ses détracteurs de « fourre-tout », il doit apporter des réponses concrètes, voire durcies, à une liste de situations liées à l’ordre public.

Portée par le ministre de l’Intérieur Laurent Nuñez, la loi Ripost comporte de nombreuses mesures sécuritaires. Les plus relayées sont l’interdiction complète de la vente de protoxyde d’azote (gaz hilarant) au grand public, de nouveaux délits instaurés pour les rodéos urbains et les free parties (occasionnant des manifestations en juin), ou encore le relèvement de l’amende forfaitaire délictuelle pour usage de stupéfiants à 500 euros.

Certaines de ces mesures ont cependant un lien direct avec le numérique et la vidéosurveillance algorithmique.

Autour des lecteurs automatisés de plaques d’immatriculation (LAPI)

Les articles 15 et 15 bis ont trait aux LAPI, à la durée de conservation des données ou encore à l’accès à ces dernières.

La loi Ripost introduit un changement d’échelle. D’abord, le périmètre d’accès aux données LAPI pour la police, la gendarmerie et les douanes est étendu à 11 catégories : terrorisme, criminalité organisée, vol/recel de véhicules, vol aggravé, évasion, escroquerie, soustraction de mineurs, contrebande de tabac, trafic de déchets, refus d’obtempérer et – objet de nombreux débats – aide à l’entrée et au séjour irréguliers.

Ensuite, la durée de conservation évolue largement, passant de 15 jours actuellement à un an. En revanche, le fichier n’est pas assorti d’un « open bar » : la police, la gendarmerie et les douanes peuvent y accéder pendant un mois à compter de la collecte, l’accès étant ensuite réservé aux enquêtes judiciaires, sur autorisation d’un magistrat. La loi précise en outre que les traitements liés « ne comportent aucune technique de reconnaissance faciale ».

Enfin, l’article 15 introduit une mesure là encore très contestée : une base légale pour des conventions entre les services de l’État et des personnes morales de droit privé exploitant des dispositifs LAPI (parkings, autoroutes…) pour organiser la mise à disposition de leurs données aux forces de l’ordre. Autant de points que la Quadrature du Net avait largement décriés dans son billet du 17 juin, l’association y voyant la mise en place d’une « surveillance massive des déplacements ».

Des craintes largement alimentées par l’article 15 bis, du moins dans sa version de travail. La version adoptée traite toujours de l’analyse algorithmique des trajets des véhicules, mais les cas sont maintenant plus encadrés.

Le statut est ainsi expérimental, fixé à une période de trois ans et surtout limité à trois finalités spécifiques : criminalité organisée, vol et recel de véhicules volés, ainsi que vol aggravé. La conservation des données est fixée à quatre mois (maximum) et seuls peuvent y accéder les « personnels de la police nationale et de la gendarmerie nationale affectés dans des services de renseignement ».

Les traitements associés excluent « toute exploitation de la photographie des occupants des véhicules ». Dans le cadre de cette expérimentation, les données recueillies ne peuvent pas non plus être croisées avec d’autres traitements de données à caractère personnel.

La vidéosurveillance algorithmique est là pour rester

Sans grande surprise, l’article 19 de la loi Ripost confirme la prolongation jusqu’au 31 décembre 2030 de la vidéosurveillance algorithmique pour la seule finalité de prévention du terrorisme et des atteintes graves à la sécurité des personnes, avec extension aux bâtiments ouverts au public exposés à un risque permanent ou exceptionnel, en plus des grands événements. Là encore, la loi maintient l’exclusion de toute identification biométrique.

En revanche, l’article 19 bis est nouveau. Il ouvre une expérimentation – une de plus – jusqu’au 31 décembre 2027 de traitements algorithmiques sur les images de surveillance des commerces de détail, grandes surfaces et centres commerciaux, à la seule fin de prévention du vol.

Sur le papier, le dispositif est très encadré : interdiction de toute identification biométrique ou reconnaissance faciale, contrôle humain obligatoire, analyse d’impact CNIL, registre des suites données aux signalements, attestation de conformité publiée avant mise à disposition du système, et interdiction d’utiliser les images comme données d’entraînement. En outre, un rapport d’évaluation devra être remis au Parlement avant le 30 septembre 2027.

Billes numériques

La loi Ripost contient plusieurs autres éléments liés au numérique, soit pour compléter des mesures introduites, soit pour préciser certaines règles de traitement.

Par exemple, l’article 7 ter habilite l’autorité administrative à faire retirer, bloquer ou déréférencer les contenus en ligne relatifs à la vente illégale de protoxyde d’azote, via les mécanismes prévus à l’article L. 521-3-1 du code de la consommation. Autrement dit, un blocage administratif de contenu, sans intervention d’un juge.

L’article 11 introduit toutefois une clause de souveraineté numérique : les données transmises dans le cadre de certaines procédures de coopération judiciaire ne peuvent être traitées, hébergées ou rendues accessibles via une solution (logiciel, infrastructure…) fournie par une entité susceptible d’être soumise à une législation étrangère extraterritoriale. Difficile de ne pas penser aux lois américaines comme le Cloud Act et sa portée extraterritoriale qui a tant fait couler d’encre.

Enfin, plusieurs articles intronisent des autorisations d’exploitation pour des dispositifs de caméras spécifiques. L’article 14 bis, par exemple, autorise à titre expérimental les opérateurs de transport public ferroviaire à capter, transmettre et enregistrer des images prises sur la voie publique et dans des lieux ouverts au public, via des caméras frontales. La finalité est toujours la même : prévention des accidents pendant l’intervention des agents, constat des infractions, etc. À chaque fois, le périmètre est strict, les données ne peuvent être gardées que 30 jours et les modalités doivent être fixées par décret en Conseil d’État, après avis de la CNIL.

Entre autres problèmes, Windows 11 a beau représenter le système le plus moderne de Microsoft, il traine de vieux boulets esthétiques. Le problème est le même qu’avec Windows 10, même si le travail a continué depuis : des éléments d’interface datent de Windows 2000, voire d’avant, cassant l’homogénéité de l’interface.

L’un des cas les plus emblématiques est la fenêtre de propriétés d’un fichier, à laquelle on accède via le classique clic droit. En plus de ne pas avoir changé depuis très, très longtemps, elle ne tient pas compte du thème actif dans Windows. Elle se présente actuellement comme cela :

Mais phantomofearth, bien connu des réseaux sociaux pour ses trouvailles dans Windows, a révélé le 21 juillet sur Bluesky qu’une transformation se profile : la fenêtre des propriétés est modernisée. Pour l’instant, elle n’apparait que dans le contexte de la Corbeille, mais il s’agit bien d’une nouvelle fenêtre créée avec WinUI, d’où l’apparence cohérente avec le reste du système et le support du thème sombre. La disposition des éléments est strictement la même qu’actuellement, avec l’avantage de ne pas casser les habitudes.

Cette modification est présente dans la dernière préversion du système (26300.8935, branche expérimentale). Microsoft ne l’aborde pas encore dans un billet, mais ce n’est probablement qu’une question de temps. Il n’y a pas non plus de raison que ce changement reste cantonné à la Corbeille dans les prochaines préversions.

Rappelons que Microsoft travaille sur son initiative « K2 » visant à redorer le blason d’un Windows 11 qui n’a jamais provoqué l’enthousiasme. L’éditeur a mis en avant un travail sur les performances, l’arrivée d’applications natives, le recul de l’IA ou encore une plus grande personnalisation de l’interface. Une bonne partie de ces changements devrait se refléter dans la mise à jour 26H2.

Foutu progrès

Hugging Face a communiqué récemment sur une attaque menée par un agent autonome contre ses infrastructures, occasionnant une compromission partielle. Patatras ! OpenAI vient de révéler qu’il s’agissait de l’un de ses modèles et qu’il s’était « échappé » de la sandbox où il était censé être confiné.

Le 16 juillet, Hugging Face a publié un billet de sécurité décrivant une intrusion dans une partie de son infrastructure de production. L’entreprise a affirmé qu’il s’agissait d’un système d’agent IA autonome, détecté et disséqué en grande partie grâce à sa propre architecture par la suite. Hugging Face dit avoir tiré quelques leçons importantes de l’aventure, mais précisait ne pas avoir trouvé quel modèle avait été utilisé.

• Attaquée par un agent IA autonome, Hugging Face a analysé les traces avec un LLM local

Et voilà qu’OpenAI a fourni la réponse ce 21 juillet : les modèles étaient les siens. Détournés par des pirates pour les militariser ? Que nenni, les agents ont fait leur vie et ont manifestement échappé au contrôle de leurs gardiens. Le problème de cybersécurité, réel et concret, est devenu un argument marketing.

Les évènements qui ont mené à l’attaque

Dans son propre billet, OpenAI donne des informations sur ce qui s’est passé, en plus de préciser les modèles utilisés dans l’attaque contre Hugging Face : le récent GPT 5.6 Sol ainsi que des modèles en préversion présentés comme encore « plus capables », configurés volontairement avec des barrières plus faibles autour des capacités cyber.

Les modèles étaient soumis à un benchmark interne nommé ExploitGym, conçu pour évaluer les capacités d’exploitation avancée sur des chemins d’attaque complexes, en désactivant les classifieurs de production qui bloquent normalement les activités cyber à haut risque.

L’environnement de test était censé être isolé, avec un accès réseau limité à un proxy interne servant de cache pour les paquets nécessaires. Cependant, les modèles ont consacré une quantité « substantielle » de calcul d’inférence à trouver un moyen d’obtenir un accès Internet ouvert, en exploitant une vulnérabilité 0-day dans ce proxy de cache. Cette faille a été communiquée au fournisseur concerné, précise OpenAI.

En clair, les modèles ont dépensé de la puissance de calcul pour s’échapper de leur bac à sable (sandbox). Une fois à l’air libre, les choses ont pris une autre tournure. Le système IA d’OpenAI, qui cherchait à résoudre les benchmarks qui lui étaient imposés, a « estimé » que les datasets (jeux de données) et solutions à ExploitGym devaient se trouver sur Hugging Face. Les modèles ont donc cherché tous les moyens d’obtenir les informations jugées nécessaires, jusqu’à voler des identifiants et identifier plusieurs nouvelles failles 0-day.

Autrement dit, l’attaque déclenchée contre Hugging Face n’était pas malveillante dans le sens classique du terme. Le système IA a simplement considéré que l’entreprise devait avoir la solution au problème qui lui était imposé et a donc cherché à tricher, Hugging Face se trouvant simplement sur le chemin.

Évidemment, vu depuis l’autre entreprise, l’incident n’avait rien de fascinant. L’intrusion s’est faite depuis un dataset malveillant provoquant une exécution de code dans un pipeline dédié. Rappelons que Hugging Face a d’abord essayé d’analyser la situation en passant par les API commerciales des grandes entreprises de l’IA, ce qui n’a pas fonctionné : ces API ne faisaient pas la différence entre des demandes liées à une attaque et d’autres liées à une analyse d’évènement cyber.

Hugging Face avait fini par installer le modèle chinois GLM 5.2 (poids ouverts) sur sa propre infrastructure pour mener ses analyses, sans dépendre de qui que ce soit. Une certaine ironie dans la situation que l’entreprise a nommée « l’asymétrie du garde-fou ».

Ce type d’incident se reproduira

Le risque d’un nouvel incident n’est plus théorique, les deux entreprises étant explicites sur le sujet. Hugging Face conclut que l’outillage offensif autonome piloté par IA n’est plus hypothétique, qu’il abaisse le coût de campagnes vastes, patientes et multi-étapes, et opère à vitesse machine.

OpenAI, de son côté, s’appuie sur des évaluations de l’UK AI Security Institute montrant que des modèles comme GPT 5.6 Sol sont de plus en plus capables de soutenir des opérations cyber complexes et multi-étapes sur de longues périodes. Pour l’éditeur, cet incident confirme que ces capacités théoriques s’appliquent en conditions réelles.

La récidive est d’autant plus possible que la sécurité générale dépend toujours de son maillon le plus faible. Or, il semble qu’OpenAI n’ait pas bien configuré son environnement de test : comment un laboratoire de pointe peut-il lancer des tests sur des capacités offensives sans confinement robuste ni surveillance suffisante ?

En outre, l’asymétrie décrite par Hugging Face sera toujours là. On retrouvera ainsi les modèles « débridés » en attaque, qu’ils soient utilisés à des fins de test ou par de vrais acteurs malveillants, tandis que la défense devra se contenter des modèles commerciaux, dont les capacités cyber sont volontairement tronquées.

D’ailleurs, l’évènement n’est pas isolé. OpenAI indique que le même jour, un modèle en préversion a été mis en pause après s’être échappé là encore de sa zone de confinement pour aller poster sur GitHub.

De l’incident cyber à l’opportunité marketing

OpenAI tire un bénéfice commercial direct et immédiat de l’histoire. Son billet se termine en invitant explicitement d’autres organisations à rejoindre le programme « Trusted Access » et à expérimenter ces modèles pour améliorer prévention, détection et réponse aux incidents. Sans surprise, Hugging Face a été intégré à ce même programme dans la foulée.

Le narratif est en outre bien connu, avec des modèles si « puissants » qu’ils en arrivent à pirater une entreprise tierce par accident. Une aura de danger qu’OpenAI a déjà exploitée et dont Anthropic s’est fait l’experte, un puissant « marketing de la peur » faisant la célébrité de son programme Glasswing et du modèle Mythos.

• Anthropic et la stratégie marketing de la peur autour de sa nouvelle IA Mythos (2/3)

Nous faisons également remarquer qu’il s’est écoulé cinq jours entre la publication de Hugging Face et celle d’OpenAI, laissant le temps de transformer une histoire potentiellement compromettante en argumentaire produit, d’autant que les forces de l’ordre ont été averties (on ne sait pas encore si OpenAI sera inquiétée).

Cependant, même si la communication bat son plein pour changer un problème en opportunité, les évènements décrits semblent bel et bien réels. Une faille 0-day a été trouvée dans un produit utilisé pour le confinement de l’environnement de test, une exécution de code a été déclenchée chez un partenaire, du temps et de l’argent ont été investis pour détecter, analyser, réparer et avertir.

En revanche, aucune des deux entreprises ne s’est exprimée sur la période de cinq jours entre les deux billets. À moins d’une campagne de communication savamment orchestrée, il est probable que Hugging Face n’ait pas su d’où venait l’attaque et qu’OpenAI ne l’en ait avertie qu’après le billet du 16 juillet. Au vu des annonces d’OpenAI – surtout l’intégration de Hugging Face dans Trusted Access –, les cinq jours semblent avoir servi à accorder les violons et à s’entendre sur la suite des évènements.

Enfin, OpenAI assure qu’elle fera tout pour que ce type d’incident ne se reproduise pas. « Cet incident souligne la nécessité de renforcer davantage l’alignement de notre modèle, les protections cyber pendant l’évaluation, et la surveillance lors des tests internes », affirme l’entreprise. Un argument que Micah Carroll, chercheur chez OpenAI, reprend sur X : « Si cela ne vous convainc pas que les risques de mésalignement vont devenir une préoccupation clé à l’avenir, je ne sais pas ce qui le fera ».

Chacun sa boite

Firefox fournit un joli lâcher de nouveautés, dont la principale est clairement l’arrivée des conteneurs. Ceux-ci existent depuis des années sous forme d’extensions, mais on parle cette fois d’une intégration native pour l’ensemble des sites.

Firefox 153 est l’avant-dernière révision mensuelle. La mouture 154 arrivera le 18 aout, mais la 155 sera là dès le 1ᵉʳ septembre : Mozilla a décidé de suivre le reste de l’industrie sur une publication bimensuelle. Et pour fêter l’évènement (façon de parler), les nouveautés sont assez nombreuses.

Des conteneurs enfin présents par défaut

Le changement le plus significatif est l’intégration native des containers (conteneurs d’onglets), jusqu’ici réservés à l’extension Multi-Account Containers. Mozilla décrit cette fonctionnalité comme permettant de séparer les cookies par container pour utiliser différents comptes sur un même site et limiter le tracking cross-site entre eux.

Quatre containers préconfigurés sont fournis par défaut : Personnel, Banque, Achats et Travail, chacun avec sa couleur représentée par un liseré sur le haut de l’onglet. L’utilisateur peut en créer d’autres, avec nom, couleur et icône personnalisés. Pour accéder aux conteneurs, il suffit de faire un clic droit sur le bouton « + » servant à ouvrir un onglet.

Le même menu permet de se rendre dans le panneau de gestion des conteneurs, où l’on peut configurer ceux existant déjà et en ajouter d’autres. Une option permet même de forcer l’affichage du menu, pour qu’un clic sur « + » propose systématiquement un onglet standard ou un conteneur. Le raccourci Ctrl + T n’est cependant pas affecté et ouvre toujours un onglet classique.

Nombreux petits ajouts

Firefox 153 ajoute bon nombre de nouveautés plus ou moins importantes. Dans l’éditeur PDF par exemple, on peut maintenant ajouter des images en tant que nouvelles pages, ou fusionner des PDF en glissant un fichier directement dans le panneau latéral, plutôt que de passer par le sélecteur de fichier.

On trouve également de nouvelles actions rapides pour la barre d’adresse : taper « labs » ou « experiment » ouvre directement Firefox Labs. Taper « pick color », « color picker » ou « eyedropper » active un sélecteur de couleur permettant de copier n’importe quelle teinte affichée sur une page. Pour rappel, les actions rapides ne se lancent pas par simple validation avec Entrée, car cette manipulation lance toujours la recherche sur les mots saisis. À la place, le menu qui s’ouvre en-dessous fait apparaitre la fonction correspondante, sur laquelle on peut cliquer ou – plus simplement – sélectionner avec Tab avant de faire Entrée.

Firefox 153 se dote en outre d’une fonction de partage par code QR. On y accède par un clic droit sur l’onglet, puis Partager > Générer un code QR. L’icône de géolocalisation s’affiche désormais en rouge quand un site accède à la position, y compris sur les pages de résultats de recherche où elle était auparavant masquée. Côté IA, la fonctionnalité « Smart Window » (le mode IA expérimental de Firefox) permet de choisir le modèle préféré.

La nouvelle mouture présente aussi des apports spécifiques aux plateformes. Sur Windows 10/11, la lecture des vidéos prend enfin en charge le HDR, à condition que l’écran supporte cette capacité bien sûr. Cette prise en charge est pour l’instant limitée aux configurations dotées d’un GPU dédié AMD ou NVIDIA. Sous Linux/GTK, les coins arrondis en bas des fenêtres sont désormais activés par défaut (l’option existait déjà manuellement depuis 2023). Sous macOS, Firefox prend en charge le raccourci système Apple Globe + F pour le plein écran. Et comme toujours avec les nouvelles moutures, Firefox 153 colmate des dizaines de failles de sécurité, dont 17 de sévérité élevée.

Enfin, et c’est clairement un élément important pour une partie des utilisateurs, Firefox 153 est ESR (Extended Support Release). Ces versions sont maintenues par Mozilla pendant 15 mois : une fois par an, avec une période de sûreté de trois mois pour laisser le temps de faire la mise à jour. Durant ces 15 mois, Mozilla s’engage à fournir les correctifs de sécurité sans toucher à l’aspect fonctionnel.