Sécurité runtime pour les agents IA en développement

Les vrais risques des exécutions d'agents IA longues et sans surveillance

Une exécution Ollama la nuit, un agent Claude Code qui échafaude une fonctionnalité complète, une pipeline de compilation qui se relance à chaque changement de fichier — ces workloads partagent une propriété : aucun humain ne regarde. Quand personne ne regarde pour vous, le garde-fou d'inactivité standard de macOS s'active mais ne trace pas de ligne dure autour du niveau de batterie ou de la chaleur CPU prolongée. L'exécution continue jusqu'à ce qu'elle se termine, ou jusqu'à ce que le Mac s'arrête de lui-même.

Le risque de batterie est cumulatif. Recharger un MacBook à partir de presque vide à plusieurs reprises force les cycles de charge plus vite que de charger de 40 à 80 %. Une seule décharge complète jusqu'à 0 % la nuit est rarement fatale ; une habitude sur plusieurs semaines accélère la perte de capacité. Le danger plus immédiat est un agent bloqué — une boucle de prompt, un délai d'API qui n'a jamais réessayé, une compilation en attente sur un port verrouillé — consommant une CPU stable à 60-70 % pendant des heures pendant que vous dormez, sans terminer ni signaler une erreur.

Le risque thermique sur un MacBook est partiellement autogéré par macOS et partiellement dépendant de l'environnement physique. La puce se limitera elle-même, mais la limitation signifie une exécution plus longue et plus chaude — pas une exécution sûre. Un MacBook sur une surface molle avec des aérations bloquées, ou fonctionnant le couvercle fermé avec une mauvaise ventilation, concentre la chaleur dans une zone plus petite. Aucun outil logiciel ne change cette réalité physique. Les garde-fous vous aident à rester dans la partie plus sûre de la plage de fonctionnement ; ils ne contournent pas la physique.

Sécurité de batterie : pourquoi un seuil de charge faible est important

Un seuil de batterie faible est un arrêt net : quand la charge tombe en dessous d'un seuil que vous définissez, l'exécution s'arrête, la machine revient à son comportement de sommeil par défaut, et vous vous réveillez avec un Mac ayant une certaine charge. La différence entre un cutoff à 10 % et à 25 % est significative. À 10 %, une brève augmentation de la charge CPU ou une réaction lente du ventilateur peut vous pousser dans la zone où macOS déclenche un arrêt d'urgence sans avertissement. À 25-30 %, vous avez une marge — assez de charge pour un arrêt propre et une marge contre les pics de charge inattendus.

La fonctionnalité d'arrêt automatique de batterie de LidRun regarde le niveau de charge via IOKit et arrête l'affirmation de puissance quand le seuil est franchi. Pour les exécutions la nuit sur batterie seule — aucun chargeur, juste la batterie — 25 % est un seuil raisonnable pour la plupart des MacBooks. Si votre workload tend à faire des pics (grandes inférences de modèles, compilation lourde), 30 % donne plus de marge. Fonctionner sur l'alimentation secteur supprime la préoccupation de vidage immédiat, mais un seuil protège toujours contre la déconnexion de l'adaptateur en cours d'exécution.

Pour toute exécution plus longue que deux heures, branchez-vous d'abord. La charge CPU prolongée sur batterie compresse les cycles de charge plus vite que la même charge sur secteur. Ce n'est pas une recommandation spécifique à LidRun — c'est une maintenance matérielle basique. La notification de santé de batterie de macOS reflète cela ; les cycles de décharge profonde répétés déclenchent l'avertissement plus tôt sur les machines utilisées fortement pour le calcul. Préférez charger pour le travail d'agent la nuit chaque fois que l'option existe.

Sécurité thermique : ce que le Mac vous dit et ce qu'il ne dit pas

macOS expose l'état thermique via ProcessInfo.thermalState : nominal, juste, sérieux, critique. LidRun lit ce signal et peut arrêter l'affirmation quand l'état atteint « sérieux ». Le problème est la granularité : « sérieux » couvre une large bande de température, et le système ne passe à « critique » que quand il throttle déjà dur. Au moment où l'API retourne « critique », les vitesses d'horloge ont déjà chuté. L'arrêt à « sérieux » est le déclencheur plus utile — il attrape la montée avant le pire de la limitation.

La vitesse du ventilateur et les données du capteur SMC sont lisibles sur les Macs Intel et certaines configurations Apple Silicon. Sur Apple Silicon, le contrôle du ventilateur est largement géré par le contrôleur de plateforme et n'est pas exposé comme il l'était sur Intel. LidRun lit les métriques des ventilateurs comme un signal de surveillance sur le matériel compatible ; il ne peut pas forcer les ventilateurs à tourner plus vite sur les puces où ce chemin est verrouillé. Savoir qu'un ventilateur tourne déjà à 4 200 RPM vous dit que le système travaille dur. Que ce soit sûr de continuer dépend de la tendance d'état thermique et de la configuration physique ensemble — pas d'une métrique unique.

Les garde-fous thermiques logiciels sont une deuxième ligne de défense. Le premier est physique : surface dure et plate, aérations dégagées, couvercle ouvert si possible. L'exécution couvercle fermé concentre la chaleur plus que l'exécution couvercle ouvert, ce qui vaut la peine de comprendre avant de configurer un workflow clamshell la nuit. Un support de portable avec dégagement inférieur, ou même une simple élévation de bureau, fait une différence mesurable. Exécuter un long travail de calcul dans un sac ou un espace clos est la configuration à plus haut risque — aucun moniteur de processus ne change le piège thermique qui crée.

Construire des défauts sûrs pour le travail d'agent la nuit

Pour une exécution typique d'agent IA la nuit sur un Mac de développement, une configuration de départ raisonnable : seuil de batterie à 25-30 %, arrêt thermique à « sérieux » ou plus, minuteur de session défini à 8 heures ou combien de temps jusqu'à ce que vous soyez réveillé. Le minuteur de session est souvent négligé. Il attrape le cas où l'agent s'est bloqué à l'heure deux mais l'affirmation de veille active a persisté jusqu'au matin — brûlant la batterie et la chaleur sur un processus qui a arrêté de faire du travail utile des heures plus tôt.

La détection de processus de LidRun peut lier l'affirmation de veille active à un processus spécifique — Claude Code, Ollama, un script Python personnalisé. Quand ce processus se termine, l'affirmation s'arrête automatiquement. C'est plus propre qu'un minuteur fixe car il correspond à la durée réelle de la workload plutôt qu'à une estimation du pire cas. Combinez-le avec un minuteur de session comme limite supérieure : l'affirmation se termine quand le processus se termine, ou après N heures, selon ce qui vient en premier.

Les notifications push via ntfy.sh ou Pushover ferment la boucle. Si vous exécutez un agent la nuit, une notification quand il s'arrête — que ce soit depuis la fin, batterie faible, ou état thermique — signifie que vous le savez à 3 AM plutôt que de découvrir un Mac froid à 12 % de charge au petit déjeuner. Pour les travaux qui devraient se terminer en deux ou trois heures, ce feedback est important : vous pouvez vérifier et démarrer la prochaine étape plutôt que de perdre demi-journée à une exécution bloquée.

Pour les exécutions courtes et surveillées, caffeinate et un terminal regardé sont souvent suffisants. Là où LidRun ajoute de la valeur est la combinaison : seuil de batterie plus arrêt thermique plus affirmation liée au processus plus notifications, gérées depuis la barre de menus sans avoir besoin qu'une session de terminal reste ouverte. La sécurité vient de la pile de garde-fous, pas d'une seule fonctionnalité. Configurez-les une fois, laissez le Mac fonctionner, et laissez les limites faire leur travail.