Qu'est-ce qu'une couche d'exécution sécurisée pour Mac ?

Ce que fait vraiment une couche d'exécution sécurisée

Une couche d'exécution sécurisée combine trois éléments : une assertion anti-veille, une surveillance active et un déclencheur de relâchement automatique. La partie assertion est la moitié facile — n'importe quel outil peut appeler IOPMAssertionCreateWithName et maintenir un verrou kIOPMAssertionTypePreventUserIdleSystemSleep ; macOS exécute simplement ce qu'on lui demande. La moitié difficile, c'est de décider quand ce verrou doit être relâché : quand la batterie devient trop faible, quand la puce chauffe, quand le travail qui justifiait de rester éveillé est réellement terminé.

LidRun est une implémentation de ce principe. Il maintient cette assertion, suit le pourcentage de batterie et l'état secteur/batterie, lit un signal thermique fourni par macOS, et surveille l'état des processus — puis relâche l'assertion dès qu'un seuil configuré est franchi. Le Mac s'endort quand il le doit, selon une règle que vous définissez (ou que les réglages par défaut définissent) — pas par chance, et pas jamais.

Adaptez le besoin à la tâche. Une compilation de 20 minutes sur un Mac de bureau branché sur secteur n'a presque besoin de rien de tout cela — la mise en veille ne se déclencherait de toute façon jamais. Une exécution d'agent IA de six heures sur un ordinateur portable sur batterie, qui peut chauffer, qui peut être débranché, et que personne ne surveille à 2h du matin, c'est une situation totalement différente — et c'est précisément celle pour laquelle ce principe a été conçu.

Pourquoi votre Mac s'endort en pleine exécution, pour commencer

macOS ne fait pas la différence entre « il ne se passe rien » et « un processus d'agent en arrière-plan réfléchit silencieusement depuis 40 minutes sans aucune entrée clavier ou souris ». Les deux se ressemblent parfaitement pour le minuteur de mise en veille automatique, qui existe justement pour économiser la batterie face à ce genre d'inactivité. Laissé à ses réglages par défaut, il se déclenchera en pleine exécution.

Fermer le capot est un déclencheur distinct, et plus brutal. Sans écran externe connecté — ou sans quelque chose qui indique explicitement à macOS d'ignorer le capteur de fermeture — refermer le capot endort le Mac presque instantanément, quoi qu'il soit en train de tourner en dessous.

Et si aucun des deux ne s'en charge, un Mac laissé sans surveillance sur batterie finit par déclencher son propre arrêt d'urgence pour batterie quasi vide — pas un arrêt propre, juste l'état dans lequel se trouvait le travail au moment où l'énergie a manqué.

La solution gratuite déjà intégrée : caffeinate et pmset

macOS propose déjà une vraie réponse pour le premier cas. caffeinate -i python train.py encapsule une commande, maintient une assertion anti-veille exactement le temps que dure cette commande, et la relâche automatiquement dès que la commande se termine — aucune installation, aucune configuration. Le wrapper CLI de LidRun reprend d'ailleurs exactement cette forme : lidrun -- python train.py --epochs 100 encapsule une commande de façon identique ; la différence tient à ce que LidRun fait de ce verrou pendant qu'il est actif, détaillé plus bas.

Pour le cas du capot fermé, la voie gratuite consiste à lancer sudo pmset -a disablesleep 1 avec un écran externe connecté — la technique classique du mode clamshell — puis sudo pmset -a disablesleep 0 pour le désactiver une fois le travail terminé. C'est exactement le même réglage système que le mode Closed-Lid de LidRun utilise ; la différence, c'est que LidRun associe toujours le 1 à un 0 correspondant, à l'arrêt, à la fermeture de l'app, et de nouveau au lancement suivant, pour rattraper tout ce qui aurait pu rester après un plantage.

Les deux sont légitimes, et pour un travail court et surveillé sur secteur, l'un ou l'autre suffit souvent largement. Ne prenez pas un outil plus lourd que ce que la tâche exige.

Où la solution gratuite atteint ses limites

caffeinate n'a aucune idée de ce que fait votre batterie. Encapsulez une tâche de plusieurs heures, éloignez-vous, et si la batterie tombe à 2 % à 3h du matin, caffeinate maintient toujours l'assertion — il n'a jamais été conçu pour savoir qu'il devrait la relâcher.

pmset disablesleep est plus risqué d'une manière bien précise : c'est un réglage système global et persistant, pas quelque chose de limité à une session. Il nécessite sudo. Et il ne se remet pas à 0 tout seul — si ce qui l'a activé plante, ou si vous oubliez simplement, le Mac se retrouve bloqué à refuser toute mise en veille, vidant silencieusement sa batterie, jusqu'à ce que quelqu'un lance la commande de retour en arrière à la main.

Aucun des deux outils ne lit la pression thermique. Aucun ne sait si le processus qui justifiait le verrou est toujours en train de faire un travail utile ou s'est discrètement figé. Ils maintiennent ; ils ne surveillent pas. Cet écart — pas un défaut de l'un ou l'autre outil, simplement en dehors de ce pour quoi ils ont été conçus — c'est exactement ce qu'une couche d'exécution sécurisée ajoute par-dessus.

Les trois signaux qu'une couche d'exécution sécurisée surveille réellement

L'état de la batterie est graduel, pas un seuil unique. Réglages par défaut de LidRun : sous 15 % sur batterie, une notification d'alerte ; sous 5 %, un avertissement plus marqué ; sous environ 4 % — un plancher strict qui ne peut pas être configuré en dessous de 4 %, quels que soient vos réglages — LidRun relâche tous les verrous anti-veille et demande au Mac de s'endormir, plutôt que de le laisser s'arrêter brutalement en pleine écriture. Ce plancher existe pour laisser à macOS assez de marge pour écrire son état sur le disque et s'endormir proprement.

Le signal thermique est lu via ProcessInfo.thermalState — une API publique (nominal / fair / serious / critical), sans habilitation particulière, disponible depuis macOS 12. C'est ce signal qui pilote réellement la décision d'arrêt automatique. Il peut toutefois accuser un retard sur la réalité : lors des propres tests de LidRun, il indiquait « fair » alors qu'un Mac emmitouflé avait déjà réduit ses performances de 24 %. C'est pourquoi, ailleurs — sur les Mac où le capteur SMC est lisible — LidRun recoupe aussi la température réelle du SoC et le pourcentage de throttle CPU avec des seuils calibrés, comme un second avis que la catégorie grossière de l'OS ne peut pas toujours fournir à elle seule. Quand le SoC atteint effectivement « critical », LidRun relâche le verrou immédiatement ; si cet état critique persiste deux minutes pendant que vous êtes absent du clavier depuis cinq minutes ou plus, ou que le capot est physiquement fermé, LidRun passe à l'étape suivante et endort réellement le Mac, car un Mac sur secteur ne se met pas forcément en veille automatique tout seul.

L'état des processus relie le verrou à la tâche elle-même. Auto Mode surveille un processus spécifique — une session Claude Code, un agent Cursor, un build — et relâche le verrou dès que le dernier processus surveillé se termine. En dessous de ça, un Safety Governor indépendant peut relâcher n'importe quelle session anti-veille, même une démarrée manuellement, si le Mac est sur batterie, hors ligne, et n'a montré aucune charge de travail active confirmée depuis 15 minutes, ou reste inactif sans charge de travail confirmée depuis 20 minutes. C'est délibérément fail-safe dans un seul sens : ces relâchements se déclenchent sur une absence de travail CONFIRMÉE, jamais sur un état inconnu — une version antérieure relâchait aussi sur « unknown », et elle avait endormi le Mac en pleine session Claude Code ; c'est aujourd'hui une règle apprise à la dure, pas une supposition.

Ce qu'une couche d'exécution sécurisée ne fait pas

Elle ne réduit pas la consommation réelle de la batterie. Garder un Mac éveillé et actif coûte toujours plus d'énergie que de le laisser dormir — c'est vrai pour n'importe quel outil anti-veille, LidRun compris. L'objectif n'est pas une consommation nulle ; le sommeil reste l'état le plus efficace qu'un Mac puisse atteindre. L'objectif, c'est que l'exécution s'arrête sur un plancher choisi par quelqu'un, plutôt que de se vider sans surveillance jusqu'à 0 %.

Elle ne sauve pas un processus figé. Auto Mode et le wrapper CLI relâchent le verrou à la sortie du processus, pas quand celui-ci « a cessé de progresser ». Un script gelé mais qui n'a pas planté est toujours lu comme étant en cours d'exécution. Pour une tâche longue et sans surveillance, associez la surveillance de processus à un plancher de batterie ou à un minuteur en filet de sécurité — ne comptez pas sur la seule surveillance de processus pour détecter qu'un problème est réellement survenu.

Et elle ne contrôle pas le refroidissement. Le signal thermique est en lecture seule du point de vue de cette couche : elle peut choisir d'arrêter de maintenir le Mac éveillé pour que macOS puisse réduire les performances et refroidir — mais, sur Apple Silicon en particulier, elle ne peut pas faire monter les ventilateurs pour refroidir la machine plus vite. Gardez le Mac dans un endroit ventilé ; une couche d'exécution sécurisée est un garde-fou sur le moment d'arrêter, pas un substitut à une bonne circulation d'air.

Couche d'exécution sécurisée vs caffeinate vs Amphetamine vs pmset

caffeinate est livré avec macOS, encapsule une commande, et maintient une assertion d'alimentation pour une durée fixe ou jusqu'à ce qu'un processus enfant se termine. Il n'a, par conception, aucune conscience de la batterie, de la thermie ou de la connectivité — ça n'a jamais été son rôle. Pour un travail court et surveillé sur secteur, il fait exactement ce qu'il promet.

pmset disablesleep est la seule voie gratuite pour obtenir un Mac véritablement capot fermé avec un écran externe. C'est un réglage brutal, réservé aux administrateurs, qui s'applique à tout le système et n'a aucune notion de session — il ne sait pas ce qui l'a déclenché, et il ne se désactivera pas tout seul.

Amphetamine est une application de barre de menus soignée, avec des plannings, des déclencheurs et des listes d'applications autorisées — elle peut démarrer et arrêter des sessions selon l'heure ou l'application au premier plan. Ce qu'elle ne fait pas, c'est surveiller le pourcentage de batterie en temps réel comme garde-fou, ni réagir à la pression thermique de macOS en cours de session ; ce n'est tout simplement pas ce qu'elle est conçue pour suivre.

Une couche d'exécution sécurisée ajoute par-dessus n'importe lequel de ces outils un étage de surveillance : plancher de batterie, signal thermique, sortie de processus, et les vérifications hors-ligne/sans-surveillance, qui déterminent ensemble si le verrou reste actif. Pour un build de 20 minutes sur secteur, caffeinate ou Amphetamine suffisent réellement — inutile d'en faire plus. Ce principe trouve sa vraie place sur les longues exécutions sans surveillance, sur du matériel dont l'état peut changer — batterie, chaleur, réseau — d'une façon que personne ne surveille en temps réel.

Où se situe LidRun

Keep Awake, Timer et Charging-Only sont gratuits sur LidRun — illimités, sans essai, sans limite de session — et ils font déjà tourner la boucle de base : maintenir l'assertion, surveiller l'escalade graduée de la batterie (15 % / 5 % / ~4 %), lire le signal thermique, et s'arrêter automatiquement sur l'un ou l'autre. C'est la couche d'exécution sécurisée de base, disponible dès l'installation.

Auto Mode (qui lie le verrou à un processus surveillé comme Claude Code ou Cursor) et le mode Clamshell capot fermé font partie de Pro, tout comme la possibilité de modifier les seuils par défaut de batterie et de thermie plutôt que d'utiliser ceux intégrés à LidRun.

Si votre usage rentre dans la voie gratuite — une seule session anti-veille, sur secteur ou surveillée à la main — c'est réellement suffisant ; utilisez-la telle quelle. S'il s'agit d'une exécution d'agent de plusieurs heures sans surveillance, liée à un processus précis, ou si le capot doit rester fermé, c'est là que le reste du principe (et le palier payant) commence à se justifier. Consultez le détail des tarifs, ou lisez comment le Safety Governor décide de relâcher une session qu'il n'a pas lui-même démarrée, pour comprendre le mécanisme derrière tout ça.