Pourquoi j’ai créé LidGuard, un programme pour lancer un agent IA et pouvoir refermer son ordinateur dans le bus ou le métro
(github.com/airtaxi)Je code souvent sur mon ordinateur portable pendant mes déplacements. En ce moment surtout, il m’arrive de plus en plus de confier à des agents de codage IA comme Codex des tâches qui prennent un peu de temps.
Le problème, c’était au moment de descendre du bus ou du métro.
Le prompt avait déjà été envoyé, l’agent était encore en train de traiter la demande, mais si je refermais le capot de l’ordinateur, il pouvait passer en veille et interrompre le travail. Du coup, je descendais souvent en gardant le portable à moitié fermé avec l’écran allumé, ou bien j’attendais encore un peu, ou alors j’interrompais simplement la tâche pour la reprendre ensuite.
Ça peut sembler être un petit inconfort sans importance, mais à force de se répéter, c’était assez agaçant.
Ce que j’ai donc créé
LidGuard est un outil de gestion de l’alimentation qui empêche l’ordinateur portable de se mettre en veille pendant qu’un agent de codage IA local travaille, puis rétablit la politique d’alimentation d’origine une fois le travail terminé.
L’idée visée était à peu près le flux suivant.
- Confier à l’agent une tâche longue.
- Si on doit se déplacer, refermer l’ordinateur portable.
- Pendant le travail de l’agent, bloquer temporairement la veille et la mise en veille liée à la fermeture du capot.
- Une fois le travail terminé, restaurer les paramètres d’alimentation d’origine.
- Selon la configuration, entrer en veille ou en veille prolongée.
Personnellement, c’est cette dernière partie que je préfère. Si l’on s’arrêtait simplement à « continuer à s’exécuter même quand le capot est fermé », l’utilisateur devrait de toute façon s’en préoccuper plus tard. Avec LidGuard, l’objectif est aussi de laisser l’ordinateur se reposer une fois le travail de l’agent terminé.
Pourquoi en faire un outil séparé
J’ai aussi cherché des programmes existants pour empêcher la veille.
Dans ce que j’ai pu trouver, la plupart se rapprochaient de l’un des cas suivants.
- Empêcher la veille tant qu’un processus précis est en cours d’exécution
- Utiliser un minuteur
- Laisser l’utilisateur activer ou désactiver la fonction manuellement
- Empêcher seulement la veille lorsque le capot de l’ordinateur portable est ouvert
Ce que je voulais était un peu différent.
- Modifier temporairement aussi le comportement de veille lorsque le capot est fermé
- Savoir quand une session d’agent IA est réellement terminée
- Restaurer ensuite la politique d’alimentation d’origine
- Si nécessaire, envoyer automatiquement l’ordinateur en veille ou en veille prolongée
J’ai donc fait en sorte que, pour les agents pris en charge, le suivi du début et de la fin des tâches repose sur des hooks. Ce n’est pas tant un « outil qui garde l’ordinateur allumé en permanence » qu’un « outil qui le maintient éveillé uniquement pendant que l’agent travaille ».
Fonctions incluses
Au départ, je pensais qu’il suffisait que cela fonctionne bien pour Codex sous Windows. C’est l’environnement que j’utilise le plus souvent, et l’agent que j’emploie est presque toujours Codex.
Mais en le développant, je me suis dit que ce problème devait être assez général, alors j’ai ajouté progressivement quelques fonctions supplémentaires.
- Contrôle de l’alimentation pour Windows, Linux basé sur systemd/logind et macOS
- Intégration avec Codex, Claude Code et GitHub Copilot CLI
- Veille ou veille prolongée automatique après la fin d’une tâche
- Paramètres de gestion des demandes d’autorisation quand le capot est fermé
- Désactivation de la prévention de veille pour les sessions inactives pendant un certain temps
- Veille prolongée d’urgence selon des seuils de capteur de température
Mon ordinateur portable est un Windows on ARM, donc pour des tâches d’agent, il n’a pas tendance à chauffer fortement dans un sac. Malgré tout, je pense qu’il faut rester prudent quand on se déplace avec un ordinateur fermé mais toujours allumé. J’ai donc aussi ajouté, dans les environnements pris en charge, une fonction qui tente immédiatement une veille prolongée ou une veille si la température dépasse un certain seuil.
Points d’attention
LidGuard ne signifie pas qu’on peut mettre son ordinateur portable dans un sac n’importe comment.
La gestion de l’alimentation, les capteurs de température, les autorisations, le firmware et les politiques du système d’exploitation peuvent se comporter différemment selon l’environnement. Même la veille prolongée d’urgence reste avant tout un dispositif de sécurité complémentaire.
Il est aussi possible d’utiliser un réglage qui traite automatiquement les demandes d’autorisation lorsque le capot est fermé, mais comme le travail peut continuer sans que l’écran soit visible, il vaut mieux l’utiliser avec prudence.
Périmètre de test actuel
L’environnement le plus testé est Windows + Codex.
La prise en charge de Linux, macOS, Claude Code et GitHub Copilot CLI est également implémentée, mais je n’ai pas suffisamment utilisé en conditions réelles toutes les combinaisons possibles. Si vous l’essayez sur un autre système d’exploitation ou avec un autre agent et remarquez quelque chose d’étrange, n’hésitez pas à ouvrir une issue ; vous pouvez même l’écrire en coréen, et j’essaierai de corriger cela autant que possible.
Au final, LidGuard est un petit outil que j’ai créé parce que je voulais utiliser les agents IA un peu plus confortablement en me déplaçant. J’espère qu’il pourra aussi être utile à ceux qui, dans le bus, le métro, un café ou entre deux salles de réunion, se sont déjà dit : « J’aimerais juste que mon ordinateur ne s’endorme pas avant la fin de cette tâche. »
6 commentaires
C’est impressionnant. Sous Windows, peut-il aussi détecter Codex ou Claude Code installés dans WSL ?
J’ai réfléchi à la meilleure approche dans un environnement WSL, et j’ai conclu que l’approche la plus propre consistait à appeler LidGuard installé côté Windows depuis le hook de l’agent installé sur Linux.
À ce sujet, j’ai publié le correctif 1.0.1, et la méthode d’installation détaillée a été reflétée dans le README(.ko).md, vous pouvez donc la consulter là-bas.
Ou bien, j’ai également ajouté dans agent-install.md, où l’on confie l’installation à l’agent, un prompt lié à la détection de l’environnement WSL, donc de ce côté aussi
Vous pouvez l’utiliser aussi ! J’ai appuyé sur le bouton d’envoi par erreur au milieu, oups
Ah non, je pense que je n'avais pas envisagé cette situation. Je vais réfléchir à la manière de la prendre en charge !
Peut-être est-ce en fait un immense compliment du genre : « C’est une idée parfaite qu’on ne peut logiquement pas critiquer, et j’en suis jaloux. »
Veuillez consulter la section consacrée aux commentaires dans le guide d'utilisation du site.
Merci de vous exprimer avec bienveillance et courtoisie.
Veuillez ne pas attaquer personnellement l’auteur du message.
Si vous avez une objection, merci de vous en tenir uniquement à son contenu.