Claude Code en pilote automatique : 30 jours de scheduler

Le 12 mars à 2h47 du matin, mon téléphone a vibré. Un commit automatique de Claude Code venait d'être poussé sur main. Le message : « refactor: simplify queue dispatch logic ». Je me suis rendormi. Le lendemain matin, je découvre que l'agent avait enchaîné 14 commits pendant la nuit, fermé 3 issues, et mis à jour 47 fichiers. Aucun n'était cassé. Un seul avait introduit une régression mineure que les tests ont rattrapée à 4h12. 30 jours plus tard, le bilan est beaucoup plus nuancé que la promesse marketing du « Claude Code Scheduler ». Voici ce que j'ai vraiment vu — logs, coûts, et les 4 règles que je n'enfreins plus.

Pourquoi j'ai voulu tester un agent qui bosse sans moi

Je code avec Claude Code depuis 14 mois. Mon workflow classique : une boucle Ralph Loop manuelle où je lis un plan, lance l'agent, revois le diff, commit, recommence. Efficace, mais ça impose ma présence. Sur un projet perso de 8 000 lignes de TypeScript, j'avais une backlog de 23 tickets « bien cadrés mais pas urgents » qui ne trouvaient jamais leur créneau.

L'annonce de Claude Code Scheduler en janvier changeait la promesse : au lieu de « je lance l'agent quand je suis là », on passe à « l'agent vérifie le backlog tous les jours à 3h du matin et bosse ». Le commit sur main n'est plus un événement ponctuel, c'est un flux. L'idée me séduisait. L'idée me faisait aussi un peu peur — laisser une IA pousser du code sur main sans supervision, ça n'est pas rien.

Le setup en 8 lignes de config

Pas de surprise, la config est triviale :

# .claude/scheduler.yml
schedule: "0 3 * * *"
mode: "autonomous"
max_iterations_per_run: 10
cost_budget_per_run_usd: 5
backlog_source: "tickets/*.md"
require_green_ci: true
commit_prefix: "[auto] "
escalate_to_human_after_fail_count: 2

Trois paramètres méritent qu'on s'y attarde : cost_budget_per_run_usd (le stop-gap financier — si une session dépasse 5 $, elle s'arrête), require_green_ci (si le build est cassé quand l'agent démarre, il ne fait rien — évite d'empiler des commits sur un tronc instable) et escalate_to_human_after_fail_count (après 2 échecs consécutifs sur le même ticket, le scheduler m'envoie un mail au lieu de retenter).

Ce dernier est la vraie assurance-vie. Sans lui, j'ai testé pendant 48h : l'agent peut boucler sur un ticket mal formulé jusqu'à consommer tout le budget.

Les 30 jours en chiffres

Voici ce que mon scheduler a produit entre le 1er et le 30 mars :

3,16 $ par nuit, c'est moins cher qu'un café. Ce que le tableau ne dit pas : les 41 tickets clos sont presque tous de la catégorie « tâche ingrate bien cadrée » — renommer des variables, ajouter des types TypeScript, migrer des appels d'API dépréciés, écrire des tests de non-régression. Des trucs que j'aurais fait en 3 mois à raison d'un créneau le dimanche. Là c'est plié en 30 jours sans que j'y pense.

La seule régression en prod : une route qui retournait null au lieu de []. Le test unitaire passait parce qu'il testait la présence de la clé, pas le type. Leçon apprise, test corrigé, refactor ajouté au backlog. L'agent lui-même a proposé le fix le lendemain matin.

Les 4 règles que j'ai apprises à la dure

Règle 1 : tickets atomiques ou rien

Les 6 escalades humaines ? Toutes sur des tickets vagues. « Améliorer les perfs de la page de recherche » n'est pas un ticket, c'est un projet. L'agent essaie, échoue, retente, consomme du budget. Maintenant, j'écris mes tickets comme si je briefais un junior : contexte en 3 lignes, critère de succès mesurable, fichiers concernés.

Exemple de ticket qui marche :

# Ajouter un index sur users.email
- Fichier : drizzle/schema.ts
- Succès : la requête `SELECT * FROM users WHERE email = ?` passe de 240 ms à <20 ms
- Test : le benchmark tests/perf/users.bench.ts passe

Règle 2 : le CI doit être ton garde-fou, pas une formalité

J'ai dû ajouter 3 étapes à mon CI en 30 jours : un lint strict, un type check strict, et un test de snapshot sur les APIs. Sans ces filets, l'agent aurait mergé 3 régressions de plus.

Règle 3 : jamais de tickets qui touchent à l'infra ou aux secrets

Le scheduler a accès à mon repo, mais pas à mes variables d'environnement de prod. Il ne doit jamais toucher aux fichiers *.env, aux GitHub Actions, aux migrations de schéma destructives. J'ai ajouté une allowlist de dossiers dans scheduler.yml — tout ce qui est hors de cette liste déclenche une escalade.

allowlist:
  - src/
  - tests/
  - docs/
deny:
  - .env*
  - .github/workflows/*
  - drizzle/migrations/*

Règle 4 : lire les diffs tous les matins, pas tous les lundis

Pendant la première semaine, j'ai voulu « faire confiance » et ne regarder les diffs que le lundi. Mauvaise idée : 23 commits à relire d'un coup, ça prend 45 minutes et on finit par skimmer. Maintenant, 10 minutes tous les matins avec le café. Je réverte en moyenne 1 commit par semaine — toujours pour des raisons de style ou d'ergonomie, jamais pour des bugs.

Là où ça casse vraiment

Trois incidents méritent qu'on en parle.

Incident 1 — la boucle d'import : nuit du 8 mars, l'agent a tenté un refactor qui a introduit un import circulaire. Le TypeScript compilait (import dynamique), les tests passaient (pas de cas qui trigger le chemin circulaire), mais l'app crashait au runtime sur une route rarement appelée. Détecté 14h plus tard par un utilisateur. Fix : ajout d'un lint import/no-cycle dans le CI.

Incident 2 — le coût qui explose : nuit du 17 mars, session à 7,40 $. Le budget de 5 $ est dépassé parce qu'un ticket ouvrait 12 fichiers énormes et que l'agent relisait chaque fichier à chaque itération. Fix : ajout de max_file_size_kb: 200 dans la config, plus un prompt qui force l'agent à utiliser grep plutôt que read sur les gros fichiers.

Incident 3 — le commit fantôme : nuit du 22 mars, un commit de 0 fichiers modifié (juste un merge commit vide). Cause : l'agent avait finalisé un refactor puis changé d'avis, mais sans rollback propre. Pas grave, mais moche dans l'historique. J'ai ajouté un hook pre-commit qui refuse les commits vides.

Verdict après 30 jours

Est-ce que je continue ? Oui, sans hésiter. Mais pas pour tous les projets. Voici ma grille de décision :

Le gros gain n'est pas le temps économisé — c'est le fait que le backlog ne m'angoisse plus. Les 40 tickets qui traînaient depuis novembre, ils sont fermés. Et ils sont fermés proprement, avec des tests, des commits lisibles, une couverture stable à 84%.

En revanche, ce mode ne remplace pas un vrai dev humain sur les décisions d'architecture, les bugs tordus, ou les features nouvelles. C'est un junior surmotivé qui bosse la nuit pour 3 $, pas un co-pilote.

Conclusion

30 nuits, 94,80 $, 186 commits, 1 régression. Ma règle simple désormais : toute tâche que je peux décrire en moins de 5 lignes et vérifier avec un test, elle part dans le backlog du scheduler. Tout le reste, je le fais moi-même.

Si tu veux le détail du setup Ralph Loop qui a rendu ce scheduler possible, j'ai écrit un livre entier dessus :

La Boucle Ralph

Guide Pratique du Coding Autonome par IA.

Découvrir →