Qu'est-ce qui empêche votre Mac de s'endormir ? Voici comment le découvrir

Comment fonctionnent les assertions d'alimentation de macOS

macOS ne s'endort pas sur la seule foi d'un compte à rebours. Avant d'assombrir l'écran ou de mettre le disque en veille, le noyau vérifie si un processus en cours détient une assertion d'alimentation — une requête déposée via le framework de gestion d'énergie IOKit, qui indique au système qu'il doit rester éveillé. macOS respecte cette requête jusqu'à ce que le processus la relâche, ou jusqu'à ce qu'il se termine.

Deux types d'assertions expliquent la majorité des comportements de mise en veille. PreventUserIdleSystemSleep empêche totalement le Mac de s'endormir — disque, écran, tout. PreventUserIdleDisplaySleep garde seulement l'écran allumé et laisse le reste du système s'endormir s'il le souhaite. Un gestionnaire de téléchargements, un lecteur vidéo, caffeinate lancé depuis Terminal, ou une appli qui garde le Mac éveillé comme LidRun peuvent détenir l'un ou l'autre type, pour des raisons différentes.

Les assertions ne sont pas un bug — c'est une fonctionnalité voulue, et le même mécanisme joue dans les deux sens. Le verrou qui garde un Mac éveillé pendant une session IA de toute une nuit est exactement le même mécanisme qu'un onglet de navigateur oublié utilise pour garder le Mac éveillé après la fin d'une vidéo. L'objectif n'est pas de se méfier de chaque assertion, mais de savoir lesquelles vous avez demandées et lesquelles se sont invitées.

Utiliser Activity Monitor pour trouver la cause

Ouvrez Activity Monitor depuis Applications → Utilitaires, ou trouvez-le avec Spotlight. Cliquez sur l'onglet Énergie. La colonne Empêche la veille affiche Oui ou Non pour chaque processus suivi par le système — cliquez sur l'en-tête de colonne pour faire remonter les assertions actives en haut de la liste.

Les surprises les plus fréquentes dans cette liste : un onglet de navigateur avec une vidéo en pause, un client de synchronisation cloud en plein envoi, une sauvegarde Time Machine encore en cours en arrière-plan, une appli de podcast, ou un appel vidéo resté ouvert après que vous avez quitté la réunion. Faites un clic droit sur une entrée suspecte et choisissez Inspecter le processus pour voir son chemin binaire complet et son processus parent — ça suffit généralement à trancher.

Activity Monitor est un bon premier réflexe, mais il a des angles morts. Les outils en ligne de commande et les daemons en arrière-plan — y compris caffeinate lancé depuis Terminal — apparaissent parfois sous un nom générique, voire pas du tout dans la liste. Pour ceux-là, la commande Terminal ci-dessous donne une vue plus complète.

Lire pmset -g assertions dans Terminal

Ouvrez Terminal et lancez pmset -g assertions. Le résultat liste toutes les assertions d'alimentation actives sur le système : le type, le nom lisible que l'appli lui a donné, et l'identifiant du processus (PID) qui l'a déposée. Un bloc récapitulatif en haut les répartit entre Listed (actives actuellement) et Timed Out (le minuteur s'est déclenché, mais l'appli n'a jamais appelé release).

Une assertion expirée (timed out) peut quand même bloquer la mise en veille — le processus avait fixé une échéance, l'échéance est passée, mais le verrou lui-même n'a jamais été relâché. Si un PID dans le résultat vous semble inconnu, croisez-le avec ps aux | grep, suivi de ce PID, pour confirmer à quel processus il appartient. Certaines assertions portent un délai explicite ; d'autres sont indéfinies — une PreventUserIdleSystemSleep indéfinie détenue par un agent en arrière-plan figé ou planté garde le Mac éveillé sans cause visible, et c'est la première chose à vérifier si la machine tourne depuis bien plus longtemps que prévu.

pmset -g assertions ne montre que ce qui est actif à l'instant présent — il n'a pas de mémoire. Deux commandes voisines comblent ces manques. pmset -g seul (sans le paramètre assertions) inclut une ligne SleepDisabled — un réglage global différent, que certains outils, et le mode Closed-Lid de LidRun lui-même, activent avec pmset -a disablesleep au lieu de déposer une assertion classique (on y revient dans la section suivante). Et pmset -g log affiche un historique des événements de veille, de réveil et d'assertions, utile si vous voulez savoir ce qui a gardé le Mac éveillé pendant la nuit plutôt qu'à l'instant présent.

Pour arrêter une assertion en ligne de commande comme caffeinate, trouvez son PID dans le résultat de pmset et lancez kill suivi de ce PID. Quitter une appli relâche aussi ses assertions immédiatement — les assertions classiques sont liées au processus, donc macOS les efface dès que le processus se termine, sans étape de nettoyage séparée. Si une assertion n'a pas de propriétaire clair, ou que son processus a déjà planté, un redémarrage efface tous les verrous restants.

Quand pmset -g assertions ne renvoie rien

Il arrive que pmset -g assertions ne renvoie rien du tout, alors que le Mac donne quand même l'impression de ne jamais vraiment s'éteindre — le ventilateur monte et redescend, ou l'écran s'allume brièvement sans aucune appli en vue. Ce n'est généralement pas une assertion cachée ; c'est un réveil furtif programmé (dark wake). macOS se réveille périodiquement et brièvement pour des tâches réseau — synchronisation iCloud, Find My, Handoff, Power Nap — même sans qu'aucun verrou ne soit posé, puis se rendort de lui-même quelques secondes plus tard.

Pour écarter cette hypothèse, allez dans Réglages Système → Batterie → Options et désactivez Réveil pour accès réseau. Ça n'arrêtera pas une vraie assertion — si quelque chose dépose vraiment une PreventUserIdleSystemSleep, ce réglage n'y changera rien — mais ça supprime le bruit de fond, ce qui rend une nouvelle vérification pmset -g assertions plus facile à lire.

C'est aussi le moment de vérifier pmset -g seul, à la recherche d'une ligne SleepDisabled: 1, décrite plus haut. Elle n'apparaîtra pas sous pmset -g assertions, car ce n'est pas une assertion — c'est un réglage système permanent, le plus souvent laissé actif par pmset -a disablesleep depuis un script, un outil tiers, ou une appli (le mode Closed-Lid de LidRun y compris) qui a planté avant de pouvoir se désactiver elle-même.

Assertions de réveil voulues ou non désirées

Toutes les assertions ne doivent pas forcément disparaître. Si vous faites tourner une longue session Claude Code, un job de modèle local, ou un agent Cursor toute la nuit, il est normal que quelque chose détienne cette assertion — la tuer tuerait aussi votre travail. La vraie question n'est pas seulement « pourquoi mon Mac est-il éveillé ? » mais « est-ce que je l'ai demandé ? »

Un gestionnaire de téléchargements qui bloque la mise en veille jusqu'à la fin d'un transfert fait son travail. Un lecteur vidéo qui la bloque après que vous avez fermé la fenêtre, non. Un outil que vous avez configuré exprès — LidRun, caffeinate -i lancé à la main — est intentionnel. Un onglet de navigateur avec une vidéo en pause que vous avez oublié ne l'est pas. La distinction se joue sur le consentement, pas sur le mécanisme.

Si vous arrivez à « oui, c'est ce que je veux », il existe déjà des options gratuites et natives. caffeinate -i, lancé depuis Terminal, dépose la même assertion PreventUserIdleSystemSleep décrite plus haut, pour toute la durée d'exécution de la commande — ajoutez -t 3600 pour un plafond d'une heure. Elle est liée au processus, donc terminer la commande ou fermer la fenêtre Terminal la relâche automatiquement. Caffeinate ne peut rien pour un capot fermé, en revanche — une assertion de veille inactive n'atteint pas la mise en veille du mode clamshell. Le seul levier gratuit à ce niveau est sudo pmset -a disablesleep 1, et il se comporte différemment, volontairement : c'est un réglage global et permanent plutôt que lié à un processus, donc il survit même si l'appli qui l'a activé plante, et reste actif jusqu'à ce que quelque chose exécute explicitement pmset -a disablesleep 0, ou que le Mac redémarre. Des applis de barre de menu comme Amphetamine, KeepingYouAwake, Lungo et Caffeine enveloppent ce même mécanisme sous-jacent dans un interrupteur en un clic, ce qui est un très bon choix si un simple bouton manuel vous suffit. Dans tous les cas, c'est toujours la même assertion ou le même indicateur disablesleep en coulisses — c'est justement pourquoi pmset -g assertions vaut la peine d'être connu, quel que soit l'outil qui a déposé le verrou. La comparaison LidRun vs caffeinate détaille l'ensemble des coûts et fonctionnalités.

Pour un verrou que vous voulez garder, mais garder de façon sûre, ce qui compte, ce sont les garde-fous : un arrêt automatique avant que la batterie ne tombe à un niveau dangereusement bas, une prise en compte de l'état thermique pour qu'un Mac chaud ne soit pas maintenu éveillé indéfiniment, et un cadrage de l'assertion sur une seule tâche, pour qu'elle se relâche dès que cette tâche se termine au lieu de compter sur la mémoire de l'utilisateur. L'Auto Mode de LidRun gère ce cadrage : indiquez-lui un nom de processus — une session Claude Code, un build, un rendu — et il ne détient l'assertion que pendant que ce processus tourne, puis la relâche à l'instant même où le processus se termine. Agent en cours, le Mac reste éveillé ; agent terminé, le verrou se relâche — c'est toute la logique du système, pas un verrou de réveil aveugle laissé actif jusqu'à ce que quelqu'un pense à l'éteindre. Le guide réveil automatique, seulement pendant le travail détaille ce fonctionnement. Sur batterie, LidRun s'arrête aussi de lui-même en dessous d'un seuil — 20 % par défaut, réglable de 15 % à 50 % — quel que soit ce qui tourne encore, et sort du mode Closed-Lid dès que le système signale une pression thermique critique (avec un avertissement au stade sérieux, juste avant), parce qu'un capot fermé bloque la principale voie de refroidissement du Mac, et qu'aucune automatisation ne devrait le garder fermé en pleine surchauffe.

Quand le coupable n'est pas désiré, quitter l'appli règle le problème immédiatement. Si le même processus revient sans cesse après un redémarrage, vérifiez Réglages Système → Général → Éléments de connexion et éléments en arrière-plan, à la recherche d'agents configurés pour se lancer automatiquement. Supprimer ou désactiver l'élément de connexion arrête le cycle à la source.