Claude en boucle : faire tourner des agents sur la durée

#Le problème : une mémoire qui repart à zéro

Claude est puissant, mais il a une contrainte fondamentale : sa fenêtre de contexte est limitée. Quand une tâche dépasse ce que Claude peut accomplir en une seule session, il faut relancer une nouvelle conversation. Et là, tout repart de zéro — Claude ne sait plus ce qu'il a fait avant.

Imagine un projet logiciel avec des développeurs qui travaillent en quarts de 8 heures, mais où chaque développeur arrive sans aucun souvenir du quart précédent. C'est exactement la situation d'un agent IA qui doit travailler sur la durée.

La question devient : comment structurer le travail pour que Claude reste productif d'une session à l'autre ?

#Le concept de harness

Un harness (littéralement "harnais") est le programme qui orchestre Claude. C'est le code qui lance l'agent, lui donne ses instructions, récupère ses résultats, et relance une nouvelle session quand c'est nécessaire.

Un harness basique ressemble à ça :

while true; do
  claude --print "Continue le travail sur le projet"
done

Mais un harness naïf ne fonctionne pas bien. Sans structure, Claude va :

Refaire des choses déjà faites
Oublier où il en était
Déclarer la tâche terminée alors qu'elle ne l'est pas
Laisser le code dans un état cassé entre deux sessions

L'article d'ingénierie d'Anthropic sur les harnesses pour agents long-running détaille une architecture qui résout ces problèmes.

#L'architecture à deux agents

La solution proposée par Anthropic repose sur deux agents spécialisés avec des rôles distincts :

Agent	Rôle	Quand il tourne
Initializer	Configure l'environnement et planifie	Première session uniquement
Coder	Implémente une feature à la fois	Toutes les sessions suivantes

#L'agent Initializer

Cet agent ne tourne qu'une seule fois, au tout début. Son travail :

Configurer l'environnement : créer un script init.sh qui lance le serveur de développement
Générer une liste de features : décomposer le projet en tâches concrètes et testables
Créer un fichier de progression (claude-progress.txt) : un journal que les futures sessions liront
Faire un commit initial : sauvegarder cet état de départ dans git

La liste de features est le cœur du système. Chaque feature est décrite dans un format structuré :

{
  "description": "Le bouton 'nouveau chat' crée une conversation",
  "steps": [
    "Cliquer sur le bouton + dans la sidebar",
    "Vérifier qu'une nouvelle conversation apparaît",
    "Vérifier que le champ de saisie est actif"
  ],
  "passes": false
}

Le champ passes est crucial : il vaut false tant que la feature n'est pas implémentée et testée. L'agent Coder ne peut le passer à true qu'après vérification.

Anthropic recommande le format JSON plutôt que Markdown pour la liste de features. Claude est moins susceptible de corrompre accidentellement un fichier JSON qu'un fichier Markdown libre.

#L'agent Coder

Cet agent tourne en boucle, session après session. À chaque lancement, il suit une routine précise :

Lire claude-progress.txt et le git log récent
Consulter la liste de features
Lancer le serveur via init.sh
Tester que les features existantes fonctionnent toujours
Choisir une seule feature à implémenter
L'implémenter et la tester
Mettre à jour le fichier de progression
Commit le tout

Le mot clé ici est une seule feature par session. C'est contre-intuitif — on pourrait vouloir que Claude en fasse le plus possible. Mais forcer le focus sur une tâche évite les erreurs en cascade et garantit un état propre entre chaque session.

#Les quatre pièges des agents long-running

L'équipe d'Anthropic a identifié quatre comportements problématiques récurrents, avec des solutions concrètes pour chacun.

#Piège 1 : tout faire d'un coup

Le problème : Claude essaie d'implémenter plusieurs features en même temps, fait des erreurs, et laisse le code dans un état incohérent.

La solution : la structure JSON avec passes: false force une approche incrémentale. Les instructions précisent que Claude ne doit modifier que le champ passes d'une feature, jamais supprimer ou réorganiser les autres.

#Piège 2 : déclarer victoire trop tôt

Le problème : Claude annonce "tout est terminé" alors que seules quelques features marchent vraiment.

La solution : au début de chaque session, Claude doit lire la liste complète des features et identifier la prochaine priorité. Pas de déclaration globale de succès — juste une feature à la fois.

#Piège 3 : laisser le code cassé

Le problème : entre deux sessions, le code est dans un état instable. La session suivante hérite d'un environnement défaillant et perd du temps à comprendre ce qui ne va pas.

La solution : chaque session commence par des tests basiques. Si quelque chose est cassé, la priorité est de le réparer avant d'avancer. Git permet de revenir à un état stable si nécessaire.

#Piège 4 : valider sans tester

Le problème : Claude marque une feature comme terminée après avoir écrit le code, sans vérifier qu'elle fonctionne réellement.

La solution : utiliser des outils d'automatisation du navigateur (comme Puppeteer via MCP) pour tester comme un vrai utilisateur. L'inspection du code seul ne suffit pas — certains bugs ne se révèlent qu'à l'exécution.

Claude ne peut pas détecter certains éléments d'interface comme les modales natives du navigateur ou les notifications système. Prévois des mécanismes de validation alternatifs pour ces cas.

#La technique Ralph Wiggum

En parallèle de l'architecture Anthropic, la communauté a développé une approche plus simple connue sous le nom de technique Ralph Wiggum (popularisée par Geoffrey Huntley et Ryan Carson).

Le principe : une boucle qui relance Claude en continu jusqu'à ce qu'il signale explicitement avoir terminé, via un mot-clé prédéfini qu'on appelle un completion promise.

COMPLETION_WORD="ULTRATHINK_COMPLETE"

while true; do
  output=$(claude --print "Continue le travail. Quand tout est fini, écris $COMPLETION_WORD")

  if echo "$output" | grep -q "$COMPLETION_WORD"; then
    echo "Tâche terminée."
    break
  fi
done

#Les quatre canaux de mémoire

Pour que la boucle Ralph fonctionne, l'agent utilise plusieurs canaux de persistance entre les sessions :

commits + diffs

Historique git

progress.txt

Fichier de progression

suite de tests

Tests automatisés

stdout capturé

Logs de session

Git : chaque itération commit ses changements. La session suivante peut faire un git diff ou lire le git log pour comprendre ce qui a changé
Fichier de progression : un journal texte que Claude met à jour à chaque session
Tests : la suite de tests sert de "mémoire fonctionnelle" — elle encode ce qui doit marcher
Logs : la sortie de chaque session est capturée pour le débogage

#La règle d'or de Boris Cherny

Boris Cherny, le créateur de Claude Code, insiste sur un principe fondamental :

Donne toujours à Claude un moyen de vérifier son propre travail.

Sans vérification, la boucle tourne indéfiniment ou s'arrête trop tôt. C'est ce qui distingue un agent autonome utile d'un agent qui brûle des tokens sans résultat.

En pratique, cela signifie :

Écrire les tests avant l'implémentation
Lancer les tests à chaque itération
Ne déclarer une tâche terminée que quand tous les tests passent

#Mettre en place une boucle dans Claude Code

Claude Code intègre nativement des mécanismes pour travailler en boucle. Voici une approche pas-à-pas pour configurer un agent qui tourne sur la durée.

#1. Préparer le fichier de progression

Crée un fichier claude-progress.txt à la racine de ton projet :

# Progression du projet

## État actuel
- Phase : initialisation
- Dernière session : (aucune)

## Features planifiées
1. [ ] Feature A - description
2. [ ] Feature B - description
3. [ ] Feature C - description

## Notes pour la prochaine session
- Commencer par la feature A
- Le serveur se lance avec `bun dev`

#2. Configurer le prompt système

Dans ton CLAUDE.md, ajoute des instructions pour la boucle :

## Routine de démarrage

À chaque nouvelle session :
1. Lis `claude-progress.txt`
2. Consulte `git log --oneline -10`
3. Lance le serveur de dev
4. Vérifie que les features existantes marchent
5. Choisis la prochaine feature à implémenter
6. Implémente-la et teste-la
7. Mets à jour `claude-progress.txt`
8. Commit tes changements

#3. Lancer la boucle

Utilise le flag --print de Claude Code pour une exécution non-interactive :

claude --print "Suis la routine de démarrage dans CLAUDE.md et implémente la prochaine feature."

Pour une boucle automatique, encapsule dans un script shell qui relance Claude tant que le fichier de progression contient des tâches non cochées.

Surveille les coûts. Un agent en boucle peut consommer beaucoup de tokens. Définis un budget maximum par session et ajoute des alertes si les dépenses dépassent un seuil.

#Bonnes pratiques

Voici les leçons tirées de l'article d'Anthropic et de l'expérience de la communauté :

Pratique	Pourquoi	Comment
Une feature par session	Évite les erreurs en cascade	Instructions explicites dans le prompt
Tests avant implémentation	L'agent peut vérifier son travail	Écrire les tests dans la feature list
Git comme filet de sécurité	Permet le rollback en cas de problème	Commit à chaque fin de session
JSON plutôt que Markdown	Moins de corruption accidentelle	Feature list en .json, pas en .md
Monitoring en temps réel	Détecter les boucles infinies	Tail sur les logs, alertes de coût

#Ce qu'il faut retenir

Les agents long-running ne sont pas magiques. Leur efficacité dépend entièrement de la qualité du harness qui les orchestre. Les principes clés :

Structurer la mémoire entre les sessions (fichiers de progression, git, tests)
Forcer le focus sur une tâche à la fois
Vérifier systématiquement le travail accompli
Maintenir un état propre du code entre chaque session

L'analogie des développeurs en quarts est parlante : une bonne équipe fonctionne grâce à de bonnes notes de passation, des tests automatisés, et des revues de code. Un bon harness applique exactement les mêmes principes à un agent IA.

Pour approfondir, consulte l'article original d'Anthropic sur les harnesses pour agents long-running et les bonnes pratiques Claude Code.