Auto-Claude 12 agents : ce que j'ai vraiment automatisé

Ouvrir Auto-Claude pour la première fois, c'est comme entrer dans une salle des machines. 12 terminaux en grille, chacun prêt à lancer un agent indépendant, un kanban qui orchestre les tickets, un rapport de coût en temps réel. La promesse est séduisante : au lieu de faire la queue devant un seul agent, tu en lances une douzaine et tu les regardes travailler. Je l'ai utilisé pendant 6 semaines sur un vrai projet avec 60 tâches à abattre. Le gain n'est pas exactement celui qu'on imagine — et le verdict change complètement selon le type de travail. Voici les chiffres bruts.

Le setup : 12 agents, 60 tickets, 6 semaines

Le projet : la réécriture d'un moteur de scraping en TypeScript, ~18 000 lignes au départ, 60 tâches de refactoring identifiées à l'avance (extraction de méthodes, ajout de types stricts, migration any → interfaces, tests unitaires manquants). Parfait candidat pour du travail parallélisable : chaque tâche touche 2-5 fichiers, aucune n'en dépend d'une autre.

Je lance Auto-Claude sur une machine avec 32 Go de RAM et 8 cores. La doc dit « 12 terminaux maximum ». Je mets 12. Budget mensuel Anthropic : 400 $ plafonné.

Ce qu'on ne te dit pas sur la parallélisation d'agents

Piège 1 : les conflits de merge

Naïvement, on pense : 12 agents sur 12 branches indépendantes, ça ne peut pas entrer en conflit. Faux. Dès que deux agents touchent au même fichier (même si c'est sur des lignes différentes), le merge au bout devient un casse-tête. Sur mes 60 tâches, 23 touchaient au même fichier src/scraper/core.ts. Résultat : une file d'attente implicite où les agents 6-12 attendaient que les 5 premiers mergent.

Fix : je distribue les tâches par « zone d'impact ». Chaque agent reçoit une liste de fichiers exclusifs qu'il est le seul à pouvoir toucher. Le kanban bloque automatiquement une tâche si un autre agent a un lock sur un de ses fichiers.

# auto-claude.yml
dispatch_strategy: "file_lock"
max_concurrent_agents: 12
lock_granularity: "file"
queue_on_conflict: true

Avec cette config, le parallélisme réel est passé de 4-5 agents actifs simultanés (sur 12 lancés) à 9-10. Un gain de 80% sur le throughput.

Piège 2 : le dispatch stupide par défaut

Par défaut, Auto-Claude pioche les tâches en FIFO. Mais toutes les tâches ne coûtent pas pareil. Une tâche « ajouter le type retourné à une fonction » prend 30 secondes. Une tâche « refactorer le module de retry » prend 12 minutes. Si tu laisses le FIFO tourner, tes 12 agents finissent par bosser tous sur des tâches longues en même temps, puis attendent.

Fix : tri des tâches par durée estimée (approximation basée sur le nombre de fichiers impactés), et dispatch « longues d'abord ». Sur mes 60 tâches, le temps total est passé de 4h18 à 2h47 — 35% de gain juste en changeant l'ordre.

tasks.sort(key=lambda t: -estimate_duration(t))

Les chiffres bruts après 6 semaines

Trois chiffres méritent un commentaire :

• •11% de taux d'échec, ça reste élevé. Un agent sur 10 abandonne ou se trompe sur une tâche donnée. En série (1 agent à la fois), j'avais mesuré 6-7% sur le même type de tâches. Le parallélisme dégrade légèrement la qualité individuelle.
• •Le coût baisse avec la meilleure stratégie (142 $ → 118 $). Pas parce que chaque agent est moins cher, mais parce que les retries diminuent.
• •59/60 tâches finies contre 56/60 en FIFO. Les 4 tâches « perdues » en FIFO étaient toutes sur le même gros fichier, bloquées dans la queue et jamais terminées avant que je coupe.

La vraie question : quand est-ce que ça vaut le coup ?

Après 6 semaines, voici ma grille de décision :

Pour un projet de refactoring, le gain est réel : ×2 à ×3 sur le wall-clock time, avec une qualité légèrement dégradée qu'on rattrape par une phase de review à la fin. Pour tout le reste, un seul agent concentré sur une tâche bat 12 agents qui tournent en parallèle.

Le coût caché : la review humaine

Ce que le tableau ne montre pas : les 2h47 de computing ont généré 59 commits qu'il a fallu que je relise. À raison de 3 minutes par commit en moyenne, c'est 2h57 de review humaine. Le wall-clock « total » n'est pas 2h47 mais 5h44 en comptant la review. Versus 4h18 + 2h pour 56 commits en mode FIFO = 6h18. Le gain réel est donc de ~10%, pas ×2.

Ma config actuelle (stable depuis 3 semaines)

# auto-claude.yml — config stable
max_concurrent_agents: 6      # pas 12, je relis mieux
dispatch_strategy: "file_lock"
sort: "longest_first"
budget_per_run_usd: 3
max_retries_per_task: 2
escalate_to_human_after_retries: true

# Limites qualité
require_green_ci: true
require_diff_under_lines: 400
auto_reject_on_conflict: true

# Reporting
report_to_slack: "#auto-claude"
daily_summary_email: "patrice@patricehuetz.fr"

Mes gains observés avec 6 agents au lieu de 12 :

• •Throughput 80% de celui à 12 agents
• •Taux d'échec 7% (proche du mode séquentiel)
• •Review humaine faisable en 1h30 au lieu de 3h
• •Coût 15% inférieur

6 agents, c'est mon sweet spot. La courbe de rendement plafonne vite.

Ce qu'il faut retenir

1. 1.12 agents Auto-Claude donnent un gain réel de ×2-3 sur le wall-clock, mais seulement sur des projets de refactoring homogène.
2. 2.Le dispatch par défaut est stupide — trie tes tâches par durée estimée, utilise des locks par fichier.
3. 3.La qualité individuelle baisse avec le parallélisme — taux d'échec qui passe de 7% à 11%.
4. 4.Le vrai goulot d'étranglement est la review humaine — si tu ne peux pas reviewer 60 commits, tu n'as pas besoin de 12 agents.
5. 5.6 agents est souvent le sweet spot — 80% du gain pour 40% de la charge de review.

Si tu veux la méthode complète pour cadrer un projet de refactoring avec des agents en Ralph Loop, j'ai écrit un livre sur ces patterns :

La Boucle Ralph

Guide Pratique du Coding Autonome par IA.

Découvrir →