Des agents qui tournent sur le mini-PC

Jusqu’ici, vous lanciez l’agent à la main, vous le regardiez bosser, vous fermiez le terminal. C’est très bien, mais c’est aussi passer à côté du vrai pouvoir d’une machine dédiée. Votre portable, vous le fermez, il dort, il part en réunion avec vous. Le mini-PC, lui, reste allumé, silencieux, à boire trois fois rien d’électricité, jour et nuit. Et ça change tout : il devient l’hôte parfait pour des agents qui travaillent sans vous.

C’est exactement ce qu’un laptop ne peut pas faire. Un agent qui se réveille tous les matins à 7 h pendant que vous dormez, qui surveille un flux toute la journée, qui vous prépare un rapport pendant votre week-end, il lui faut une machine qui ne s’éteint jamais. Vous en avez une. Voyons quoi en faire.

L’idée : une machine toujours là = des agents qui tournent sans vous

Un agent, on l’a vu dans C’est quoi un agent, c’est une boucle : objectif, action, observation, on recommence. Rien n’oblige cette boucle à se dérouler sous vos yeux. Si vous pouvez la déclencher tout seul : sur un horaire, sur un événement, en tâche de fond, alors votre mini-PC se transforme en collègue qui bosse pendant que vous vivez votre vie.

Quelques exemples qui deviennent possibles le jour où la machine ne dort plus :

• Tous les matins, un agent relit les pull requests ouvertes et vous poste un résumé sur Slack.
• Un agent surveille un flux RSS ou une API et vous prévient quand quelque chose bouge.
• Un rapport récurrent (les chiffres de la veille, l’état d’un service) généré et envoyé sans que vous leviez le petit doigt.
• Un agent qui monitore un service et vous alerte quand il tombe.

Le point commun : personne n’est devant l’écran. Et c’est là que le mini-PC dédié bat le laptop à plate couture.

Les agents en tâche de fond ou sur planning

Comment on passe d’« un agent que je lance » à « un agent qui se lance » ? Avec les deux vieux outils de planification de Linux : cron et les timers systemd. Vous en avez croisé dans Réglages système, ce sont eux qui déclenchent une commande à heure fixe, encore et encore, sans vous.

L’astuce, c’est que votre agent sait tourner en mode non-interactif (« headless ») : au lieu d’ouvrir un terminal et de discuter, vous lui passez une tâche d’un coup, il l’exécute, il rend son résultat, il s’arrête. Branchez ce mode sur un timer, et vous avez un agent récurrent.

La forme réelle, sans les détails de syntaxe :

# crontab -e, tous les matins à 7 h, on réveille l'agent sur une tâche fixe
0 7 * * *  cd ~/projets/veille && /chemin/vers/agent "Relis les PR ouvertes et poste un résumé" >> ~/logs/veille.log 2>&1

Le timer appelle l’agent avec une tâche, l’agent boucle tout seul jusqu’à « c’est fait », écrit dans un log, et rend la main. Demain matin, rebelote.

Claude Code sait aussi planifier lui-même, mais à d’autres échelles. /loop relance une consigne à intervalle régulier tant que la session reste ouverte (et les tâches récurrentes expirent au bout de sept jours). Les routines (/schedule) tournent sur un planning, mais dans le cloud d’Anthropic, donc loin de vos fichiers et de vos modèles locaux. Pour un agent qui travaille sur le mini-PC, cron et systemd restent la bonne plomberie.

Le combo gagnant : agents locaux + Ollama

Un agent qui tourne cent fois par jour, vous n’avez pas envie de le payer cent fois par jour. Et s’il brasse des données sensibles, vous n’avez pas envie qu’elles partent chez un tiers à chaque tour de boucle. C’est exactement le terrain de jeu de l’hybride cloud + local, appliqué au travail autonome.

L’idée : pour les boucles à haute fréquence, privées ou hors-ligne, vous pointez l’agent vers un modèle local servi par Ollama. Coût marginal : zéro. Données qui sortent : aucune. Un agent de fond qui classe, résume ou surveille mille fois par jour tourne gratuitement et en privé sur votre machine. Vous réservez le cloud (Claude, GPT) pour le rare moment où il faut vraiment du raisonnement de pointe.

Pour choisir ce modèle, Quelle IA tient un classement des modèles à installer chez soi et une page machine par machine (par exemple pour un Ryzen AI Max+ 395 avec 128 Go). Pour un agent, croisez avec le classement Agents : un modèle bon en conversation n’est pas forcément bon pour enchaîner des actions seul.

Joignable de partout

Le mini-PC est sur votre réseau privé. Donc vous n’avez pas besoin d’être physiquement devant pour lui confier du travail ou voir où il en est. Depuis votre téléphone dans le métro, depuis votre laptop chez un client : vous textez une tâche à votre machine, elle bosse pendant que vous êtes ailleurs, et vous relisez le résultat plus tard.

Claude Code le fait nativement avec Remote Control : lancez claude --remote-control (ou tapez /remote-control dans une session ouverte), et la session devient pilotable depuis claude.ai/code ou l’appli Claude sur téléphone, pendant que le code et les fichiers restent sur le mini-PC. Il faut un abonnement Pro, Max, Team ou Enterprise. Côté Codex, le pilotage depuis le téléphone passe par l’onglet Codex (ou Remote) de l’appli ChatGPT, qui se connecte à l’appli de bureau ChatGPT sur un Mac ou un PC Windows ; cette appli de bureau sait ouvrir un projet du mini-PC en SSH, à condition que codex y soit installé et connecté. Et si vous préférez écrire à votre agent dans Telegram ou Discord, les Channels de Claude Code et les passerelles comme Hermes ou OpenClaw sont présentés dans Hermes & OpenClaw.

Pour tout le reste, c’est l’objet du chapitre réseau qui arrive : Tailscale tisse le lien privé entre vos appareils, et Travailler à distance montre comment rejoindre la machine en SSH depuis n’importe où. Le mini-PC devient un atelier que vous emportez dans votre poche sans jamais le débrancher.

Garder une session vivante avec tmux

Tous les agents ne sont pas des jobs planifiés. Une session interactive longue lancée en SSH meurt avec votre connexion, sauf si vous l’avez démarrée dans tmux : la session vit sur le mini-PC, vous vous détachez, et vous la retrouvez plus tard pile où vous l’aviez laissée. Le mode d’emploi est dans Travailler à distance. Le duo tmux + claude --remote-control marche très bien : tmux garde le processus en vie, Remote Control vous le met dans la poche.

La sécurité d’un agent autonome

On arrive au point sérieux. Un agent qui agit sans humain dans la boucle, c’est précisément l’endroit où la règle du moindre privilège compte le plus. Quand vous êtes devant l’écran, vous pouvez dire « non » avant la bêtise. En tâche de fond à 3 h du matin, personne ne dira non à votre place.

Mettre en place un agent récurrent : la checklist

Les trois agents font l’affaire pour ce travail de fond. Ils ne proposent pas les mêmes modèles : la page Outils de code de Quelle IA recense ceux de Claude Code, Codex et OpenCode, avec le score de chacun. Et pour un assistant à demeure que vous joignez par messagerie, avec mémoire et tâches planifiées intégrées, voyez Hermes & OpenClaw.

# crontab -e, tous les matins à 7 h
0 7 * * *  cd ~/projets/veille && ~/.local/bin/codex exec --sandbox workspace-write -o ~/logs/veille-resume.md "Relis les PR ouvertes et rédige un résumé" >> ~/logs/veille.log 2>&1

Un mot honnête sur l’autonomie longue

L’autonomie sans surveillance sur des tâches longues et ouvertes reste la frontière du domaine. Les modèles locaux, en particulier, sont bien meilleurs comme ouvriers de fond bien bornés que comme opérateurs totalement autonomes, on l’a dit sans détour dans Choisir son modèle local. Lâché sur un objectif flou et lointain, un modèle local produira du plausible-mais-faux, en confiance, en boucle.

La parade est simple et tient en deux mots : borne et vérifie. Découpez en tâches courtes et nettes, faites-en des jobs idempotents, gardez un humain qui relit le résultat. Un agent de fond qui fait bien une petite chose mille fois vaut infiniment mieux qu’un agent ambitieux qui se perd. C’est moins spectaculaire, et bien plus utile.