L'insomnie du MacBook Pro

• Sur un MacBook Pro Silicon M1 Max, j'ai observé une consommation de batterie la nuit.
• J'ai tenté d'analyser les logs de gestion d'alimentation moi-même, mais cela n'a pas suffi pour identifier la cause du problème.
• Grâce à l'application dédiée Sleep Aid, il est possible de visualiser visuellement les événements de réveil.
• Dans les paramètres de Sleep Aid, j'ai constaté que la désactivation de "Wake for maintenance" (réveil de maintenance) était responsable du problème.
• Après avoir à nouveau activé cette option, la décharge nocturne de la batterie a été résolue.

---

Expérience d'un problème de décharge de batterie pendant la nuit sur MacBook Pro

• J'utilise un MacBook Pro Silicon M1 Max depuis plusieurs années.
• Récemment, lorsque je laisse le portable non branché, j'ai constaté une décharge nocturne de la batterie qui devient très importante.
• Le problème s'est aggravé progressivement, ce qui m'a conduit à lancer une analyse directe de la cause.

Tentative d'analyse du journal de gestion de l'alimentation

• Sous macOS, la commande terminale pmset -g log permet de consulter le journal lié à la gestion de l'alimentation.
• La sortie de ce journal est volumineuse et difficile à interpréter, alors j'ai utilisé un petit outil simple que j'ai développé moi-même, pmset-analyzer, pour l'analyse des logs.
• Toutefois, cet outil n'a pas grandement aidé à trouver une solution concrète.

Ajustement des réglages précis et investigations supplémentaires

• En suivant la documentation officielle et les communautés, j'ai ajusté un à un les réglages de gestion d'alimentation tels que tcpkeepalive.
• Les modifications de réglages seules n'ont pas eu d'effet significatif sur la résolution du problème.

Résolution grâce à l'application Sleep Aid

• Au cours des investigations supplémentaires, j'ai découvert une application nommée Sleep Aid.
  • Cette application affiche visuellement les wake events (événements de réveil) et offre une interface intuitive pour modifier divers paramètres de gestion de l'alimentation.
• J'ai constaté via Sleep Aid que l'option "Wake for maintenance (Réveil pour maintenance)" était désactivée.
• Selon la description de l'application, si ce réglage est désactivé, des événements de réveil fréquents peuvent survenir.
• J'ai à nouveau activé cette option, et depuis, la décharge de batterie pendant la nuit ne se produit plus.

[ahwjdekf]

Je mets mon MacBook en veille pour dormir, puis soudain, en pleine nuit, l’écran s’allume et toute la chambre est illuminée. Ça m’est arrivé souvent de me réveiller à cause de ça et de simplement l’éteindre complètement. Ça fait polémique depuis un moment déjà, et pourtant c’est toujours là...

[GN⁺]

Commentaires sur Hacker News

• Encore une astuce utile à partager. Dans le Moniteur d’activité, ouvrez l’onglet Energy et triez par la colonne « Preventing sleep » pour voir quelles apps empêchent macOS de se mettre en veille. Dans mon cas, j’ai identifié l’app Devonthink comme responsable. Je n’ai pas encore soumis de bug report. Je trouve étrange que la gestion de l’alimentation d’Apple n’avertisse pas l’utilisateur de ce genre de problème. Je me demande si ce n’est pas un sujet important quand un Mac chauffe dans un sac et vide sa batterie. Pendant ce temps, le fait que Chrome demande sans cesse l’autorisation de rechercher des appareils sur le réseau me semble bien moins important
  • Je suis déjà surpris que la gestion de l’alimentation d’Apple n’affiche pas d’alerte à ce sujet, mais je suis encore plus surpris qu’une app puisse empêcher le système de se mettre en veille même quand le capot est fermé. Je comprends qu’une prévention de veille basée sur un timeout soit parfois nécessaire, par exemple pour un lecteur vidéo. En revanche, il y a très peu de cas où il est vraiment utile qu’une app décide que le système ne doit pas dormir quand on ferme le capot ou qu’on appuie sur le bouton de veille. Dans la plupart des cas, cela augmente surtout les chances de retrouver un portable en surchauffe dans un sac à dos. En plus, si une simple page web peut empêcher le système de dormir, il devient difficile de savoir lequel des 70 onglets pose problème. Ce serait bien de séparer le droit d’empêcher la veille via timeout et le droit de modifier un comportement cœur du système comme « fermer le capot = dormir systématiquement ». On peut autoriser l’usage d’un timeout, mais pour un événement comme la fermeture du capot, le système devrait obligatoirement prévenir l’utilisateur et demander son accord
  • Je ne savais pas que n’importe quelle app pouvait empêcher la veille de l’ensemble du système. Ce type d’autorisation devrait clairement être sous le contrôle de l’utilisateur. Je me demande si les développeurs ne devraient pas au minimum avoir besoin d’un entitlement pour appeler ces API
  • Dans le shell, la commande pmset -g assertions permet de voir quels processus empêchent le système de se mettre en veille, ainsi que les détails des power assertions en attente. pmset contient aussi des commandes qui ne figurent pas dans la documentation officielle, mais qu’on peut repérer dans le code source publié par Apple. Il existe également une commande pour ignorer une assertion donnée. Attention toutefois : si vous désactivez l’assertion « UserIsActive », il peut devenir difficile de réveiller le système
  • Je ne connaissais pas cette fonction, merci. Je me demandais récemment pourquoi la batterie de mon MacBook, que je n’utilisais pas, se déchargeait sans arrêt, et il s’est avéré que Firefox empêchait la veille. C’est probablement à cause des vidéos en autoplay. Ce n’est pas idéal, mais au moins c’est un problème qu’on peut corriger
  • Safari, de son côté, affiche une notification disant de le fermer quand il consomme trop d’énergie pendant qu’on regarde Netflix
• J’ai eu un problème similaire sur mon MacBook Pro également. Ce n’était pas un modèle Apple Silicon, mais un ancien modèle. À l’époque, j’avais modifié sur mon routeur la durée de bail DHCP pour la passer à 15 minutes, bien en dessous de la valeur par défaut. Je pense que le MacBook se réveillait toutes les 15 minutes pour renouveler son IP, puis se rendormait brièvement avant de se réveiller à nouveau, encore et encore. Quand j’ai remis la durée du bail du routeur à sa valeur par défaut précédente, le problème de batterie s’est complètement résolu. C’était difficile à deviner, mais comme je venais justement d’acheter un nouveau MacBook Pro, j’étais plus attentif que d’habitude à ce genre de problèmes, ce qui m’a permis de trouver rapidement la cause
  • Un client DHCP correctement implémenté tente de renouveler son bail à 50 % de sa durée. Il est donc probable qu’il se réveillait encore plus souvent que vous ne le pensez
  • Je suis curieux de savoir pourquoi vous aviez mis la durée du bail DHCP à 15 minutes. Quel était l’objectif ?
  • Je viens de l’apprendre moi aussi, mais le routeur mikrotik que j’utilise définit par défaut une durée de bail de 10 minutes
  • Je trouve ça fascinant. Je me demande combien de mAh sont consommés à chaque réveil pour renouveler l’IP. J’imagine quelque chose de l’ordre de quelques milliampères-millisecondes, puisqu’au final le portable ne fait sans doute qu’allumer brièvement le Wi‑Fi et échanger quelques paquets. Bien sûr, comme c’était un modèle d’avant Apple Silicon, il est possible qu’il fasse aussi d’autres choses pendant qu’il est réveillé
  • Je pense que c’est un bug de macOS. Quand la machine est en veille, elle n’a pas besoin d’une IP, donc se réveiller pour renouveler un bail DHCP n’est pas normal. C’est le genre de problème qu’on rencontre avec un OS dont le code source n’est pas public
• Si l’option « Wake for maintenance » est désactivée, Sleep Aid indique dans sa fenêtre de réglages que cela peut entraîner des réveils fréquents. Je me demande si l’auteur n’a pas écrit par erreur « l’option était désactivée »
  • J’ai pensé la même chose. Ce n’est qu’une hypothèse, mais si ce réglage est désactivé, les événements de réveil ne seraient peut-être pas regroupés par créneaux horaires pour être traités d’un coup, et pourraient au contraire se produire à n’importe quel moment tout au long de la nuit. Cela semble justement expliquer le phénomène observé
  • Je trouve ça contre-intuitif. Je me demande si le fait d’activer explicitement une option de réveil de l’ordinateur peut en réalité réduire le nombre de réveils
  • Moi aussi ça me perturbe. Dans la capture d’écran de l’auteur, c’est indiqué comme activé. Cela paraît être l’état « normal », donc il n’est pas intuitif de comprendre pourquoi l’état désactivé provoquerait davantage de réveils
  • Ce genre d’explication contraire au bon sens mérite un complément d’explication, ou au moins de préciser clairement qu’il s’agit d’une exception. C’est le genre de problème difficile à repérer quand on relit et corrige un article après publication
• Sur tous les Mac portables que j’ai eus, j’ai toujours réglé la fermeture du capot sur l’hibernation pour éviter ce problème. À la réouverture, il faut attendre environ 20 à 30 secondes pour reprendre la session, mais je trouve que c’est un faible prix à payer pour avoir beaucoup moins à se soucier de la veille et de la batterie. On peut le faire dans le terminal avec cette commande : sudo pmset -a hibernatemode 25. Pour revenir au réglage d’origine, il suffit d’entrer sudo pmset -a hibernatemode 3
  • Je me demande si le mode hibernation fonctionne bien avec le FDE (chiffrement complet du disque). Sous Linux, écrire le contenu de la mémoire sur disque implique tout un ensemble de précautions liées au chiffrement
  • Je pense que c’est la manière la plus simple de configurer le comportement que la plupart des gens attendent
• J’ai vraiment passé énormément de temps à creuser les problèmes de veille sur Mac, mais dans mon cas, le responsable semble être WindowServer, et il va probablement falloir réinstaller complètement l’OS. Il n’y a presque rien de plus frustrant que de sortir de son sac, une fois tous les un ou deux mois, un portable chaud et complètement déchargé, puis d’entendre en réponse : « moi ça ne m’est jamais arrivé, tu dois mal l’utiliser »
• J’ai l’impression que macOS est quasiment en mode maintenance depuis dix ans. J’imagine qu’il y a eu un énorme travail de portage vers ARM/Mac Silicon. Les mises à jour IA ont aussi été décevantes, et j’ai l’impression qu’il n’y a pas eu beaucoup d’améliorations vraiment substantielles récemment. Il y a longtemps, j’utilisais un Intel Macbook Air dont le bouton d’alimentation était juste à côté de la touche retour arrière, et j’avais trouvé sur un forum Mac un script qui obligeait à maintenir le bouton au lieu d’éteindre la machine au moindre appui. Mais ce script contenait un cheval de Troie, et j’ai dû réinitialiser le Mac aux paramètres d’usine ainsi qu’effacer tout iCloud. On m’a dit que ce script contenait aussi des GUID qui semblaient être des variables internes et qu’il pouvait télécharger des ressources depuis un endroit inconnu. Moi, j’avais simplement cru qu’il s’agissait de variables internes
• La documentation officielle d’assistance Apple indique que cette fonction (options d’alimentation) est fournie nativement
  • Sur mon M4 MacBook Air avec macOS 26 DB installé, il n’y a pas de power nap à cet endroit. À la place, on trouve « Wake for network access », avec la valeur par défaut « Only on Power Adapter »
  • Je croyais à tort que power nap et « wake for network access » étaient la même chose. Il semble qu’il n’y ait plus d’option distincte dans macOS 26. Chez moi, le réglage est sur « Only on Power Adapter », ce qui paraît raisonnable. Je parle bien d’un M4 MacBook Air
• J’ai moi aussi écrit un billet de blog presque identique la semaine dernière. Malheureusement, dans mon cas, cette solution n’a pas fonctionné, car autre chose que power nap continue de réveiller la machine. Article lié : post sur annoying.technology
• L’onglet Energy du Moniteur d’activité est utile dans ce genre de situation. Il permet de voir quelles apps empêchent complètement la mise en veille du système, ainsi que la consommation électrique de chaque processus sur les 12 dernières heures. On peut ainsi remonter rapidement à la cause dès le lendemain matin
• Je rencontre moi aussi un problème similaire sur un MacBook Pro (Apple Silicon). Si je mets la machine en veille avec un SSD branché, le système semble se réveiller périodiquement pour réactiver le disque. Résultat : le portable comme le SSD chauffent, et la batterie se vide rapidement. La seule parade que j’ai trouvée est de débrancher tous les disques externes avant la mise en veille et de laisser l’ordinateur branché au chargeur. C’est un bug assez pénible. J’ai l’impression qu’il y a eu un manque de contrôle qualité et de tests