J’ai récemment connu un problème assez frustrant sur mon PC, sous Windows 11. Depuis plusieurs mois, sans raison apparente, mon PC refusait obstinément de se mettre en veille correctement. À chaque fois que j’appuyais sur “Mettre en veille” depuis le menu Démarrer, le même scénario se répétait : les écrans s’éteignaient instantanément, mais la tour restait allumée. Les ventilateurs continuaient de tourner, les LED restaient actives et rien ne laissait penser que la machine s’était réellement mise en veille.
Après des semaines à vivre avec ce défaut sans trop m’en soucier, j’ai fini par prendre le temps de creuser sérieusement le problème. Voici donc le récit complet de ce diagnostic, avec toutes les fausses pistes explorées avant d’arriver à la véritable cause.
La configuration de mon PC
Pour situer le contexte, voici la configuration de la machine sur laquelle ce problème s’est produit :
- Processeur : Intel Core i5-14400F
- RAM : 32 Go DDR5
- Carte graphique : NVIDIA GeForce RTX 5060 Ti – ASUS Dual OC Edition
- Carte mère : MSI B760 Gaming Plus WiFi
- Version de l’OS : Windows 11 Professionnel, canal Insider Preview, version 25H2, build 26220.9022
Ce dernier point aura son importance dans la suite de l’article. Cependant, j’ai constaté que ce problème existait déjà avant mon passage sur le canal Insider, ce qui a longtemps compliqué le diagnostic en écartant à tort certaines pistes évidentes.
Tout ce qui n’a pas marché, pour que vous le sachiez si ça vous concerne
Premier réflexe : essayer d’identifier ce qui empêche la veille
La première étape logique pour ce genre de problème consiste à demander directement à Windows ce qui bloque la mise en veille. La commande suivante, exécutée dans une invite de commande, liste tous les processus ou pilotes qui empêchent activement le système de s’endormir :
powercfg /requestsRésultat : rien. Toutes les catégories (DISPLAY, SYSTEM, AWAYMODE, EXÉCUTION, PERFBOOST, ACTIVELOCKSCREEN) affichaient “Aucune”. Cette commande, censée être la première à consulter dans ce genre de situation, s’est révélée totalement muette sur mon cas, comme assez souvent finalement quand on essaie de creuser un problème sur Windows.
Vérifier la disponibilité des états de veille
L’étape suivante consistait à vérifier que mon système supportait bien l’état de veille classique, appelé “S3” (je l’ai appris en cherchant), celui qui coupe l’alimentation de la plupart des composants tout en conservant le contenu de la mémoire vive :
powercfg /aLe résultat confirmait que l’état S3 était bien disponible et actif sur ma configuration, tout comme la veille prolongée. Les états S1 et S2, ainsi que la veille moderne S0 (Modern Standby), n’étaient pas pris en charge par le BIOS de la carte mère. Donc en théorie, la vraie veille aurait dû fonctionner. Dans les faits, ce n’était toujours pas le cas.
Éliminer les causes classiques
À ce stade, j’ai enchaîné plusieurs vérifications standards, sans succès, même si aucune de ces pistes n’a changé quoi que ce soit au comportement du PC. :
- Mise à jour des pilotes graphiques NVIDIA, au cas où le GPU était responsable
- Désactivation du démarrage rapide dans les options d’alimentation
- Vérification des paramètres avancés d’alimentation, notamment la veille sélective USB et la gestion d’énergie de la carte réseau
- Test de débranchement des périphériques USB non essentiels
L’observateur d’événements et le début de piste du mode Absence
En creusant dans l’Observateur d’événements Windows, je suis tombé sur un message qui semblait intéressant mais ne m’avait clairement pas mis la puce à l’oreille : “Le système entre en mode Absence”. Le principe de ce mode : le PC coupe l’écran et le son, bloque les périphériques d’entrée, mais reste pleinement actif pour continuer une tâche en arrière-plan. Le symptôme collait parfaitement à ce que j’observais.
Le problème, c’est que la commande powercfg /requests, relancée juste après avoir déclenché la veille, n’affichait toujours rien sous la catégorie AWAYMODE. Aucune application ne réclamait ce mode. Cette contradiction m’a fait abandonner temporairement cette piste, alors qu’elle était en réalité la bonne. J’y reviendrai.
Écarter l’hypothèse d’un problème de réveil
Un autre indice trompeur : après chaque tentative de mise en veille ratée, une application revenait systématiquement au premier plan, que ce soit Steam ou la page des paramètres Windows. Ce comportement ressemblait à un réveil intempestif du système. J’ai donc vérifié :
powercfg /lastwake
powercfg /waketimersLes deux commandes indiquaient un compteur de réveil à zéro et aucun minuteur de réveil actif. Il n’y avait donc pas de réveil au sens propre : le système ne s’était en réalité jamais réellement endormi.
Le rapport d’analyse énergétique
J’ai ensuite généré un rapport de diagnostic complet avec la commande suivante :
powercfg /energy /output C:\energy-report.html /duration 30Ce rapport a mis en évidence plusieurs éléments, notamment une gestion ASPM PCI Express désactivée en raison d’une incompatibilité matérielle connue, ainsi que plusieurs périphériques USB qui ne passaient pas en mode de suspension sélective. Sur le moment, ces éléments semblaient être des pistes sérieuses.
En réalité, le rapport précisait lui-même, pour chaque périphérique USB concerné, que ce problème n’empêchait pas l’état de veille du système. Ce rapport ne contenait donc aucune explication au blocage réel de la veille.
Le test décisif : appeler directement l’API de mise en veille
Pour vraiment isoler le problème, j’ai testé un appel direct à la fonction Windows responsable de la mise en veille, en contournant complètement le menu Démarrer et tout logiciel tiers :
rundll32.exe powrprof.dll,SetSuspendState 0,1,0Résultat : cette fois, tout s’est déroulé presque normalement. Ventilateurs et LED coupés, retour rapide au réveil, redemande du code PIN pour déverrouiller la session. C’était bien une mise ne veille, mais ma petite LED sur le dessus de ma tour ne clignotait plus, alors qu’elle le fait lors de la veille classique.
Malgré tout, ce test a été le véritable tournant du diagnostic. Il prouvait que le matériel, le BIOS et les pilotes n’avaient strictement aucun problème avec la veille, qu’elle soit profonde ou non. Le souci se situait donc ailleurs : pourquoi est-ce que ma veille basique, celle qui se met en place toute seule ou via le menu Démarrer, ne marchait toujours pas ?
Confirmer le blocage avec les journaux Kernel-Power
Pour confirmer cette hypothèse, j’ai filtré l’Observateur d’événements sur la source Kernel-Power, cliqué sur Menu Démarrer puis Veille, et comparé les événements générés à ceux obtenus lors du test avec SetSuspendState. Le constat était sans appel : lors d’un déclenchement via le menu Démarrer, l’événement ID 42, qui signale l’entrée effective du système en état de veille, n’apparaissait jamais.
Windows n’essayait tout simplement pas d’entrer en veille par ce chemin. Il se contentait d’éteindre l’affichage, sans jamais appeler la véritable transition système. J’ai également testé le raccourci Alt+F4 depuis le bureau : même échec.
Les autres pistes qui n’ont mené à rien
Avant de trouver la véritable cause, j’ai testé un certain nombre d’autres hypothèses, toutes infructueuses. À un moment donné, j’ai également envisagé la piste Hyper-V, présent sur ma machine à cause de traces d’activité du commutateur virtuel dans les journaux système, bien que je n’utilise ni machine virtuelle ni WSL de manière active. J’ai choisi de ne pas désactiver l’hyperviseur, une mesure trop radicale et hors de proportion avec le problème. Voici donc les quelques idées que j’ai appliquées à ce moment :
- Démarrage en mode minimal (démarrage sélectif via msconfig, tous les services et programmes tiers désactivés) : aucun changement, ce qui écartait tout logiciel installé, y compris les utilitaires de gestion de périphériques comme les logiciels constructeur de cartes graphiques ou de captures vidéo
- Réinitialisation des plans d’alimentation par défaut avec
powercfg /restoredefaultschemes - Vérification et désactivation de l’intégrité de la mémoire (isolation du noyau) : déjà désactivée
- Vérification de fichiers système avec
sfc /scannow: aucune violation d’intégrité détectée - Réparation de l’image système avec
DISM /Online /Cleanup-Image /RestoreHealth - Modification manuelle de la valeur d’action associée au bouton de veille via
powercfg /setacvalueindex
Petit couac au passage : à force de tester des choses, ma carte réseau Ethernet a fini par disparaître complètement du système, sans que je comprenne vraiment pourquoi sur le moment. Un simple reset matériel (alimentation débranchée et bouton d’allumage maintenu trente secondes) a suffi à résoudre ce problème annexe. J’avais heureusement toujours ma carte Wi-Fi indépendante de la carte mère qui m’a permis de rester connecté au W-Fi de ma Livebox 7, pour chercher ma solution.
La véritable cause : un bug connu du mode Absence (sous 25H2 ?)
En cherchant sur internet, je suis tombé sur un commentaire posté sur Reddit qui décrivait exactement mon symptôme. Selon cette personne, le coupable était le mode Absence, la piste que j’avais écartée trop tôt au tout début de mon diagnostic à cause de l’absence de résultat dans powercfg /requests. En désactivant la politique qui autorise ce mode, le problème disparaissait.
J’ai voulu vérifier si cette explication tenait la route au-delà d’un simple témoignage isolé. En creusant un peu, j’ai découvert que le symptôme que je décris, écran qui s’éteint mais tour qui reste allumée sans jamais entrer en veille S3, est en réalité un problème documenté sur Windows 11 25H2, remonté par de nombreux utilisateurs sur les forums Microsoft et repris par plusieurs médias spécialisés. Il existe même une mise à jour, KB5074109, identifiée comme aggravant ce comportement sur certaines configurations. Microsoft n’a toutefois pas publié d’explication technique officielle et détaillée du mécanisme exact en cause, et certains témoignages évoquent plutôt des soucis liés aux minuteurs de réveil ou à des composants de maintenance système, sans lien direct avec le mode Absence.
Autrement dit, le bug de veille S3 cassée sous 25H2 est réel et bien connu. En revanche, l’explication précise que j’ai retenue, à savoir le déclenchement silencieux du mode Absence, reste une piste communautaire qui a fonctionné dans mon cas précis, sans validation officielle de Microsoft sur le mécanisme exact. Je le précise ici pour rester honnête sur le niveau de certitude de cette explication, plutôt que de la présenter comme une vérité établie.
La solution appliquée et tout fonctionne comme avant
Le mode Absence est piloté par un paramètre caché des options d’alimentation Windows, nommé “Allow Away Mode Policy”. Ce paramètre n’apparaît pas par défaut dans l’interface graphique. Pour le faire apparaître, il faut passer par une modification du registre, via une invite de commande ouverte en administrateur :
REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\25DFA149-5DD1-4736-B5AB-E8A37B5B8187 /v Attributes /t REG_DWORD /d 2 /fUne fois cette clé ajoutée, le paramètre “Allow Away Mode Policy” (en français, “Autoriser la stratégie du mode Absence) devient visible dans le panneau de configuration, sous Options d’alimentation, puis Modifier les paramètres du mode, Modifier les paramètres d’alimentation avancés, dans la section Veille. Il ne reste plus qu’à désactiver ce paramètre (le passer sur “Non”) pour empêcher Windows d’entrer en mode Absence et forcer une véritable mise en veille S3 lors du déclenchement normal via le menu Démarrer.
Depuis cette modification, la veille fonctionne enfin comme elle le devrait : les ventilateurs s’arrêtent, les LED s’éteignent (sauf le témoin de veille), et le PC redemande bien le code PIN au réveil.
Petit bilan sur ce diagnostic
Ce qui me frappe un peu avec le recul, c’est le temps nécessaire pour cerner un problème pourtant assez répandu, alors que les outils de diagnostic intégrés à Windows, notamment powercfg /requests, sont censés justement signaler ce type de blocage. Que la cause exacte soit le mode Absence ou un autre mécanisme interne, le fait qu’aucun de ces outils officiels n’ait laissé la moindre trace exploitable est en soi un défaut de fiabilité qui mérite d’être signalé, d’autant que ce bug de veille S3 sous 25H2 semble toucher un nombre significatif de configurations, bien au-delà de mon simple cas isolé.
Si vous rencontrez ce même symptôme, écran qui s’éteint mais tour qui reste allumée, ventilateurs actifs en continu, je recommande de vérifier ce paramètre de mode Absence avant toute autre manipulation plus lourde. Cela m’aurait évité pas mal de détours.