Il y a des chiffres qui en disent long sur l'état d'un logiciel, et celui-ci en fait clairement partie. Microsoft vient de corriger 570 failles de sécurité d'un seul coup lors de son dernier Patch Tuesday, ce rendez-vous mensuel où l'éditeur rebouche les trous de ses programmes, et jamais encore il n'avait sorti un paquet de correctifs aussi monstrueux, presque le triple d'un mois précédent qui battait pourtant déjà tous les records.

Le ménage s'étend à peu près à tout ce que la maison fabrique, de Windows à Office jusqu'aux gros serveurs qui font tourner les entreprises. Dans le lot se cachent trois failles particulièrement vicieuses, de celles que les pirates connaissaient et exploitaient déjà avant même qu'un correctif n'existe, dont deux servaient carrément dans de vraies attaques au moment de la publication. La plus inquiétante s'attaque au chiffrement qui protège le disque de votre PC, même si, rassurez-vous, il faudrait pour cela qu'un malandrin ait la machine physiquement entre les mains.

Mais le plus intéressant dans cette histoire n'est pas vraiment le score, c'est la manière dont il a été atteint. Microsoft a lâché son intelligence artificielle dans les entrailles de Windows pour y débusquer les bugs à la chaîne, et le résultat ne s'est pas fait attendre, puisque le compteur s'emballe désormais d'un mois sur l'autre. L'éditeur prévient même que ces montagnes de correctifs vont devenir la routine, et qu'il va falloir prendre l'habitude de voir passer des Patch Tuesday obèses quasiment tous les mois.

Pour vous, dans la pratique, rien ne change vraiment, il suffit d'ouvrir Windows Update, de tout installer sans se poser de question et de redémarrer sans traîner, d'autant que certaines de ces failles sont déjà activement utilisées quelque part. Voir une intelligence artificielle repérer les défauts plus vite que les ingénieurs humains a de quoi rassurer sur le papier, mais ça souligne surtout l'incroyable quantité de failles qui roupillaient tranquillement dans Windows depuis des années, sans que jamais personne n'aille les chercher.

Source : Bleeping Computer

Windows serait passé sous la barre des 60 % de parts de marché. C'est ce qu'on peut lire un peu partout dans la presse tech cette semaine. C'est StatCounter qui le dit avec précisément 56,61 % de Windows comptabilisé en juin 2026. Et juste en dessous, sur la ligne suivante du même tableau, il y a une case bien étrange qui s'appelle "Unknown" et qui est évaluée à 21,45 %. Presque 5 fois Linux ! Et ça, pas grand monde n'en parle...

StatCounter compte ce "Unknown" comme un OS, à côté de macOS, de Chrome OS, de Linux et même de la PlayStation, et si vous cliquez sur le petit bouton "Download" de la page Statcounter, le CSV que vous récupérez ne contient aucune case "Unknown". Le site recalcule tout sans elle et dans ce fichier, Windows remonte à 72 % de part de marché.

Du coup, je me suis demandé quelle était la bonne mesure pour connaître la part de Windows sur le desktop. Est-ce que c'est 56,61 % en comptant les visiteurs non identifiés comme un système d'exploitation, ou 72 % en ne les comptant pas. Si vous faites la division vous-même, 56,61 sur 78,55 (100 − 21,45 = 78,55) donne bien les 72 % du CSV.

Et là, si vous comparez avec l'an dernier, vous verrez qu'en juin 2025, Windows était à 70,13 % dans ce tableau, et "Unknown" à 9,17 %.

Et 12 mois plus tard, v'la ti pas que Windows perd un peu plus de 13 points et la case des non-identifiés en gagne 12. Étrange non ?

Les 2 courbes sont presque symétriques ( Source : StatCounter )

Mais la domination de Microsoft s'effrite quand même, car même sur la base ils sont passés de 77,22 % à ces 72 % en un an. Donc y'a bien une tendance, mais ça n'a rien de l'effondrement annoncé partout. Linux, lui, grimpe de 4,50 % à 5,59 % sur cette même base, et le gros gagnant de l'année, c'est Apple, qui passe de 16,90 % à 20,87 % !

Alors qu'est-ce qu'il y a dans cette case Unknown en réalité ? Et bien on ne le sait pas car StatCounter ne dit pas ce qu'il y a dedans. Mais sur Hacker News , les hypothèses tournent autour des scrapers d'IA qui n'envoient pas d'user-agent standard, des bots qui se déguisent en Windows, et des navigateurs qui brouillent votre empreinte .

Mais pour le moment, aucune n'est réellement prouvée. Ce qui est mesurable par contre, c'est que la case des inconnus gonfle... Nous sommes à peine en juillet 2026 et elle est déjà à 23,67 % de part de marché. Perso, ça m'intrigue plus que le podium Windows / Apple / Linux.

Après, le parseur de StatCounter s'est d'ailleurs déjà planté en beauté par le passé. En octobre 2025, il affichait Windows 7 à 9,61 % pour le mois de septembre, contre 0,88 % en juillet et suite à une résurrection / correction aussi miraculeuse que silencieuse, si vous allez regarder la même case aujourd'hui, vous y lirez 1,62 %.

Leur FAQ précise tout de même que les stats restent révisables durant 45 jours donc ces chiffres qu'on voit actuellement peuvent encore bouger jusqu'à la mi-août... On verra bien.

En tout cas, je suis content de voir que la poussée de Linux n'est pas une illusion. La plupart des jeux Windows tournent maintenant sous Proton , Windows 11 continue de refuser les machines trop vieilles , sans parler du fait que Windows 10 est mort et enterré depuis octobre 2025 (même si les rustines de sécurité de l'ESU tiennent encore la baraque jusqu'en octobre 2027...) donc vous avez tous de vraies raisons de bouger.

Bref, Windows baisse, Linux monte mais un cinquième du panel est devenu invisible, et ça c'est louche...

Source

Comme je vous le disais tout à l'heure, en avril 2026, le FBI a coincé un membre présumé de Scattered Spider. Le mec planquait son trafic derrière un VPN, avec des IP dans trois pays différents. Et devinez quoi ? Ce n'est pas une fausse manip qui l'a balancé mais un identifiant que votre Windows se trimballe H24 et que Microsoft refile aux autorités quand elles le demandent : le GDID. Je vous en ai déjà causé dans cet article , et après avoir écrit l'article, je me suis demandé si on pouvait le virer.

Du coup j'ai monté une petite VM Windows 11 Pro et j'ai mis les mains dedans en me faisant assister de mon LLM préféré et voilà ce que j'ai trouvé. Ce qui marche, et surtout ce qui ne marche pas du tout, vous allez voir.

Déjà, faut comprendre ce qu'est ce GDID. C'est pas le numéro de série de votre carte mère, c'est pas un hash en lien avec votre matos. Non, c'est un PUID de 64 bits, c'est-à-dire un identifiant que les serveurs de Microsoft collent à votre compte dès que vous ouvrez une session Windows. Il est écrit en clair dans votre registre, votre machine l'enregistre dans un annuaire côté Microsoft, et un service le fait remonter peinard quand c'est nécessaire. Et si vous changez d'IP avec un VPN, bah lui il s'en fout. Le GDID ne bouge pas d'un poil.

Regardez votre propre mouchard en face

On commence par le voir de nos yeux. Ouvrez un PowerShell et collez ça :

$lid=(Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID
"g:$([Convert]::ToUInt64($lid,16))"

Sur ma VM, ça m'a craché g:6755487812206045. C'est celui que Microsoft peut raccrocher à tout ce que je fais. (En théorie hein, parce que c'est le code qui est associé à ma VM, donc je m'en fous et c'est pour ça que je vous le montre).

Vous venez de lire l'étiquette qu'on vous a collée dans le dos.

Le supprimer ? Laissez tomber

Réflexe de base, on efface la clé dans la base de registres HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties et hop, plus de mouchard. C'est ce que j'ai testé au début... J'ai shooté la valeur, redémarré le service qui s'en occupe, et là plus rien. Gagné ? Ben non. J'ai ouvert le Microsoft Store durant deux petites secondes, et le GDID est revenu. Et pas un nouveau, hein, LE MÊME !!

C'est ça qui est fou. C'est que votre GDID n'est pas planqué sur votre disque, il est planqué chez Microsoft, bien accroché à votre compte comme une moule à son rocher. Votre PC ne fait que le retélécharger encore et encore. Après si vous réinstallez tout, Windows vous donne un nouveau numéro, d'accord, mais l'ancien et tout ce qui y était rattaché restent tout de même bien au chaud sur leurs serveurs. Le passé, on le récupère jamais...

Couper la télémétrie ne change rien non plus

Un autre conseil qu'on voit partout, c'est de désactiver la télémétrie de Windows. Sur ma VM, le service de télémétrie classique était déjà à l'arrêt. Et pourtant mon GDID était là, bien lisible, et les services qui le font remonter tournaient à plein régime. Le mouchard ne passe pas par la télémétrie que vous croyez couper. Il passe ailleurs, par les services de la plateforme d'appareils connectés et de l'optimisation de distribution.

Vous pouvez donc cliquer sur tous les boutons vie privée des réglages, il s'en tape.

Fermer le robinet pour de vrai

Alors puisqu'on peut pas l'effacer, on va faire la seule chose qui est en notre pouvoir : L'empêcher de sortir. Et sans se déconnecter du compte Microsoft, histoire de garder un PC utilisable, hein.

Et pour ça, on a 2 leviers. Le premier, c'est de désactiver les services qui enregistrent et remontent les infos de votre machine. Le second, c'est de renvoyer les serveurs de Microsoft dans le décor simplement via le fichier hosts, comme ça même si les services qui mouchardent tournent, et bien ils ne peuvent plus joindre personne... Et surtout, on ne touche pas à login.live.com, sinon adieu la connexion à votre compte.

Toutefois, il y a un petit piège, vous vous en doutez... Le service qui fait remonter le GDID, DoSvc, refuse de se laisser désactiver par la voie normale. Même en admin, Windows vous balance "Accès refusé". La parade, c'est donc de le désactiver direct dans le registre, où l'admin a le droit d'écrire là où le gestionnaire de services vous bloque.

Maintenant pour faire ça, plutôt que de vous mettre des tonnes de lignes de code à copier-coller, j'ai tout regroupé dans des scripts propres, que j'ai testés, avec une commande pour tout remettre comme avant.

Le projet est là : no-gdid sur GitHub . Vous lancez d'abord l'audit en lecture seule pour voir où vous en êtes, puis les scripts de blocage en mode aperçu, et seulement après avec l'option qui applique vraiment. Testez dans une VM avec un snapshot avant de faire ça sur votre vraie bécane, parce qu'on désactive quand même des services système. Et si vous voulez juste couper le réseau d'un process précis sans tout ce cirque, ce bon vieux ProcNetBlocker fait déjà une partie du taf.

Allez c'est parti mon canard !

Ouvrez un PowerShell en administrateur, et la première fois faites-le dans une VM avec un snapshot histoire de tester et de vous familiariser avec les commandes. Étape 1, on clone le projet :

winget install --id Git.Git
git clone https://github.com/Korben00/no-gdid
cd no-gdid

D'abord on regarde sa propre situation. Cet audit est en lecture seule, il ne modifie rien, il vous affiche juste votre GDID et quels services de la chaîne tournent :

powershell -ExecutionPolicy Bypass -File .\audit\Get-GDID-Audit.ps1

Ensuite on regarde ce que la mitigation changerait, sans rien appliquer. Sans l'option -Apply, les deux scripts tournent en mode aperçu et se contentent de lister ce qu'ils feraient :

powershell -ExecutionPolicy Bypass -File .\mitigate\Disable-GDID-Services.ps1
powershell -ExecutionPolicy Bypass -File .\mitigate\Block-GDID-Endpoints.ps1

Si ça vous va, on coupe pour de vrai. Cette fois on ajoute -Apply : les services qui enregistrent et remontent l'appareil sont désactivés, et les serveurs de Microsoft correspondants sont renvoyés dans le vide via le fichier hosts. Votre compte Microsoft, lui, reste connecté :

powershell -ExecutionPolicy Bypass -File .\mitigate\Disable-GDID-Services.ps1 -Apply
powershell -ExecutionPolicy Bypass -File .\mitigate\Block-GDID-Endpoints.ps1 -Apply

Et pour tout remettre comme avant, une seule commande :

powershell -ExecutionPolicy Bypass -File .\mitigate\Revert-GDID.ps1

Une fois appliqué, tout redeviendra calme... les services d'enregistrement seront à l'arrêt, leurs serveurs injoignables, et votre compte Microsoft restera toujours connecté. Le GDID reste bien évidemment lisible sur le disque, mais il ne remontera plus chez Microsoft.

La vérité qui pique

Après, je ne vais pas faire un tuto qui vous vend du rêve. Ces manips réduisent ce que Microsoft pourra corréler à l'avenir mais elles n'effacent pas votre GDID, qui traîne sur leurs serveurs depuis votre toute première connexion, et elles ne vous rendent pas anonyme. Ensuite, passer en compte local comme j'ai pu le lire ailleurs supprime le chemin qu'on vient de bloquer, mais rien ne prouve encore qu'un identifiant anonyme ne prend pas le relais derrière.

La seule vraie parade solide pour une activité sensible, est plus brutale : ne pas faire cette activité sous Windows. Un Linux live par exemple offre un contrôle total de ce qui sort de votre machine. Le reste, c'est que de la réduction des dégâts, rien de plus.

Voilà, défendre sa vie privée, ça commence par savoir ce qu'on vous colle sur le dos et maintenant vous le savez. Pas merci Microsoft.

Source : The Register et le reverse engineering de SmtimesIWndr .

Putain, c'est abusé, vous allez voir ! Peter Stokes, 19 ans, accusé d'appartenir au groupe Scattered Spider, enchaînait les VPN et changeait de pays pour brouiller les pistes mais le FBI l'a quand même coincé. Et vous savez grâce à quoi ?

Hé bien grâce à un petit numéro planqué dans son Windows. C'est Microsoft qui l'a mouchardé aux enquêteurs et ça a suffi pour le relier à une intrusion malgré tous ses VPN.

Et alors me direz-vous, vous aussi vous avez un numéro sur votre machine qui peut servir à vous identifier... Ce truc s'appelle le GDID, pour Global Device Identifier et c'est un identifiant unique qui est attribué lors de chaque installation de Windows. Il sert à la télémétrie, au rapport de plantage, à la vérification des licences et surtout il reste constant même après des mises à jour.

Vous ne le voyez jamais, vous ne l'avez jamais choisi, et il ne bouge pas d'un poil quand vous changez d'adresse IP. Normal, un VPN protège la couche réseau, mais pas ce que laisse fuiter votre OS. Et ça on l'apprend dans la plainte de 39 pages qui a été rendue publique début juillet, où elle expliquait comment Microsoft a fourni au FBI l'historique des adresses IP rattachées à ce GDID précis.

Les enquêteurs n'ont eu qu'à croiser ça avec les comptes perso de Stokes, de son compte Apple à ses comptes de gaming, en passant par Snapchat et Facebook, pour finalement découvrir des adresses IP à Tallinn, New York, ou encore la Thaïlande, ce qui correspond exactement à ses déplacements.

Le mec pouvait empiler 10 VPN s'il le voulait, Microsoft le suivait à la trace quand même. Et c'est là que ça me hérisse le poil, parce que le problème, ce n'est pas que la justice ait serré un type accusé d'avoir extorqué des millions. Ça, c'est le boulot du FBI, et tant mieux s'ils l'ont arrêté.

Non, le vrai problème, c'est que Microsoft dispose d'un identifiant permanent sur plus d'un milliard de machines, qu'ils ne communiquent pas dessus, qu'ils le partagent tranquille sur demande, et qu'on ne peut même pas le désactiver.

Alors on fait quoi ? Bah déjà, on arrête de subir. Vous pouvez installer Windows 11 sans compte Microsoft pour couper une partie de la laisse, désactiver la télémétrie facultative pour limiter les autres fuites, ou carrément regarder du côté d'une stack privacy européenne . Aucune de ces astuces ne touchera au GDID par contre, car il n'y a aucun bouton pour ça, et c'est bien ça le fond du problème.

Mais bon, j'imagine que des petits malins vont sortir des logiciels qui vont permettre soit de désactiver ce numéro ... Et là, vous pourrez compter sur moi pour que je vous le partage. Quoi qu'il en soit, quand vous utilisez Windows, gardez juste en tête que vous n'êtes jamais vraiment seul. Et que quelqu'un vous épie en permanence... Brrrr.

Source

Vous vous souvenez de Windows Movie Maker ? Mais siiii, ce petit logiciel de montage livré avec les Windows depuis l'époque de Windows ME ? C'est celui sur lequel vous avez bricolé vos premiers diaporamas de vacances avec des transitions en forme d'étoile. Aaah, ça vous parle maintenant, hein ?

Eh bien, ces gros méchants de Microsoft l'ont laissé mourir en janvier 2017. Mais heureusement, SkylerDaGirl vient de le remettre au goût du jour et vous pouvez maintenant télécharger un installer fonctionnel sur Internet Archive qui va vous permettre d'installer la V6.0.

Le site Windows Latest l'a testé et apparemment c'est incroyable parce que Movie Maker s'est contenté d'une vingtaine de Mo de RAM alors que son remplaçant officiel, Clipchamp, lui, en réclamait près de 800 Mo pour faire globalement la même chose. D'après les captures d'écran du testeur, ça fait à peu près 97% de mémoire en moins pour l'ancêtre. Une fois encore, ça prouve que les logiciels modernes sont comme nous, ils grossissent au fil des années...

Maintenant, si vous cherchez plutôt du léger côté navigateur, il y a d'ailleurs des alternatives modernes comme Cutia ou Pikimov qui tournent sans installer une usine à gaz.

Après, je ne vous conseille pas non plus de passer sur Windows Movie Maker, parce que déjà, ce n'est pas un logiciel supporté officiellement par Microsoft. Ces derniers n'ont absolument rien ressuscité. Et puis ces fameux 97%, c'est une mesure qui a été réalisée par un seul testeur et pas vraiment un benchmark qu'on peut reproduire. Donc bon, vous pouvez essayer, mais il n'y a aucune promesse.

Et surtout, gros panneau ACHTUNG ACHTUNG côté sécurité puisque ce build n'est plus supporté par Microsoft depuis neuf ans, donc zéro correctif, zéro garantie sur ce que contient réellement l'installeur.

M'enfin, ceux qui aiment gratter la nostalgie apprécieront ce portage et également l'effet VHS de ntsc-rs pour donner à vos exports ce grain d'époque qui va bien avec l'esthétique Movie Maker ^^.

Source

Bon, j'avoue que j'ai un petit peu lâché l'affaire pour mon summer body. Avec cette canicule, je suis à deux doigts de me faire une raclette. Par contre, s'il y a un truc dont je ne supporte pas qu'il grossisse, c'est bien mon système d'exploitation.

Et pourtant, si vous êtes sous Windows 11, eh bien c'est le cas ! Celui-ci se remplit tout seul sans explication, en tout cas jusqu'à maintenant, parce qu'on tient enfin le coupable !! C'est un fichier caché qui grossit dans son coin depuis des mois et des mois et Microsoft vient enfin de reconnaître le bug et de le corriger. Donc je vous explique tout...

Le fautif s'appelle CapabilityAccessManager.db-wal, planqué dans le dossier C:\ProgramData\Microsoft\Windows\CapabilityAccessManager et derrière ce nom barbare se cache en réalité le log d'une petite base de données SQLite, celle qui note chaque fois qu'une application réclame l'accès à votre webcam, votre micro ou votre position. Normalement ce fichier pèse quelques dizaines de kilo-octets et se vide tout seul, sauf que pas de bol, une mise à jour de Windows a cassé ce petit ménage automatique et donc notre journal enfle chaque jour un peu plus sans jamais se compacter. Alors vous pourriez vous dire que c'est pas très grave, mais il grossit quand même de deux giga par jour ce sagouin.

Résultat, des utilisateurs ont vu ce fichier grimper à 70 Go, 110 Go, 200 Go, et le record documenté monte à 513 Go. Le "500 Go" des gros titres, c'est donc le cas extrême, pas la moyenne mais même à 50 ou 100 Go engloutis en douce, ça suffit à saturer un SSD et à ralentir toute la machine. Plusieurs personnes ont aussi remarqué un Wi-Fi qui traîne, un effet de bord du même souci.

La bonne nouvelle maintenant, c'est que Microsoft a fini par corriger le tir avec la mise à jour optionnelle KB5095093 du 23 juin dernier, qui nettoie même le fichier gonflé au redémarrage et vous rend l'espace perdu d'un coup. Et le correctif deviendra obligatoire pour tout le monde lors du Patch Tuesday de juillet. Si vous ne l'avez pas encore, direction Windows Update, options avancées, puis les mises à jour facultatives.

Et si c'est trop tard, et que votre disque est déjà plein à ras bord et que vous voulez récupérer la place immédiatement, vous pouvez supprimer le fichier à la main. Attention quand même, il faut d'abord arrêter le service concerné, sinon le fichier reste verrouillé et la suppression échoue.

Dans un PowerShell en administrateur :

net stop camsvc
del "C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.db-wal"

Supprimez uniquement le fichier terminant par .db-wal, surtout pas le .db juste à côté. Un redémarrage plus tard, le service repart proprement et le fichier repart de zéro. Si vous croisez du Dell SmartByte ou d'autres bloatwares du genre sur un portable, virez-les aussi, ils font partie des déclencheurs connus.

Pour le reste, si vous avez la manie du disque bien rangé, c'est le bon moment pour un grand ménage de printemps avec BleachBit , jeter un œil à ces astuces quand Windows rame , ou carrément partir sur un Windows 11 allégé façon tiny11 .

Bref, voilà, si votre espace disque a fondu ces derniers mois sans raison, vous savez maintenant où regarder.

Source

Nomlings, c'est un Tamagotchi qui vit à côté de votre terminal, et dont la seule nourriture, ce sont les tokens que crament vos sessions Claude Code. Vous bossez, il mange. Vous glandez, il patiente.

Et pendant que vous regardez votre usage fondre comme neige au soleil, bah lui il se régale !!

La bestiole s'appelle un Munchling, un "tokivore" quoi, qui s'affiche sur un écran de 64 pixels et chaque tâche terminée lui rapporte +10 XP et un snack.

Quand un outil plante, il fait la gueule et quand Claude attend une réponse de votre part depuis un moment parce que vous êtes parti vous refaire un café, il vous alerte pour que vous reveniez bosser. Bref, c'est une créature en pixels qui vous fera culpabiliser de procrastiner, ce qui peut-être pas mal quand on est un indé à son compte et grosse feignasse en même temps ^^.

Derrière tout ça, le soft digère en réalité les événements de vos sessions, en se branchant sur les hooks officiels de Claude Code (SessionStart, PostToolUse et Stop), qui transitent uniquement en local. Si l'app n'est pas lancée, ces hooks ne font strictement rien, donc aucun ralentissement à craindre. Ça marche un peu comme Notchi pour ceux qui connaissent.

Côté élevage, votre Munchling démarre donc dans un œuf et évolue jusqu'à l'âge adulte, en gagnant d'abord une antenne, puis une deuxième (la classe ^^). Il reçoit un goûter à chaque tâche terminée, plus un snack qu'il part fourrager tout seul toutes les 30 minutes, même app fermée, avec un maximum de 5 en réserve. Y'a aussi un bouton FEED qui vous laisse le nourrir quand il fait les yeux doux. Et rassurez-vous, contrairement au Tamagotchi de votre enfance retrouvé mort au fond du cartable, celui-là ne peut pas mourir !

Ah vous n'utilisez pas Claude Code ?

Pas grave, y'a un mode companion prévu pour vous. Dans ce mode, le serveur de hooks et le watcher de transcript ne démarrent jamais, et rien n'est écrit dans votre ~/.claude. La bestiole se nourrit à la place des tâches que vous effectuez et des interactions que vous déclenchez dans Nomlings. Par exemple, cocher une tâche rapporte +10 XP et un snack, exactement comme une session Claude. Ça me rappelle Codachi, ce Tamagotchi qu'on adopte dans VSCode pour coder moins seul, sauf qu'ici pas besoin d'éditeur particulier.

En tout cas, c'est rigolo et c'est gratuit, sauf si vous optez pour le pack cosmétique qui débloque 9 espèces supplémentaires (dragon, poussin, fantôme, robot, grenouille, abeille…), ainsi que 9 coques pour habiller le boîtier et des couleurs à choisir librement.

Maintenant, reste LE point qui fâche : pour l'instant, Nomlings tourne uniquement sous Windows. Ouais désolé, c'est la vie !

Bref, si vous pensez que tous les tokens que vous cramez sur Claude Code méritent une fin plus glorieuse qu'un simple compteur qui vous fout la pression, c'est par ici que ça se passe.

Honnêtement, avec la puissance actuelle de nos LLM, finalement, est-ce qu'on a encore besoin d'avoir des applications ?

Un outil type Claude Code ou Microsoft Copilot, à côté, un gros tas de données diverses et variées, quelques accès à des services et basta ! C'est peut-être ce vers quoi on se dirige, à notre grand détriment...

La preuve avec cette vidéo qui traîne sur le Discord de BetaWiki, tournée en 2024 et dont Microsoft ne dit mot. Des sources internes ont authentifié le clip pour le compte de Windows Central , le site qui a sorti l'affaire en premier. Dedans, un prototype d'OS baptisé Project Aion, où Copilot remplace le menu Démarrer, la barre des tâches et tout le shell classique. Il n'y a plus d'applications à lancer comme d'habitude mais une simple boîte de dialogue pour piloter votre machine, et c'est à peu près tout.

J'sais pas si vous avez remarqué mais autant sous iOS on peut mettre une authentification Face ID sur n'importe quel app, autant sous MacOS, on peut certes verrouiller tout son ordi, mais on ne peut pas locker une app en particulier.

Et c'est chiant parce que parfois, on doit laisser son ordi à un collègue, un enfant ou PIRE sa mère, et ils ont alors accès sans restriction à vos Messages, vos Photos, votre gestionnaire de mots de passe , votre boîte mail et j'en passe des vertes et des pas mûres...

Dweep Desai, un développeur qui s'est visiblement retrouvé dans cette galère, a heureusement sorti FaceGate , un petit utilitaire open source tiers qui ajoute enfin du verrouillage par application sur macOS, avec déverrouillage à la trombine !

curl -fsSL https://raw.githubusercontent.com/dweep-desai/FaceGate-Mac/main/install.sh | bash

Microsoft vient de lâcher un truc qui va faire plaisir à tous ceux qui bidouillent fort des conteneurs Linux depuis leur machine Windows. Ça s'appelle WSL Containers (WSLC pour les intimes, et pas WSL 3) et l'objectif c'est de faire tourner des conteneurs Linux nativement sous Windows sans avoir à passer par des outils tiers du genre Docker.

Pour en profiter, tapez la commande suivante :

wsl --update --pre-release

Cela mettra à jour votre WSL en version 2.9.3 ou supérieure et vous obtiendrez alors une toute nouvelle commande : wslc.

WSLC est un alias qui lance en réalité container.exe et qui permet de gérer tout le cycle de vie d'un conteneur Linux avec des commandes très classiques : run, stop, build, tag, push, pull, prune. Voici un vrai exemple tiré de la doc de Microsoft :

wslc run -d --name=webtop -e PUID=1000 -e PGID=1000 -e TZ=Etc/UTC -p 3000:3000 -p 3001:3001 lscr.io/linuxserver/webtop:ubuntu-kde

Ce qu'on lance là c'est bien une image en provenance de LinuxServer dont je vous ai déjà parlé, et comme vous pouvez le voir, vous ne serez pas dépaysé si vous connaissez déjà un peu Docker.

La GameCube, on la connaît pour avoir fait tourner la meilleure version de Smash Bros et pour son look de petit cube vaguement "rectangulaire". Mais on ne la connait pas vraiment pour faire tourner un système d'exploitation de bureau du milieu des années 90.

Et pourtant, une bande de bidouilleurs emmenée par Rairii (alias Wack0), épaulé par NTx86 et stonedDiscord, s'est amusée à virer les jeux pour loger un vrai Windows NT là-dedans. Oui, le vrai NT de Microsoft.

Merveilleux non ?

Et le plus beau, c'est que ce n'est même pas de l'émulation, c'est carrément un portage natif. Le truc que j'ignorais, c'est qu'à une époque Microsoft avait sorti une version PowerPC de Windows NT, du temps où le système supportait encore des architectures un peu exotiques. Or la GameCube tourne justement sur un processeur PowerPC, le fameux Gekko.

Les deux étaient donc faits pour se rencontrer, et il ne manquait qu'un type assez taré pour les marier. Le projet s'appelle entii-for-workcubes , et il ne s'arrête pas à la GameCube. Vous pouvez aussi le booter sur une Wii, sur une Wii Mini (qui réclame quand même un petit hardmod pour la carte SD), et même dans le mode vWii de la Wii U.

Petit retour en arrière quand même pour les plus jeunes... Dans les années 90, Windows NT n'était pas du tout le truc Windows-x86-only qu'on connaît aujourd'hui. Il tournait sur MIPS, sur DEC Alpha, sur PowerPC, parce que Microsoft voulait un OS portable, qui ne soit pas marié à un seul fabricant de puces. L'histoire a tranché en faveur du x86 et tout le reste est tombé dans l'oubli. Sauf que ces vieux binaires PowerPC existent toujours, et c'est ce qui rend ce hack possible 25 ans plus tard.

Une seule petite ligne de code envoyée au mauvais endroit pouvait transformer un Surface Laptop en bloc de métal inutilisable. C'est sur cette faille que Microsoft a discrètement travaillé pendant trois mois, avant qu'elle ne soit rendue publique le 12 juin.

L'histoire commence de façon assez improbable. Jack Darcy, un chercheur en sécurité australien, a demandé à Microsoft Copilot (l'assistant IA intégré à Windows) de régler le rétroéclairage de son écran, rien de dingue donc. Bien gentil, Copilot écrit tout seul un script Python, l'exécute, et la paf, il rend l'ordinateur totalement inopérant. Plus de démarrage, plus d'accès au BIOS, rien, queudalle.

En creusant, Darcy comprend ce qui vient de se passer. Le script a écrit n'importe quoi dans le firmware du SAM, le Surface Aggregator Microcontroller, cette petite puce qui coordonne le matériel sur les Surface : alimentation, ventilateurs, clavier, capteurs. Une fois sa mémoire corrompue, la machine ne sait tout simplement plus démarrer.

Le problème de fond, c'est que cette puce n'avait aucun garde-fou. Elle acceptait n'importe quelle valeur en écriture sans vérifier si elle avait le moindre sens. Pire, les commandes de lecture et celles d'écriture partageaient la même numérotation, ce qui rendait toute exploration prudente impossible. "Vous ne pouvez littéralement pas scanner deux commandes qui se suivent sans une chance sur deux de tomber sur une commande d'écriture", résume Darcy.

Du coup, un seul paquet expédié pouvait griller la carte mère pour de bon. Aucune réparation logicielle, aucune réinitialisation d'usine, aucun accès USB de secours : direction le remplacement complet de la carte mère, soit plusieurs centaines d'euros.

Tout n'est pas si noir quand même. Pour déclencher la catastrophe, il fallait déjà disposer des droits administrateur sur la machine et avoir désactivé Secure Boot et Secure Core, les deux protections activées par défaut sur les Surface. Autrement dit, un parc d'entreprise géré normalement ne risquait rien, et les seules machines réellement exposées étaient celles des bidouilleurs tournant sous Linux, en configuration gaming allégée ou avec des pilotes maison.

Les modèles concernés vont du Surface Laptop 3 au Surface Laptop 6 et du Surface Book 1 au Surface Book 3. Les Surface Go semblent épargnés, et les versions ARM n'ont pas été testées.

Côté correctif, Microsoft a plutôt bien joué le jeu. Prévenu le 10 mars, l'éditeur a reconnu le défaut puis déployé des mises à jour de firmware via Windows Update dès le mois de mars, si bien que la grande majorité des appareils touchés sont désormais protégés. Darcy a récupéré un Surface tout neuf pour le dédommager.

Un point chiffonne quand même. Microsoft a refusé d'attribuer un CVE, l'identifiant officiel qui répertorie une faille de sécurité, estimant que le bug "n'atteignait pas le seuil" requis. Pour un défaut capable de tuer une machine de façon irréversible, l'argument laisse songeur.

Pour la suite, Redmond mise sur le langage Rust, réputé pour empêcher ce genre de débordements mémoire. Le firmware embarqué est en cours de réécriture intégrale, baptisée "Secure EC", tout comme une partie de l'UEFI sous le nom de "Project Patina".

Bref, un Copilot qui brique tout seul le PC sur lequel il tourne, voilà une démo involontaire dont Microsoft se serait bien passé.

Source : The Register