Faire tourner vos agents IA pendant que vous dormez

Pourquoi le Mac interrompt votre agent IA la nuit

macOS est conçu pour s'endormir dès qu'il ne détecte aucune entrée utilisateur — clavier, souris, trackpad. Un agent IA qui tourne dans un terminal ne génère aucun événement d'entrée, donc la minuterie de veille de l'écran se déclenche en premier, suivie de la veille système. Au moment où la machine se suspend, l'agent perd l'ordonnancement CPU et l'accès réseau — le run s'arrête en plein milieu de la tâche, sans reprise propre, pas même un point de sauvegarde à moins que l'outil n'en ait écrit un lui-même.

Fermer le capot est un déclencheur distinct, plus rapide, et il se moque de ce qui tourne. Par défaut, un MacBook se suspend en quelques secondes après la fermeture du capot, quel que soit le travail en arrière-plan. Un outil comme caffeinate -i bloque la veille d'inactivité tant que le capot est ouvert, mais sur batterie il ne peut pas empêcher la veille clamshell de plus bas niveau que macOS déclenche à l'instant même où le capot se ferme — aucune assertion d'alimentation au niveau utilisateur ne le peut. C'est une limitation de macOS, pas de caffeinate : tout outil construit sur le même mécanisme IOPMAssertionCreateWithName, y compris le Keep Awake manuel de LidRun, se heurte au même mur sans un mécanisme dédié au capot fermé.

La batterie ajoute un troisième mode de défaillance. macOS a son propre arrêt d'urgence en cas de batterie critique, et peut forcer la mise en veille avant ce seuil s'il estime que les conditions le justifient. Un agent qui fait de l'inférence lourde ou un build long peut faire tomber une batterie à 50 % en trois à quatre heures. Sans point d'arrêt défini, c'est l'OS qui décide quand le run se termine — et il ne choisira pas toujours un moment propre.

Les options natives gratuites — et où chacune montre ses limites

Avant de vous tourner vers une app tierce, ça vaut le coup de savoir ce que macOS offre déjà gratuitement, parce que pour une tâche courte au premier plan, c'est souvent suffisant. caffeinate -i empêche la veille d'inactivité tant qu'il tourne ; ajoutez -w <pid> et il se termine automatiquement quand ce processus se termine — le schéma intégré le plus propre pour une commande unique que vous surveillez, par exemple caffeinate -i -w $(pgrep -f "python train.py"). caffeinate -d bloque aussi la veille de l'écran, et -s bloque spécifiquement la veille système sur secteur. Il est livré avec chaque Mac, ne nécessite aucune installation, et se script entièrement.

Rien de tout ça ne survit à un capot fermé sur batterie, cependant. Le seul levier public qui empêche la veille au capot fermé sans écran externe est sudo pmset -a disablesleep 1 — un réglage système global, pas une assertion par processus, et il nécessite les privilèges administrateur. C'est aussi le même mécanisme sous-jacent qu'utilise le mode Closed-Lid de LidRun ; il n'y a aucune API privée ici, juste le réglage pmset documenté. L'autre voie native est le vrai mode clamshell d'Apple : branchez un écran externe et restez sur secteur, et le Mac fonctionne capot fermé exactement comme prévu, sans aucune commande à taper. C'est la voie officiellement supportée, mais elle implique de posséder et de transporter un écran — pas très pratique pour un run de nuit dans une chambre d'hôtel ou une chambre d'amis.

Les apps tierces dans la barre de menu comblent l'écart entre ces deux extrêmes. Amphetamine, KeepingYouAwake, Caffeine et Lungo sont tous des interrupteurs de maintien en éveil solides et ciblés — interface soignée, minuteries, certains gèrent des plages horaires programmées. Ce sont de bons choix si ce que vous voulez, c'est simplement « rester éveillé jusqu'à ce que je dise le contraire ». Ce qu'aucun d'eux ne fait, c'est lier la contrainte à un processus en arrière-plan précis, surveiller l'état de la batterie ou la température, ou se relâcher automatiquement dès qu'un processus d'agent se termine — ce n'est tout simplement pas leur rôle.

Le risque de le faire manuellement

Les deux voies natives ont un point sensible sur un run de nuit sans surveillance. caffeinate -i sans -w tourne jusqu'à ce que vous le tuiez — rien ne l'arrête automatiquement quand la tâche se termine, donc il est facile de laisser un Mac éveillé en train de brûler de la batterie pendant des heures après que l'agent a réellement fini, et il se fait quand même surprendre par un capot fermé sur batterie.

sudo pmset -a disablesleep 1 est risqué d'une autre manière, car il est global et persistant — pas limité à votre session de terminal ni au processus qui vous intéressait. Le réglage survit après la fin de la commande qui l'a défini. Si vous fermez le terminal, si le Mac plante, ou si vous oubliez simplement d'exécuter sudo pmset -a disablesleep 0 le lendemain matin, le Mac ne s'endormira plus jamais tout seul — ni cette nuit-là, ni le lendemain — jusqu'à ce que vous le réinitialisiez manuellement ou que vous redémarriez. Pendant ce temps, rien ne surveille un seuil de batterie ni un plafond thermique, et rien ne remarque que l'agent a en fait terminé vingt minutes plus tôt.

C'est là le vrai problème — non pas que caffeinate ou pmset soient de mauvais outils, ils sont parfaitement adaptés à une tâche au premier plan que vous surveillez. Le problème, c'est qu'aucune des options gratuites, ni aucun des interrupteurs toujours-allumés tiers, ne sait ce que signifie « l'agent a terminé ». Ils maintiennent le Mac éveillé ou non ; il n'existe aucune notion de relâchement à la fin du processus, de recul sur un seuil de batterie, ou de recul face à la chaleur.

Le schéma le plus sûr : lier le maintien en éveil au processus de l'agent

La solution, c'est ce que LidRun appelle Auto Mode : un maintien en éveil lié au processus, le mécanisme central derrière la couche d'exécution sûre de LidRun pour le travail IA sur Mac. Il maintient une assertion d'alimentation uniquement tant qu'un processus reconnu est en cours d'exécution, et la relâche dès que ce processus se termine — pas un verrou d'éveil aveugle qui garde le Mac éveillé sans se soucier de ce qui se passe réellement. Son catalogue intégré reconnaît déjà Claude Code, Codex, Cursor, Windsurf, Aider, Cline, Continue, Goose, OpenHands, Zed, Ollama, LM Studio et vLLM par nom de processus, ainsi que les scripts d'interpréteurs (python, node, ruby, et d'autres) et tout ce que vous ajoutez vous-même avec lidrun watch <pattern>.

Il est aussi plus prudent qu'une simple correspondance de nom. Une fenêtre Cursor simplement ouverte et inactive ne maintient pas le Mac éveillé — une app graphique doit franchir un seuil CPU réel (au-delà d'environ 40 % d'un cœur) avant de compter comme du travail, donc laisser un éditeur ouvert toute la nuit ne bloque pas la veille sans raison. Et un agent connu qui s'est tu un moment — en attente d'une réponse d'API, en train de réfléchir entre deux appels d'outils — n'est pas non plus abandonné immédiatement : les processus d'agents nommés bénéficient d'une vraie patience, jusqu'à 30 minutes de quasi-inactivité, avant qu'Auto Mode les considère comme terminés, pour qu'une réponse lente du modèle ne vous coûte pas tout le run.

Pour une tâche ponctuelle via SSH, ou sur une machine headless sans barre de menu à regarder, le CLI encapsule directement une seule commande : lidrun -- claude-code run-task maintient une assertion limitée exactement à la durée de vie de ce processus, sans configuration de liste de surveillance nécessaire. Auto Mode fait partie de LidRun Pro — le palier gratuit couvre un Keep Awake manuel illimité, un Timer illimité, et des runs Charging-only illimités ; la détection automatique des processus est ce qu'apporte le passage à Pro.

Pour les runs capot fermé, l'emplacement du matériel compte toujours — une détection de processus plus intelligente ne change rien à la physique de la chaleur. Posez le Mac sur une surface dure et plane où l'air peut circuler en dessous : un bureau, un support, une table solide — pas un lit, pas dans un sac, pas dans un espace clos. Un capot fermé supprime le principal chemin de circulation d'air, donc la chaleur qui s'évacue normalement par le clavier doit trouver une autre issue. Privilégiez le fonctionnement sur secteur : une décharge de batterie soutenue sous charge génère davantage de chaleur que de tourner branché. La configuration spécifique à chaque outil est couverte dans les guides garder Claude Code actif quand le MacBook est fermé et garder l'agent Cursor actif sur Mac.

Rien de tout cela n'est non plus totalement « configurez et oubliez ». Une tâche avec un point d'arrêt défini — une liste de tâches, un délai, un fichier précis à écrire — est plus sûre qu'une consigne ouverte qui peut boucler sur des erreurs ou se relancer elle-même. Avant de fermer le capot, vérifiez que l'agent a un endroit où s'arrêter ; un run qui peut boucler indéfiniment continuera à consommer de l'énergie et à générer de la chaleur sans avancer, et l'usage CPU seul ne permet pas de distinguer « encore au travail » de « coincé dans une boucle ».

Définir des garde-fous de batterie et de température

20 % est un seuil raisonnable pour la plupart des charges de travail nocturnes — c'est aussi le réglage par défaut de LidRun lui-même, à la fois pour l'arrêt automatique général du keep-awake et pour le seuil de batterie d'Auto Mode. Ça laisse une vraie marge au-dessus du seuil de survie strict de LidRun (un filet de sécurité de mise en veille forcée bloqué entre 4 % et 8 % quel que soit le réglage choisi) et ça laisse assez de charge pour réellement utiliser le Mac le lendemain matin. Pour un travail plus léger dépendant de l'API, où l'agent attend surtout des réponses réseau, 15 % peut suffire ; pour de l'inférence locale ou des builds lourds, restez à 20 % ou plus. L'important, c'est de fixer un seuil, quel qu'il soit — sans ça, c'est l'OS qui décide quand s'arrêter, et il ne choisira pas toujours un moment propre.

Les limites thermiques valent la peine d'être configurées même si vous faites confiance aux protections propres du Mac. macOS réduit les performances du CPU avant que quoi que ce soit de critique ne se produise, mais cette réduction signifie que l'agent ralentit à l'extrême pendant des heures supplémentaires au lieu de s'arrêter proprement — et rester lent et chaud plus longtemps génère plus de chaleur cumulée qu'un arrêt délibéré suivi d'un redémarrage. Le Safety Governor de LidRun surveille l'état thermique via l'API publique ProcessInfo.thermalState d'Apple, et il est délibérément à sens unique : il ne maintient jamais le Mac éveillé, il ne fait que relâcher une contrainte ou forcer une mise en veille quand les conditions semblent dangereuses. En cas de chaleur véritablement critique, il relâche immédiatement, quel que soit le mode et quelle que soit la source d'alimentation — mais il n'escalade vers une mise en veille forcée réelle que si vous êtes absent du clavier ou que le capot est physiquement fermé, donc une session active que vous surveillez capot ouvert ne vous est jamais arrachée sous le nez ; il relâche la contrainte et laisse la propre régulation thermique du Mac faire son travail.

Sur Apple Silicon, un logiciel en espace utilisateur peut lire l'état thermique mais pas contrôler directement la vitesse des ventilateurs — c'est le territoire du noyau, donc traitez tout réglage thermique comme un garde-fou, pas comme un curseur. Combinez le seuil de batterie et le garde-fou thermique et vous obtenez deux conditions d'arrêt automatique indépendantes : celle que le run atteint en premier tire le frein, plutôt que de laisser la tâche tourner jusqu'à ce que le matériel ou l'OS intervienne de lui-même. Le guide du safety governor détaille comment les limites de batterie, de température et de plafond de temps interagissent.

Vérifier que ça fonctionne vraiment

Avant de fermer le capot, une vérification de cinq secondes vaut mieux qu'une découverte à 7h du matin. L'icône de la barre de menu indique si LidRun maintient actuellement un keep-awake ou une contrainte clamshell — jetez-y un œil avant de partir. Via SSH, ou sur une machine headless sans barre de menu à consulter, lancez plutôt lidrun status depuis le terminal ; il affiche le mode actuel, si l'assertion d'alimentation est active, si Closed-Lid est activé, le pourcentage de batterie actuel et l'état de charge, le niveau thermique, et — si Auto Mode est activé — quels processus surveillés il voit actuellement.

Si un processus que vous attendez de voir surveillé n'apparaît pas, lidrun patterns liste tout ce qui figure actuellement sur la liste de surveillance, y compris le catalogue d'agents intégré. Ajoutez ce qui manque avec lidrun watch <pattern> — utile pour un script wrapper personnalisé ou un outil qui ne se présente pas sous l'un des noms déjà reconnus.

Être notifié quand la tâche se termine

Les notifications push bouclent la boucle — sans elles, vous vérifiez manuellement ou vous devinez. LidRun prend en charge ntfy.sh, un relais de notifications gratuit et ouvert, pour envoyer une notification sur votre téléphone dès que la session de keep-awake se termine ; Pushover est aussi pris en charge si vous préférez une app payante dédiée. Cette session se termine quand le processus de l'agent se termine, donc la notification est un indicateur direct de la fin ou de l'arrêt de la tâche — aucune intégration webhook côté serveur n'est nécessaire.

La notification signale la fin de la session, pas la réussite de la tâche — que l'agent ait terminé, rencontré une erreur, ou se soit arrêté parce qu'un garde-fou de batterie ou de température s'est déclenché, ça se ressemble sur votre téléphone. Ouvrez le Journal d'activité pour voir de quoi il s'agissait réellement ; LidRun enregistre la raison précise de l'arrêt — une fin de tâche normale, un arrêt automatique sur batterie ou chaleur, un arrêt manuel, ou le Safety Governor relâchant la contrainte — et ce journal est local et toujours disponible même si la notification elle-même n'arrive jamais. Une notification perdue peut arriver : ntfy.sh est un relais tiers et Pushover a besoin d'une connexion active au moment de l'envoi, donc si le réseau du Mac a eu un accroc juste au moment où le run s'est terminé, vérifiez le journal directement plutôt que de supposer que rien ne s'est passé.

Pour un run plus long, une couche Watchdog optionnelle (une fonctionnalité payante) peut alerter en cours de run si un agent surveillé se tait pendant un moment — potentiellement bloqué plutôt que terminé — au lieu de vous laisser le découvrir seulement à la fin. Traitez ça comme un avertissement, pas comme un verdict : distinguer un agent planté d'un agent qui a simplement terminé une tâche rapidement demande plus de signal que ce dont LidRun dispose actuellement (durée de tâche attendue, codes de sortie), donc une alerte d'agent bloqué signifie « allez jeter un œil », pas « c'est sûrement en échec ».

« Mon agent s'est quand même arrêté » — lire la raison de l'arrêt

Si le keep-awake était activé et que le run s'est quand même arrêté, le Journal d'activité explique presque toujours pourquoi, et c'est généralement l'une de ces trois raisons. Si l'entrée montre un événement de fin de tâche normale ou de sortie de processus, ce n'est pas un échec — le processus de l'agent s'est terminé et Auto Mode a relâché la contrainte exactement comme prévu.

Si c'est un arrêt lié à la batterie ou à la température, c'est le garde-fou qui fait son travail, pas un bug — tout l'intérêt de fixer un seuil, c'est qu'il se déclenche parfois. Vérifiez le pourcentage ou le niveau thermique dans le journal par rapport à ce que vous avez réglé ; s'il se déclenche plus tôt que prévu, le seuil est peut-être fixé plus haut que ce que la charge de travail nécessite, ou le Mac était sur batterie sous une charge plus lourde que d'habitude.

Si le journal montre que le Safety Governor a relâché la contrainte de lui-même, ça n'arrive que sur batterie, quand LidRun a confirmé que rien ne tourne réellement et que vous êtes absent du clavier depuis un moment — un éditeur de code ouvert sans activité CPU réelle se lit comme une inactivité confirmée, pas comme du travail. Lancez lidrun status pendant que l'agent est actif pour vérifier qu'il apparaît bien comme une tâche reconnue avec un usage CPU réel. Si ce n'est pas le cas, le nom du processus ne correspond probablement à rien dans la liste de surveillance (vérifiez lidrun patterns et ajoutez-le avec lidrun watch <pattern>), ou l'outil est une app graphique qui reste sous le seuil CPU qu'Auto Mode utilise pour distinguer « ouvert » de « au travail ».