Pendant plusieurs années, les utilisateurs de Windows ont vécu avec une bizarrerie aussi frustrante qu’incompréhensible : cliquer sur « Mettre à jour et arrêter » n’arrêtait pas toujours l’ordinateur. Au lieu de cela, le système redémarrait sournoisement pour finaliser les mises à jour avant de s’éteindre — un comportement souvent perçu comme une trahison logicielle. Avec la mise à jour 25H2 de Windows 11, Microsoft vient enfin de corriger cette anomalie. Et derrière cette correction en apparence mineure se cache une véritable refonte de la logique du système d’exploitation. À partir de Windows 11 25H2 Build 26200.7019 (ou 26100.7019 sur 24H2) et des versions plus récentes, votre PC s'éteindra enfin lorsque vous choisirez explicitement « Mettre à jour et éteindre ».
Pour quiconque a utilisé Windows depuis au moins Windows 10, la scène est familière : en fin de journée, on sélectionne « Mettre à jour et arrêter », l’écran s’éteint, et l’on quitte le bureau avec soulagement. Le lendemain, surprise : l’ordinateur s’allume tout seul dans la nuit, ou démarre automatiquement pour « terminer les mises à jour ». Ce comportement était lié à la manière dont Windows gérait historiquement le cycle de mise à jour du système : même lorsque l’utilisateur choisissait « Arrêter », Windows forçait un redémarrage complet afin d’appliquer certains composants critiques avant extinction.
La conséquence ? Des ordinateurs rallumés sans consentement, des laptops déchargés, et une incompréhension totale du sens du mot « arrêter ». Sur les forums Microsoft et Reddit, des milliers d’utilisateurs s’en plaignaient encore ces dernières années.
La mise à jour 25H2 : une correction discrète mais symbolique
Le correctif intégré à la build 25H2 de Windows 11 modifie profondément cette séquence. Désormais, lorsque l’on sélectionne « Mettre à jour et arrêter », le système applique les correctifs en tâche de fond, puis s’éteint sans passer par le cycle de redémarrage. En d’autres termes, la commande fait enfin ce qu’elle promet.
Microsoft indique que cette amélioration s’inscrit dans un ensemble plus vaste de changements apportés à la gestion de l’énergie et du service Windows Update. L’entreprise affirme avoir réécrit certaines parties du code responsable de la planification des mises à jour et de la gestion des dépendances système, afin que les redémarrages ne soient plus systématiques.
Selon les rapports des utilisateurs, les plaintes concernant ce bug remontent à 2021 sur les PC équipés de Windows 11 et Windows 10 (la date de sortie de ce système remonte à 2015). Bien sûr, les utilisateurs peuvent toujours éteindre manuellement leur PC à l'aide du bouton d'arrêt normal, mais le comportement parfois erratique du système d'exploitation a irrité les utilisateurs.
Microsoft n'a pas expliqué la cause de cette erreur. Cependant, les utilisateurs ont émis l'hypothèse que cela était dû au fait que le PC avait besoin d'être redémarré pour finaliser les mises à jour logicielles, ce qui pouvait entraîner le PC à ignorer par erreur la commande d'arrêt.
Sous Windows 11, téléchargez la mise à jour facultative KB5067036 dans Paramètres > Mise à jour et sécurité > Windows Update. Microsoft a également déclaré à qu'elle prévoyait de déployer un correctif général pour ce bug avec son Patch Tuesday du 11 novembre, qui devrait se télécharger automatiquement. Microsoft a mis fin au support de Windows 10, sa prolongation d'un an ne couvrant que les mises à jour de sécurité.
Un correctif qui ne fait pas oublier les désastres récents
L’objectif initial de la mise à jour 25H2 semblait banal : améliorer la compatibilité matérielle, renforcer la sécurité des pilotes et préparer le terrain pour les futurs PC dits “AI PCs”. En réalité, elle a plongé une partie des utilisateurs dans l’impossibilité totale d’utiliser les fonctions de dépannage de Windows.
Depuis le déploiement du correctif en octobre, de nombreux messages affluent sur les forums officiels de Microsoft et dans les forums spécialisés. Tous décrivent le même scénario : après installation, si Windows rencontre un problème et que l’utilisateur tente d’ouvrir le mode de récupération, aucun périphérique USB n’est reconnu. Le curseur reste immobile, les touches muettes, et le système de secours devient inutilisable.
Ce bug, apparemment lié à une mise à jour des pilotes HID (Human Interface Device) intégrés au noyau de WinRE, empêche toute interaction humaine avec l’environnement de réparation. En d’autres termes, le seul outil censé sauver Windows en cas de défaillance a été désactivé par Windows lui-même.utilisateur
Pareil pour moi... Le clavier et la souris ont cessé de fonctionner après la dernière mise à jour (pré-25h2) en mode de récupération. Tout fonctionnait correctement avant la dernière mise à jour. Pensant que cela venait peut-être de mon combo sans fil, j'ai débranché tous les périphériques USB, branché un clavier/une souris filaires, redémarré Windows, appuyé sur SHIFT-RESTART, mais le clavier et la souris ne fonctionnaient toujours pas...
J'ai raté « l'ancienne » touche F8 lors du démarrage pour passer en mode sans échec...
autre utilisateur
J'ai essentiellement le même problème. Après la dernière mise à jour, mon ordinateur de bureau démarrait jusqu'à l'écran de connexion, mais la souris et le clavier ne fonctionnaient pas, ce qui m'empêchait de saisir le code PIN pour accéder à Windows. J'ai redémarré et j'ai pu accéder au mode sans échec, mais la souris et le clavier ne fonctionnaient pas non plus dans ce mode. J'ai donc dû éteindre trois fois l'ordinateur et passer en mode de récupération, puis en démarrage avancé, afin de désinstaller la dernière mise à jour, ce qui a permis au clavier et à la souris de fonctionner à nouveau. Je me suis immédiatement connecté et j'ai suspendu les mises à jour. Je ne sais pas quel est le problème, peut-être s'agit-il d'une isolation du noyau où Windows bloque un ancien pilote et ne le laisse pas se charger pour l'USB.
Le Recovery Environment : un pilier vital devenu inopérant
Le Windows Recovery Environment (WinRE, environnement de récupération Windows) est un ensemble d'outils de dépannage intégrés à Windows pour réparer les problèmes qui empêchent le système de démarrer correctement. Il permet de lancer des options comme la réparation au démarrage, la restauration du système, la réinitialisation de l'ordinateur, l'accès à l'invite de commande et le mode sans échec. WinRE peut être lancé en passant par les paramètres de Windows ou en maintenant la touche Maj enfoncée tout en redémarrant l'ordinateur
Dans le cas présent, WinRE se lance bien… mais ne détecte plus les périphériques d’entrée USB.
Les conséquences sont dramatiques. Sans clavier ni souris, impossible de naviguer dans les menus de restauration ou de saisir le mot de passe BitLocker. Même les utilisateurs avancés, capables d’utiliser l’invite de commandes pour restaurer le système, se retrouvent bloqués avant même de pouvoir taper la moindre commande.
Certains ont trouvé des solutions de fortune : connecter un ancien clavier PS/2 (quand leur carte mère dispose encore du port), utiliser un hub avec compatibilité BIOS, ou créer un support de récupération externe sur un autre ordinateur. Mais pour l’immense majorité, c’est un mur infranchissable.
Le bug ne se limite pas à un périphérique ou un constructeur précis : tous les claviers et souris USB semblent concernés, qu’ils soient sans fil, Bluetooth avec dongle, ou câblés.
Le symptôme d’un modèle de mise à jour défaillant
Ce n’est pas la première fois qu’une mise à jour de Windows 11 provoque des dégâts. Ces derniers mois, des patchs ont successivement entraîné des ralentissements de SSD, des plantages réseau, des pannes Bluetooth, voire des conflits avec des antivirus. Avec cette même mise à jour KB5066835, Microsoft a été contraint de publier un correctif d'urgence pour les connexions localhost, qui empêchaient d'accéder à son propre ordinateur, ce qui est crucial pour de nombreux développeurs.
Mais la gravité a atteint un niveau supérieur lorsque l’outil de récupération lui-même est tombé en panne. Un problème qui a été noté sur Windows 11 25H2, 24H2 et même Windows Server.
Windows 11 ces derniers mois c'est :
Le bug du Wi-Fi apparu en octobre 2025, qui déconnectait les machines de certaines cartes Intel après chaque redémarrage.
La panne du Windows Explorer causée par Copilot, l’assistant IA de Microsoft, qui faisait geler le bureau lors des suggestions contextuelles.
Les problèmes d’impression récurrents, toujours non résolus, qui empêchent les imprimantes réseau d’être détectées après une mise à jour.
Le bug des fonds d’écran animés, qui figeait la barre des tâches et faisait planter les sessions utilisateur.
Et surtout, les crashs massifs liés au Windows Subsystem for Linux (WSL), brisant les environnements de développement d’ingénieurs et d’administrateurs système.
Chaque mise à jour semble désormais corriger une poignée de bugs tout en en introduisant une dizaine d’autres.
Cela pose une question fondamentale sur la stratégie de mise à jour continue imposée par Microsoft. À force d’intégrer de nouvelles fonctionnalités à un rythme trimestriel, sans contrôle qualité exhaustif sur l’ensemble des configurations matérielles, Windows devient son propre facteur de risque. Les utilisateurs n’ont plus la possibilité de bloquer ou de différer les correctifs problématiques, puisque les mises à jour sont souvent forcées par le système.
Dans un contexte où Microsoft pousse à fond la fusion de Windows avec l’écosystème Copilot et les fonctions d’IA locales, chaque nouvelle version devient un pari risqué. Le bug 25H2 montre que même des éléments aussi fondamentaux que les pilotes USB ou les environnements de secours peuvent être affectés sans avertissement.
merci à Developpez.com
