Comment les agents IA ont transformé la gestion de l'alimentation Mac
Vous lancez un agent IA de codage avant le dîner — une refactorisation multi-fichiers qui durera deux heures. Vous revenez pour découvrir votre MacBook en veille, le travail arrêté et une modification à moitié appliquée dans votre espace de travail. Ce mode d'échec n'existait pas il y a cinq ans et révèle un véritable écart entre la façon dont macOS gère l'alimentation et la manière dont les développeurs utilisent réellement leurs machines aujourd'hui.
Comment les ordinateurs portables ont été conçus pour se mettre en veille (et pourquoi cela fonctionnait)
La gestion de l'alimentation des ordinateurs portables a été construite selon les rythmes humains. Pas de clavier pendant quelques minutes : l'écran s'assombrit. Un peu plus longtemps : mise en veille. Les minuteurs d'inactivité d'Apple avaient du sens, car le rôle de la machine était d'attendre, et attendre consommait de la batterie.
Le modèle a fonctionné pendant une décennie avec des téléchargements en arrière-plan, des compilations longues et des encodages vidéo, car ces tâches ou bien se terminaient rapidement, ou bien maintenaient des assertions IOKit pour signaler au système d'exploitation qu'il y avait une activité. Un lecteur vidéo maintient une assertion multimédia ; xcodebuild se termine en quelques minutes et se ferme. Le système avait toujours un signal sur lequel s'appuyer.
Rien dans cette conception n'anticipait une charge de travail qui s'exécute pendant des heures sans intervention de l'utilisateur et sans limite d'achèvement naturelle. Ce scénario n'existait simplement pas quand le modèle d'alimentation a été écrit.
Ce que les charges de travail IA agentiques ont changé dans les besoins des développeurs
Les agents de codage IA — Claude Code, l'agent de fond de Cursor, Aider, GitHub Copilot Workspace — fonctionnent en chaînant des dizaines d'étapes : lire un fichier, planifier une modification, écrire du code, exécuter un test, interpréter les résultats, boucler. Une seule tâche de refactorisation peut s'exécuter pendant deux ou trois heures.
macOS ne voit rien de tout cela comme une activité. Il n'y a pas d'événement clavier, pas de mouvement souris, pas de frame d'affichage rendu. Le minuteur d'inactivité compte jusqu'à zéro. L'écran se met en veille. Le système suit peu de temps après, terminant la session du terminal au milieu du travail.
Ce n'est pas un bug de macOS. La mise en veille par inactivité est correcte pour une machine qui est véritablement inactive. Le problème structural est que le système d'exploitation n'a pas de concept intégré d'un processus effectuant un travail cognitif pour le compte de l'utilisateur — un travail que l'utilisateur souhaite réellement terminer.
Guide associéQu'est-ce qu'une couche de runtime sécurisée sur Mac?Pourquoi un simple verrou de réveil crée de nouveaux risques
Le correctif évident est un verrou de réveil : caffeinate, Amphetamine, ou un changement pmset. Ceux-ci maintiennent une assertion de puissance IOKit et suspendent le minuteur d'inactivité. L'agent continue de s'exécuter. Pour une courte session diurne alors que vous êtes branché et à proximité, c'est souvent tout ce dont vous avez besoin.
L'image change pour les travaux nocturnes ou sur batterie. Un verrou de réveil aveugle n'a pas de seuil de batterie. Laissez un MacBook exécuter caffeinate sur une charge de 40 % avec une boucle d'agent lourd, et quatre heures plus tard, vous découvrirez peut-être la batterie à zéro, la session perdue et un commit partiel dans un état incohérent. L'outil a fait son travail — il a maintenu la machine active — mais il n'y avait aucun moyen d'arrêter proprement avant que l'alimentation s'épuise.
La chaleur est la préoccupation plus subtile. Un MacBook sous charge soutenue avec un flux d'air limité ralentit, et un verrou de réveil qui ne vérifie jamais l'état thermique n'a pas de garde-fou. Ce risque s'aggrave dans les espaces confinés — un couvercle presque fermé, une surface souple qui bloque les aérations, ou un sac. L'agent s'exécute ; la machine tourne chaud sans mécanisme de recul.
Le modèle d'exécution sûr pour le travail piloté par l'IA
Une couche d'exécution sûre maintient l'assertion de réveil et surveille les conditions qui rendraient la poursuite de l'exécution dangereuse. La différence est à peu près : un verrou de réveil tient une porte ouverte ; une couche d'exécution la tient ouverte jusqu'à ce que le système signale un problème, puis la ferme proprement. Comprendre ce qu'une couche d'exécution sûre fait est un contexte utile si vous exécutez régulièrement de longs travaux IA.
En pratique, cela signifie un seuil de batterie faible — auto-arrêt à 15 ou 20 % pour que la machine puisse toujours se réveiller proprement après. Cela signifie vérifier le signal thermique que le système d'exploitation expose et ralentir quand le système signale une pression thermique. Un surveillance de processus optionnelle ajoute un autre garde-fou : arrêter la session quand le processus agent se termine plutôt que de continuer jusqu'à ce que la batterie atteigne zéro.
Pour une exécution rapide en journée sur AC, caffeinate suffit — aucun outillage supplémentaire nécessaire. Pour les sessions nocturnes, sur batterie ou couvercle fermé, une couche qui surveille les conditions aux côtés de l'assertion de réveil aide à réduire le risque de se réveiller sur une machine morte ou un travail qui est mort dans un mauvais état.
Une fonctionnalité de LidRun's keep-awake engine.
LidRun garde votre travail actif capot fermé, avec une protection batterie et thermique intégrée.
Questions fréquentes
Pas toujours. Pour une exécution courte pendant que vous êtes à votre bureau et branché, une simple commande caffeinate ou une application de maintien actif gère le problème principal : le minuteur de veille par inactivité. Pour les exécutions plus longues, les sessions nocturnes ou le travail sur batterie uniquement, vous avez également besoin d'un seuil de batterie faible et d'une certaine conscience thermique. Sans cela, la machine peut s'épuiser ou devenir chaude sans moyen d'arrêter proprement avant que quelque chose se casse.
macOS mesure le temps d'inactivité par l'intervention de l'utilisateur — événements clavier, mouvements souris et activité d'affichage. Un agent IA ne génère aucun de ceux-ci ; il s'exécute en arrière-plan sans toucher aux périphériques d'entrée. Une fois que le minuteur d'inactivité atteint son seuil, le système se met en veille et termine la session du terminal de l'agent ou suspend complètement son processus.
Pour une machine branchée dans un environnement stable, caffeinate fonctionne généralement bien. Cela devient un risque sur batterie : caffeinate maintient l'assertion de réveil mais n'a pas de seuil de batterie, donc la machine peut s'épuiser à zéro au milieu du travail. Si la batterie commence à 40 % et le travail dure quatre heures, la session peut ne pas survivre. Un outil qui auto-arrête à un seuil de batterie faible réduit ce risque sans vous obliger à surveiller l'exécution.
Une longue compilation s'exécute pendant quelques minutes, se termine proprement, et de nombreux outils de compilation maintiennent des assertions IOKit pendant la compilation. Les agents IA sont open-ended : ils boucent, appellent des API externes, écrivent et testent du code, et peuvent s'exécuter pendant des heures sans temps d'achèvement défini. La combinaison de la longue durée et de l'achèvement imprévisible est ce qui rend la gestion de l'alimentation une vraie préoccupation — une compilation qui se termine tôt ne vous coûte rien ; un agent qui meurt la nuit vous coûte la session entière.