Lancer une commande longue, puis laisser le Mac s'endormir une fois qu'elle est terminée

Le problème du maintien en éveil manuel

Le rituel habituel tient en deux étapes qu'il faut se rappeler de faire dans le bon ordre : activer le maintien en éveil, lancer le job, puis, avec un peu de chance, désactiver le maintien en éveil une fois que c'est fini. C'est la seconde étape qui saute.

Oubliez-la, et le Mac reste éveillé pendant des heures après la fin d'un job de quarante minutes — à vider sa batterie, ou tout simplement à ne pas se reposer sur le bureau. Désactivez-la trop tôt, et vous coupez le job en plein élan. Dans les deux cas, ce n'est pas ce que vous vouliez vraiment, qui était plus simple que ce que permettent les réglages : garder le Mac éveillé pendant que cette commande tourne, puis s'arrêter. Lier l'état de veille-éveil à la vie du travail lui-même, pas à un interrupteur qu'on bascule à la main.

La méthode gratuite et intégrée : caffeinate

Avant de vous tourner vers une appli, sachez que macOS fait déjà l'essentiel gratuitement. caffeinate est présent sur tous les Mac, et selon sa propre page man : « Si un utilitaire est spécifié, caffeinate crée les assertions pour le compte de cet utilitaire, et ces assertions persistent pendant toute la durée de son exécution. » Son propre exemple illustre exactement ce schéma : caffeinate -i make fork make, maintient une assertion anti-veille-idle tant qu'il tourne, puis la relâche à sa sortie. Remplacez par votre propre job — caffeinate -i ./run-migrations.sh ou caffeinate -i npm test — et vous obtenez le même maintien en éveil calé sur la durée de la commande que propose LidRun, sans rien installer.

Les options comptent : -i empêche la veille par inactivité (le cas le plus courant), -d garde en plus l'écran allumé, -s empêche carrément la veille système mais ne fonctionne que sur secteur, et -m empêche le disque de se mettre en veille. Sans aucune option, un simple caffeinate your-command empêche quand même la veille par inactivité par défaut. C'est un outil vraiment solide pour un job au premier plan que vous surveillez.

Ce que caffeinate ne touche pas, c'est un capot fermé. Ses assertions bloquent la veille par inactivité, pas la veille forcée que macOS déclenche dès que vous fermez physiquement le capot sur un Mac sans écran externe branché. Le correctif gratuit traditionnel dans ce cas est le montage clamshell classique — écran externe plus clavier/souris externes, capot fermé, le Mac continue de tourner parce que macOS le traite comme s'il était effectivement en dock. L'autre levier, celui que le mode Closed-Lid de LidRun appelle en coulisses, est le fameux (mais non documenté) sudo pmset disablesleep 1 — un drapeau à l'échelle du système qui bloque complètement la veille jusqu'à ce que quelque chose le remette à 0.

Là où la méthode gratuite atteint ses limites

caffeinate ne vous dit rien quand le job se termine. Pas de code de sortie affiché, pas de durée, pas de notification — vous en revenez à surveiller un onglet de terminal, ou à écrire votre propre wrapper du genre caffeinate -i ./job.sh; echo "exit $?" en vous souvenant d'aller vérifier plus tard. Pour une migration de quarante minutes, c'est un désagrément mineur ; pour un export lancé avant de vous coucher, ça veut dire vous réveiller devant une fenêtre de terminal à faire défiler, et non une réponse claire.

caffeinate ne sait rien non plus de votre batterie ni de l'état thermique de votre Mac. Il maintient l'assertion aveuglément tant que le processus tourne — ce qui est exactement ce que vous lui avez demandé, mais ça veut dire qu'un job caffeinate -i laissé sans surveillance sur batterie toute la nuit n'a personne pour surveiller à votre place le seuil de batterie basse que vous avez configuré. pmset disablesleep est encore plus brut : il faut sudo, il agit à l'échelle du système (bloque la veille pour tout, pas juste votre job), et il reste réglé sur 1 jusqu'à ce que quelque chose le remette explicitement à zéro — sautez cette étape, et le Mac ne s'endormira plus pour rien tant que vous ne vous en souviendrez pas.

Les applis tierces à bascule — Amphetamine, KeepingYouAwake, Lungo, l'original Caffeine — méritent d'être citées honnêtement plutôt que balayées d'un revers de main. Amphetamine en particulier a un système de déclencheurs riche : elle peut s'activer au lancement d'une appli, sur un planning, ou selon le niveau de batterie, ce qui est plus configurable que tout ce que LidRun propose ici. KeepingYouAwake et Lungo sont des bascules de barre de menus volontairement minimalistes ; Caffeine est le classique en un clic. Ce qu'aucune d'elles ne fait, c'est surveiller le code de sortie d'une commande précise — elles gèrent un état d'éveil persistant que vous démarrez et arrêtez vous-même, ou selon un déclencheur qui n'a rien à voir avec le fait que votre job tourne encore ou non. C'est le même problème d'oubli-de-désactiver que dans la première section, avec juste une plus jolie icône dans la barre de menus.

Confier la commande à LidRun à la place

Run & Watch a Command est une fonctionnalité Pro qui inverse le modèle de caffeinate : au lieu que ce soit vous qui gériez l'état de veille-éveil, vous confiez la commande à LidRun et c'est lui qui gère l'état à votre place. En coulisses, il lance votre commande via le même shell de connexion que celui utilisé par votre Terminal (/bin/zsh -l -c), donc les outils du PATH — Homebrew, pyenv, nvm, tout ce dont claude ou ollama a besoin pour se résoudre — fonctionnent de la même façon que si vous aviez tapé la commande vous-même. Il maintient le maintien en éveil pendant toute la durée de vie de la commande et le relâche à l'instant où elle se termine, la même promesse que LidRun tient partout ailleurs dans l'appli : commande en cours → rester éveillé, commande terminée ou dangereuse → relâcher.

Pendant qu'elle tourne, LidRun capture une fenêtre glissante de la sortie — les 200 dernières lignes, visibles en direct dans la fenêtre de la barre de menus — pour que vous ne fixiez pas un terminal nu en espérant qu'il soit toujours vivant. C'est une vue en direct, pas un fichier journal sauvegardé, donc si vous avez besoin de la transcription complète plus tard, redirigez la sortie de la commande elle-même vers un fichier comme vous le feriez normalement. Si vous tapez un simple interpréteur sans rien à exécuter réellement (python3 sans script), le runner le signale au lieu de faire comme si une sortie en zéro seconde était un vrai job.

Quand elle se termine, vous obtenez la partie qui compte le plus : le code de sortie et la durée, présentés sobrement (12m 34s, 1h 23m). Vous recevez toujours une notification locale ; si vous avez configuré un fournisseur push — ntfy.sh (gratuit) ou Pushover — elle arrive aussi sur votre téléphone, et en Pro vous pouvez en plus la relayer vers Telegram, Discord, Slack, ou une URL de webhook générique. Si vous démarrez une session sur batterie, LidRun vous annonce d'emblée le seuil d'arrêt automatique configuré (20 % par défaut) plutôt que de vous laisser le découvrir plus tard.

C'est aussi là qu'est la vraie différence de sécurité par rapport à un simple maintien caffeinate : si votre batterie passe sous ce seuil, ou si le Mac atteint une pression thermique critique, LidRun ne se contente pas de relâcher discrètement l'assertion en espérant que tout ira bien — il envoie à la commande en cours un véritable signal d'arrêt, comme si vous cliquiez sur Stop. C'est une vraie interruption, pas une simple suggestion, donc c'est plus protecteur qu'un verrou d'éveil aveugle — même si un job arrêté quelques minutes avant qu'il n'ait fini tout seul reste une interruption, pas une garantie que l'exécution aille à son terme. Et comme caffeinate, ceci garde le Mac éveillé face à la veille par inactivité, pas face à un capot physiquement fermé — associez-le au mode Closed-Lid (ou à un écran externe) si le capot va être fermé.

La même chose depuis la ligne de commande

Si vous vivez dans le terminal, lidrun -- <command> [args...] fait le même lien avec le cycle de vie, et contrairement à Run & Watch, c'est gratuit et entièrement autonome — ça fonctionne même si l'appli LidRun n'est pas lancée, parce qu'il maintient sa propre assertion IOKit de courte durée rien que pour le processus enveloppé, puis la relâche quand le processus se termine. lidrun -- ./run-migrations.sh ou lidrun -- npm test se lit exactement comme si on tapait la commande directement, parce qu'en coulisses, c'est bien le cas — même shell de connexion, même résolution du PATH. Ctrl-C l'interrompt comme n'importe quel job au premier plan.

Comme c'est autonome, autant le dire clairement : lidrun -- ne vérifie pas lui-même votre pourcentage de batterie ni l'état thermique — ce garde-fou vit dans la fonctionnalité GUI Run & Watch, lié aux réglages de sécurité habituels de l'appli. Sur batterie, pour un job de plusieurs heures, ça vaut le coup de le savoir avant de le lancer en arrière-plan et de vous en aller ; le secteur reste de toute façon le choix le plus sûr.

Un vrai piège à connaître si vous voulez enchaîner plusieurs commandes sous un seul maintien en éveil : mettez l'ensemble entre guillemets comme un seul argument shell. lidrun -- 'npm test && npm run build' fonctionne correctement — les deux commandes tournent sous une seule session enveloppée. L'envelopper dans un shell supplémentaire à la place, comme lidrun -- bash -c 'npm test && npm run build', ne fonctionne pas : LidRun recolle la liste d'arguments avec de simples espaces avant de la relancer via le shell de connexion, ce qui fait silencieusement sauter les guillemets internes et peut couper une partie de la commande. Les guillemets sur un seul argument sont le schéma fiable. Dans les deux cas, le code de sortie renvoyé est celui de votre propre commande, donc il s'insère directement dans une chaîne &&/|| de script ou un test $? exactement comme si vous lanciez la commande directement.

CLI ou GUI — lequel choisir

Optez pour le CLI quand vous étiez de toute façon sur le point de taper la commande, que vous voulez l'intégrer dans un script ou un workflow piloté par terminal, ou que vous n'avez pas (ou pas besoin) de Pro. Le code de sortie revient immédiatement dans votre propre shell, et il n'y a rien à ouvrir ni à configurer.

Optez pour le GUI Run & Watch a Command quand vous voulez que l'arrêt automatique batterie/thermique surveille vraiment le job — pas juste maintenir une assertion en espérant que tout se passe bien — ou quand vous voulez une notification sur votre téléphone sans garder une fenêtre de terminal ouverte, ou quand une fenêtre de sortie en direct dans la barre de menus est plus confortable qu'un onglet de terminal. Ça coûte une licence Pro ; le CLI est l'équivalent gratuit pour tout, sauf ce garde-fou de sécurité et le relais de notifications.

Dans les deux cas, la destination est la même : le travail se termine, le résultat est connu, et le Mac est libre de s'endormir au lieu de rester éveillé à cause d'un interrupteur que personne n'a repensé à rebasculer.

Où ça s'inscrit

Pensez aux jobs que vous lancez avant d'aller faire autre chose : une longue migration de base de données dont vous voulez confirmer qu'elle s'est bien terminée, une suite de tests complète de vingt minutes que vous préférez ne pas surveiller, un export de données lancé avant de vous coucher qui devrait être fini au matin. Pour tous ces cas, le rapport final représente la moitié de la valeur — connaître le code de sortie et la durée vous dit si la migration s'est appliquée, si la suite de tests est passée, si l'export s'est vraiment terminé, sans avoir à faire défiler la sortie.

Ça tourne dans la même limite de sécurité que tout le reste de l'appli quand c'est le chemin GUI : franchissez le seuil de batterie configuré, ou atteignez une pression thermique critique, et LidRun arrête carrément la commande plutôt que de pousser le matériel à bout. Le chemin CLI n'a pas ce garde-fou intégré, donc pour une exécution nocturne sans surveillance, le secteur et une surface dure et ventilée restent le bon choix quel que soit le chemin utilisé — ça aide à réduire le risque sur une longue exécution sans surveillance ; ça ne promet pas que le job survivra quoi qu'il arrive côté matériel.