Perte de batterie du portable pendant la nuit : l’état de veille qui ment

Le mensonge : « Veille » comme terme marketing

La veille des anciens portables (celle dont on garde un bon souvenir) signifiait : la RAM reste alimentée, la plupart du système est éteint et la machine consomme une quantité minime et prévisible d’énergie. On la mettait dans un sac, on oubliait, on revenait des jours plus tard et tout allait bien.

La veille moderne signifie souvent : le CPU est « principalement » endormi, le réseau peut rester actif, le système peut se réveiller brièvement pour faire des tâches, et certains périphériques ne s’éteignent jamais complètement parce que pilotes et firmware ne s’entendent pas sur ce que signifie « éteint ». C’est un état d’esprit de centre de données mis dans un châssis alimenté par batterie. Dans une baie serveur, « réveil pour synchroniser les e-mails » s’appelle « opérations normales ». Sur un portable à 2h du matin, ça s’appelle « pourquoi mon sac est chaud ? »

La décharge de batterie pendant la nuit est rarement mystérieuse. Il s’agit généralement de l’un de ces cas :

• Vous n’avez pas obtenu l’état de veille que vous pensiez avoir (S0 « Modern Standby » / s2idle au lieu de S3 « deep »).
• Vous avez obtenu le bon état, mais des périphériques vous réveillent (réseau, USB, Bluetooth, stations d’accueil Thunderbolt, souris rancunières).
• Vous êtes resté en veille, mais la consommation est trop élevée à cause d’échecs de gestion d’alimentation firmware/pilote/périphérique (NVMe qui n’entre pas en basse consommation, Wi‑Fi qui refuse de dormir, GPU qui reste à moitié réveillé).
• Vous ne vous êtes pas mis en veille du tout (suspend bloqué, application qui empêche, politique de fermeture du capot incorrecte), et l’écran s’est juste éteint.

Une fois que vous arrêtez de traiter la « veille » comme une promesse et que vous la considérez comme une machine d’états avec des logs, c’est corrigeable.

Faits intéressants et brève histoire (pourquoi c’est pire)

Voici quelques points concrets qui expliquent pourquoi votre portable de 2012 se comportait mieux que votre ultrabook de 2023, même si tout le reste est plus rapide :

1. ACPI S3 (« suspend-to-RAM ») remonte à une époque où les portables n’étaient pas censés être toujours connectés. C’est simple : la RAM est alimentée, la plupart du reste est éteint.
2. Microsoft a poussé « Connected Standby » (rebaptisé plus tard « Modern Standby ») pour faire en sorte que les PC se comportent comme des téléphones. C’est S0 low-power idle, pas S3.
3. Beaucoup de nouveaux portables Windows sont livrés sans support S3 activé du tout. Si vous ne pouvez pas utiliser S3, vous ne pouvez pas le « choisir » avec un réglage ; c’est une décision de plateforme.
4. Les S0ix d’Intel (états C du package en S0 idle) sont un élément technique clé pour Modern Standby. Quand ça fonctionne, c’est génial. Quand ça ne fonctionne pas, vous obtenez une « veille » avec une activité de fond de grade serveur.
5. Les disques NVMe peuvent être un coupable silencieux. Si le SSD n’entre pas en états de très basse consommation (ou si l’OS ne le permet pas), la plateforme ne peut souvent pas atteindre la résidence d’idle la plus profonde.
6. Les docks USB-C et Thunderbolt ont changé le paysage des réveils. Un dock est effectivement un bus de périphériques, dont chacun peut demander de l’alimentation ou déclencher un réveil.
7. La gestion d’économie d’énergie du Wi‑Fi n’est pas qu’une case à cocher ; c’est une négociation entre OS, pilote, firmware et comportement du point d’accès. De mauvaises combinaisons existent. Elles sont livrées en série.
8. Les « wake timers » existent depuis des lustres, mais les mécanismes modernes de mise à jour les utilisent de façon agressive. Tâches de maintenance, télémétrie, scans de mises à jour—certains fournisseurs les planifient comme si c’était leur portable, pas le vôtre.
9. macOS utilise depuis longtemps le « dark wake » et des maintenances planifiées en arrière-plan. Généralement, c’est bien géré, mais quand ce n’est pas le cas, ça ressemble à un graphe de batterie hanté.

Une idée paraphrasée que les SRE répètent parce qu’elle est vraie : paraphrased idea de Werner Vogels : « Tout échoue, tout le temps ; concevez et opérez en supposant cela. » La veille n’est qu’un autre système distribué—firmware, pilotes, périphériques, OS, politiques—échouant de petites manières qui s’additionnent jusqu’à une batterie à plat.

Mode d’intervention rapide (premier/deuxième/troisième)

Si vous êtes de garde pour votre propre portable, vous avez besoin d’un triage qui fonctionne en cinq minutes, pas d’un week-end de plongée dans les forums.

Premier : confirmer l’état de veille réel obtenu

• Windows : vérifiez les états de veille supportés et les transitions récentes de veille (powercfg).
• Linux : vérifiez si la suspension utilise s2idle ou deep et ce que la plateforme supporte (/sys/power/mem_sleep).
• macOS : inspectez les raisons de sommeil/réveil et le nombre de « dark wake » (journaux pmset).

Décision : Si vous n’êtes pas en mode profond (S3/deep) et que votre plateforme le supporte, forcez-le. Si votre plateforme ne le supporte pas, supposez Modern Standby/s2idle et concentrez-vous sur les sources de réveil et la gestion d’alimentation des périphériques.

Second : identifier les sources de réveil et la fréquence des réveils

• Est-ce qu’il se réveillait de manière répétée (beaucoup de réveils courts), ou qu’il ne dormait pas vraiment (une longue période éveillée) ?
• La source de réveil est-elle le réseau, l’USB, le Bluetooth, le capot, le minuteur RTC ou « inconnue » ?

Décision : Si les réveils sont fréquents, désactivez les sources de réveil spécifiques (Wake-on-LAN, réveil USB, réveil Bluetooth, timers planifiés). Si les réveils sont rares mais que la décharge est élevée, concentrez-vous sur la consommation en état de veille (NVMe/Wi‑Fi/GPU/firmware).

Troisième : tester avec des variables contrôlées

• Mettre en veille sans périphériques (pas de dock, pas de souris externe, pas de stockage USB).
• Désactiver temporairement le réseau (mode avion, ou désactiver le réveil réseau).
• Tenter l’hibernation pendant une nuit comme contrôle.

Décision : Si l’hibernation règle le problème, votre état de veille est en cause. Si l’hibernation se décharge encore, la santé de la batterie est suspecte ou l’appareil n’entre pas réellement en hibernation (rare, mais ça arrive).

Blague #1 : Modern Standby, c’est comme un « jeûne optionnel ». Votre portable promet qu’il se repose tout en grignotant discrètement des watts dans le placard.

Un modèle mental pratique : où vont vos watts la nuit

La décharge de batterie pendant la nuit concerne soit le temps (trop de réveils), soit le niveau de base (trop de consommation pendant la « veille »). La correction dépend de votre cas.

Cas A : le portable se réveille souvent

C’est le classique « pourquoi t’as réveillé ? ». Chaque réveil peut être court, mais il remonte des parties du système coûteuses : pics CPU en turbo, activité radio Wi‑Fi, lectures/écritures SSD, ou une vraie fête du service de mise à jour.

Déclencheurs courants :

• Wake on LAN / motifs réseau
• Réveil USB (souris, clavier, dock, casque)
• Périphériques Bluetooth qui se reconnectent
• Tâches programmées / wake timers (mises à jour, agents de sauvegarde)
• Fenêtres de « maintenance » conçues par quelqu’un qui ne prend pas le métro avec l’ordinateur

Cas B : il reste « en veille » mais consomme trop

C’est plus subtil et plus courant sur les systèmes modernes. La machine peut ne pas enregistrer d’événements de réveil explicites, mais elle n’atteint jamais l’idle profond. Quelque chose empêche le package CPU et les périphériques d’entrer dans leurs états de puissance les plus bas.

Coupables fréquents :

• Disque NVMe qui n’entre pas en basse consommation (APST désactivé, firmware buggy)
• Pilote Wi‑Fi maintenant le système dans un état d’idle supérieur
• GPU (surtout dGPU) ne s’éteignant pas complètement
• Contrôleurs Thunderbolt restant actifs avec des périphériques connectés
• Bugs du noyau/pilotes bloquant la suspension ou provoquant une reprise immédiate

Pourquoi « fermer le capot » n’est pas une garantie

La fermeture du capot déclenche une politique. La politique déclenche une transition. La transition dépend de la coopération des pilotes. Si une pièce refuse, l’OS peut revenir en arrière, se bloquer ou faire une demi-suspension. Pour l’utilisateur, ça ressemble à un « écran éteint ». Pour la batterie, ça ressemble à « toujours au travail ».

Windows : prouver l’état obtenu, puis chasser les sources de réveil

La décharge de batterie sous Windows pendant la nuit est fréquemment un problème de Modern Standby. Parfois, ça fonctionne comme prévu. Ce n’est pas un compliment.

Modern Standby (S0 low power idle) versus S3

Si votre système ne supporte que S0 idle, vous ne pouvez pas forcer S3 avec une astuce de registre qui « fonctionne toujours ». Certaines plateformes n’implémentent littéralement pas S3. La bonne démarche est de (a) réduire les sources de réveil, (b) restreindre l’activité réseau en veille, (c) mettre à jour pilotes/BIOS, ou (d) choisir l’hibernation quand vous avez besoin d’une faible consommation garantie.

SleepStudy est votre ami

Windows propose un rapport intégré étonnamment utile pour analyser le comportement de Modern Standby. Il montrera quels composants ont été actifs, pendant combien de temps et ce qui empêche la résidence en basse consommation.

N’ignorez pas les politiques « connected standby allowed »

Les images d’entreprise incluent souvent des politiques qui maintiennent la machine « joignable ». C’est acceptable sur secteur. Sur batterie, c’est une panne lente. Vous voulez des politiques qui traitent la batterie comme un budget, pas comme une suggestion.

macOS : pmset, darkwakes et les jolis mensonges

macOS dort en général correctement, mais il est aussi très engagé à faire des choses utiles pendant que vous ne regardez pas. « Dark wake » est le terme poli pour « je me suis réveillé sans vous le dire parce que j’avais des choses à faire ». Parfois ces choses sont légitimes : sauvegardes, indexation, synchronisation iCloud. Parfois c’est un pilote ou un périphérique qui provoque une boucle de réveils.

Power Nap et réveil réseau

Power Nap peut réveiller le système périodiquement. L’accès réseau peut également déclencher des réveils selon les réglages et le matériel. Si votre Mac se décharge la nuit, vérifiez les réveils répétitifs et s’ils se corrèlent avec des services réseau ou des périphériques USB‑C connectés.

La chaleur dans un sac est un signal d’alerte

Si un MacBook est chaud après une « veille », cela suggère soit qu’il s’est réveillé en boucle, soit qu’il n’a pas réellement atteint un état de basse consommation. N’acceptez pas « c’est normal ». Chaud signifie que de l’énergie est partie quelque part, et ce n’était pas pour votre productivité.

Linux : s2idle vs deep, pilotes et la trappe de la suspension

Linux vous donne du pouvoir. Linux vous donne aussi de la corde. Le comportement de suspension varie selon le noyau, la configuration de la distribution, le firmware et les pilotes de périphériques. Vous pouvez avoir un portable qui se suspend parfaitement sur le noyau 6.1 et qui se décharge comme un radiateur spatial sur le 6.6, parce qu’un seul pilote a changé ses paramètres de gestion d’énergie.

s2idle (S0) vs deep (S3)

Sur de nombreux portables, Linux choisira par défaut s2idle (un idle coordonné par logiciel en S0). Ça peut être correct. Ou ça peut être une fuite de batterie si les périphériques ne se comportent pas.

deep correspond à S3 quand c’est supporté. Il a tendance à être plus économe et moins « bavard », mais peut poser des problèmes de compatibilité avec certains périphériques (problèmes de reconnexion Wi‑Fi, périphériques USB qui ne reprennent pas, etc.).

Systemd, journald et les logs de suspension

Linux vous donne le post-mortem que vous avez toujours voulu. Si la suspension échoue, les journaux montreront souvent quelle unité ou quel pilote l’a bloquée. Ne devinez pas ; lisez le journal.

NVMe et ASPM sont des coupables courants

NVMe APST et PCIe ASPM ont de l’importance. Si la plateforme ne peut pas réduire les liens PCIe en états de basse consommation, votre consommation de base sera plus élevée. Linux peut être conservateur selon les bizarreries du firmware du système. Parfois il faut activer une politique ; parfois il faut arrêter de lutter contre le BIOS et simplement le mettre à jour.

Matériel et firmware : NVMe, Wi‑Fi, USB et options BIOS

Les ingénieurs aiment blâmer le logiciel parce que nous pouvons changer le logiciel. La décharge de batterie en veille est souvent médiée par le matériel/firmware. Cela ne veut pas dire que vous êtes coincé ; cela veut dire que le correctif pourrait être « mettre à jour le BIOS » et non « basculer mille réglages OS ».

Paramètres BIOS/UEFI qui comptent

• Sélection d’état de veille : certains firmwares exposent des bascules S3 vs Modern Standby / S0ix.
• Wake on LAN : désactivez sur batterie sauf si vous avez une vraie raison.
• Recharge USB en veille : pratique, mais ça coûte de l’énergie. Désactivez si vous cherchez à réduire la décharge.
• Sécurité Thunderbolt / support pré‑boot : peut affecter le comportement d’alimentation avec les docks.

Les périphériques sont coupables jusqu’à preuve du contraire

Dock + écran externe + récepteur USB + adaptateur Ethernet est un système distribué. Et comme tous les systèmes distribués, il échoue de manière créative à 3h du matin. Si votre décharge arrive « uniquement quand c’est docké », croyez‑le. Isolez.

Blague #2 : Un dongle USB peut réveiller votre portable plus sûrement que votre réveil, et il ne s’excuse jamais.

Trois micro-récits d’entreprise du terrain

Incident #1 : la mauvaise supposition (« La veille, c’est la veille »)

Une grande équipe informatique interne a déployé un nouveau modèle de portable à un groupe d’ingénieurs qui voyageaient souvent. L’ancien modèle avait une veille S3 solide. Les gens fermaient le capot, prenaient l’avion et l’ouvraient à l’hôtel avec à peu près le même pourcentage de batterie.

Le nouveau modèle était livré uniquement avec Modern Standby. L’hypothèse—jamais écrite, jamais testée—était que « le comportement de veille est le même sur tous les portables ». Ce n’était pas le cas. Le premier signal réel fut une vague de plaintes : « Mon portable meurt dans mon sac », « Il est chaud », « Il est à 0 % quand j’atterris ». Le second signal fut plus coûteux : quelques batteries ont commencé à gonfler plus tôt que prévu parce qu’elles passaient trop de temps chaudes dans un espace confiné.

Ils l’ont d’abord traité comme une erreur utilisateur. Puis ils ont extrait des rapports SleepStudy d’une poignée de machines. L’histoire était cohérente : activité réseau répétée en veille, timers programmés périodiques et quelques pilotes empêchant la résidence basse consommation. Rien de dramatique—juste la mort par mille petites coupures.

Le correctif n’était pas un réglage magique unique. Ils ont ajusté les politiques d’alimentation pour restreindre la connectivité réseau sur batterie, désactivé des capacités de réveil spécifiques pour certains pilotes NIC, et poussé des mises à jour BIOS. Ils ont aussi changé les consignes de voyage : si vous mettez le portable dans un sac pendant des heures, utilisez l’hibernation. C’était ennuyeux. Ça a marché.

Incident #2 : l’optimisation qui s’est retournée (joignabilité permanente)

Un groupe sécurité voulait que les appareils restent joignables pour des vérifications de conformité, renouvellements de certificats et rapports d’état d’endpoint. Objectifs raisonnables. Ils ont activé des timers de réveil agressifs et autorisé la connectivité réseau en veille sur batterie pour toute la flotte.

Cela a « optimisé » la conformité. Cela a aussi optimisé la décharge de batterie. Les utilisateurs sont arrivés aux réunions avec des machines mortes et une méfiance réflexe envers l’indicateur de batterie. Cette méfiance compte : quand les gens cessent de croire la télémétrie, ils inventent leurs propres rituels—arrêts fréquents, désactivation des mises à jour, ou refus des paramètres gérés par la politique.

Le problème n’était pas l’intention sécurité ; c’était l’absence de budget. La consommation en veille est un budget. Si vous le dépensez pour la joignabilité, vous ne pouvez pas aussi le dépenser pour « encore de la batterie le matin ».

Le compromis final : autoriser la connectivité réseau en veille seulement sur secteur, et sur batterie seulement dans une courte fenêtre après la fermeture du capot. Ils ont aussi rendu les timers de réveil optionnels pour les appareils assignés à des rôles spécifiques. La conformité est restée bonne. La confiance en la batterie est revenue. Tout le monde a arrêté de traiter la veille comme un pari.

Incident #3 : la pratique ennuyeuse mais correcte qui a sauvé la situation (base + contrôle des changements)

Une équipe plateforme supportant des portables Linux a fait une chose peu glamour : elle a maintenu un test de suspension/reprise et de décharge en veille dans sa checklist pré‑release. Même matériel, même noyau, même charge de travail, mêmes périphériques. À chaque mise à jour noyau ou BIOS, ils exécutent le même test nocturne.

Une fois, ils ont remarqué une doublement de la décharge en veille sur un sous‑ensemble de machines après une mise à jour du noyau. Aucun utilisateur ne s’était encore plaint. Ils avaient des données en premier. Le journal montrait des suspensions propres, mais la machine restait en s2idle sans atteindre les états bas consommation des périphériques, le sous‑système NVMe étant fréquemment actif.

Ils ont bissé le changement jusqu’à une modification du comportement de gestion d’énergie dans la configuration d’un pilote de stockage interagissant avec un firmware SSD particulier. Le « correctif » à court terme fut de figer un paramètre noyau pour les états d’alimentation NVMe et de travailler avec le fournisseur sur des mises à jour firmware. Ils ont aussi changé le mode de suspension par défaut en deep quand c’était supporté.

Ce n’était pas héroïque. C’était contrôle des changements plus mesure. Voilà à quoi ressemble ce qui « a sauvé la situation » en opérations réelles : vous attrapez les régressions avant qu’elles n’atteignent vos utilisateurs, et vous n’apprenez pas une fuite de batterie par un cadre dans un salon d’aéroport.

Erreurs courantes : symptôme → cause → correctif

Symptôme : Le portable perd 20–50 % pendant la nuit et il est chaud le matin.

Cause : Modern Standby / s2idle avec réveils fréquents ou niveau de base élevé ; souvent lié au réseau ou au dock.

Correctif : Désactiver le réveil sur réseau/USB, restreindre le réseau en veille sur batterie, mettre à jour BIOS/pilotes, tester la veille sans périphériques, utiliser l’hibernation pour les voyages.

Symptôme : La décharge n’arrive que quand l’appareil est connecté à un dock ou hub USB‑C.

Cause : Périphériques du dock générant des événements de réveil ; contrôleur Thunderbolt restant actif ; réveil USB activé.

Correctif : Désactiver le réveil USB pour des périphériques spécifiques, mettre à jour le firmware du dock, éviter les fonctions « USB toujours alimenté », tester différents ports/câbles.

Symptôme : La batterie se décharge même quand l’ordinateur est « éteint », ou la décharge est bien pire que prévu.

Cause : Pas réellement éteint (Fast Startup/hiberboot sur Windows), ou l’appareil supporte la « recharge USB en S5 ».

Correctif : Désactiver Fast Startup ; dans le BIOS désactiver l’alimentation USB en S5 ; vérifier avec les logs et rapports d’alimentation.

Symptôme : Le portable se réveille immédiatement après la mise en veille.

Cause : Périphérique capable de réveil (USB/Bluetooth/NIC) déclenchant la reprise, ou un timer de réveil.

Correctif : Inspecter la dernière source de réveil ; désactiver les capacités de réveil ; effacer les timers ; mettre à jour les pilotes.

Symptôme : Le portable Linux « se suspend » mais les ventilateurs tournent ou les voyants restent allumés.

Cause : Blocage de la suspension ou repli ; périphérique/pilote qui bloque ; coincé en s2idle avec périphériques actifs.

Correctif : Vérifier le journal autour de la suspension ; passer en deep ; blacklister/désactiver les modules problématiques ; mettre à jour noyau/firmware.

Symptôme : La batterie macOS baisse de 10–20 % pendant la nuit sans réveil évident.

Cause : Darkwakes répétés pour réseau/sauvegarde/indexation, ou réveils déclenchés par des périphériques.

Correctif : Inspecter les logs pmset ; ajuster Power Nap / réveil réseau ; débrancher les périphériques suspects ; réinitialiser la NVRAM/SMC si approprié (selon la plateforme).

Tâches pratiques avec commandes (et comment décider)

Ci‑dessous des tâches concrètes à exécuter. Chacune inclut : une commande, une sortie réaliste, ce que cela signifie et la décision à prendre. Utilisez‑les comme un runbook d’incident : collectez des preuves, changez une variable, retestez.

Task 1 (Windows): Check which sleep states are supported

cr0x@server:~$ powercfg /a
The following sleep states are available on this system:
    Standby (S0 Low Power Idle) Network Connected
    Hibernate
    Fast Startup

The following sleep states are not available on this system:
    Standby (S1)
    Standby (S2)
    Standby (S3)
        The system firmware does not support this standby state.
    Hybrid Sleep
        Standby (S3) is not available.

Ce que cela signifie : S3 n’est pas une option. Vous êtes en Modern Standby (S0 low power idle). La « veille » n’est pas du type classique.

Décision : Arrêtez d’essayer de forcer S3 avec des astuces. Concentrez‑vous sur les sources de réveil, les politiques de connected standby et la gestion d’alimentation des périphériques. Utilisez l’hibernation lorsque vous avez besoin d’une décharge prévisible.

Task 2 (Windows): Generate a SleepStudy report (Modern Standby analysis)

cr0x@server:~$ powercfg /sleepstudy /duration 3
Sleep study report saved to file path C:\Windows\system32\sleepstudy-report.html.

Ce que cela signifie : Vous avez maintenant un rapport détaillant les sessions de standby, les composants actifs et la décharge.

Décision : Ouvrez le rapport et cherchez : principaux coupables, « temps actif » en standby et tout composant empêchant la résidence basse consommation. Si « Network » ou « Audio » ou un pilote spécifique domine, ciblez‑le.

Task 3 (Windows): Find what woke the machine last

cr0x@server:~$ powercfg /lastwake
Wake History Count - 1
Wake History [0]
  Wake Source Count - 1
  Wake Source [0]
    Type: Device
    Instance Path: PCI\VEN_8086&DEV_15F3&SUBSYS_00008086&REV_03\3&11583659&0&FE
    Friendly Name: Intel(R) Ethernet Connection (7) I219-V
    Description: Intel(R) Ethernet Connection (7) I219-V
    Manufacturer: Intel

Ce que cela signifie : La carte réseau a réveillé le portable.

Décision : Désactivez le réveil sur la NIC (ou « Allow this device to wake the computer » dans le Gestionnaire de périphériques), surtout sur batterie, et désactivez Wake-on-LAN dans le BIOS si vous n’en avez pas besoin.

Task 4 (Windows): List devices allowed to wake the computer

cr0x@server:~$ powercfg /devicequery wake_armed
HID Keyboard Device
HID-compliant mouse
Intel(R) Ethernet Connection (7) I219-V
Intel(R) Wireless-AC 9560 160MHz

Ce que cela signifie : Plusieurs périphériques peuvent réveiller le système.

Décision : Commencez par désactiver le réveil pour tout ce qui n’est pas essentiel (souris, Wi‑Fi, Ethernet). Gardez l’activation clavier si vous la voulez. Retestez la nuit suivante.

Task 5 (Windows): Disable wake timers (policy-level lever)

cr0x@server:~$ powercfg /waketimers
There are no active wake timers in the system.

Ce que cela signifie : Aucun timer de réveil actif pour l’instant, mais des timers futurs peuvent être créés par la politique ou des tâches.

Décision : Si la décharge persiste, ne vous arrêtez pas là. Vérifiez les tâches planifiées et le réglage « Allow wake timers » du plan d’alimentation actif. Dans les environnements gérés, revoyez la stratégie de groupe.

Task 6 (Windows): Battery report to validate actual drain over time

cr0x@server:~$ powercfg /batteryreport /duration 7
Battery life report saved to file path C:\Windows\system32\battery-report.html.

Ce que cela signifie : Une série chronologique d’utilisation et de décharge en veille, plus des estimations de capacité.

Décision : Si la capacité est fortement dégradée, vous poursuivez une réalité matérielle. Si la capacité est correcte mais la décharge en veille importante, c’est un problème d’état de veille/réveil, pas une « batterie vieille ».

Task 7 (macOS): Show recent sleep/wake reasons

cr0x@server:~$ pmset -g log | grep -e "Wake reason" -e "Entering Sleep" | tail -n 12
2026-02-04 22:31:10 -0500 Entering Sleep state due to 'Clamshell Sleep':TCPKeepAlive=active
2026-02-04 23:12:44 -0500 Wake reason: EC.LidOpen (User)
2026-02-05 01:07:03 -0500 Entering Sleep state due to 'Idle Sleep':TCPKeepAlive=active
2026-02-05 01:18:39 -0500 Wake reason: RTC (Alarm)
2026-02-05 01:22:10 -0500 Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active
2026-02-05 03:34:02 -0500 Wake reason: XDCI (USB)

Ce que cela signifie : Vous voyez des réveils dus à des alarmes RTC (tâches programmées) et à de l’USB.

Décision : Si l’USB wake se corrèle avec la décharge nocturne, débranchez les périphériques/docks la nuit et retestez. Si les réveils RTC se corrèlent, examinez Power Nap / le comportement de maintenance planifiée et les agents installés.

Task 8 (macOS): Inspect current power management settings

cr0x@server:~$ pmset -g
System-wide power settings:
Currently in use:
 standby              1
 Sleep On Power Button 1
 hibernatemode        3
 powernap             1
 womp                 1
 tcpkeepalive         1
 ttyskeepawake        1
 disksleep            10
 sleep                15

Ce que cela signifie : Power Nap (powernap) et Wake on Magic Packet (womp) sont activés ; TCP keepalive est actif.

Décision : Si vous voulez une préservation maximale de la batterie la nuit, désactivez Power Nap et les fonctions de réveil réseau (au moins pour les usages sur batterie). Retestez.

Task 9 (Linux): Check whether the system uses s2idle or deep

cr0x@server:~$ cat /sys/power/mem_sleep
s2idle [deep]

Ce que cela signifie : Le deep sleep est disponible et actuellement sélectionné (les crochets indiquent l’option courante).

Décision : Si la décharge reste élevée, vous avez probablement des événements de réveil ou un périphérique qui ne s’éteint pas correctement même en deep. Passez aux sources de réveil et aux logs.

Task 10 (Linux): Force deep sleep (when supported) for a test

cr0x@server:~$ echo deep | sudo tee /sys/power/mem_sleep
deep

Ce que cela signifie : Vous avez changé la cible de suspension en deep pour cette session de démarrage (la persistance dépend de la configuration de la distro).

Décision : Faites un test d’une nuit. Si la décharge chute fortement, gardez deep par défaut et résolvez séparément tout problème de reprise des périphériques.

Task 11 (Linux): Review suspend/resume logs around last sleep

cr0x@server:~$ journalctl -b -1 | grep -E "suspend|Suspend|resume|Resume" | tail -n 20
Feb 04 22:40:11 laptop systemd[1]: Starting System Suspend...
Feb 04 22:40:11 laptop kernel: PM: suspend entry (deep)
Feb 04 22:40:12 laptop kernel: ACPI: EC: interrupt blocked
Feb 04 22:40:13 laptop kernel: PM: suspend exit
Feb 04 22:40:13 laptop systemd[1]: Finished System Suspend.
Feb 04 22:40:13 laptop kernel: usb 1-4: reset high-speed USB device number 7 using xhci_hcd
Feb 04 22:40:14 laptop kernel: iwlwifi 0000:00:14.3: WRT: Invalid buffer destination
Feb 04 22:40:14 laptop kernel: PM: Some devices failed to suspend, or did not enter low power state

Ce que cela signifie : Le noyau vous dit que des périphériques ne se sont pas mis en suspension proprement. Le pilote Wi‑Fi est suspect.

Décision : Mettre à jour noyau/firmware pour le Wi‑Fi, tester avec le Wi‑Fi désactivé avant la suspension et inspecter les sources de réveil. Si la désactivation du Wi‑Fi règle la décharge, vous avez un décalage pilote/firmware/économie d’énergie.

Task 12 (Linux): Identify devices allowed to wake the system

cr0x@server:~$ grep -r . /proc/acpi/wakeup | sed -n '1,12p'
Device  S-state   Status   Sysfs node
XHC0      S3    *enabled   pci:0000:00:14.0
RP05      S3    *enabled   pci:0000:00:1c.4
GLAN      S3    *disabled  pci:0000:00:1f.6
HDEF      S3    *disabled  pci:0000:00:1f.3

Ce que cela signifie : Le contrôleur USB (XHC0) et un port racine PCIe (RP05, souvent lié au Wi‑Fi/WWAN/NVMe) peuvent réveiller le système.

Décision : Désactivez temporairement le réveil pour XHC0 pour tester si des périphériques USB provoquent la reprise. Ensuite retestez sans périphériques.

Task 13 (Linux): Disable a wakeup device for testing (temporary)

cr0x@server:~$ echo XHC0 | sudo tee /proc/acpi/wakeup
XHC0

Ce que cela signifie : Cela bascule la capacité de réveil. Relancez cat /proc/acpi/wakeup pour vérifier qu’elle est passée en disabled.

Décision : Si la désactivation de XHC0 règle la décharge nocturne, vous avez soit un périphérique USB bruyant/dock soit un problème de contrôleur/pilote. Décidez ensuite de le laisser désactivé, changer de périphériques ou mettre à jour le firmware.

Task 14 (Linux): Check what woke the system last (systemd)

cr0x@server:~$ journalctl -b | grep -E "Wakeup|wakeup|ACPI: Waking up" | tail -n 10
Feb 05 03:34:01 laptop kernel: ACPI: Waking up from system sleep state S3
Feb 05 03:34:01 laptop kernel: xhci_hcd 0000:00:14.0: xHC error in resume, USBSTS 0x401, Reinit
Feb 05 03:34:01 laptop kernel: PM: resume devices took 1.842 seconds

Ce que cela signifie : Le chemin de reprise implique le comportement du contrôleur USB.

Décision : Concentrez‑vous sur les sources de réveil USB et le firmware du contrôleur ; testez sans dock ; envisagez une mise à jour du BIOS.

Task 15 (Cross-platform sanity check): Verify battery health/capacity (Linux example)

cr0x@server:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 | sed -n '1,18p'
  native-path:          BAT0
  vendor:               SMP
  model:                5B10W139
  serial:               0123
  power supply:         yes
  updated:              Wed 05 Feb 2026 08:01:22 AM
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    energy:              28.4 Wh
    energy-full:         45.2 Wh
    energy-full-design:  57.0 Wh
    capacity:            79.3%

Ce que cela signifie : La capacité de la batterie est d’environ 79 % du design. Ce n’est pas catastrophique, mais vous avez moins de marge pour la décharge.

Décision : Si la décharge est limite, une capacité dégradée la rendra catastrophique. Vous corrigez toujours la décharge en veille, mais planifiez aussi un remplacement de batterie si vous comptez sur de longues périodes hors charge.

Task 16 (Windows): Detect if “shutdown” is actually hibernated (Fast Startup)

cr0x@server:~$ powercfg /hibernate
Hibernation has not been enabled.

Ce que cela signifie : L’hibernation est désactivée ; Fast Startup peut aussi être impliqué.

Décision : Si vous voulez un « arrêt » fiable avec une faible consommation, activez l’hibernation et choisissez hiberner explicitement pour les voyages. Si vous suspectez une « décharge après arrêt », auditez Fast Startup et le comportement USB en S5 dans le BIOS.

Listes de contrôle / plan étape par étape

Checklist A: One-night isolation test (the quickest win)

1. Chargez jusqu’à un pourcentage connu (par ex. 80 %). Notez‑le.
2. Débranchez tous les périphériques : dock, dispositifs USB, cartes SD, écrans externes.
3. Désactivez le Bluetooth pour le test si possible.
4. Sur Windows, mettez le réseau en mode avion ou désactivez le « network connected standby » si vos politiques le permettent.
5. Mettez la machine en veille. Ne vous contentez pas de fermer le capot si vous ne lui faites pas confiance—utilisez l’action de veille de l’OS.
6. Laissez 8–10 heures.
7. Vérifiez le pourcentage de batterie et la température.

Interprétation : Si la décharge est minimale maintenant, vos périphériques ou dispositifs capables de réveil sont la cause. Si la décharge reste élevée, c’est le comportement de veille de la plateforme, le firmware ou un pilote qui maintient la consommation de base élevée.

Checklist B: Decide between S3/deep vs Modern Standby/s2idle

1. Vérifiez les états supportés (Windows : powercfg /a ; Linux : /sys/power/mem_sleep).
2. Si S3/deep existe : passez en deep et testez une nuit.
3. Si ce n’est pas le cas : arrêtez de pleurer S3. Durcissez Modern Standby en éliminant les sources de réveil et l’activité réseau de fond.

Checklist C: Wake source lockdown (stop the “night shift”)

1. Listez les périphériques armés pour le réveil (Windows : powercfg /devicequery wake_armed).
2. Désactivez le réveil pour les NIC sauf si requis explicitement.
3. Désactivez le réveil pour les souris et récepteurs USB (ils génèrent du bruit).
4. Désactivez les wake timers sur batterie (ou restreignez‑les).
5. Retestez la nuit suivante.

Checklist D: Firmware and drivers (the unsexy fix that works)

1. Mettez à jour le BIOS/UEFI vers la dernière version stable.
2. Mettez à jour les pilotes Wi‑Fi et chipset (ou sur Linux, mettez à jour noyau + paquet firmware).
3. Mettez à jour le firmware du dock si vous en utilisez un.
4. Relancez votre test de base nocturne.

Checklist E: Use hibernate strategically

1. Activez l’hibernation.
2. Utilisez l’hibernation quand le portable sera dans un sac pendant des heures.
3. Utilisez la veille quand vous avez besoin d’un retour rapide et que le portable est sur un bureau.

Interprétation : L’hibernation est le mode « l’énergie, c’est de l’argent ». La veille est le mode « le temps, c’est de l’argent ». Choisissez selon ce que vous dépensez.

FAQ

1) Pourquoi mon portable se décharge plus en veille maintenant que les anciens modèles ?

Parce que la « veille » signifie souvent S0 low power idle (Modern Standby / s2idle), qui autorise plus d’activité en arrière‑plan et repose fortement sur une coordination parfaite pilote/firmware.

2) Modern Standby est‑il intrinsèquement mauvais ?

Non. Quand la plateforme atteint des états d’idle profonds et que les événements de réveil sont contrôlés, ça peut être efficace. Le problème est qu’un seul périphérique mal comporté peut maintenir tout le système dans un état de consommation supérieur.

3) Mon portable est chaud dans mon sac. Que faire immédiatement ?

Cessez d’utiliser la veille pour le transport en sac. Utilisez l’hibernation ou éteignez, et désactivez Wake on LAN/USB. La chaleur est la preuve d’un travail effectué, et travailler dans un sac fait vieillir les batteries plus vite.

4) Désactiver le Bluetooth résoudra‑t‑il la décharge nocturne ?

Parfois. Les périphériques Bluetooth peuvent déclencher des réveils ou maintenir les radios actives. C’est un bon test d’isolation. Si ça aide, vous pouvez laisser le Bluetooth activé mais désactiver les capacités de réveil ou modifier le comportement des périphériques.

5) Pourquoi le branchement sur un dock USB‑C aggrave‑t‑il la situation ?

Les docks ajoutent des adaptateurs réseau, des hubs USB, des périphériques audio et parfois du stockage—autant de sources potentielles de réveil. Ils maintiennent aussi les contrôleurs Thunderbolt/USB4 actifs. Mettez à jour le firmware du dock et désactivez le réveil sur les périphériques non essentiels.

6) Dois‑je simplement désactiver la veille et toujours utiliser l’hibernation ?

Si votre priorité est une faible consommation garantie, oui. Le compromis est un redémarrage plus lent et plus d’écritures SSD (globalement sans gravité, mais existant). Beaucoup de gens utilisent la veille au bureau et l’hibernation pour les voyages. C’est le compromis raisonnable.

7) Sur Linux, quelle est la différence entre s2idle et deep ?

s2idle est un état d’inactivité coordonné par logiciel en S0 ; il dépend davantage du bon comportement des pilotes. deep correspond à S3 suspend‑to‑RAM quand c’est supporté, typiquement plus faible consommation mais parfois moins compatible.

8) Un SSD peut‑il vraiment affecter la décharge en veille de la batterie ?

Oui. Si le disque NVMe n’entre pas en états de basse consommation, il peut empêcher l’idle profond de la plateforme. Vous verrez une consommation de base plus élevée sans événements de réveil évidents.

9) Comment savoir si c’est des réveils ou une consommation de base élevée ?

Cherchez des logs/rapports montrant de nombreux événements de réveil (Windows powercfg, macOS pmset, Linux journalctl). Si les réveils sont rares mais que la décharge reste élevée, suspectez la consommation de base (états de puissance des périphériques, firmware).

10) Si je mets à jour BIOS et pilotes et que ça se décharge encore, que faire ?

Exécutez le test d’isolation (sans périphériques, radios éteints) et comparez veille vs hibernation. Si l’hibernation est correcte et que la veille ne l’est pas, vous avez confirmé un problème d’état de veille. À ce stade, choisissez l’hibernation par défaut pour la nuit et continuez à traquer le pilote/périphérique spécifique en parallèle.

Conclusion : étapes suivantes pour arrêter la fuite

Cessez de vous battre avec le mot « veille ». Traitez‑le comme un mode d’exploitation qui nécessite vérification, journalisation et budget. Votre objectif est une décharge prévisible, pas une pureté philosophique.

1. Confirmez votre état de veille (Windows powercfg /a, Linux /sys/power/mem_sleep, macOS journaux pmset).
2. Exécutez un test d’isolation d’une nuit avec tous les périphériques retirés et les radios réduites. Établissez une base.
3. Éliminez les sources de réveil (NIC, USB, Bluetooth, wake timers) une catégorie à la fois, en retestant après chaque changement.
4. Mettez à jour le BIOS et les pilotes/firmware critiques avant de faire quoi que ce soit de subtil. Les astuces sont fragiles ; les bugs firmware sont réels.
5. Adoptez l’hibernation pour les voyages et la nuit si votre plateforme ne délivre pas une veille basse consommation de façon cohérente. Ce n’est pas une défaite ; c’est de la maturité opérationnelle.

Quand votre portable se réveille la nuit, il doit le faire parce que vous le lui avez demandé. Tout autre cas est un incident. Traitez‑le comme tel.