Comment déployer un AI Coding Agent 24h/24 ?

En bref : En 2026, beaucoup d'équipes veulent un AI Coding Agent qui prend les issues la nuit, modifie le code et ouvre des PR — et se trompent dès la première étape en pensant qu'installer Cursor ou acheter une API suffit. Un autonomous coding agent durable repose sur une surface d'exécution permanente, une planification des tâches et une validation objective. Ce guide suit quatre axes : couches d'architecture, topologie de déploiement, stack minimal et durcissement production.

1. Qu'est-ce qu'un AI Coding Agent 24h/24 ?

Contrairement à Copilot ou Cursor Tab dans l'IDE, un AI Coding Agent 24h/24 répond à une autre question : en votre absence, qui a le droit de modifier le dépôt, d'exécuter des commandes et d'obtenir des signaux de validation dans un environnement réel ?

Un déploiement qui tient la route combine quatre capacités — en manquer une, ce n'est pas un « autonomous coding agent 24h/24 » :

• Environnement d'exécution permanent (L0) — nœud macOS ou Linux sans coupure, capable d'exécuter git, npm, xcodebuild.
• Processus agent de codage (L3/L5) — couche pair (Claude Code) ou autonome (OpenHands) qui lit le contexte et produit des diffs.
• Entrées et file de tâches — label d'issue GitHub, webhook, cron, commande Slack pour alimenter l'agent.
• Validation objective (L1) — GitHub Runner ou scripts de test produisant des Facts crédibles pour l'organisation, pas seulement « c'est bon » de l'agent.

En une phrase : le nœud est le socle et les utilities ; l'agent est l'ouvrier ; le Runner est le contrôle qualité. Beaucoup d'équipes achètent une API modèle et lancent un script sur MacBook — fermeture du capot, veille, concurrence mémoire et IP changeante tuent le job à trois heures du matin.

2. Un schéma : de l'entrée de tâche à la PR fusionnable

La chaîne causale ci-dessous résume un pipeline autonomous coding agent typique. À gauche la chaîne principale, à droite succès vs échecs typiques.

3. Les cinq couches décortiquées

Comme pour les couches d'infrastructure AI Agent, pas besoin de tout acheter d'un coup — mais il faut savoir ce qui manque si une couche est absente :

Claude Code produit le Diff, le Runner le Fact, OpenHands le Workflow — la répartition des rôles. Pour du lint nocturne, L0 + L5 + L1 suffit souvent ; pour du pair architecture le jour, ajoutez L3 en gérant la planification mémoire sur la même machine (planification mémoire parallèle).

4. Topologie : Mac mini local vs Cloud Mac

Le nœud peut être physique, VM ou location cloud — le critère est la SLA de disponibilité, pas la marque :

Les dépôts backend purs (Go / Node / Python) peuvent théoriquement tourner sur Linux — dès que xcodebuild, swift test ou signature Apple entre dans le workflow, l'exécution doit revenir sur macOS. D'où le Mac par défaut dans les guides 2026 : frontière ABI, pas nostalgie.

5. Stack minimal (MVP) : une tâche nocturne de bout en bout

Pas besoin de Kubernetes + base vectorielle le jour un. Combinaison la plus rapide pour « issue → PR → CI vert » :

• Nœud : Mac mini M4 16 Go ou Cloud Mac équivalent ; avec OpenHands + Runner, 24 Go conseillés.
• Agent : OpenHands (autonome) ou Claude Code + wrapper shell simple (semi-auto).
• Modèle : API Claude / GPT ; Ollama local optionnel, pas requis 24h/24.
• Entrée : label agent sur l'issue → webhook GitHub.
• Validation : Runner self-hosted sur la même machine, runs-on: [self-hosted, macOS].
• Contexte : GitHub MCP lecture seule + AGENTS.md avec lignes rouges.

6. Checklist de déploiement en 7 étapes

Suivez cet ordre — chaque étape est validable seule. Cœur opérationnel du guide, pour éviter « tout installé, Runner jamais enregistré ».

Étape 1 — Nœud L0. SSH, synchro horaire, disque ≥ 256 Go (Xcode + plusieurs workspaces consomment beaucoup). Utilisateurs Cloud Mac : initialisation instance et IP statique d'abord.

Étape 2 — Identité git restreinte. GitHub App ou deploy key dédié à l'agent : écriture sur branches feature uniquement, pas de write sur main. Secrets prod et token npm hors variables d'environnement agent.

Étape 3 — Installer l'agent de codage. Exemple OpenHands (Docker ou natif selon doc) :

# Sur le nœud L0, cloner OpenHands et configurer la clé API LLM
git clone https://github.com/OpenHands/OpenHands.git
cd OpenHands
# .env : MODEL, GITHUB_TOKEN (issues lecture seule), WORKSPACE_BASE
make run

Étape 4 — Brancher MCP (optionnel, recommandé). Gros dépôt : CodeGraph MCP pour que l'agent « voie » les dépendances avant d'éditer.

Étape 5 — Enregistrer GitHub Runner. Même machine que l'agent, label ex. macos-agent. Extrait workflow :

# .github/workflows/agent-verify.yml
name: Agent PR Verify
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  verify:
    runs-on: [self-hosted, macOS, agent]
    steps:
      - uses: actions/checkout@v4
      - run: swift test   # ou npm test / go test

Étape 6 — Entrées de tâches. Webhook GitHub vers service HTTP léger sur le serveur, ou intégration OpenHands ; filtre label agent-ready pour ne pas déclencher chaque commentaire.

Étape 7 — Monitoring et circuit breaker. Logger tokens, durée et fichiers modifiés par tâche ; timeout (ex. 90 min) → kill ; concurrence à 1 jusqu'à stabilité, puis 2.

7. Durcissement prod : éviter que l'agent casse main la nuit

Le plus gros risque n'est pas un « modèle bête », mais trop de droits sans revue humaine. Avant mise en prod, au minimum :

8. Coûts et dimensionnement

La facture d'un AI Coding Agent 24h/24 se découpe en trois postes :

• Nœud de calcul : Mac mini achat unique + électricité ; Cloud Mac abonnement jour/semaine (location vs achat).
• API modèle : agent autonome en boucles multiples — souvent 5–20× les tokens du pair coding ; plafond budgétaire par tâche.
• Exploitation humaine : au début quelques heures par semaine logs, prompts, tâches bloquées — pas « installer et oublier ».

Règle empirique : OpenHands seul + dépôt moyen — 16 Go possible mais risque de swap ; Agent + Runner + Ollama optionnel sur une machine — 24 Go plus serein (16 Go vs 24 Go).

9. Erreurs fréquentes

• Outil de pair pris pour agent autonome — Claude Code s'arrête en fin de session sans couche de planification.
• Pas de couche Fact — l'agent dit que les tests passent, le Runner n'a jamais tourné (pourquoi un Runner self-hosted vaut le coup).
• Trop de concurrence — deux tâches autonomes sur 16 Go → swap.
• Contexte à nu — monorepo million de lignes sans CodeGraph = refactoring à l'aveugle.
• Fuseaux et alertes ignorés — PR à moitié finies découvertes le matin sans alarme nocturne.

10. Questions fréquentes

Q : Cursor Background Agent compte-t-il comme AI Coding Agent 24h/24 ?
A : Cursor héberge la surface d'exécution — pas besoin de garder votre machine allumée 24h/24. Mais droits dépôt, validation CI et conformité restent à votre charge. L'auto-hébergement, c'est données et exécution sur un nœud que vous contrôlez.

Q : GitHub Copilot Workspace / OpenAI Codex ?
A : Oui en couche L3/L5 modèle et interface ; le déploiement reste exécution + planification + validation. Après fusion Codex-ChatGPT, plutôt orienté pair — l'unsupervised exige un wrapper workflow (fusion Codex expliquée).

Q : OpenHands Docker sur Linux suffit-il ?
A : Pour web/backend pur, oui ; toute étape toolchain Apple exige un nœud macOS. Architecture mixte courante : Linux planifie, Cloud Mac macOS build et agent.

Q : Seul à maintenir — besoin du 24h/24 ?
A : Pair coding le jour uniquement ? Non. Le 24h/24 convient aux backlogs d'issues, équipes multi-fuseaux, ou dette technique la nuit sur la machine.

Q : Comparaison avec Devin / Factory ?
A : Les produits commerciaux vendent agent + exécution + UI packagés. L'auto-hébergement vise audit, droits personnalisés, alignement Runner/MCP. Beaucoup d'équipes explorent en commercial et produisent en self-hosted.