Du terminal a l’usine — Faire tourner des AI Agents headless 24/7

C’est le changement architectural le plus significatif dans le coding assiste par l’IA en 2026. On passe d’un outil local — ou l’on surveille un terminal, babysitte un agent et ferme son laptop quand on a fini — a un backend headless ou les agents vivent sur un serveur et ou l’on dispatche des taches depuis n’importe ou.

La difference est fondamentale : l’assistant de coding IA n’est plus un outil qu’on utilise. C’est un service qu’on opere.

Je fais tourner ce setup depuis quelques mois, et ca a transforme ma facon de penser la capacite de developpement. Voici le guide complet pour construire sa propre infrastructure d’agents headless avec les fonctionnalites Remote Control et Dispatch de Claude Code.

L’architecture : outil local vs. backend headless

Avant de plonger dans le comment, il faut comprendre ce qui change :

Dimension	Outil local (2025)	Backend headless (2026)
Execution	Tourne sur le laptop	Tourne sur une VM cloud ou un serveur persistant
Interface	On tape dans un terminal	On envoie des commandes via Dispatch (mobile/web)
Persistance	S’arrete quand on ferme le capot	Tourne 24/7 via Remote Control et /loop
Supervision	On regarde chaque ligne modifiee	On review les diffs, artefacts et logs de maniere asynchrone
Echelle	Un agent, une tache	Plusieurs agents, taches paralleles, coordonnes via des channels

Ce n’est pas juste une amelioration de confort. C’est un multiplicateur de capacite. Au lieu de coder 8 a 10 heures par jour avec l’aide de l’IA, on a des agents qui travaillent en permanence — trient les issues, corrigent les tests, reviewent les PRs et construisent des features pendant qu’on dort, qu’on vole ou qu’on vit sa vie.

Etape 1 : Preparer le serveur headless

A la place du laptop, il faut un environnement persistant — un VPS, un serveur local dedie ou un conteneur Docker — qui reste actif 24/7. J’utilise un Mac Studio dans mon bureau, mais n’importe quel VPS Linux (Hetzner, DigitalOcean, AWS EC2) fait l’affaire.

Installer Claude Code sur le serveur :

npm install -g @anthropic-ai/claude-code

Configurer pour le mode headless en editant ~/.claude/settings.json :

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
    "CLAUDE_CODE_HEADLESS": "true"
  }
}

Le flag HEADLESS indique a Claude Code de fonctionner sans attendre d’input terminal interactif. Le flag AGENT_TEAMS active la coordination multi-agents via des channels.

Important : Toujours lancer les sessions headless dans tmux ou screen. Ca offre un fallback physique d’attachement — si une tache bloque, on peut se connecter en SSH au serveur, attacher la session tmux et intervenir directement. C’est le filet de securite human-in-the-loop.

tmux new-session -s agent-factory

Etape 2 : Configurer Remote Control (le pont mobile)

Remote Control est le pont entre le telephone (ou n’importe quel appareil) et l’agent cote serveur. C’est ce qui rend le setup vraiment “headless” — pas besoin d’etre devant un terminal pour interagir avec ses agents.

Initialiser le pont sur le serveur :

claude remote-control

Un QR code s’affiche dans le terminal. Le scanner avec l’app Claude Mobile sur le telephone.

Le resultat : le telephone est desormais une telecommande pour l’agent cote serveur. On peut fermer le laptop, quitter son bureau, aller courir — le processus agent est toujours vivant sur le serveur, en attente de commandes via l’interface mobile.

On peut :

• Voir sur quoi l’agent travaille en ce moment
• Envoyer de nouvelles instructions ou corrections
• Approuver ou rejeter les changements proposes
• Tuer une tache qui derape

C’est le moment “je review du code depuis le cockpit en croisiere” qui justifie a lui seul tout le setup.

Etape 3 : Dispatch — Gestion structuree des taches

Au lieu de taper dans un chat en esperant le meilleur, Dispatch permet d’envoyer des taches structurees que l’agent prend en charge, execute et sur lesquelles il fait un rapport.

Envoyer un job Dispatch :

claude dispatch "Refactor the auth service to use the new Redis cache"

Contrairement au chat standard, Dispatch cree un job ID tracable. On peut verifier le statut depuis son telephone ou un autre terminal sans interrompre le travail en cours de l’agent. Chaque job Dispatch possede :

• Un identifiant unique pour le suivi
• Un statut (queued, running, completed, failed)
• Un log d’execution complet
• Le diff de toutes les modifications effectuees
• La possibilite d’approuver ou rejeter le resultat

Le batch dispatching revele toute la puissance du systeme. Empiler plusieurs taches avant d’aller se coucher :

claude dispatch "Add rate limiting to the /api/documents endpoint"
claude dispatch "Write integration tests for the validation engine"
claude dispatch "Update the Swagger docs for v2 API changes"

Chaque tache s’execute sequentiellement (ou en parallele avec les Agent Teams), et on review les resultats le lendemain matin.

Etape 4 : Agent Teams pour l’execution parallele

Pour les projets plus importants, ne pas utiliser un seul agent. Utiliser une equipe. Avec les Agent Teams actives, on peut lancer plusieurs agents specialises qui se coordonnent via des channels.

Definir les roles en restreignant l’acces aux fichiers :

• Backend Agent — acces restreint a /src/backend, /src/api
• Frontend Agent — acces restreint a /src/frontend, /src/components
• DevOps Agent — acces a /infrastructure, /.github/workflows
• Test Agent — acces a /tests, lecture seule sur les fichiers sources

Utiliser les channels pour la communication inter-agents :

Quand le Backend Agent termine un nouvel endpoint API, il peut notifier le Frontend Agent via un channel pour mettre a jour le composant UI correspondant. Le DevOps Agent surveille les changements d’infrastructure et met a jour les configs de deploiement en consequence.

Ca reproduit le fonctionnement d’une vraie equipe d’ingenieurs — roles specialises, frontieres claires, communication asynchrone. Sauf que ces coequipiers travaillent 24/7 et n’ont jamais besoin de standup.

Etape 5 : Automatisation evenementielle (l’usine)

La derniere etape transforme le dispatching manuel en usine autonome avec des triggers evenementiels.

Health checks cron avec le protocole natif /loop :

# Dans une session Claude Code detachee
/loop 2h "Check for any failing tests in the CI pipeline and attempt to fix them"

Ca tourne toutes les 2 heures, detecte et corrige automatiquement les echecs de tests. L’ingenieur QA de nuit personnel.

Triggers webhook depuis la CI/CD :

Integration avec GitHub Actions pour que, lorsqu’une PR est ouverte, l’instance Claude cote serveur automatiquement :

1. Pull le dernier code
2. Review la PR pour detecter les problemes
3. Lance la suite de tests
4. Poste des commentaires de review
5. Optionnellement auto-corrige et pousse les corrections

# .github/workflows/agent-review.yml
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  agent-review:
    runs-on: self-hosted  # Your agent server
    steps:
      - uses: actions/checkout@v4
      - run: claude dispatch "Review this PR: ${{ github.event.pull_request.title }}"

Taches de maintenance planifiees :

/loop 24h "Run dependency audit, check for CVEs, and create a PR if updates are needed"
/loop 12h "Review open issues labeled 'bug' and attempt to reproduce and fix"

Mon setup actuel

Voici a quoi ressemble mon usine a agents en pratique :

• Hardware : Mac Studio M2 Ultra (toujours allume, dans mon bureau)
• Sessions : 3 fenetres tmux — Backend Agent, Frontend Agent, Maintenance Agent
• Remote Control : Appaire avec mon iPhone via l’app Claude Mobile
• Dispatch queue : J’empile 5 a 10 taches chaque soir avant de me coucher
• Loop tasks : Monitoring des tests (2h), audit des dependances (24h), nettoyage des PRs stales (12h)
• Routine matinale : Review des diffs de la nuit avec le cafe, approuver/rejeter, dispatcher un nouveau batch

Le resultat est environ 3x le debit de developpement par rapport aux sessions Claude Code purement locales. Non pas parce que les agents sont plus rapides — mais parce qu’ils ne s’arretent jamais.

Considerations pratiques

Couts : Faire tourner des agents 24/7 consomme des credits API significatifs. J’utilise l’abonnement Claude Max qui rend cela economiquement viable. Surveiller sa consommation et configurer des alertes budget.

Securite : Le serveur a acces a la codebase et aux cles API. Le traiter comme un serveur de production — uniquement des cles SSH, firewall configure, secrets dans les variables d’environnement, mises a jour de securite regulieres.

Controle qualite : Ne jamais auto-merger l’output des agents. Toujours reviewer les diffs avant le merge. L’usine de nuit produit du code ; c’est toujours l’humain qui decide de ce qui part en production. Les agents sont des developpeurs juniors infatigables, pas des decideurs autonomes.

Commencer petit : Ne pas essayer de monter l’usine complete des le premier jour. Demarrer avec Remote Control et des jobs Dispatch individuels. Ajouter les Agent Teams quand on est a l’aise. Ajouter l’automatisation par loop en dernier, une fois qu’on fait confiance a la qualite des resultats non supervises.

Et ensuite

Le paradigme des agents headless est encore jeune. Pour 2026-2027, j’anticipe :

• Hebergement cloud natif pour les agents Claude Code (plus besoin de serveur auto-heberge)
• Dashboards visuels pour monitorer le statut de la flotte d’agents, les couts et la qualite de l’output
• Protocoles agent-to-agent au-dela des channels — contexte partage, ownership du code, coordination des merges
• Agents auto-apprenants qui apprennent des patterns de review et ajustent leur approche

La transition de “l’IA comme outil” a “l’IA comme service” se produit en ce moment meme. Les developpeurs qui apprennent a operer des flottes d’agents — et pas seulement a utiliser des assistants IA — auront un avantage structurel qui se compose avec le temps.