Lors de la publication de ses résultats trimestriels, Microsoft a révélé que son système d'exploitation Windows 11 avait atteint ses objectifs plus rapidement que prévu.
Microsoft confirme avoir transmis des clés de récupération BitLocker au FBI, relançant le débat sur la confidentialité réelle des données chiffrées sous Windows.
Il y a quelques jours, je vous parlais d’un bug introduit par la mise à jour de janvier 2026 de Windows 11 (KB5074109), qui provoquait des plantages d’Outlook lorsque ses fichiers de données étaient stockés sur un service de stockage en ligne comme OneDrive. Plus largement, ce problème affectait aussi d’autres applications dès qu’elles tentaient d’accéder … Lire la suite
Microsoft : "Ah non on ne peut pas lire votre disque dur quand il est chiffré avec BitLocker !"
Also Microsoft : Donne au FBI des clés BitLocker qu'il a stockées.
(Sous Linux quand vous chiffrez votre disque avec LUKS, il n'y a que VOUS qui pouvez lire le disque. Un point c'est tout. Je dis ça, je dis rien.)
Ces derniers jours, de nombreux utilisateurs ont signalé un comportement inhabituel sous Windows 11 : le système refuse de s’éteindre et redémarre sans raison apparente. Ce détail, en apparence anodin, rend pourtant l’ordinateur pratiquement inutilisable . La bonne nouvelle, c'est que Microsoft a déjà préparé un correctif dédié et non planifié , conçu pour tout remettre en ordre sans attendre les mises à jour mensuelles habituelles. Microsoft a publié la mise à jour KB5077797 , un correctif déployé hors cycle , c'est-à-dire en dehors du calendrier habituel. Ce type de correctif est publié uniquement lorsque le système d'exploitation rencontre des problèmes suffisamment critiques pour justifier une mise à jour anticipée. Ce correctif résout deux problèmes distincts. Le premier concerne le Bureau à distance : certaines tentatives de connexion étaient rejetées même avec des identifiants corrects , bloquant ainsi l’authentification. La deuxième correction concerne la section Alimentation et batterie de Windows 11. Sur les appareils dotés de Secure Launch , un dysfonctionnement empêchait l'arrêt ou la mise en veille prolongée . Chaque tentative aboutissait toujours au même résultat : un redémarrage immédiat . Pour le moment, la mise à jour n'est pas encore distribuée via Windows Update ; la seule voie officielle pour l'obtenir est donc le Catalogue Microsoft Update . Sur la page dédiée à KB5077797, vous pouvez télécharger manuellement le package et choisir entre les versions x64 et Arm64 , selon votre appareil. L' apparition de nouvelles anomalies sur Windows 11 ne surprend plus personne, mais au moins cette fois-ci, la solution n'a pas tardé à arriver. (Lire la suite)
Windows 95 a marqué un tournant pour les systèmes d'exploitation de Microsoft et peut être considéré comme un logiciel révolutionnaire pour son époque. Or, il recèle des secrets qui ne sont dévoilés que des années plus tard. Windows 95 était un système qui devait jongler avec plusieurs réalités à la fois. D'une part, il prenait en charge les anciens programmes et applications DOS 16 bits de l'ère Windows 3.x, et d'autre part, il introduisait les applications modernes Win32 32 bits. Cela a contraint les développeurs de Microsoft à faire de nombreux compromis, mais a également permis de trouver des solutions originales. L'une d'elles était une fonction cachée de redémarrage rapide qui, dans certaines conditions, permettait au système de démarrer légèrement plus vite que la normale. Cette solution a été évoquée par Raymond Chen, un employé de longue date de Microsoft devenu célèbre pour ses articles sur les curiosités de Windows. Il expliquait que Windows 95 disposait d'une option de redémarrage rapide « cachée ». Il était possible de lancer cette fonction en maintenant la touche Maj enfoncée tout en redémarrant le système depuis l'interface graphique. Si tout se déroulait correctement, le bureau s'afficherait plus rapidement qu'au démarrage normal. Cette fonctionnalité ne fonctionnait pas toujours correctement. Parfois, au lieu de redémarrer plus rapidement, le système se bloquait ou plantait.
Ce mécanisme s'appuyait sur l'indicateur EW_RESTARTWINDOWS, transmis à la fonction ExitWindows 16 bits, héritée de Windows 3.1. L'appel de cette fonction déclenchait la séquence d'arrêt du système. Le noyau Windows 16 bits était arrêté en premier, puis le gestionnaire de mémoire virtuelle 32 bits, et enfin, tout revenait à la normale. Le mode réel est le mode de fonctionnement principal des processeurs x86, présent aussi bien dans les anciens systèmes Intel que dans les systèmes AMD actuels. Windows 95 a basculé le processeur du mode réel au mode protégé, permettant ainsi la gestion de la mémoire et des mécanismes de sécurité de base. Les systèmes 64 bits modernes utilisent un autre mode, appelé mode long, qui donne accès à l'ensemble des capacités de l'architecture 64 bits. Une fois le processeur passé en mode réel, le contrôle est revenu à win.com. Sa tâche consistait à redémarrer Windows 95 sans passer par une initialisation matérielle complète. Cela permettait théoriquement un démarrage plus rapide du système. Intel a un temps tenté de supprimer le mode réel et d'autres fonctionnalités de rétrocompatibilité de l'architecture x86S, mais l'idée a finalement été abandonnée. Cependant, à l'époque de Windows 95, ces fonctionnalités étaient indispensables pour assurer la compatibilité avec un grand nombre de logiciels anciens.
Le programme win.com était écrit en langage assembleur. Son rôle était de libérer toute la mémoire disponible et de créer un bloc unique et contigu, nécessaire au chargement de Windows en mode protégé. Si ce processus échouait, la mémoire resterait fragmentée et le système ne pourrait pas bénéficier d'un redémarrage rapide. Dans ce cas, win.com procéderait alors à un redémarrage complet de l'ordinateur. C’est pourquoi la fonction de redémarrage rapide ne fonctionnait que dans certains cas et était sujette à des erreurs. Chen souligne que cette instabilité était typique des systèmes Windows 9x, qui combinaient des solutions modernes à de nombreux mécanismes anciens. À une époque où le démarrage d'un système d'exploitation pouvait prendre plusieurs minutes, toute tentative pour raccourcir le processus était précieuse. Le redémarrage rapide caché de Windows 95 était l'une de ces expériences. Bien qu'il n'ait pas toujours fonctionné comme prévu, il illustre parfaitement la complexité et l'ingéniosité du système. (Lire la suite)
Je me souviens encore du lancement de Windows 95... c'est un sacré souvenir pour moi... J'avais suivi ça de très près et j'en rêvais même la nuit après avoir vu la pub. Puis cette musique "Start Me Up" des Rolling Stones, c'était cool quand même. C'était le futur !
Mais est-ce que vous vous souvenez de cette petite astuce de ninja qui permettait de redémarrer cet OS aussi vite qu'une baston dans un bar du 62 ???
J'suis sûr que non, mais moi je m'en souviens encore car sur ma machine, ça me changeait vraiment la vie. En fait, il fallait maintenir la touche MAJ enfoncée en cliquant sur "Redémarrer", et hop, au lieu de se taper tout le cirque du BIOS, Windows se relançait "presque" instantanément !
Et magie magie, le secret de cette sauce vient d'être raconté par l'inoxydable Raymond Chen, vétéran de chez Microsoft, et vous allez voir, c'est chouette !
En fait quand vous faisiez ce MAJ+Redémarrer, Windows envoyait un petit "flag" spécial baptisé EW_RESTARTWINDOWS au kernel 16 bits. Comme ça au lieu de dire à la machine de faire un "cold boot" (un redémarrage à froid quoi..), le système fermait gentiment le kernel. Et le gestionnaire de mémoire virtuelle avant de faire redescendre le CPU en mode réel.
Et c'est là que le fameux win.com reprenait la main puisqu'en recevant ce signal. Ça lui disait : "Hey gros, on ne s'arrête pas, on repart pour un tour !".
win.com essayait alors de remettre le système dans un état clean, comme s'il venait d'être lancé, sauf que pour relancer Windows en mode protégé, il fallait un gros bloc de mémoire contigu. Malheureusement, si vos logiciels avaient mis trop de bazar et fragmenté la RAM, l'astuce foirait et le PC finissait par faire un vrai reboot complet. Pas cool Raoul !
Par contre, si y'avait assez de mémoire contigu libre alors win.com relançait le VMM (Virtual Machine Manager) et l'interface graphique pouvait repartir sans repasser par la case départ. Un vrai exploit de champion quoi ! C'était pour l'époque une bidouille de génie car chaque seconde gagnée sur le chargement de l'OS était une grande victoire contre l'ennui !!
Chouette comme anecdote non ? Et si vous voulez
croquer encore plus de madeleines
et tester ça vous-même, y'a des outils comme
EmuOS
qui simulent tout ça très bien. Et pour les puristes, vous monter un petit
Dosbian sur Raspberry Pi
reste la base pour bidouiller de vieux kernels.
Bref, même trente ans après, ces entrailles pourries de nos vieux OS recèlent encore de plein de petits secrets passionnants !
Bon, on va pas se mentir, j’étais pas parti pour l’écrire cet article. Mais faut dire que j’ai un peu merdé dans les grandes largeurs pour le live, donc bon, sachant qu’en plus je traite d’un angle particulier de l’usage de ce cher Plakar, autant en faire un billet, ça sera le premier (et j’espère pas le seul) de 2026. On y croit ?
Plakar est une solution développée en France par une petite équipe apparemment friande des jeux de mots, puisqu’au delà de son nom même, le site est hébergé par la société Kandbaz. Voilà voilà…
Des confrères blogueurs ont déjà fait quelques présentations de l’outil (exemple: Adrien), principalement pour s’en servir sous Linux. Il se trouve que j’ai une machine Windows qui a besoin d’être sauvegardée, en vue d’une mise à jour de firmware de SSD qui devrait bien se passer, mais on doit toujours faire une sauvegarde avant de faire ce genre de choses. Mieux vaut prévenir que guérir comme on dit. Et la présentation en live aurait du se passer plus ou moins tranquille, mais bon, j’ai pas percuté la micro-coupure pendant plus d’une heure (habitué à ne pas avoir d’activité dans le chat), donc, je vous remet le processus sur « papier numérique ».
Je ne redétaille pas l’installation de Garage parce qu’on l’a faite en live sans souci.
Petit rappel rapide des caractéristiques de l’outil
On a donc un outil principalement en ligne de commande, qui repose sur un concept voisin de celui de Borg, qui nécessite la configuration d’un dépôt et propose un chiffrement natif des sauvegardes. Ce dépôt, local ou distant, peut être contacté de différentes manières, natives (SFTP/SSH) ou via des intégrations supplémentaires à installer au besoin. C’est le cas notamment du support S3.
Le setup
En soit, c’est très bien documenté : une fois l’outil installé, vous ajoutez le package directement, mais vous tombez sur un mur que je n’aime pas : créer un compte Plakar pour accéder aux intégrations. J’ai une petite idée de pourquoi ça peut avoir du sens (les intégrations concernent en général des solutions d’entreprise), mais ça me gonfle plus que profondément quand ça concerne des particuliers, qui se font déjà violer en permanence, donc pas la peine d’en rajouter (on a la même avec BitWarden, ou El Gato et son Stream Deck Marketplace pour l’intégration… d’OBS, qui est pourtant mis en avant comme native – c’est donc faux). Fort heureusement, l’outil propose de builder l’intégration depuis les sources qui sont disponibles sur Github, comme le reste des sources de l’outil, et ça sans création de compte. C’est facile… si on est sous Linux.
J’avoue que pour l’instant les installations sont un peu brutes de décoffrage, mais le support Windows est vraiment frais, donc je ne vais pas trop me formaliser là-dessus. Le fait que ça doit déjà proposé pour une version 1.0 est déjà assez cool. Par contre, concernant la compilation des intégrations, c’est plus ardu : il faut disposer de Go (dans la version qui est demandée par Plakar), de Make (à priori à part Chocolatey pas de moyen indépendant), et peut-être d’autres outils, mais je me suis heurté à un mur à cause de ça. La solution, comme d’hab’, aura demandé un pas de côté.
La cross compilation à la rescousse
Une des particularités de Go, c’est qu’on peut nativement compiler pour un autre système d’exploitation que celui sur lequel on se trouve. Et la chaine de compilation nécessaire est plus facile à déployer sous Linux; ça tombe bien, WSL est là pour ça. Après l’installation de la même version de Plakar que sous Windows, j’ai donc installé build-essential (pour être sûr d’avoir un max d’outils, donc Make), installé la version 1.24.12 de Go via asdf-vm (je vous renvoie vers la doc de Stéphane Robert qui a tout expliqué au sujet de cet outil trop pratique). Et pour la compilation d’un autre OS, c’est simple : on configure une variable d’environnement, GOOS, éventuellement l’architecture (oui, parce que c’est aussi possible), l’extension de fichier dans la variable EXT (parce que sous Windows, il faut un .exe pour qu’il soit exécutable – oui c’est débile en 2026, mais que voulez-vous, l’IA c’est plus intéressant à intégrer que moderniser un OS don personne ne voulait à la base) et on lance la compilation de l’intégration via la commande plakar ad-hoc. Vraiment, c’est aussi simple que ça :
$ export GOOS=windows
$ export EXT=.exe
$ plakar pkg build s3
info: fetching https://plugins.plakar.io/kloset/recipe/v1.0.0/s3.yaml
/usr/bin/make -C /tmp/build-s3-v1.0.7-161840773 EXT=.exe
3fe849cb: OK ✓ /manifest.yaml
3fe849cb: OK ✓ /s3Importer.exe
3fe849cb: OK ✓ /s3Exporter.exe
3fe849cb: OK ✓ /s3Storage.exe
3fe849cb: OK ✓ /
Plugin created successfully: s3_v1.0.7_windows_amd64.ptar
$ ls -l
.rw------- 1 42M seboss666 16 Jan 22:29 s3_v1.0.7_windows_amd64.ptar
On peut donc désormais copier le fichier ptar sous Windows (il faudra que je creuse ce format qui semble un peu maison), et on peut l’installer avec la bonne commande :
> .\plakar.exe pkg add ./s3_v1.0.7_windows_amd64.ptar
> .\plakar.exe pkg list
s3@v1.0.7
La sauvegarde ? Ben ça fonctionne
On peut donc attaquer le dur. J’ai juste suivi la doc de l’intégration, à savoir créer le kloset l’initialiser, et lancer le backup d’un dossier vers ce kloset là :
.\plakar.exe store add garage s3://192.168.1.201:3900/backup-pc access_key=<accesskey> secret_access_key=<secret_key> use_tls=false
.\plakar.exe at "@garage" create
repository passphrase:
repository passphrase (confirm):
.\plakar.exe at "@garage" ls
repository passphrase:
.\plakar.exe at "@garage" backup C:\\Users\\Seboss666\\Pictures\\blog
repository passphrase:
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/Firefox_groupe_onglets.png
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/Firefox_profils.png
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/docker-docker-everywhere.jpg
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/418-error-page.png
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/cross.svg
(...)
.\plakar.exe at "@garage" ls
repository passphrase:
2026-01-16T21:40:31Z e363f7fa 42 MiB 0s /C:/Users/Seboss666/Pictures/blog
Bonus, on peut vérifier l’état du backup depuis un autre PC, ou un autre OS, donc je suis retourné sur WSL, j’ai viré les variables d’environnement pour builder l’intégration pour Linux cette fois, et rebuildé/ajouté l’intégration. On reprend ensuite la même commande pour ajouter le Kloset, mais pas besoin de l’initialiser, on peut directement lister son contenu en fournissant la bonne passphrase :
$ plakar store add garage s3://192.168.1.201:3900/backup-pc access_key=<access_key> secret_access_key=<secret_key>
$ plakar at "@garage" ls
repository passphrase:
2026-01-16T21:40:31Z e363f7fa 42 MiB 0s /C:/Users/Seboss666/Pictures/blog
On peut donc faire à peu près ce qu’on veut dès lors : restauration complète ou partielle, création de nouveaux backups, etc.
Verdict
Donc oui, tout a fonctionné pratiquement du premier coup. J’ai quand même tâtonné au départ concernant le build de l’intégration, à vouloir « make » direct à partir du dépôt git. Mais dans ce cas, on se retrouve avec les trois binaires, sans infos sur la construction du fameux ptar (on est là encore dans le simili-jeu de mots, vraiment…), ce qui est plutôt dommage. Il m’aura fallu quelques minutes pour me résigner à utiliser plakar directement. Il faudrait aussi un peu plus de retour sur les commandes qui se déroulent bien (sans erreur). Autant quand on se plante, on le sait, mais quand on se plante pas, voir juste un retour à la ligne est un peu frustrant et déroutant.
Il y a question aussi sur les performances de la sauvegarde testée. j’ai testé sur un dossier de 108 images, et un des développeurs s’est étonné sur BlueSky du temps que ça a pris. J’avoue que pour l’instant, je n’ai pas creusé le sujet, il y a des chances que ça soit dû aux performances S3 elle-mêmes, à NTFS, une combinaison de tout ça. Garage est censé être performant, mais bon, on est sur un processeur ARM assez poussif quand même, qui doit déjà gérer le transfert réseau, donc on est pas à l’abri que ça soit un problème purement chez moi.
En tout cas, pour un jeune logiciel, la qualité de la documentation et l’implémentation Windows déjà opérationnelle (même si encore un peu buggée chez certains, en lien notamment avec les différences slash/antislash à cause de Windows), en bonus une interface web pour parcourir les backups, il m’a très agréablement surpris. On ne peut souhaiter que ça mature comme il faut et que l’entreprise trouve son équilibre (la stabilité financière et l’open-source, hein…). Et moi que je regarde d’un peu plus près le statut du live la prochaine fois (ou que je configure l’enregistrement en plus du stream)…
Windows 11 ne se contente pas de gagner de nouvelles fonctionnalités, il est aussi de plus en plus dysfonctionnel à chaque mise à jour. Microsoft a réussi l'impossible à cet égard. Cette fois-ci ne fera sans doute pas exception. Microsoft a confirmé qu'après l'installation de la mise à jour de sécurité de janvier, certains ordinateurs exécutant Windows 11 version 23H2 ne s'éteignent pas ou ne peuvent pas entrer en mode hibernation. Au lieu de s'éteindre, Windows 11 continue de fonctionner même si l'utilisateur clique plusieurs fois sur l'option d'arrêt. Bien que tout semble normal pour l'utilisateur, l'ordinateur reste inactif et continue de tourner, ce qui peut entraîner une décharge plus rapide de la batterie des ordinateurs portables. Selon Microsoft, ce bogue est lié à Secure Launch, un mécanisme de sécurité basé sur la virtualisation qui garantit que seuls les composants de confiance sont chargés lors du démarrage du système. Sur les appareils où le lancement sécurisé est activé, les tentatives d'arrêt, de redémarrage ou de mise en veille prolongée après l'installation des correctifs de janvier peuvent échouer. L'entreprise n'a pas communiqué le nombre exact d'ordinateurs concernés ni les détails concernant la cause de l'erreur.
D'après Microsoft, vous pouvez éteindre votre ordinateur en saisissant « shutdown /s /t 0 » dans l'invite de commandes. Cette commande force l'arrêt immédiat du système. En attendant la résolution du problème, l'entreprise recommande d'enregistrer votre travail et d'éteindre votre ordinateur de cette manière afin d'éviter de le laisser allumé et de consommer de l'énergie inutilement. Aucun correctif n'est disponible pour le moment. Microsoft indique seulement qu'une solution sera proposée dans une prochaine mise à jour. Ce n'est pas le seul problème apparu depuis le Patch Tuesday de janvier. Microsoft a également reconnu qu'Outlook pouvait se bloquer ou ne plus répondre après l'installation de la mise à jour pour les comptes POP. L'entreprise a par ailleurs indiqué qu'une enquête était en cours pour déterminer la cause du problème.
Le Patch Tuesday a pour but de corriger les failles de sécurité, même les plus graves ; il est donc fortement déconseillé de les ignorer. Cependant, les mois suivants montrent que, parallèlement aux correctifs, de nouveaux problèmes apparaissent également, ce qui peut s'avérer gênant pour certains utilisateurs. Finalement, nous nous habituons peu à peu à l'idée que les mises à jour système peuvent réserver des surprises indésirables. (Lire la suite)
Microsoft a déployé les mises à jour de sécurité de janvier pour Windows 11 et Windows 10 dans le cadre du programme de mises à jour de sécurité étendues (ESU). Ces correctifs étaient censés apporter des améliorations de stabilité et de sécurité, ainsi que de nombreuses fonctionnalités. Cependant, peu après leur installation, un nouveau problème a été signalé, affectant principalement les environnements professionnels utilisant l'infrastructure cloud de Microsoft. L'entreprise a confirmé l'existence de ce bogue dans le tableau de bord officiel Windows Release Health. Ce problème affecte certaines versions de Windows 11 et de Windows Server et se manifeste après l'installation de la mise à jour de janvier, KB5074109. Le problème signalé est dû à des invites d'authentification incorrectes lors de la tentative d'établissement de connexions Bureau à distance. Ces problèmes surviennent lors de la connexion aux services Windows 365 et Azure Virtual Desktop via des applications Windows. Les utilisateurs rencontrent des difficultés de connexion, les empêchant d'accéder à leurs espaces de travail hébergés dans le cloud. Microsoft n'a pas encore précisé l'étendue exacte du problème. L'annonce indique qu'il affecte certaines configurations système, et l'équipe Azure Virtual Desktop collabore avec l'équipe Windows Update pour effectuer un diagnostic.
En attendant la solution définitive, Microsoft recommande d'utiliser des méthodes alternatives pour se connecter aux bureaux distants. Vous pouvez notamment utiliser le client Bureau à distance Windows classique conçu pour Azure Virtual Desktop ou vous connecter via un navigateur web grâce au client web Windows disponible dans le service cloud de Microsoft. Ces solutions permettent de contourner le mécanisme d'authentification problématique des applications Windows, même si elles ne remplacent pas entièrement le scénario de travail standard de nombreuses organisations. La liste des plateformes concernées comprend Windows 11 versions 25H2 et 24H2, ainsi que Windows Server 2025, 2022 et 2019. Bien que Microsoft souligne que ce bogue affecte un groupe limité de clients, il s'agit principalement d'environnements d'entreprise qui utilisent intensivement le télétravail et les bureaux virtuels. D'autres doutes subsistent, notamment du fait que la mise à jour du Patch Tuesday de janvier pour Windows 11 incluait des correctifs relatifs à la connectivité RemoteApp dans les environnements Azure Virtual Desktop. L'apparition de nouveaux problèmes d'accès à distance laisse légitimement penser que ces correctifs ont peut-être, en corrigeant un problème, en en créant un autre. (Lire la suite)
Ce 13 janvier 2026, Microsoft a publié la mise à jour KB5073724 à destination des ordinateurs sous Windows 10 qui sont inscrits au programme Extended Security Updates (ESU). Pour rappel, depuis la fin du support officiel de Windows 10, seules les machines inscrites à ce programme reçoivent encore les mises à jour de sécurité mensuelles. … Lire la suite
Ce 13 janvier 2026, Microsoft a déployé la mise à jour KB5074109 à destination de tous les ordinateurs sous Windows 11 version 25H2 et Windows 11 version 24H2. Cette mise à jour mensuelle obligatoire apporte avant tout des correctifs de sécurité, avec pas moins de 114 vulnérabilités corrigées, mais aussi plusieurs corrections de bugs. En revanche, … Lire la suite
Microsoft a publié les mises à jour de sécurité de janvier 2026 pour Windows 10 et 11. Correctifs critiques, failles comblées et améliorations système sont au programme.