Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

Surface RTX Spark Dev Box - L'IA locale signée NVIDIA

Microsoft vient d'annoncer lors de son événement Build 2026 l'arrivée de sa Surface RTX Spark Dev Box, un petit boîtier qui se pose sur le bureau et qui fait tourner des modèles IA de 120 milliards de paramètres en local, sans rien envoyer dans le cloud.

Et bien sûr derrière le badge Surface, c'est NVIDIA qui se tape tout le boulot.

Dans cette boîte noire, vous avez donc la puce NVIDIA RTX Spark, qui rassemble un GPU Blackwell et un processeur Grace pour sortir environ 1 pétaflop de puissance IA et 128 Go de mémoire unifiée.

De quoi donc faire tourner un gros modèle avec une fenêtre de contexte d'un million de tokens, ou carrément affiner (fine-tuner) un modèle sans louer des GPU dans le cloud. Le tout dans un châssis en aluminium pensé pour servir de dissipateur, donc refroidi passivement. Et un malheur n'arrivant jamais seul (je plaisante ^^), Windows 11 Pro arrive préconfiguré dessus pour les devs, avec tous les outils qui vont bien déjà installés.

D'après le site de Microsoft, ce petit joujou sera donc dispo fin 2026, aux États-Unis d'abord.

Détails du châssis

Maintenant, le truc à bien capter, c'est que cette puce RTX Spark, c'est exactement la même famille que la DGX Spark , le mini-PC que NVIDIA vend depuis octobre dernier. Même architecture Grace Blackwell, même pétaflop, mêmes 128 Go unifiés.

Eh oui, Microsoft n'a pas conçu de puce maison pour cette box (ses puces Maia, c'est pour ses datacenters), mais a juste pris la plateforme d'NVIDIA et l'a habillée en Surface avec une image Windows maison. Ce qui n'est pas grave, hein, mais autant le savoir avant de croire à une révolution Microsoft.

Côté tarif, pas de chiffre officiel encore mais les estimations tournent autour de 3500 dollars. Pour vous donner une idée, la DGX Spark d'NVIDIA, sa cousine sous Linux, est passée de 3999 à 4699 dollars récemment, la faute à la flambée des prix de la mémoire. Donc, ce ne sera pas donné, mais vous vous en fichez parce que vous êtes probablement pété de thunes ^^.

Cela dit, même si c'est cher, l'idée de faire tourner un modèle costaud entièrement chez soi, ça reste sacrément séduisant. Vos données ne sortent jamais de la machine, y'a zéro facture d'API qui gonfle à chaque requête, et vous pouvez bidouiller un fine-tuning maison tranquillement. C'est une tendance qu'on voit monter depuis un petit moment maintenant avec par exemple des gens qui glissent un GPU de datacenter dans leur PC gaming juste pour s'affranchir du cloud ^^.

Après, vous n'avez pas besoin d'attendre cette box pour faire de l'IA locale. La DGX Spark existe déjà, un Mac avec assez de mémoire unifiée encaisse de gros modèles aussi, sans oublier qu'il y'a carrément moyen de remplacer l'API d'OpenAI par votre propre Mac . Sans parler des PC AMD Strix Halo...

Non, le vrai plus de Microsoft ici, c'est le combo refroidissement passif et image Windows dev clé en main, taillé pour le futur "Windows agentique" qu'ils nous préparent, et grâce auquel les agents IA tourneront en permanence sur nos machines pour taffer à notre place.

Bref, rien de dingue, c'est certain mais ça peut clairement dépanner ceux qui veulent un PC IA local sans avoir à bricoler. J'ai hâte de connaître le prix en tout cas !

Source

Age of Empires II est aussi conscient que votre ChatGPT

Vous connaissez ce refrain qu'on entend partout dans la presse, comme quoi ChatGPT ou Claude "comprendrait vraiment" ce que vous racontez, qu'il aurait une "morale", une "intention" , voire bientôt une conscience ?

Bah Adrian de Wynter, chercheur principal chez Microsoft, vient d'y répondre de la plus belle des manières en prouvant que si c'est le cas, alors Age of Empires II a lui aussi des attributs très humains.

Et c'est on ne peut plus sérieux (enfin... presque).

En effet, dans son papier de recherche il explique qu'il s'est monté un petit réseau de neurones à l'intérieur du bon vieux AoE2, et nous explique tranquillement que n'importe quel système posé sur un "substrat" assez puissant (comprenez : le "moteur" sur lequel ça tourne, peu importe lequel) peut afficher ce genre de propriétés. Ça marche donc avec le jeu de Microsoft, mais aussi les LEGO, ou carrément l'agglomération de Boston.

Son raisonnement c'est que quand un fanboy IA (ou un employé d'Anthropic, loool) affirme qu'un LLM "a" une morale ou "comprend" le langage sans dire précisément comment il le mesure, il ne décrit pas vraiment la machine mais projette tout simplement ses attentes sur elle. Car les expériences ont beau rester les mêmes d'un substrat à l'autre, leur interprétation, elle, change selon ce qui les produit. Du coup, déclarer que ces attributs humains existent dans l'absolu, sans critère mesurable, mène soit à un raisonnement circulaire, soit à une conclusion qui ne dit rien de très probant.

Mais attention, je vous vois venir les Anti-IA Bro ! Il ne dit pas que les LLM sont nuls... Non, non, il dit juste qu'on les mesure mal.

À la place, de Wynter propose donc de travailler à partir d'une "hypothèse nulle", qui est un grand classique de la démarche scientifique consistant à ne plus partir du principe que l'IA pense, mais au contraire, partir de l'inverse. De se dire en fait qu'elle n'a rien d'unique, et c'est ensuite à l'expérience de prouver le contraire avec des mesures explicites. C'est d'après lui précisément ce qui manque à la tonne de papiers qui crient à l'"émergence" dès qu'un modèle fait un truc inattendu.

Et le bonhomme sait de quoi il parle puisque c'est déjà lui qui avait fait jouer GPT-4 à Doom en 2024, en s'inquiétant au passage de la facilité avec laquelle on pouvait lui faire tirer sur tout ce qui bouge. C'est aussi lui qui a épluché plus de 2000 publications sur les LLM pour montrer le manque de rigueur du domaine. Et en bonus de tout cela, il a démontré également que Age of Empires II était Turing-complet , donc capable en théorie de faire tourner n'importe quel calcul. Des gens "codaient" déjà dans le jeu depuis des lustres, mais en avoir une preuve formelle aujourd'hui, c'est cool !

Mais bon après derrière la vanne, y'a surtout un vrai sujet qui est que de prêter des intentions humaines à une IA, ça pousse surtout les gens à trop faire confiance à un chatbot, à lui confier des trucs intimes, parfois à s'y attacher pour de bon. Alors mettre un réseau de neurones dernier cri et une bonne vieille partie d'AoE2 sur le même plan, c'est sûr que c'est vexant pour l'ego de l'IA et de ses ingénieurs, mais carrément plus sain pour le nôtre !

Bref, la prochaine fois qu'on vous vend une IA "qui comprend" ou que vous penserez que seul ChatGPT vous comprend vraiment, repensez aux petits paysans qui coupent du bois dans Age of Empires qui sont tout aussi conscients que votre IA préférée.

ls, grep, cp : Microsoft fait entrer les commandes Linux nativement dans Windows

À sa conférence Build 2026, le 2 juin, l'éditeur a lancé Coreutils for Windows, un paquet qui amène directement dans Windows les commandes de base bien connues des utilisateurs de Linux.

On parle des classiques du terminal, ls pour lister des fichiers, cp pour copier, mv pour déplacer, grep pour chercher du texte, ou encore cat, find et rm. Au total, près de 75 petites commandes que tout bidouilleur tape machinalement sans même y penser.

Au passage, une petite précision historique s'impose (et merci à MG pour le rappel) : si on les appelle par habitude des « commandes Linux », ces classiques sont en réalité bien plus vieux que ça. ls, cp, cat et compagnie viennent d'Unix, le système né au tout début des années 70 dans les labos de Bell, soit une bonne vingtaine d'années avant que Linux ne débarque en 1991. On les retrouve d'ailleurs dans à peu près toutes les versions d'Unix, de Solaris aux BSD jusqu'à macOS, et Linux n'a fait qu'hériter de ce patrimoine. Donc « commandes Unix » serait techniquement plus juste, mais bon, on se comprend.

Le but affiché est simple. Les développeurs jonglent en permanence entre Windows, macOS et Linux, et s'agacent quand une commande qui marche d'un côté refuse obstinément de fonctionner de l'autre. L'idée, ici, c'est de pouvoir réutiliser les mêmes commandes et les mêmes scripts partout, sans rien réécrire.

Le plus intéressant, c'est ce qu'il y a sous le capot. Et là, surprise. Coreutils for Windows ne réinvente rien, puisqu'il s'appuie sur uutils, un projet communautaire qui réécrit les fameux coreutils de GNU en Rust, un langage réputé pour éviter toute une famille de bugs mémoire.

Autrement dit, Microsoft reprend un travail open source mené par la communauté, l'empaquette proprement et le maintient sous son nom. Le tout s'installe en une seule ligne via WinGet, le gestionnaire de paquets maison de Windows, avec un simple winget install Microsoft.Coreutils.

Côté technique, l'astuce est plutôt élégante. Plutôt que de livrer un exécutable par commande, Microsoft fournit un unique programme, coreutils.exe, et crée à l'installation une série de raccourcis (ls.exe, cp.exe, grep.exe et les autres) qui pointent tous vers lui. Selon le nom que vous tapez, ce programme sait quelle casquette enfiler. Malin.

Tout n'a pas fait le voyage, cela dit. Des commandes comme chmod, chown ou kill restent sur le carreau, faute d'équivalent propre sous Windows, qui ne gère pas les permissions de fichiers à la manière d'Unix.

Ce n'est d'ailleurs pas un geste isolé. Depuis des années, Microsoft a glissé un vrai noyau Linux dans Windows avec WSL, ouvert le code de pans entiers de ses outils et multiplié les passerelles avec l'écosystème open source. Coreutils for Windows s'inscrit dans cette continuité, et confirme que l'éditeur a définitivement enterré la hache de guerre.

Reste que pour quiconque vit dans un terminal et passe ses journées entre WSL, la couche Linux intégrée à Windows, et l'invite de commandes classique, c'est un vrai confort au quotidien. Et voir Microsoft s'appuyer ouvertement sur du logiciel libre écrit en Rust, on n'aurait pas forcément parié là-dessus il y a dix ans.

Bref, le Microsoft qui détestait Linux est bel et bien mort, et c'est tant mieux pour ceux qui codent les deux pieds dans le terminal.

Source : Bleeping Computer

Microsoft lance Intelligent Terminal, un terminal open source qui vous laisse choisir votre IA

Microsoft a présenté le 2 juin, pendant sa conférence développeurs Build 2026, une version expérimentale de son terminal baptisée Intelligent Terminal 0.1, un logiciel open source publié sous licence MIT qui intègre directement des assistants IA dans la fenêtre où l'on tape des commandes.

Pour situer le truc si vous êtes vraiment très noob, le terminal c'est cette interface en texte que les développeurs et les administrateurs système utilisent au quotidien pour lancer des commandes, compiler du code ou piloter un serveur à distance. Microsoft propose déjà Windows Terminal depuis des années, et Intelligent Terminal en est une déclinaison distincte, pas un remplacement.

L'élément central, c'est l'agent pane, un panneau ancré sur le côté de la fenêtre qui joue le rôle de copilote. Il lit en permanence ce qui s'affiche dans votre terminal, et quand une commande échoue, il détecte l'erreur et vous propose une explication ou un correctif.

Vous pouvez choisir de recevoir une simple notification dans la barre d'état, ou laisser l'assistant appliquer directement ses corrections selon la configuration que vous avez définie.

Il y a aussi une astuce intégrée à la palette de commandes : tapez un point d'interrogation suivi de votre demande, et l'outil lance une tâche en arrière-plan dans un onglet dédié, sans bloquer la session en cours. Pratique quand on veut déléguer une opération longue sans interrompre son travail.

Côté assistants, Microsoft a fait un choix ouvert. Par défaut, c'est GitHub Copilot CLI, l'assistant maison qui fonctionne en ligne de commande. Mais Intelligent Terminal accepte n'importe quel agent compatible avec l'Agent Client Protocol (ACP), une norme qui permet à différents assistants IA de venir se brancher sur le même outil.

Vous pouvez donc passer par Claude Code, l'assistant de codage signé Anthropic, le concurrent d'OpenAI, ou par Codex, l'équivalent maison d'OpenAI, à la place de la solution de Microsoft. C'est suffisamment rare chez l'éditeur de Windows pour être signalé.

Le logiciel s'installe depuis le Microsoft Store ou via la commande winget install Microsoft.IntelligentTerminal, et il se pose à côté de Windows Terminal sans le remplacer. Microsoft précise que si vous ne voulez pas d'IA dans votre terminal habituel, rien ne change pour vous.

Il y a quand même un détail qui coince, et c'est Phoronix, le site spécialisé dans l'actualité Linux, qui le relève : malgré son code ouvert publié sous licence MIT, Intelligent Terminal ne tourne pour le moment que sous Windows.

On parle aussi d'une version 0.1 estampillée expérimentale, ce qui annonce des bugs et des changements à venir avant une éventuelle version stable.

Bref, un terminal open source qui laisse l'utilisateur choisir son IA au lieu d'imposer la sienne, c'est un geste plutôt bien pensé de la part de Microsoft.

Source : Phoronix

De faux utilitaires PC transforment votre carte graphique en mineur de crypto à votre insu

Vous installez CrystalDiskInfo pour surveiller l'état de vos disques, FurMark pour pousser votre carte graphique dans ses retranchements, HWMonitor pour garder un œil sur les températures... Attention !

Sauf que depuis quelques semaines, certains de ces téléchargements sont piégés. Les équipes Microsoft Defender Experts ont repéré, depuis le mois de mars, plus de 150 faux sites qui se font passer pour ces utilitaires et installent en douce un mineur de cryptomonnaie.

Le choix des logiciels copiés n'a rien du hasard. À cette liste s'ajoutent Display Driver Uninstaller, l'outil qui nettoie en profondeur les pilotes graphiques, le K-Lite Codec Pack ou encore PDFgear. Ce sont exactement les programmes qu'installe quelqu'un qui possède une grosse carte graphique dédiée, justement le composant qui rend le minage rentable.

Le but, c'est de faire tourner cette carte à votre insu pour fabriquer de la cryptomonnaie au profit des pirates, ce qu'on appelle le cryptojacking. Reste à attirer les victimes. Les attaquants trafiquent le référencement, pour propulser leurs faux sites tout en haut des résultats de recherche.

Et depuis avril, ils ont ajouté un canal : les chatbots IA. Quand un utilisateur demande à un assistant où récupérer tel logiciel, la réponse générée peut très bien pointer vers un domaine contrôlé par les pirates, présenté avec le même aplomb qu'un lien parfaitement sain.

Le piège, lui, est bien construit. Dans le ZIP, le vrai logiciel s'ouvre normalement. Mais à côté dort autorun.dll, une bibliothèque piégée que l'exécutable charge tout seul, sans la moindre alerte, par une technique de détournement appelée DLL sideloading. Le code malveillant passe pour un composant attendu, et Windows ne bronche pas.

Ensuite tout s'enchaîne. msiexec, l'installateur intégré à Windows, dépose un second fichier, vcredist_x64.dll. Le nom singe le Visual C++ Redistributable, un composant Microsoft qu'on croise partout. Sauf que c'est un faux. Dessous se cache ScreenConnect, un vrai outil d'administration à distance, qui ouvre aux pirates une porte permanente sur votre PC.

Et le minage démarre. lolMiner, gminer, SRBMiner-MULTI : des mineurs GPU connus se mettent à faire tourner votre carte pour fabriquer de la crypto. Le plus vicieux, c'est leur patience, parce qu'ils attendent que la machine soit au repos pour bosser et se figent à la seconde où vous lancez un jeu ou une grosse application. Vous ne voyez rien.

Pendant ce temps, votre carte chauffe et s'use pour enrichir un parfait inconnu. Et votre facture d'électricité grimpe, sans la moindre contrepartie.

La parade est toute bête. Pour installer un utilitaire, ne cliquez pas sur le premier lien d'un moteur de recherche ou d'un chatbot. Passez par le site officiel de l'éditeur, ou par le Microsoft Store.

Bref, le point faible n'est plus le téléchargement louche au fond du web, mais le réflexe de cliquer sur le premier lien venu, suggestion d'IA comprise.

Source : Microsoft

AudioHijack - Le son inaudible qui pirate votre assistant IA

Meng Chen, doctorant à l'université Zhejiang, vient de prouver avec son équipe qu'on pouvait complétement détourner un assistant vocal IA avec un simple son que vous prendriez probablement pour un simple parasite. Avec sa bidouille, il a ainsi réussi à pousser les agents vocaux commerciaux de Microsoft et de Mistral à exécuter des actions que personne ne leur avait demandées.

Gloups !

L'attaque s'appelle AudioHijack, et ça consiste à planquer des ordres dans un fichier audio, une vidéo, un clip musical, une note vocale. Comme ça, le modèle qui l'écoutera vous obéira à VOUS, plutôt qu'à l'utilisateur. C'est comme une injection de prompt sauf que celle-ci s'entend à peine.

"Une demi-heure pour entraîner le signal, et comme il ignore le contexte, vous attaquez quand vous voulez, peu importe ce que dit l'utilisateur", résume Chen dans son interview . Reste qu'il faut un accès complet au modèle pour fabriquer le signal, ce que Microsoft et Mistral ne donnent pas. Alors il suffit à l'attaquant de l'entraîner sur un modèle ouvert qu'il contrôle, puis de rejouer le même signal contre le modèle fermé et en général, ça se passe bien parce qu'ils partagent souvent les mêmes briques audio.

Voilà et ça une fois que c'est fait, il suffit de "polluer" une source, et d'attendre qu'un poisson morde à l'hameçon...

Et le menu des possibilités est plutôt copieux vous allez voir. Le modèle peut par exemple prétendre qu'il ne sait pas traiter l'audio, refuser vos demandes, sortir de fausses infos, glisser un lien piégé, changer de personnalité, ou pire, déclencher des outils tout seul. Genre envoyer un mail avec vos données, ou télécharger un fichier depuis un serveur de l'attaquant s'il en a la possibilité technique (coucou MCP). Ainsi, sur les treize modèles testés, la réussite moyenne grimpe entre 79 et 96% selon le méfait.

Mais pour fabriquer ce signal vérolé, l'attaquant doit sentir dans quelle direction "pousser" le son pour rapprocher le modèle de son but, un peu comme suivre une pente vers le bas.

Sauf que ces modèles transforment l'audio en le découpant par exemple. Et la pente peut du coup devenir un escalier, puis du plat, voire une arête cassante... c'est clairement impossible à suivre ! Mais l'équipe de Chen a réussi à reconstituer cette pente à grand coups d'échantillonnage, puis a maquillé le bruit en réverbération.

Et comme notre oreille est trop limitée pour flairer l'anomalie, ça passe tranquille... Je vous avais déjà parlé de l'injection de prompt avec une simple doc empoisonnée qui pilote une IA , mais là, ça pourrait même surgir de la bande son d'une simple vidéo Youtube...

Et pour se protéger de ça, y'a pas grand chose à faire à part faire relire le prompt final... Le plus sûr, c'est donc plutôt de ne pas brancher votre assistant vocal sur vos mails, vos fichiers ou vos paiements, et de regarder plus en détails ce qui se passe s'il refuse soudainement une tâche ou vous sort un lien après avoir écouté un audio douteux...

De leur côté, les modèles fermés d'OpenAI ou d'Anthropic sont plus durs à viser, faute d'accès à l'architecture mais comme ils s'appuient aussi sur des briques audio open source, l'équipe de Meng pense que l'attaque pourrait se faire aussi.

Méfiance donc...

Source

MiniPlasma - La faille Windows que Microsoft croyait corrigée

Si vous tournez sur un Windows 11 à jour, sachez qu'il existe une faille qui permet à un programme local spécialement conçu de grimper tranquillou jusqu'au compte SYSTEM. Pour rappel, c'est le compte tout-puissant de la machine, c'est à dire celui qui passe même au-dessus de l'administrateur ! Et cette faille elle s'appelle MiniPlasma, et elle vient d'être balancée en public sur GitHub par un chercheur planqué derrière le pseudo Nightmare-Eclipse.

Et le plus gênaaaaant dans l'histoire, c'est que Microsoft était censé avoir bouché ce trou depuis 2020, dans cette CVE-2020-17103 , après un signalement de James Forshaw, le chercheur du Project Zero de Google.

Le bug vit sa life dans cldflt.sys, le pilote Cloud Files de Windows. Ce truc c'est un composant système livré d'office avec l'OS, qui est principalement utilisé par OneDrive mais aussi par d'autres stockages cloud. Et bien sûr, il reste présent sur la machine même si vous ne touchez jamais à OneDrive.

Du coup, en passant par une API non documentée baptisée CfAbortHydration, l'exploit crée des clés de registre là où il ne devrait pas, et s'en sert pour détourner un chemin d'exécution privilégié, ce qui finit par lui ouvrir les droits SYSTEM.

Le code de démo est dispo sur le dépôt GitHub du projet , écrit en C#, et il lance directement un cmd.exe en SYSTEM quand ça fonctionne. Parce que oui, ça ne marche pas à tous les coups puisque c'est une race condition. Le taux de réussite varie donc d'une machine à l'autre.

Le PoC en action : à gauche, un compte « user » standard lance l'exploit (« Exploit succeeded ») et à droite, le shell obtenu où whoami renvoie nt authoritysystem.

Maintenant, le truc qui fait vraiment mal au cul, c'est que la fameuse faille patchée par Microsoft est donc toujours vulnérable 6 ans après sa détection. Personne ne vérifie chez krosoft ??? C'est dingue !

Selon le chercheur, c'est exactement la même faiblesse qu'à l'époque. Reste à savoir pourquoi ça leur a échappé. Le patch n'a peut-être jamais corrigé la racine du problème, ou il a sauté quelque part en cours de route, j'en sais rien... Faudra analyser le code de Windows et de ses MAJ au fil du temps pour comprendre où ça a merdé.

Du coup, votre machine peut avoir avalé tous les Patch Tuesday et rester quand même exposée à une élévation de privilèges locale dès qu'un attaquant (ou un malware) arrive à exécuter du code dessus.

J'sais pas vous, mais on a déjà vu ce film avec d'autres dossiers Windows, comme cette histoire de BitLocker contournable , ou encore ces contournements de Secure Boot signés Microsoft . Certains trous de sécu sont tout simplement increvables !

Nightmare-Eclipse n'en est d'ailleurs pas à son coup d'essai puisque le chercheur enchaîne les divulgations publiques de 0-days Windows depuis quelques semaines, du contournement BitLocker au déni de service sur Defender en passant par plusieurs élévations de privilèges, toujours avec le PoC qui va bien et zéro divulgation coordonnée.

Et y'a pas de "on prévient Microsoft et on attend gentiment 90 jours" ici. Il balance tout car il est a ras-le-bol de la lenteur de Microsoft. C'est violent, dangereux et clairement discutable côté éthique, mais ça met une grosse pression pour corriger au plus vite. Maintenant pour nous tous, ça signifie surtout qu'un PoC public et fonctionnel, ce sont des malwares qui vont vite l'intégrer.

Côté protection, il n'y a pas de correctif officiel ni la moindre déclaration de Microsoft et ucune mitigation validée par l'éditeur non plus. Puis pour un particulier, pas de moyen simple de savoir après coup si la machine a été touchée.

La bonne nouvelle (relative c'est vraie), c'est que l'attaque est purement locale, donc il faut déjà pouvoir exécuter du code sur l'ordi pour en profiter. Votre vraie défense, c'est donc votre hygiène tech habituelle, à savoir ne pas lancer le premier binaire douteux venu, se méfier des cracks et autres pièces jointes, et côté admins, une surveillance EDR des élévations de privilèges inattendues vaut mieux qu'une règle maison non testée.

Source

VS Code signe vos commits avec Copilot, même sans Copilot

Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.

En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <[email protected]> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.

Quelle lose, hein ? La Product Manager Courtney Webster a poussé cette fameuse pull request #310226 des enfers le 15 avril dernier sans aucune description, et le dev dmitrivMS l'a mergée tranquillou le lendemain.

Et le résultat de tout ce bordel, vous pouvez le lire dans la PR #310226 qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.

L' issue de suivi #314311 , ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...

Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :

"git.addAICoAuthor": "off"

C'est le seul réglage qui marche vraiment, parce que dans la version buguée même chat.disableAIFeatures à true n'arrêtait pas le soucis. Et pour votre historique déjà bien pollué, un git rebase -i ou un git filter-branch permettra de virer les contributeurs parasites dans vos derniers commits. Mais après bonne chance si vos commits sont déjà sur des PR mergées chez d'autres. Là c'est mort...

Ce que les devs reprochent à Microsoft, c'est pas vraiment d'avoir créé l'option (elle existait depuis VS Code 1.110 en opt-in tranquille). Non, le vrai problème c'est surtout ce qu'il y a derrière cette vilaine Pull Request... 2 fichiers touchés, le change de "default", absolument AUCUNE description, une seule review d'approbation toute nulle, et hop, c'est mergé OKLM.

Pour un changement qui touche les messages de commit de plusieurs millions de devs, ça sent quand même la décision unilatérale prise à l'arrache entre 2 portes...

Et puis surtout il y a le bug #313064 qui a fait basculer l'histoire de la simple polémique à la grosse colère communautaire.

En effet, la nouvelle valeur par défaut "all" attribuait à Copilot des complétions qui ne venaient PAS de Copilot. Un dev explique par exemple avoir tapé son code à la main, vérifié son message de commit, supprimé toute suggestion Copilot, écrit le sien à la main... et a finalement retrouvé quand même Co-authored-by: Copilot dans le git log final.

Et comme le mode "je ne veux pas d'IA" n'était pas plus respecté, l'IA s'auto-créditait quand même sur tout et n'importe quoi.

Côté communauté, le ton est monté très vite. Sur le fil GitHub, y'en a un qui écrit que, je cite, "C'est pas une régression, c'est de la fraude. On ne peut pas s'attribuer un travail qu'on n'a pas fait." et un autre dev parle de "vandalisme" pur.

Windows Central a même sorti un titre choc : "This could cost people their jobs", parce que dans les boites en fintech ou sur du code soumis à audit, faire passer du code humain pour de l'IA-assisté peut coller un fail d'audit et faire péter des contrats. Ah bah ouais, j'avoue que je n'y avais pas pensé...

Heureusement, Microsoft a fini par bouger puisque dans VS Code 1.118, le default est finalement repassé de "all" à "chatAndAgent", déjà moins agressif. Et dans la PR #313931 , dmitrivMS a remis le default à "off" pour la version 1.119, dont le déploiement public commence justement aujourd'hui.

Bien sûr, la Product Manager a fait son mea culpa public, en reconnaissant, je cite que "la manière dont c'était implémenté et déployé n'a pas atteint le niveau de correction attendu", ce qui, dans la langue corporate, veut dire "on est des branleurs, déso, bisous".

Maintenant ce qui revient souvent dans les commentaires, c'est que Claude Code et Codex CLI font la même chose par défaut quand ils committent, sauf que la différence, c'est que ces agents committent quand C'EST EUX qui ont écrit le code, donc le co-author est tout à fait légitime.

VS Code, lui, modifiait des commits écrits à la main par des humains donc c'est pas du tout le même problème. Et pour le coup, sur Codex CLI la mention reste aussi désactivable via une option alors que chez Claude Code même si c'est pareil, l'opt-out n'est pas toujours très respecté d'après les retours que j'ai pu lire.

En tout cas, ce loupé arrive dans un climat déjà tendu puisque Microsoft pousse Copilot dans Windows, dans Notepad, dans Office, et même jusque dans l'écosystème Apple via une extension Xcode , dans tous les coins, et beaucoup de devs commencent à voir chaque nouveauté MS à travers ce prisme. La théorie du "ils gonflent les KPI Copilot pour les boards et les analystes" de plus en plus crédible et comme personne n'aime se sentir transformé en stat marketing, tout le monde commence à se barrer des outils et services Microsoft.

Maintenant, si vous voulez vraiment vous protéger des prochains coups foireux de M$, je vous propose d'abord de basculer sur VSCodium ou Zed , deux éditeurs sans télémétrie ni AI imposée. Et ensuite, déménager vos repos chez Codeberg ou Forgejo en suivant la procédure de migration que je vous donne dans cet article Patreon, comme ça même si Microsoft fait n'importe quoi côté éditeur, votre code n'est plus chez eux côté forge.

À voir maintenant si Microsoft tient ses promesses sur le consentement explicite avant toute mention d'agent IA, ou si on rejouera ce film encore et encore tous les 6 mois sur une autre fonctionnalité.

Edge - Les mots de passe en clair en mémoire, by design

Si vous utilisez le gestionnaire de mots de passe intégré à Microsoft Edge, et que vous le trouvez cool, hé bien accrochez-vous les amis, car Tom Jøran Sønstebyseter Rønning, chercheur norvégien en cybersécurité, vient de publier sur GitHub un PoC qui dump TOUS vos credentials en clair directement depuis la mémoire du processus du navigateur ! Et de ce que j'ai compris, Microsoft a l'air d'assumer ça tranquillou...

Et n'allez pas croire qu'activer "l'Authentification avant remplissage automatique" dans Edge règle le souci... Ça ne change absolument RIEN au problème, parce que les credentials sont chargés en clair en RAM dès l'ouverture du navigateur. Cette option bloque uniquement l'interface, et pas la mémoire. La seule vraie parade, c'est donc de basculer carrément vers un gestionnaire de mots de passe comme Bitwarden, KeePassXC, ou Mistikee car tant qu'ils restent verrouillés, ils ne chargent rien en mémoire.

Le PoC, baptisé EdgeSavedPasswordsDumper, tient en un seul fichier C#. Tom a choisi .NET Framework 3.5 plutôt qu'une version récente, parce que AMSI, l'Antimalware Scan Interface qui inspecte en temps réel le code .NET sous Windows, a une couverture vraiment réduite sur la 3.5 par rapport aux versions modernes. Du coup, le binaire passe plus facilement sous les radars des EDR et antivirus.

Maintenant, le truc, c'est que ce sujet n'est pas nouveau. En effet, en juin 2022, Zeev Ben Porat de chez CyberArk publiait déjà un papier détaillant exactement la même méthode appliquée à Chromium en général (et dont Edge découle...). Il utilisait les APIs Windows OpenProcess et ReadProcessMemory pour lire la mémoire privée des processus du navigateur et y récupérer URLs, logins, mots de passe et même cookies de session. Et à l'époque, Microsoft et Google avaient répondu en gros pareil, à savoir que c'était hors du "threat model", donc que c'était pas la peine de corriger.

Sauf que 4 ans plus tard, Tom Rønning n'arrivait pas à reproduire le dump sur Chrome avec la même méthode. En effet, le navigateur de Google semble charger ses credentials de façon plus granulaire (lazy loading, déchiffrement au besoin) plutôt que tout exposer en RAM dès l'ouverture. Alors que Edge, lui, n'a pas évolué et charge encore TOUS les credentials en clair dès le démarrage du navigateur, qu'on en ait besoin ou pas, et surtout les garde en mémoire tant que le processus parent tourne. Et c'est cette différence-là que Tom met en lumière avec son outil.

Après concernant la dangerosité de ce problème, faut que je nuance un peu tout ça car pour viser sa propre session Edge, l'attaquant n'a pas besoin d'être admin (un malware tournant sous votre compte y arrivera). Par contre, pour aller lire la mémoire des AUTRES utilisateurs sur la même machine, là, il faut les droits administrateur.

Et c'est surtout ce scénario que Tom met en avant dans son README. Il y parle d'un terminal server où plusieurs utilisateurs seraient connectés simultanément via RDP, et sur lequel un admin compromis pourrait dumper les mots de passe de tous les autres avec leur Edge ouvert, y compris les sessions déconnectées tant que le processus parent tourne. C'est assez spécifique quand même mais pas impossible évidemment...

Microsoft, contacté par Tom avant publication, a bien sûr répondu que le comportement était "by design"... Leur doc Edge enterprise explique même noir sur blanc que les attaques physiquement locales et les malwares sont hors du modèle de menace et qu'aucun navigateur n'est armé pour résister à un attaquant déjà infiltré dans le compte utilisateur.

C'est cohérent c'est vrai... Mais ça occulte un truc qui reste très "gênant" comme disent les ados. C'est que leur implémentation expose une surface d'attaque plus large que leurs concurrents basés sur le MÊME moteur Chromium. C'est pas normal....

Et côté communauté, ça n'a pas trainé non plus, puisque Whitecat18 sur GitHub a déjà sorti un portage Rust du PoC. C'est intéressant car Rust offre encore moins de surface AMSI que .NET 3.5 et se compile comme un binaire natif sans aucune dépendance. Donc pour un attaquant, c'est un upgrade de furtivité significatif... Et pour un défenseur, c'est surtout une raison de plus de pousser vos utilisateurs vers des vrais gestionnaires de mots de passe.

Concernant la divulgation responsable , Tom Rønning a fait les choses dans les règles : signalement à Microsoft, attente de la réponse officielle, présentation publique le 29 avril 2026 à BigBiteOfTech (l'évènement Palo Alto Networks Norway), puis publication du PoC.

Voilà... Microsoft persiste, Edge reste as-is (lumière !), et la sécurité de vos mots de passe est officiellement votre problème. Donc si vous utilisez Edge, je pense que ça vaut clairement le coup de migrer vers un gestionnaire externe... vous verrez, c'est pas la mer à boire.

Source

❌