Qu'est-ce que la continuité des agents IA ?

Pourquoi la continuité des agents IA compte pour les développeurs

Des agents IA comme Claude Code, Cursor, OpenAI Codex CLI, Aider et Gemini CLI ne se contentent plus de répondre aux questions à la demande. Ils font tourner des boucles agentiques — appeler des outils, écrire des fichiers, exécuter des tests, itérer sur le résultat — pendant des minutes, parfois des heures d'affilée. Une seule exécution interrompue peut signifier un schéma de base de données à moitié migré, une suite de tests qui ne s'est jamais terminée, ou un job de génération de code qu'il faut relancer depuis le début.

Le terme décrit la propriété d'une session d'agent qui survit aux événements normaux de gestion de l'alimentation d'un Mac : la mise en veille pour inactivité, la fermeture du capot et l'arrêt automatique en cas de batterie faible. C'est un problème de catégorie, pas une fonctionnalité isolée à corriger. Bien faire les choses suppose de traiter les trois pièges à la fois, pas seulement de bloquer la veille pour inactivité et de considérer l'affaire réglée.

Pour une génération rapide de cinq minutes, la gestion de l'alimentation de macOS gêne rarement — le job se termine avant que le système ne juge la session inactive. Le problème apparaît sur les tâches plus longues : analyse complète d'un repo, refactoring multi-fichiers, entraînements qui tournent toute la nuit, tout ce qui dure assez longtemps pour que le Mac ait le temps de décider que la session semble abandonnée, et d'agir en conséquence.

Les trois façons dont un Mac interrompt un run d'agent

La mise en veille pour inactivité est le piège le plus fréquent. macOS surveille les événements d'entrée — clavier, souris, activité de l'écran — et déclare une session inactive au bout d'un délai configurable. Un agent IA ne génère pas ces événements. Même pendant qu'il écrit activement des fichiers et enchaîne les appels API, le Mac ne voit aucune activité au niveau des entrées et s'endort. Sur batterie, avec un réglage Économiseur d'énergie agressif, ce délai peut être assez court pour interrompre un run en quelques minutes à peine.

La mise en veille au capot fermé se déclenche à l'instant même où le capot d'un MacBook se referme, indépendamment de tout délai d'inactivité. Beaucoup de développeurs ferment le capot pour passer du bureau à la salle de réunion en supposant qu'un job en arrière-plan va simplement attendre — ce ne sera pas le cas, sauf si quelque chose a explicitement demandé à macOS de maintenir une assertion anti-veille pendant la fermeture du capot. Un outil qui ne bloque que la veille pour inactivité ne sert à rien ici : la fermeture du capot est un déclencheur totalement distinct.

La batterie faible est la moins prévisible des trois. Apple ne publie aucun pourcentage universel à partir duquel macOS force la mise en veille — le comportement exact dépend du modèle de Mac, de la version de macOS, et du fait que le mode Basse consommation soit actif ou non. Ce qui reste constant, c'est la tendance : à mesure que la charge baisse, macOS bride de plus en plus agressivement et, près de la batterie vide, force la mise en veille ou l'extinction pour protéger la batterie, qu'un terminal ait un job en cours ou non. Un agent qui démarre un job de deux heures à 40 % peut heurter ce mur en plein milieu de la tâche, et cela ressemble à un plantage alors qu'il s'agit en réalité d'un événement de gestion de l'alimentation.

Un outil qui bloque la veille pour inactivité mais ignore le capot, ou qui bloque le capot mais ignore la batterie, laisse toujours un run d'agent exposé sur le mode qu'il ne couvre pas. Il faut gérer les trois en même temps pour que le terme ait un sens.

Des solutions gratuites pour garder un run d'agent en vie

Avant même de chercher une application, macOS propose déjà des solutions gratuites pour couvrir deux des trois pièges. caffeinate -i bloque la veille pour inactivité depuis le Terminal — une commande intégrée que possède déjà chaque Mac. Son astuce la plus utile pour ce cas d'usage précis, c'est le flag -w : caffeinate -i -w $(pgrep -n claude) bloque la veille pour inactivité exactement le temps que le processus donné reste en vie, puis se libère automatiquement dès qu'il se termine. Rien à installer, rien à nettoyer, et c'est lié à la durée de vie réelle de l'agent plutôt qu'à une minuterie fixe.

La fermeture du capot a elle aussi un contournement manuel gratuit : sudo pmset -a disablesleep 1 avant de fermer le capot, puis sudo pmset -a disablesleep 0 une fois terminé. C'est exactement le même réglage système que n'importe quel outil de gestion du capot fermé finit par appeler en coulisses — il n'existe pas de mécanisme plus privilégié que celui-ci.

Il existe aussi une option entièrement native qui ne nécessite aucun contournement. Le workflow officiel d'Apple pour le capot fermé consiste à brancher le secteur et connecter un écran externe (les anciennes recommandations demandaient aussi un clavier et une souris externes ; sur la plupart des MacBook récents, le secteur plus un écran suffisent). Fermez le capot, l'écran interne s'éteint, le Mac continue de tourner sur l'écran externe — aucun flag disablesleep en jeu, rien à penser à remettre à zéro. Pour quiconque travaille à un bureau avec un moniteur, c'est sans doute la plus sûre des trois solutions, car rien ne reste dans un état à moitié terminé si vous oubliez une étape.

Où les solutions gratuites montrent leurs limites

caffeinate ne couvre que la veille pour inactivité. Il ne survit absolument pas à la fermeture du capot — celle-ci prend le dessus quel que soit le flag utilisé — et il n'a aucune notion du pourcentage de batterie. Laissé sans surveillance, il continuera sans problème à maintenir un job en vie jusqu'à ce que le Mac se force lui-même à un arrêt d'urgence, plutôt que de s'arrêter tôt de son propre chef.

Le duo manuel pmset disablesleep est global et persistant par conception. Oubliez le disablesleep 0 qui doit suivre — un plantage, un Terminal forcé à quitter, un redémarrage sauté — et le Mac reste dérogé indéfiniment. Sur un bureau avec une bonne circulation d'air, c'est surtout cosmétique. Cela devient un vrai risque si le Mac finit ensuite enfermé quelque part : un sac, une housse, une pile de livres, tout endroit où la chaleur ne peut pas s'échapper. La solution n'est pas d'éviter le mode capot fermé, c'est de garder le Mac sur une surface plane et ventilée, et d'avoir un vrai plan pour désactiver le contournement, pas juste l'espoir que vous vous en souviendrez.

L'astuce de l'écran externe ne fonctionne que relié à un moniteur. Elle n'aide en rien le cas où vous fermez le capot, mettez le Mac dans un sac et partez pendant qu'un job tourne toute la nuit — ce qui est exactement le scénario derrière la plupart des questions sur la continuité des agents IA.

Le point commun : aucune des trois solutions gratuites ne surveille le niveau de batterie ni l'état thermique pendant que le job tourne, et aucune ne se libère automatiquement quand le processus de l'agent se termine réellement. Quel que soit l'outil utilisé, c'est cette couche de surveillance qui fait vraiment la continuité — et avec les solutions gratuites, c'est une discipline manuelle dont vous êtes responsable à chaque fois.

L'approche sûre de la continuité

Le bon mécanisme pour la veille pour inactivité est une assertion d'alimentation IOKit — précisément kIOPMAssertionTypePreventUserIdleSystemSleep, la même catégorie d'assertion que macOS utilise lui-même quand, par exemple, une vidéo tourne en plein écran. Elle indique au système qu'il se passe quelque chose de significatif, sans toucher aux régulateurs de sécurité thermique ou batterie — c'est pour ça que c'est la bonne brique à utiliser plutôt qu'un contournement : elle coopère avec macOS au lieu de le combattre.

Couvrir la fermeture du capot suppose d'associer pmset disablesleep 1 à un 0 automatique correspondant — à l'arrêt, à la fermeture de l'app, et revérifié au lancement suivant au cas où l'arrêt précédent n'aurait pas été propre. Sauter ce nettoyage, c'est exactement le risque décrit plus haut : un Mac coincé en dérogation permanente. Quand le capot est réellement fermé, utilisez une surface plane avec une bonne circulation d'air et gardez le Mac ventilé plutôt qu'enfermé ; être branché sur secteur compte aussi, puisque le capot fermé retire la possibilité de simplement recharger un peu la batterie en cours de job, comme vous pourriez le faire capot ouvert.

Côté batterie, comme le seuil propre à macOS n'est pas documenté, la solution la plus sûre est de fixer votre propre plancher bien en amont, plutôt que d'essayer de deviner le chiffre de macOS. LidRun s'arrête automatiquement par défaut à 20 % de batterie (réglable entre 15 % et 50 %), avec des avertissements plus tôt à 15 % et 5 %, soutenus par un plancher d'urgence qu'on ne peut pas descendre en dessous de 4 % — à peu près le point en dessous duquel macOS n'a peut-être plus assez de marge pour s'endormir proprement avant que le Mac ne s'éteigne — et ce plancher se déclenche même si l'arrêt automatique classique a été désactivé.

La température fonctionne de la même façon. macOS expose quatre niveaux thermiques publics via ProcessInfo — nominal, fair, serious, critical — le même signal qu'utilisent des apps comme les encodeurs vidéo pour lever le pied. Le mode capot fermé est là où ça compte le plus, puisque fermer le capot supprime le principal chemin d'air du Mac ; un outil bien conçu surveille ce signal, avertit à serious, et désactive automatiquement le mode capot fermé à critical, pour que le matériel puisse brider et s'endormir normalement plutôt que d'y être forcé. Rien de tout ça n'est une garantie — une minuterie de session et une surveillance thermique aident à réduire le risque, elles ne l'éliminent pas — mais la combinaison d'une véritable assertion d'alimentation, d'un plancher de batterie et d'une surveillance thermique est ce qui fait qu'exécuter un agent capot fermé devient un compromis défendable plutôt qu'un pari inconsidéré.

Au final, une configuration sûre a la même forme, que vous la construisiez vous-même ou que vous utilisiez un outil pour ça : maintenir l'assertion anti-veille pour inactivité pendant la durée du job, pas indéfiniment ; si le capot doit se fermer, associer disablesleep 1 à un 0 automatique ; fixer un plancher de batterie au-dessus de celui, non documenté, de macOS, et le laisser actif ; surveiller l'état thermique et lever le pied avant que ça ne devienne forcé ; et lier le tout au processus de l'agent pour que ça se libère au moment où le job se termine réellement, pas seulement quand vous pensez à l'éteindre.

Les outils qui prennent en charge la continuité des agents IA sur Mac

Les solutions gratuites ci-dessus couvrent un vrai terrain — le flag -w de caffeinate est un pattern vraiment efficace pour un job ponctuel au premier plan, et l'astuce du clamshell avec écran externe ne demande rien à installer. Là où elles s'arrêtent, c'est à peu près là où s'arrêtent aussi la plupart des utilitaires tiers de la barre de menus : du blocage de veille généraliste que vous configurez pour approcher ce cas précis, pas quelque chose conçu spécifiquement autour de la surveillance d'un processus d'agent IA.

Amphetamine est le plus riche en fonctionnalités des outils populaires de la barre de menus — gratuit sur le Mac App Store, avec des déclencheurs par app, nom de processus, niveau de batterie, réseau Wi-Fi et planification, plus sa propre façon d'autoriser l'usage capot fermé avec un écran externe connecté. Si vous cherchez une personnalisation poussée et que ça ne vous dérange pas de passer du temps dans ses réglages de déclencheurs, c'est un excellent choix généraliste.

KeepingYouAwake est gratuit et open-source : un simple interrupteur de barre de menus, à usage unique, sans planification ni déclencheurs — parfait si tout ce que vous voulez, c'est un interrupteur manuel marche/arrêt et rien d'autre. Lungo et l'app Caffeine du Mac App Store reprennent tous les deux la même idée sous forme d'un interrupteur simple et peu coûteux basé sur une minuterie, utile si vivre dans le Terminal n'est pas votre truc. Aucun de ces quatre outils n'a été conçu spécifiquement autour d'un agent IA sans surveillance — vous configurez un bloqueur de veille généraliste pour coller au cas, ce qui fonctionne globalement, mais le plancher de batterie et le cycle de vie du processus restent de votre responsabilité.

LidRun est bâti autour de ce cas précis. L'offre gratuite — sans essai, sans limite de session — inclut déjà la fonction Garder éveillé, un minuteur de session, le mode Uniquement en charge, l'arrêt automatique batterie faible avec les planchers 20 %/4 % décrits plus haut, un régulateur de sécurité, un journal d'activité, la CLI lidrun, et un visualiseur d'assertions en direct — le fameux « pourquoi mon Mac est-il éveillé ? » — qui vous montre exactement ce qui bloque la veille, et pourquoi, à tout moment.

L'offre payante est un achat unique avec mises à jour à vie et sans abonnement — les formules ne diffèrent que par le nombre de Macs que vous pouvez activer, avec un remboursement possible sous 14 jours si ça ne vous convient pas. Elle ajoute Auto Mode, qui surveille plus de deux douzaines de motifs de processus IA et dev intégrés (claude, codex, cursor, aider, gemini, et bien d'autres, plus tout motif personnalisé que vous ajoutez) et démarre puis libère l'assertion en fonction de la durée de vie réelle du processus plutôt que d'une minuterie devinée ; la possibilité d'exécuter une commande et de la surveiller ; le mode Closed-Lid avec l'association pmset et la désactivation automatique en cas de surchauffe déjà prises en charge pour vous ; plus un tableau de bord, des smart rules, des alertes watchdog et des rapports hebdomadaires.

L'objectif de conception, en dessous de tout ça, tient en une phrase : agent en cours, on reste éveillé ; agent terminé ou situation à risque, on relâche et on laisse dormir. Ce n'est délibérément pas un blocage de veille aveugle — c'est un ensemble de garde-fous qui ne maintiennent l'assertion que tant qu'il y a une raison réelle de le faire, et qui la relâchent dès que la batterie, la température ou l'agent lui-même signale que le job est terminé. Pour la mise en place pratique, étape par étape, d'un run de nuit sans surveillance, l'article sur la façon de garder les agents IA actifs pendant que vous dormez couvre tout le processus de bout en bout.