Gardez votre Mac éveillé uniquement quand il travaille vraiment

Une appli ouverte n'est pas une appli qui travaille

Un simple verrou anti-veille ne fait pas la différence entre un build qui tourne à plein régime et un éditeur resté inactif pendant une heure. Pour lui, ce sont juste deux processus qui existent, donc il maintient le Mac éveillé dans les deux cas — et continue de le faire bien après que le travail est réellement terminé.

Mais « l'appli est ouverte » et « l'appli travaille » sont deux choses différentes. Claude Code qui attend votre prochaine instruction à l'invite ne sollicite pas le CPU. Un daemon Ollama sans rien de chargé non plus. Garder le Mac éveillé pour l'un ou l'autre, c'est juste vider la batterie pour rien.

L'Auto Mode trace la ligne au niveau de l'activité, pas de la présence. Il surveille une liste d'outils de dev et d'IA et pose une question plus précise pour chacun : ce processus est-il vraiment occupé en ce moment, ou tourne-t-il simplement ?

La méthode gratuite qu'on essaie en premier : caffeinate et pmset

macOS propose déjà deux façons gratuites de s'en approcher, et ça vaut la peine de les connaître avant de se tourner vers une appli. caffeinate est un outil en ligne de commande intégré : lancez caffeinate -i npm run build et le Mac ne partira pas en veille tant que cette commande tourne. Dès que le build se termine, caffeinate se termine avec lui, et l'assertion disparaît. C'est vraiment proche de garder un Mac éveillé seulement quand il travaille, ça ne coûte rien, et ça ne demande aucune configuration.

Pour une configuration écran fermé, la brique gratuite d'un cran en dessous, c'est sudo pmset disablesleep 1 — elle indique à macOS d'ignorer complètement sa propre politique de veille, écran fermé y compris. C'est le même interrupteur de base qu'appelle finalement toute appli en mode clamshell, y compris le Closed-Lid de LidRun. On l'active, on ferme l'écran, et le Mac continue de tourner.

Il existe aussi une voie sans aucun logiciel : brancher un écran externe, un clavier et une souris pendant que le Mac est sur secteur, et le comportement clamshell natif d'Apple le laisse tourner écran fermé sans rien installer. Ça ne fonctionne toutefois que relié à un écran et au secteur — peu utile pour un portable qui travaille seul, sur batterie, dans un café.

Là où les outils gratuits montrent leurs limites

caffeinate n'a aucune idée de si la commande qu'il enveloppe est réellement occupée. Pointez-le vers un REPL interactif que vous avez laissé sans surveillance, et il maintient le Mac éveillé à 0 % de CPU tant que le shell reste ouvert — parce qu'il ne regarde jamais le CPU, il vérifie seulement que le processus existe encore.

pmset disablesleep est risqué d'une manière bien précise : il n'est rattaché à rien. Rien ne le remet à 0 automatiquement. On l'active une fois pour un build tardif, on l'oublie, et le Mac reste éveillé — écran fermé, peut-être dans un sac — aussi longtemps que le réglage reste actif. C'est une façon bien connue de retrouver un Mac chaud et déchargé plus tard. C'est exactement pour ça que le Closed-Lid de LidRun, qui appelle ce même interrupteur pmset, fait toujours suivre le 1 d'un 0 correspondant à l'arrêt, à la fermeture et de nouveau au relancement, plutôt que de compter sur la mémoire de quiconque.

Aucun des deux outils ne surveille la batterie ou l'état thermique. Ils maintiendront un Mac éveillé à 2 % de charge ou ventilateurs à fond aussi facilement qu'à 90 % et au frais, parce qu'aucun signal de ce type n'est intégré — gérer ce compromis vous revient entièrement.

Aucun des deux n'est non plus conscient des processus à l'échelle d'une session entière. Lancez Claude Code dans un onglet de terminal, un serveur de dev dans un autre, et Docker en arrière-plan : caffeinate ne connaît que le seul PID contre lequel vous l'avez lancé — il faudrait envelopper chaque commande séparément, et penser à le faire.

Comment l'Auto Mode mesure l'activité

LidRun repère les outils par nom de processus ou par bundle d'appli, et pour les interpréteurs shell — python, node, ruby, perl, bun, deno, java, sh, bash, zsh, php — il lit aussi la ligne de commande, si bien qu'un motif comme train.py est reconnu même si le processus qui l'exécute s'appelle simplement « python ». La détection n'est pourtant que la moitié du travail.

Le CPU est le facteur décisif. Pour un processus en ligne de commande, le seuil par défaut est 20 % d'un cœur, réglable de 1 % à 50 % dans Réglages. Une appli GUI doit franchir un seuil fixe de 40 % d'un cœur, quel que soit ce curseur — une fenêtre Cursor simplement ouverte et qui tourne à quelques pourcents ne compte jamais, seule celle qui compile ou indexe vraiment compte. Un tout nouveau processus CLI bénéficie du doute lors de sa toute première vérification, puisqu'il n'y a pas encore d'écart de CPU à comparer et que LidRun préfère ne pas rater le début d'une vraie tâche ; une appli GUI n'a droit à aucun passe-droit de ce genre.

Les agents de code connus — Claude Code, Codex, l'agent de Cursor, Windsurf, Aider, Cline, Continue, Goose, OpenHands, Zed, ainsi que des runtimes locaux comme Ollama, LM Studio et vLLM — bénéficient d'une couche supplémentaire une fois qu'ils ont prouvé avoir réellement travaillé au moins une fois : ensuite, ils comptent comme actifs par simple présence plutôt que par % de CPU, parce qu'un agent qui attend une réponse de modèle peut rester près de 0 % de CPU sans avoir vraiment terminé. Un agent tout juste lancé, qui n'a encore rien fait, doit gagner cette confiance de la façon normale, sur le CPU.

Le délai de grâce, avec des chiffres réels

Les charges de travail réelles sont irrégulières — un build marque une pause entre les étapes, un agent attend un appel réseau, une inférence reprend son souffle entre deux tokens. Relâcher l'assertion dès que le CPU redescend, et le Mac pourrait s'endormir en plein milieu d'une tâche.

Le délai de grâce par défaut est de 60 secondes, réglable de 10 à 600 dans Réglages : après le dernier échantillon actif, LidRun continue de tenir pendant ce laps de temps avant de conclure que le travail s'est vraiment arrêté. Un agent connu qui a déjà prouvé son activité bénéficie à la place d'un délai de grâce plus long, 30 minutes, parce que rester quasi inactif en attendant une réponse d'API fait partie normale du travail, pas un signe que c'est terminé.

La fréquence à laquelle LidRun vérifie est un réglage distinct du temps qu'il attend. L'intervalle de sondage est Rapide (5 secondes), Équilibré (10 secondes, la valeur par défaut), ou Économie de batterie (30 secondes) — ou n'importe quelle valeur exacte de 1 à 60 secondes en mode Avancé. Une vérification plus espacée sacrifie un peu de réactivité contre moins de CPU consommé en arrière-plan.

L'Auto Mode avec le Closed-Lid, et voir ce qu'il surveille

L'Auto Mode et le Closed-Lid sont des interrupteurs distincts, pas des modes concurrents, et ils fonctionnent ensemble. L'Auto Mode décide si une tâche est réellement active ; le Closed-Lid, séparément, empêche la fermeture de l'écran de forcer la mise en veille. Activez l'Auto Mode, puis fermez l'écran avec le Closed-Lid actif, et la même logique CPU-et-délai-de-grâce continue de décider si l'assertion tient — ce n'est pas un verrou anti-veille aveugle juste parce que l'écran s'est éteint.

Pour voir ce qu'il surveille réellement, le menu de la barre de menu affiche une carte « Tâches actives » : chaque processus reconnu y apparaît, les processus actifs listés avec leur % de CPU en direct, les inactifs-mais-dans-le-délai-de-grâce résumés en dessous. Si un outil que vous attendiez n'apparaît pas du tout, c'est le signal honnête d'aller vérifier la liste de surveillance plutôt que de supposer que l'Auto Mode est cassé.

Pourquoi le laisser s'endormir est tout l'intérêt

Un verrou anti-veille permanent a un coût, qu'il se passe quelque chose ou non : sur batterie, il vide la cellule ; sur secteur, il empêche quand même la puce de se reposer. L'intérêt de l'Auto Mode, c'est qu'il s'arrête quand le travail s'arrête — et par défaut, si rien de surveillé n'a été actif depuis 20 minutes, LidRun met le Mac en veille de façon proactive, plutôt que de simplement relâcher l'assertion et attendre le minuteur d'inactivité de macOS. Cette fenêtre de 20 minutes, comme le fait même de s'endormir, sont réglables dans Réglages.

Chaque décision anti-veille passe par les mêmes seuils de sécurité, quel que soit le mode actif. Par défaut, LidRun commence à se relâcher à 20 % de batterie, considère 5 % comme critique, et force le relâchement à un plancher dur d'environ 4 %, quoi qu'il tourne encore. L'Auto Mode décide quand rester éveillé est justifié par le travail ; la couche de sécurité décide quand ce n'est plus sûr, point final.

Rien de tout ça ne remplace les précautions de base. Réglez le seuil CPU et le délai de grâce une fois, et oubliez-les en grande partie — mais gardez le Mac ventilé pour les longues sessions d'IA ou de dev, et considérez les seuils de batterie comme un garde-fou, pas comme un substitut au branchement secteur pendant une tâche de plusieurs heures.

Où ça se situe, et ce que ça coûte

L'Auto Mode fait partie de l'offre payante de LidRun. Keep Awake, le Timer et le mode Charging-only sont gratuits, sans limite de session, mais la détection automatique basée sur le CPU décrite dans cet article est réservée à Pro. Si le seul besoin est « rester éveillé le temps que cette commande tourne », caffeinate ou l'enveloppe CLI lidrun -- <command> de LidRun couvrent exactement ce cas gratuitement, sans aucun des réglages ci-dessus.

Face aux autres outils de barre de menu : Amphetamine est gratuit et possède le moteur de règles le plus poussé du groupe — déclencheurs par appli, par réseau, par batterie — mais ses règles portent sur quelle appli tourne, pas sur si elle est réellement occupée. KeepingYouAwake et Caffeine sont de simples interrupteurs gratuits en un clic, sans aucune logique de relâchement automatique. Lungo est un interrupteur payant, épuré, basé sur un minuteur. Aucun des cinq ne surveille le CPU processus par processus comme le fait l'Auto Mode ; c'est un rôle plus étroit, pas une prétention à les surpasser sur ce pour quoi ils ont été conçus.