Qu'est-ce qu'un gardien de poste de travail IA ?
Un gardien de poste de travail IA est un logiciel qui garde un Mac éveillé uniquement pendant qu'une tâche IA tourne réellement — en surveillant batterie et chaleur tout du long — puis le laisse s'endormir dès que le job se termine ou qu'une limite de sécurité est atteinte. C'est la couche au-dessus d'un simple interrupteur anti-veille : au lieu de maintenir le Mac éveillé indéfiniment en espérant que vous pensiez à l'éteindre, il se cale sur la charge de travail et se retire quand les conditions l'exigent. Le problème qu'il résout est familier : vous lancez un fine-tuning ou un ollama pull, vous fermez le capot ou vous vous éloignez, et vous revenez pour trouver soit le Mac endormi en plein job, soit la batterie descendue plus bas que vous ne l'auriez laissé faire si vous aviez surveillé. Faire tourner un Mac comme petit poste de travail IA — surtout en headless, capot fermé, sans personne au clavier — oblige à penser au-delà du simple anti-veille : surveiller batterie et chaleur pendant toute la durée, s'arrêter proprement quand les limites sont atteintes, et recevoir une alerte quand le job se termine vraiment.
Pourquoi un Mac s'endort ou bride ses performances en plein job IA
macOS a en réalité trois mécanismes distincts qui jouent contre un job IA long, et un simple interrupteur anti-veille n'en touche qu'un seul. La veille par inactivité (idle sleep) se déclenche quand le Mac décide que rien ne se passe ; c'est exactement ce que IOPMAssertionCreateWithName — l'appel IOKit sur lequel repose finalement tout outil anti-veille, LidRun et caffeinate compris — est conçu pour bloquer. Fermer le capot déclenche un mécanisme séparé et plus bas niveau, la veille clamshell, qu'aucune assertion d'alimentation ordinaire ne peut arrêter.
Ce second mécanisme explique pourquoi « il suffit de tenir une assertion » ne suffit pas pour un travail capot fermé. Avec un écran externe branché et le Mac sur secteur, le support clamshell natif de macOS le garde déjà éveillé capot fermé — aucun outil supplémentaire n'est nécessaire. Retirez l'écran et il n'existe plus aucun moyen natif de garder un Mac capot fermé éveillé ; le seul levier public restant est un override de veille à l'échelle du système, ce qui nous amène à la solution gratuite ci-dessous.
Le throttling thermique est un troisième mécanisme, physique celui-là, pas une forme de veille, et rien dans l'anti-veille n'y change quoi que ce soit. Un fine-tuning ou une boucle d'inférence soutenue pousse le CPU et le GPU assez fort, assez longtemps, pour que la puce réduise elle-même sa fréquence afin de rester dans son enveloppe thermique. Cela se produit indépendamment de ce qui garde le Mac éveillé — ou même si rien ne le garde éveillé du tout.
La solution gratuite : caffeinate, pmset et les astuces clamshell
macOS embarque tout ce qu'il faut pour empêcher un Mac de s'endormir pendant un job, gratuitement, sans app supplémentaire. caffeinate est l'outil en ligne de commande intégré : caffeinate -i long_running_command tient une assertion anti-veille par inactivité exactement le temps que dure cette commande, ou caffeinate -d -t 3600 la tient pendant une heure fixe, quoi qu'il tourne par ailleurs. pmset noidle fait le même travail en un seul mot — laissez cette fenêtre de Terminal ouverte et la veille par inactivité reste bloquée jusqu'à ce que vous appuyiez sur Control-C.
Pour un travail capot fermé sans écran externe, le levier gratuit est sudo pmset -a disablesleep 1 — le même réglage système que le mode Closed-Lid de LidRun bascule en coulisses. Il exige les droits administrateur et doit toujours être associé à sudo pmset -a disablesleep 0 une fois le travail terminé.
Si la ligne de commande n'est pas votre truc, plusieurs apps de barre de menu gratuites ou peu coûteuses habillent la même assertion sous-jacente d'une interface : Amphetamine (gratuite sur le Mac App Store, la plus configurable du lot — minuteurs, plannings, règles de déclenchement), KeepingYouAwake (gratuite et open source, un wrapper caffeinate épuré avec un compte à rebours dans la barre de menu), Lungo (un outil léger à préréglages, majoritairement gratuit), et Caffeine (l'un des tout premiers utilitaires « garder ce Mac éveillé » en un clic dans la barre de menu). Pour une tâche courte où vous restez au clavier tout du long, n'importe lequel de ces outils — ou caffeinate tout seul — est un bon choix. LidRun ne cherche pas à remplacer cet usage.
Là où la solution gratuite atteint ses limites
L'écart apparaît dès que vous arrêtez de surveiller le Mac vous-même. Aucun des outils ci-dessus n'a conscience de la charge de travail : ils tiennent une assertion pendant une durée que vous fixez, ou « jusqu'à ce que je l'éteigne », pas « jusqu'à ce que le job que je fais tourner se termine réellement ». Lancez un fine-tuning de plusieurs heures sous caffeinate et éloignez-vous : rien ne surveille la batterie ou la chaleur à votre place — le run continue jusqu'à ce que l'arrêt d'urgence de la batterie intervienne lui-même, un arrêt brutal, pas contrôlé.
caffeinate a aussi un mode de défaillance plus discret : il reste lié à la session Terminal qui l'a lancé. Quittez Terminal, ou laissez cette session shell s'interrompre, et l'assertion disparaît avec elle — en plein job, sans prévenir — à moins d'avoir explicitement détaché le processus au préalable. C'est le problème inverse d'un Mac qui ne veut pas s'endormir : un Mac qui s'endort précisément quand vous ne le vouliez pas.
disablesleep joue dans l'autre sens. C'est un réglage système global et persistant, pas limité à votre job. Si ce qui l'a activé plante avant de le réinitialiser — ou si vous oubliez tout simplement l'étape pmset -a disablesleep 0 — le Mac ne s'endormira plus, capot fermé ou non, tant que vous ne le remettez pas à zéro à la main ou ne redémarrez pas. C'est exactement la situation qui laisse une machine chaude tourner sans aucune circulation d'air si elle finit fermée dans un sac avant d'avoir refroidi. Rien de tout cela ne fait des outils gratuits un mauvais choix pour une tâche courte et surveillée — cela signifie simplement qu'une fois qu'un run devient assez long pour que vous vous éloigniez, la sécurité doit primer sur le confort, et c'est exactement à ça que sert une couche supplémentaire.
Ce qu'un gardien de poste de travail ajoute : un anti-veille propre au processus
Un gardien de poste de travail part de la même brique de base que caffeinate — une assertion d'alimentation IOKit — et y ajoute les deux choses que les outils gratuits laissent de côté : il se cale sur la charge de travail réelle, et il se retire de lui-même quand les conditions l'exigent. La règle que LidRun s'impose est simple : agent actif → rester éveillé ; agent terminé ou situation à risque → relâcher l'assertion et laisser le Mac s'endormir. Ce n'est pas un wake lock aveugle qui garde le Mac éveillé indéfiniment en attendant que vous pensiez à l'éteindre.
La détection de processus est ce qui rend concrète la moitié « agent actif ». Ajoutez un processus à surveiller — ollama, python, node, xcodebuild — et LidRun le repère par son nom ; pour les langages interprétés, il peut aussi filtrer sur un argument de script, comme train.py, si bien que python train.py compte alors que python seul serait trop large pour être surveillé sans risque. Une correspondance CLI doit franchir un seuil de CPU (5 % par défaut) pour compter comme travail actif plutôt que simplement présent ; une app graphique doit franchir un seuil plus haut, 40 %, pour qu'un éditeur simplement ouvert ou une fenêtre de model-runner inactive ne garde jamais le Mac éveillé à elle seule.
Un court délai de grâce (holdoff, 60 secondes par défaut) absorbe les brèves chutes de CPU — Ollama entre deux tokens, un script qui patiente sur une E/S — sans relâcher l'assertion trop tôt. Les agents de codage IA connus bénéficient d'un holdoff bien plus long, 30 minutes, pour la même raison : un agent qui attend une réponse d'API peut rester près de 0 % de CPU pendant plusieurs minutes tout en étant encore en pleine tâche, et relâcher le Mac sous ses pieds irait à l'encontre du but recherché. Quand le processus surveillé se termine réellement, l'assertion se lève d'elle-même — aucune étape séparée à retenir.
Surveiller batterie, chaleur et alimentation pendant un run
Pendant un run, LidRun surveille le niveau de charge de la batterie, le niveau de pression thermique du système, et si le Mac tourne sur secteur ou sur batterie. N'importe lequel des trois peut déclencher un arrêt contrôlé à la limite que vous avez fixée.
Côté batterie, le seuil d'arrêt automatique est fixé par défaut à 20 % et vous pouvez le monter ou le descendre ; un avertissement de batterie faible se déclenche vers 15 % dans tous les cas. Sous votre propre réglage se trouve un plancher dur — environ 4 % — qui déclenche toujours une mise en veille d'urgence, quelle que soit la façon dont vous avez configuré l'arrêt automatique. C'est un plancher que vous pouvez légèrement relever, pas un que vous pouvez désactiver, pour qu'un run sans surveillance ne puisse pas discrètement vider la batterie. Cela aide à réduire le risque ; cela ne promet pas une autonomie précise, puisque c'est la charge de travail elle-même qui consomme la batterie.
Côté chaleur, LidRun surveille le niveau de pression thermique du système (normal, fair, hot ou very hot) et, sur les Macs qui exposent des données SMC utilisables, le recoupe avec la température mesurée et le throttling du CPU, pour qu'une lecture OS grossière ne sous-estime pas la pression réelle. Une lecture « very hot » désactive automatiquement le mode Closed-Lid pour laisser le matériel brider ses performances et s'endormir comme il est conçu pour le faire. Sur Apple Silicon, les ventilateurs sont largement pilotés par le firmware ; LidRun lit les clés de température SMC comme un simple signal de surveillance et ne cherche pas à outrepasser la courbe de ventilation propre au firmware. Voyez le garde-fou thermique comme un déclencheur d'arrêt contrôlé, pas comme un moyen de maintenir la puce à une température choisie — le positionnement et la circulation d'air affectent la température réelle de la puce bien plus que n'importe quel garde-fou logiciel.
Notifications et rapport hebdomadaire pour les runs sans surveillance
Quand une session sous surveillance se termine ou qu'un événement de sécurité se déclenche, LidRun peut alerter Telegram, Discord, Slack, ntfy.sh, Pushover, ou un webhook générique. Telegram demande le moins de configuration : envoyez un message au bot LidRun partagé, appuyez sur Start, et collez en retour le Chat ID qu'il vous donne — pas de jeton de bot à créer ni à gérer. Chaque canal transmet les mêmes types d'événements : session terminée, plancher de batterie atteint, arrêt thermique, minuteur de session expiré.
La différence entre un événement de fin normale et un événement de sécurité vaut la peine d'être connue. Une fin propre signifie que le travail s'est achevé et que le processus s'est terminé normalement. Un arrêt thermique ou batterie signifie que quelque chose a coupé le run court. Recevoir une alerte étiquetée plutôt que le silence vous dit lequel des deux s'est produit, pas seulement que le Mac s'est arrêté.
Le rapport hebdomadaire de poste de travail Mac condense les sept derniers jours de l'Activity Log en temps de fonctionnement total, votre plus longue session, et un Workstation Score. Le score démarre à 100 et perd 8 points par avertissement thermique et 6 points par mise en veille d'urgence survenus dans la semaine, avec un plancher à 0. Trois avertissements thermiques ou plus, ou deux mises en veille d'urgence ou plus, signalent une semaine à risque réel plutôt qu'une simple baisse mineure. Un score bas est une invitation à revoir le positionnement et les habitudes de circulation d'air — ce n'est pas un diagnostic disant que le matériel a un problème.
Les limites honnêtes d'un portable en poste de travail IA
Un MacBook effectue du calcul réel quand il fait tourner une boucle d'inférence ou un fine-tuning. Un gardien aide à réduire le risque autour de ça, mais il ne change rien à la nature du matériel. Le throttling thermique est bien réel sur les charges soutenues. La batterie est finie. Les ventilateurs Apple Silicon sont pilotés par le firmware et aucun logiciel ne peut les outrepasser. Rien de tout cela n'est spécifique à LidRun — c'est vrai dès qu'une charge de travail lourde démarre, avec n'importe quel outil anti-veille, ou même sans aucun.
Le positionnement échappe à la portée de tout logiciel, gardien ou non. Un Mac posé sur une surface dure et plane avec de la circulation d'air en dessous chauffe moins que le même Mac posé sur un lit, un canapé, ou enfermé dans un sac — exactement le genre de situation qu'un disablesleep oublié rend risqué. Pour tout ce qui dépasse un run court, surtout capot fermé, gardez le Mac ventilé ; une surface ferme et un espace libre en dessous ne sont pas optionnels. Les limites de sécurité réagissent à ce qu'elles peuvent mesurer ; elles ne peuvent pas corriger une installation qui piège la chaleur par construction.
À une certaine échelle — de l'inférence GPU soutenue pendant de nombreuses heures, ou un fine-tuning laissé tourner toute la nuit — un poste de travail dédié ou un GPU cloud reste la réponse honnête ; un MacBook sous surveillance ne remplace pas de la RAM ECC et un refroidissement de niveau serveur. Ce qu'il apporte réellement : une amélioration concrète par rapport à un MacBook non surveillé et à un simple anti-veille, parce qu'il se cale sur le job, surveille les deux choses qui tournent vraiment mal — la batterie et la chaleur — et vous dit laquelle s'est produite au lieu de vous laisser deviner. C'est là sa vraie valeur : réduire le risque d'un échec silencieux, pas éliminer les compromis liés au fait de faire tourner du calcul réel sur du matériel portable. Utilisez-le avec précaution, sur une surface ventilée, et laissez-le assurer la surveillance que vous ne pouvez pas faire vous-même en votre absence.
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
Un gardien de poste de travail IA garde un Mac éveillé uniquement pendant qu'une charge de travail IA tourne réellement, surveille la charge de la batterie et la pression thermique pendant toute la durée, arrête automatiquement la session aux limites que vous fixez, et vous notifie quand le job se termine ou qu'un événement de sécurité se déclenche. Il vient se poser au-dessus d'un simple anti-veille — la différence, c'est qu'il est calé sur la charge de travail et conscient des deux choses qui tournent vraiment mal sur un portable : la chaleur et la batterie.
Pas au niveau de la brique de base — LidRun tient le même type d'assertion d'alimentation IOKit que caffeinate, et son mode Closed-Lid bascule exactement le même réglage pmset disablesleep que vous pourriez activer à la main. La différence, c'est la portée et la conscience du contexte : caffeinate et pmset tiennent une assertion pour une durée ou un processus que vous précisez, rien de plus, alors qu'un gardien se lie à un motif de charge de travail, surveille l'état de la batterie et la température tout du long, applique des limites d'arrêt automatique, et vous prévient quand c'est fini. Pour une tâche courte où vous restez au clavier, caffeinate seul reste un bon choix.
Oui, avec des limites honnêtes. Un MacBook Apple Silicon récent gère bien l'inférence locale, les téléchargements de modèles, et les runs de fine-tuning plus courts. Les contraintes sont le throttling thermique sur les charges soutenues, un contrôle des ventilateurs limité par le firmware sur les puces M, et une batterie finie. Un gardien aide à réduire le risque pendant les runs sans surveillance ; il ne change pas le plafond matériel. Pour des charges de travail longues et lourdes, une machine dédiée ou un GPU cloud reste probablement le meilleur choix.
La charge de la batterie par rapport à votre seuil d'arrêt automatique et à un plancher dur de batterie faible, le niveau de pression thermique du système (plus la température SMC sur les Macs qui l'exposent), si le Mac tourne sur secteur ou sur batterie, et le motif de processus que vous avez configuré — de sorte que le gardien reste actif tant que le travail correspondant tourne et se désactive automatiquement dès qu'il s'arrête. Chaque déclenchement est enregistré dans l'Activity Log.
LidRun prend en charge Telegram via un bot partagé (aucune configuration de jeton nécessaire), les webhooks entrants Discord, les webhooks Slack, les topics ntfy.sh, Pushover, et un webhook JSON générique. Configurez le canal dans Settings et LidRun envoie une alerte à la fin de la session ou lors d'un événement de sécurité comme un plancher de batterie ou un arrêt thermique. Une fin propre et un arrêt forcé sont étiquetés différemment, pour que vous sachiez lequel des deux s'est produit.
Oui — ajoutez n'importe quel processus par son nom (docker, xcodebuild, un binaire personnalisé) et LidRun le surveille directement. Pour les langages interprétés — Python, Node, Ruby, Bash, et quelques autres — vous pouvez à la place filtrer sur un argument de script, comme train.py, pour qu'un nom d'interpréteur générique ne finisse pas par surveiller tous les processus Python du Mac.