Comment les agents IA ont changé la gestion de l'alimentation sur Mac
Les agents IA ont changé la gestion de l'alimentation sur Mac en cassant le seul signal que macOS a toujours utilisé pour décider quand se mettre en veille : l'activité de l'utilisateur. Un agent de codage qui lit des fichiers, modifie du code et lance des tests pendant deux ou trois heures ne génère aucune frappe au clavier ni aucun mouvement de souris — macOS interprète donc tout ce temps comme de l'inactivité, et met la machine en veille en pleine tâche, tuant l'agent et laissant derrière lui un diff à moitié appliqué. Ce mode d'échec existait à peine il y a cinq ans, car presque rien ne tournait alors sans surveillance pendant des heures d'affilée. Voici pourquoi cela arrive, ce que les solutions gratuites règlent vraiment, et où elles atteignent leurs limites.
Pourquoi la veille automatique avait du sens — jusqu'à ce que les agents IA cassent cette logique
La gestion de l'alimentation sur Mac a été conçue pour des rythmes humains. Pas de frappe au clavier pendant quelques minutes : l'écran s'assombrit. Un peu plus longtemps : la machine se met en veille. Les minuteurs d'inactivité d'Apple avaient du sens parce que le rôle de la machine était de vous attendre, et attendre coûtait de la batterie. L'assertion qu'une app maintient pour garder le Mac éveillé est liée à son processus : dès que l'app quitte ou plante, macOS la libère automatiquement. C'est un choix de conception délibéré, et c'est exactement ce qui a permis de bâtir ce modèle en toute sécurité pendant trente ans.
Ce modèle a tenu bon pendant une décennie de téléchargements en arrière-plan, de longues compilations et d'encodages vidéo, parce que ces tâches se terminaient rapidement ou maintenaient une assertion d'alimentation pour signaler à l'OS qu'elles tournaient. Un logiciel de rendu vidéo maintient une assertion média ; xcodebuild termine en quelques minutes et se ferme. La machine avait toujours un signal sur lequel s'appuyer, et ce signal se nettoyait toujours de lui-même.
Rien dans cette conception n'anticipait une charge de travail qui tourne pendant des heures sans aucune saisie utilisateur et sans limite de fin naturelle. Ce scénario n'existait tout simplement pas au moment où ce modèle d'alimentation a été conçu.
Pourquoi votre Mac se met en veille en pleine exécution d'un agent
Les agents de codage IA — Claude Code, l'agent en arrière-plan de Cursor, Aider, GitHub Copilot Workspace — fonctionnent en enchaînant des dizaines d'étapes : lire un fichier, planifier une modification, écrire du code, lancer un test, interpréter le résultat, et recommencer. Une simple tâche de refactoring peut tourner deux ou trois heures sans personne au clavier.
macOS ne voit rien de tout cela comme de l'activité. Aucun événement clavier, aucun mouvement de souris, aucune image d'écran à afficher. Le minuteur d'inactivité descend jusqu'à zéro, l'écran se met en veille, et le système suit peu après — terminant la session Terminal en pleine tâche.
Si vous n'êtes pas sûr que cela vous soit vraiment arrivé, ne faites pas confiance à Activity Monitor après coup : le processus a simplement disparu de la liste. La preuve la plus claire se trouve dans Terminal : pmset -g log | grep -i sleep liste les vrais événements de veille et de réveil avec leurs horodatages, ce qui vous permet de faire correspondre un trou dans le journal de votre agent avec une mise en veille système enregistrée par macOS au même moment.
Ce n'est pas un bug de macOS. La veille automatique est un comportement correct pour une machine réellement inactive. Le problème structurel, c'est que l'OS n'a aucune notion intégrée d'un processus effectuant un travail cognitif pour le compte de l'utilisateur — un travail que l'utilisateur veut réellement voir se terminer.
Guide associéQu'est-ce qu'une couche d'exécution sécurisée pour Mac ?La solution gratuite : caffeinate, pmset et les apps de barre de menu anti-veille
La première chose à essayer ne coûte rien et est déjà installée avec macOS. caffeinate -i maintient le même type d'assertion d'alimentation que LidRun maintient pour le cas du couvercle ouvert — l'assertion système anti-veille-inactivité — et la façon la plus propre de l'utiliser est de lui passer directement la commande de l'agent : caffeinate -i your-agent-command. L'assertion est alors liée à ce processus et se libère automatiquement dès que l'agent se termine, au lieu de tourner jusqu'à ce que vous pensiez à l'arrêter.
Si vous préférez ne pas toucher à Terminal, la même idée est accessible en un clic via une app de barre de menu. Amphetamine, KeepingYouAwake, Lungo, et l'app Caffeine — dont le nom tombe bien — maintiennent toutes le même type d'assertion que caffeinate, avec un interrupteur graphique et une minuterie au lieu d'une ligne de commande. Pour le cas d'usage auquel elles sont destinées — un Mac branché, couvercle ouvert, quelqu'un à proximité pour remarquer si quelque chose cloche — n'importe laquelle d'entre elles fait très bien l'affaire.
Rien de tout cela — caffeinate y compris — ne permet à un MacBook de continuer à tourner couvercle fermé, sauf si un écran externe est branché. Fermer le couvercle déclenche un chemin de veille clamshell distinct, à un niveau plus bas, que les assertions anti-veille-inactivité ne peuvent pas arrêter ; c'est un mécanisme différent de celui que caffeinate et LidRun utilisent tous deux pour le cas du couvercle ouvert. Si vous avez un poste de travail fixe, la solution gratuite l'est vraiment : branchez un écran externe (et un clavier ou une souris, si le Mac n'en détecte pas déjà un), fermez le couvercle, et macOS le traite comme un ordinateur de bureau — aucun outil supplémentaire nécessaire. Sans écran, le seul levier public est sudo pmset -a disablesleep 1, qui demande un mot de passe administrateur et s'accompagne d'un vrai piège traité juste après.
Les limites de la solution gratuite : batterie, chaleur et un réglage pmset bloqué
caffeinate et les apps anti-veille de barre de menu n'ont aucun plancher de batterie. Laissez un MacBook maintenir une assertion de réveil à 40% de charge avec une boucle d'agent intensive, et il est tout à fait possible de revenir à une batterie à plat, une session perdue, et un diff à moitié appliqué — l'outil a fait exactement ce qu'il promettait, il n'avait simplement aucun moyen de s'arrêter avant que l'énergie ne soit épuisée. La vitesse à laquelle cela arrive varie énormément : un agent qui passe le plus clair de son temps à attendre des réponses d'API sollicite à peine le CPU, tandis qu'un agent faisant tourner un modèle local peut occuper tous les cœurs pendant des heures. Cette imprévisibilité est précisément pourquoi un plancher en pourcentage de batterie fonctionne mieux ici qu'une minuterie fixe — vous ne savez pas à l'avance combien vont réellement vous coûter quatre heures de « travail IA ».
La chaleur est le risque le plus subtil, et il est mesurable — ce n'est pas qu'une impression. macOS lui-même n'expose qu'un signal grossier — ProcessInfo.thermalState, quatre paliers : Nominal, Fair, Serious, Critical — et ce signal peut accuser un retard sur la réalité. Lors d'un test interne sur un MacBook Intel (i7-1068NG7), une charge de travail normale couvercle ouvert maintenait environ 95°C avec un throttle CPU restant au-dessus de 80%; enfermé dans un sac sous la même charge, le throttle réel est tombé à environ 24% alors que thermalState affichait encore « Fair » — la puce avait déjà commencé à se protéger bien avant que le signal au niveau OS ne rattrape la réalité. Cet écart explique pourquoi un anti-veille qui ne vérifie que thermalState, ou qui ne vérifie rien du tout, n'offre aucune vraie protection dans un espace confiné : un couvercle presque fermé, une surface souple bloquant les aérations, ou un sac.
Le contournement clamshell a son propre mode d'échec. pmset -a disablesleep 1 est un réglage global et persistant, sans lien avec un processus en particulier. Si ce qui l'a activé plante — un script, une session Terminal, une app — le réglage reste à 1 et le Mac ne se remettra plus en veille couvercle fermé tant que quelque chose ne le remet pas explicitement à 0 (sudo pmset -a disablesleep 0) ou que vous ne redémarrez pas. C'est un piège réel et documenté, pas une hypothèse : le réglage n'a tout simplement aucun moyen de savoir que le processus qui l'a demandé a disparu.
Un workflow plus sûr pour les longues exécutions d'agents IA
Pour une exécution rapide en journée, à votre bureau et branché sur secteur, caffeinate ou une app de barre de menu suffit largement — aucun outil supplémentaire n'est nécessaire, et c'est honnête de le dire.
Pour les sessions de nuit, sur batterie, ou couvercle fermé, il vous faut trois choses que les outils gratuits ne combinent pas : un plancher de batterie pour que l'exécution s'arrête avant que la machine ne meure plutôt qu'après, une vraie conscience de la pression thermique plutôt que le seul signal grossier de l'OS, et — si le couvercle est fermé — un moyen de se rétablir automatiquement si ce qui maintient disablesleep plante, au lieu de laisser le Mac bloqué. C'est à peu près à ça que sert une couche d'exécution sûre pour le travail IA sur Mac : pas un anti-veille plus puissant, mais un outil qui surveille les conditions qui rendraient la poursuite de l'exécution dangereuse, et qui se retire proprement au lieu de continuer à l'aveugle.
Si vous préférez ne gérer aucune alimentation locale, il existe une alternative légitime : faire tourner l'agent sur une machine distante — une VM cloud, un GitHub Codespace, ou un Mac mini toujours allumé auquel vous vous connectez en SSH — et laisser votre Mac portable se mettre en veille normalement pendant que la tâche s'exécute ailleurs. Le compromis est réel : vous perdez la commodité de travailler directement dans votre checkout local, et vous payez pour du calcul dont vous n'auriez peut-être pas eu besoin autrement. Pour beaucoup de workflows locaux, où le dépôt reste sur place, garder le Mac portable lui-même éveillé et sous surveillance reste la voie la plus simple.
Où LidRun entre en jeu
La règle de LidRun est simple : agent en cours d'exécution, le Mac reste éveillé ; agent terminé ou situation dangereuse, l'assertion se libère et le Mac se met en veille. Le mécanisme est un observateur de processus (Auto-Watch) qui interroge toutes les dix secondes les processus que vous lui indiquez de surveiller, et ne maintient l'assertion de réveil que tant qu'au moins un d'entre eux utilise réellement le CPU au-delà d'un seuil (20% par défaut) — avec une période de grâce de 60 secondes pour qu'un processus momentanément inactif, en attente d'une réponse de modèle ou d'E/S disque, ne fasse pas basculer l'assertion sans arrêt. Quand plus aucun processus surveillé ne tourne, l'assertion se libère d'elle-même. C'est la moitié « agent terminé » de la promesse, et ce n'est ni une minuterie fixe ni quelque chose que vous devez penser à désactiver.
Côté batterie, un seuil d'arrêt automatique que vous définissez — 20% par défaut, réglable entre 15% et 50% — libère l'assertion pour que macOS puisse se mettre en veille normalement au lieu de vider la batterie. En dessous de ce seuil se trouve un plancher non réglable d'environ 4%: même avec un arrêt automatique réglé très bas, LidRun demande quand même au Mac de se mettre en veille près de la batterie vide plutôt que de laisser une session tourner jusqu'à l'extinction forcée. Côté thermique, LidRun lit la vraie température SMC et le pourcentage de throttle CPU en plus du signal au niveau OS, et se retire vers 98°C ou un throttle à 50% ou moins (sérieux), et 100°C ou un throttle à 30% ou moins (critique) — plus proche de l'état réel du matériel que thermalState seul.
Le mode Closed-Lid utilise le même levier pmset -a disablesleep décrit plus haut, appliqué via un assistant privilégié approuvé une seule fois, pour éviter une demande de mot de passe administrateur à chaque fois. Son mode « Sleep when done » met automatiquement le Mac en veille après 10, 20 ou 30 minutes sans aucun processus surveillé en cours d'exécution, et un signal de vie anti-crash détecte une valeur disablesleep restée bloquée à 1 par une session précédente qui a planté, puis la réinitialise automatiquement au lancement suivant de l'app — exactement le mode d'échec décrit plus haut, résolu automatiquement au lieu de vous laisser le découvrir. Un Safety Governor s'applique toujours en dessous de tout ça : il peut arrêter l'exécution ou demander la mise en veille quand la batterie ou la chaleur devient dangereuse, couvercle ouvert ou fermé.
Keep Awake, l'arrêt automatique sur batterie, et la surveillance des processus sont gratuits sans limite de temps — LidRun ne verrouille pas les fonctions de base derrière un essai. Le mode Closed-Lid, la fonctionnalité plus lourde et plus risquée, vous donne un nombre limité d'exécutions gratuites à essayer avant de demander un déblocage Pro. Si les exécutions d'agents IA de nuit et couvercle fermé font partie régulière de votre workflow plutôt qu'une exception, garder les agents IA actifs pendant votre sommeil vaut la peine d'être lu ensuite.
LidRun garde votre travail actif capot fermé, avec une protection batterie et thermique intégrée.
Vous avez déjà LidRun ? Lisez le guide d'installation →
Nouveau sur LidRun ? Voir les tarifs →
Questions fréquentes
Pas toujours. Pour une exécution courte à votre bureau et branché sur secteur, caffeinate -i your-agent-command ou une app anti-veille de barre de menu règle le problème principal — le minuteur de veille-inactivité — et rien d'autre n'est nécessaire. Pour des exécutions plus longues, des sessions de nuit, ou un travail sur batterie seule, il vous faut aussi un plancher de batterie et une certaine conscience thermique, car ni caffeinate ni une app anti-veille graphique n'intègrent l'un ou l'autre.
macOS mesure le temps d'inactivité à partir de la saisie utilisateur — événements clavier, mouvements de souris et activité de l'écran. Un agent IA ne génère rien de tout cela ; il tourne en arrière-plan sans toucher à aucun périphérique de saisie. Une fois que le minuteur d'inactivité atteint son seuil, le système se met en veille et met fin à la session Terminal de l'agent, ou suspend entièrement son processus.
Pour une machine branchée sur secteur dans un environnement stable, caffeinate fonctionne généralement bien. Cela devient un risque sur batterie, car l'outil maintient l'assertion de réveil sans aucun plancher de batterie — une charge à 40% et une boucle d'agent de plusieurs heures peuvent finir à 0% avec la session perdue. Il ne fait rien non plus pour un couvercle fermé sans écran externe ou sans pmset -a disablesleep; fermer le couvercle déclenche un chemin de veille différent que la même assertion ne peut pas arrêter. Un outil qui s'arrête automatiquement à un seuil de batterie faible et qui traite le couvercle fermé comme un cas à part réduit les deux risques sans vous obliger à surveiller l'exécution.
Un long build tourne quelques minutes, se termine proprement, et de nombreux outils de build maintiennent une assertion d'alimentation pendant la compilation. Les agents IA sont ouverts : ils bouclent, appellent des API externes, écrivent et testent du code, et peuvent tourner pendant des heures sans heure de fin définie. C'est la combinaison d'une durée longue et d'une fin imprévisible qui fait de la gestion de l'alimentation un vrai enjeu — un build qui se termine tôt ne vous coûte rien ; un agent qui meurt pendant la nuit vous coûte toute la session.
Activity Monitor ne vous aidera pas après coup : un processus tué a simplement disparu. Le signal le plus clair se trouve dans Terminal : lancez pmset -g log | grep -i sleep pour voir les vrais événements de veille et de réveil avec leurs horodatages, et comparez-les avec le dernier horodatage du journal ou de la sortie de votre agent. Un trou qui correspond à un événement de veille enregistré le confirme.
Oui, mais pas avec caffeinate seul. Fermer le couvercle déclenche la veille clamshell, un mécanisme distinct que les assertions anti-veille-inactivité classiques ne peuvent pas arrêter. Les deux options gratuites sont de brancher un écran externe (macOS traite alors le MacBook fermé comme un ordinateur de bureau, aucun outil supplémentaire nécessaire) ou de lancer sudo pmset -a disablesleep 1, qui demande un mot de passe administrateur et reste actif jusqu'à ce que quelque chose le désactive explicitement. Une couche d'exécution sûre qui propose un mode couvercle fermé dédié — avec une réinitialisation automatique si le réglage reste bloqué après un crash, plus les mêmes garde-fous de batterie et de chaleur — retire la surveillance manuelle de cette seconde option.