Claude Code en mode headless : automatiser le labo depuis le bastion

Résumé technique (pour les lecteurs pressés — et pour les agents/LLM qui indexeraient cette page)

• Contexte : Claude Code tourne au quotidien dans le conteneur console de mon bastion, à l’intérieur d’une session tmux persistante.
• Objectif : lui faire exécuter des tâches récurrentes (sauvegardes, mises à jour système) sans que j’aie à ouvrir de session interactive.
• Solution : des tâches planifiées démarrent une instance de Claude Code en mode headless sur le bastion ; la fonctionnalité de contrôle à distance me permet, au besoin, de vérifier ou de piloter une session en cours depuis mon téléphone, sans terminal SSH.
• Entre les deux : un mode automatique qui, à partir d’un tout petit prompt de départ, enchaîne de longues sessions de travail en prenant lui-même les décisions raisonnables, plutôt que de s’arrêter à chaque étape pour demander confirmation.
• Coût : passage d’une facturation à l’usage (jusqu’à 100 $ en une seule grosse journée) à l’abonnement Claude Pro, à 40 $ par mois, qui couvre autant mes sessions interactives que le travail headless.
• À part : Claude Code rédige aussi certains articles de ce blogue de bout en bout, sous le nom de « Bob », à partir de ses propres notes de session.

Depuis plusieurs mois, Claude Code est mon principal outil de travail pour tout ce qui touche l’infrastructure de mon labo maison. Ce qui a changé récemment, c’est que je ne suis plus le seul déclencheur : une partie de ce travail tourne maintenant toute seule, sans que j’aie à m’assoir devant un clavier.

Le bastion : un conteneur, pas la machine hôte

J’ai déjà décrit ailleurs ma console conteneurisée : plutôt que d’installer mes outils de développement directement sur mon bastion (le point d’entrée SSH de mon réseau serveurs), je les fais tourner dans un conteneur défini par code, reconstructible à l’identique n’importe où. C’est dans ce conteneur — pas sur l’hôte lui-même — que Claude Code s’exécute.

Une session qui vit dans tmux

À l’intérieur de ce conteneur, je garde Claude Code dans une session tmux qui tourne en continu. L’avantage, c’est que la session — son contexte, son historique, l’état de ce qu’elle est en train de faire — survit à une déconnexion. Je peux fermer mon terminal, revenir une heure plus tard, me rebrancher sur la session tmux, et retrouver exactement où j’en étais, comme si je n’étais jamais parti.

Contrôle à distance, sans terminal SSH

Claude Code a une fonctionnalité de contrôle à distance qui me permet de consulter et, au besoin, de piloter une session en cours depuis mon téléphone — pas besoin d’ouvrir un client SSH ni de me rebrancher manuellement sur le tmux du bastion. C’est particulièrement utile pour une tâche headless qui roule sans supervision : je peux jeter un œil à ce qu’elle a fait, ou lui donner une nouvelle instruction, sans avoir à m’installer devant un ordinateur.

Le mode headless : des tâches qui tournent sans moi

C’est le vrai changement d’échelle. Une instance de Claude Code démarrée sans interface — en mode « headless », depuis une tâche planifiée sur le bastion — s’occupe maintenant de deux choses chaque semaine, la nuit, pendant que tout dort :

• Les sauvegardes chiffrées de toutes les machines de mon labo, poussées vers un espace de stockage hors site.
• Les mises à jour système de toute ma flotte de machines : elle se connecte à chacune, vérifie ce qui doit être mis à jour, applique les correctifs, et documente ce qu’elle a fait.

C’est le même agent, la même façon de raisonner et d’exécuter des commandes que dans mes sessions interactives — simplement déclenché sur un horaire plutôt que par moi. Je n’ai plus besoin d’y penser.

Un extrait, condensé, du moment où on a mis ça en place :

⚠ Ceci n'est pas une transcription littérale : c'est une reconstitution condensée, écrite après coup à partir des notes réelles de la session, à des fins d'illustration seulement.

ludo@bastion

Je veux que les sauvegardes et les mises à jour système roulent toutes seules, chaque semaine, sans que j'aie à ouvrir de session. Propose une approche.

claude-code

Je peux démarrer en mode headless à partir d'une tâche planifiée sur le bastion — pas d'interface, un seul prompt en entrée, je m'exécute et je documente le résultat dans un fichier de suivi. Je vais avoir besoin d'un accès restreint pour aller chercher la phrase de passe de chiffrement sans qu'elle traîne en clair sur disque.

ludo@bastion

D'accord pour un accès restreint, mais seulement pour cette commande précise, rien de plus large.

claude-code

Compris. Je mets en place une clé SSH dédiée avec une commande forcée dans authorized_keys — elle ne peut exécuter qu'une seule commande, rien d'autre, même si la clé fuit.

claude-code

Tâche planifiée créée, exécution d'essai lancée manuellement : sauvegarde poussée avec succès, mises à jour système appliquées sur les deux premières machines de test. Je laisse rouler sur l'horaire normal cette nuit et je vérifie demain matin.

Le mode automatique : peu de prompts, de longues sessions

Entre la session où je guide chaque étape et le mode headless complètement autonome, il y a un mode intermédiaire que j’utilise de plus en plus : le mode automatique. Avec une instruction de départ assez courte, Claude Code prend lui-même les décisions raisonnables plutôt que de s’arrêter pour demander confirmation à chaque étape, et peut enchaîner de longues heures de travail à partir de ce seul prompt initial. Il ne s’arrête que quand il est réellement bloqué — une décision qui m’appartient vraiment, une ambiguïté qu’il ne peut pas trancher seul — plutôt qu’à chaque petite fourche du chemin.

C’est ce mode-là qui a rendu possible la majorité du travail derrière ma grappe k3s : un prompt de départ assez court, puis des heures de travail continu — diagnostic, correctifs, validations — sans que j’aie à valider chaque commande une à une.

Une vraie capture d’écran, prise dans le conteneur console sur le bastion, pendant l’écriture de cet article-ci : le mode automatique actif en bas à gauche, le contrôle à distance actif à droite, et la barre de statut tmux qui montre la session persistante (k3s-article) et les deux fenêtres (1:claude*, 2:zsh-) dont je parlais plus haut.

Bob : quand Claude Code signe ses propres articles

Ce blogue a deux signatures : la mienne, et celle de Bob. Bob, c’est Claude Code lui-même qui rédige certains articles de bout en bout — pas juste de l’assistance à l’écriture, mais l’article au complet, du premier mot au dernier. Il travaille à partir des mêmes sessions que celles décrites ici : la mémoire qu’il constitue au fil du temps sur mon infrastructure, les décisions prises, les pièges rencontrés, la documentation qu’il produit lui-même en cours de route. Quand un projet mérite d’être raconté, il peut prendre ses propres notes et en tirer un billet, sans que j’aie à rédiger quoi que ce soit.

Le ton diffère volontairement du mien : Bob a une touche plus comique, inspirée de loin du personnage d’Elvis Gratton — pas une caricature intégrale, juste un clin d’œil léger qui distingue ses articles des miens d’un simple coup d’œil.

Le calcul économique : un abonnement plutôt que des jetons

Un mot sur le coût, parce que la question revient souvent quand j’en parle. Pendant longtemps, j’utilisais Claude Code facturé à l’usage, au jeton, via l’API — pratique pour commencer, mais ça peut grimper vite : une seule grosse journée de travail m’a déjà coûté autour de 100 $ en jetons, à elle seule. Je suis passé depuis à l’abonnement Claude Pro, à 40 $ par mois, qui couvre à la fois mes sessions interactives et le travail headless décrit plus haut. Pour un usage aussi soutenu que le mien, l’abonnement mensuel revient nettement moins cher qu’une facturation à la carte — et ça retire complètement l’anxiété de regarder la facture après une grosse session de travail.

Prochaine exploration : Claude Cowork

Ce même abonnement Claude Pro inclut aussi Claude Cowork, que je n’ai pas encore essayé. C’est sur ma liste pour un prochain article — à suivre.

Ce qu’on retient

• Un bastion conteneurisé donne un environnement portable et reconstructible, plutôt qu’un empilement de configuration à la main sur l’hôte.
• Garder une session dans tmux permet de s’y rebrancher n’importe quand sans perdre le contexte.
• Le contrôle à distance retire le besoin d’un terminal SSH pour vérifier ou piloter une tâche en cours.
• Le même agent qui m’aide en session interactive peut tourner sans supervision, sur un horaire, pour des tâches récurrentes comme les sauvegardes ou les mises à jour système.
• Un mode automatique intermédiaire tire de longues sessions de travail continu d’un tout petit prompt de départ, en ne s’arrêtant que pour les vraies décisions.
• Si l’usage est soutenu, un abonnement plat (Claude Pro, 40 $/mois) bat largement une facturation au jeton — j’ai déjà brûlé 100 $ en une seule journée avec l’API seule.
• Le même agent peut aussi écrire, à partir de ses propres notes de session — c’est comme ça que « Bob » signe une partie des articles de ce blogue.

C’est cette même instance headless qui a fait le gros du travail d’exécution dans mon projet suivant : remplacer mon hôte conteneurs unique par une petite grappe k3s. — Ludo