La Boucle Ralph : quand l'IA code pendant que tu dors

Vendredi soir, 23h. Je travaille avec Claude Code depuis trois heures sur une refonte d'API. Les trente premières minutes étaient magiques : l'IA comprenait mon architecture, proposait des solutions élégantes, écrivait du code testé. Mais là, à la troisième heure, elle vient de réintroduire une dépendance que j'ai explicitement retirée deux fois. Elle mélange deux approches discutées à des moments différents. Elle génère des fonctions qui appellent des types qui n'existent plus.

Je ne suis pas devenu plus bête. C'est le contexte de l'IA qui s'est dégradé — et je ne l'ai pas vu venir.

Ce soir-là, en cherchant une solution, je tombe sur un post de Geoffrey Huntley, un développeur australien. Trois lignes de bash. Une idée radicalement simple. Et une méthode qui va changer ma façon de coder.

Le problème que tout le monde ignore

Avant de parler de la solution, il faut comprendre le problème. Et il est plus grave qu'on ne le croit.

Un LLM comme Claude Opus dispose d'une fenêtre de contexte de 200 000 tokens. Ça semble vaste. Mais décomposons ce qui s'y accumule pendant une session de travail :

Plus la session dure, plus l'historique grossit, et moins il reste d'espace pour la réflexion. C'est comme essayer de résoudre un problème complexe dans une pièce qui se remplit de meubles — à un moment, il n'y a plus de place pour le tableau blanc.

La dégradation est insidieuse. Elle ne se manifeste pas par un message d'erreur. Le code continue de compiler. Mais il ne fait plus ce que tu veux. Les décisions architecturales prises en début de session sont silencieusement abandonnées. Les conventions se mélangent. Les hallucinations se multiplient.

Trois lignes de bash qui changent tout

Fin 2025, Geoffrey Huntley se bat avec un projet ambitieux : construire un langage de programmation complet à l'aide d'agents IA. Pas un prototype. Un vrai langage, avec parseur, compilateur, système de types. Chaque soir, même scénario : il lance Claude Code, travaille deux heures, regarde la qualité se dégrader, redémarre. Deux heures plus tard, même résultat.

Un soir, exaspéré, il écrit trois lignes dans un fichier loop.sh :

#!/bin/bash
while :; do
  cat PROMPT.md | claude --dangerously-skip-permissions
done

Et il va se coucher.

Le lendemain matin, il ouvre son laptop. Git log affiche 47 commits. Le compilateur a un nouveau module de typage. Les tests passent. L'IA a travaillé toute la nuit — pas dans une session continue de 8 heures, mais dans 47 sessions indépendantes de 10 minutes chacune.

Le Ralph Loop venait de naître.

Les cinq principes fondateurs

Ce qui rend le Ralph Loop puissant, ce n'est pas la boucle bash — c'est la philosophie derrière. Cinq principes que j'ai formalisés dans mon livre après des semaines de pratique.

1. Le filesystem est la mémoire

Dans une conversation classique, l'information vit dans le contexte et meurt quand la session s'arrête. Dans le Ralph Loop, toute information importante est écrite sur le disque : IMPLEMENTATION_PLAN.md pour l'état d'avancement, AGENTS.md pour les conventions, les specs dans des fichiers dédiés, et bien sûr le code lui-même. Quand une nouvelle itération démarre, elle n'a pas besoin de l'historique de la conversation. Elle lit les fichiers, comprend l'état actuel, et continue.

2. Une tâche par itération

C'est la règle la plus contre-intuitive et la plus importante. Chaque itération ne fait qu'une seule chose : implémenter un endpoint, écrire les tests d'un module, corriger un bug spécifique. Pourquoi ? Parce qu'une tâche unique tient confortablement dans la « zone de lucidité » du contexte — les premiers 30-40 % de la fenêtre. L'IA n'a jamais besoin de jongler avec plusieurs objectifs.

3. Le contexte frais est non négociable

Chaque itération doit commencer avec un contexte vierge. Pas de « continuation de session ». Pas de « résumé de la session précédente injecté dans le prompt ». L'IA lit les fichiers du projet — point. C'est radical, mais c'est ce qui élimine la dégradation.

4. Git est le journal de bord

Chaque itération se termine par un commit. Le message de commit documente ce qui a été fait. L'historique git devient le journal du projet — bien plus fiable que n'importe quel résumé de conversation :

a3f2c1d feat: add pagination to /api/users endpoint
b7e4a0f test: add integration tests for user service
c9d1f3e refactor: extract validation logic to shared utils
d2a5b8c fix: handle null email in user registration
e6c3d7a feat: implement user registration endpoint

5. Let Ralph Ralph

Faites confiance au processus. Chaque itération peut être imparfaite. Un commit peut introduire une implémentation partielle. Les tests peuvent échouer temporairement. La force du Ralph Loop n'est pas dans la perfection de chaque itération — c'est dans la consistance éventuelle obtenue par la répétition.

Le backpressure : le filet de sécurité indispensable

Le backpressure, c'est l'ensemble des vérifications automatiques qui empêchent le code invalide de passer. Trois couches sont nécessaires :

Sans la couche 1, l'IA commite du code qui ne compile pas. Sans la couche 2, elle mélange les conventions. Sans la couche 3, elle commite du code qui compile mais ne fonctionne pas. Les trois couches sont nécessaires — aucune n'est suffisante seule.

Concrètement, dans ton PROMPT_build.md, tu ajoutes une section validation obligatoire :

## Phase de validation (OBLIGATOIRE avant tout commit)
1. `npx tsc --noEmit` — vérification des types
2. `npm run lint` — vérification du style
3. `npm test` — tests unitaires et intégration

Si une validation échoue, corrige avant de commiter. Max 3 tentatives.

Si les tests ne passent pas, l'IA doit corriger avant de pouvoir commiter. C'est le « mur » qui garantit la qualité.

Mon expérience concrète : des nuits de 40+ commits propres

J'ai utilisé le Ralph Loop intensivement sur plusieurs projets. Le résultat typique d'une nuit : 40 à 60 commits propres, des tests qui passent, un code que je n'ai pas besoin de réécrire le lendemain.

Voici mon setup type :

#!/bin/bash
while true; do
  claude \
    --print \
    --model opus \
    --allowedTools "Read,Write,Edit,Bash,Glob,Grep" \
    < PROMPT_build.md
  echo "--- Itération terminée. Redémarrage... ---"
  sleep 2
done

Et le PROMPT correspondant :

Tu es un développeur autonome. À chaque itération :
1. Lis IMPLEMENTATION_PLAN.md
2. Sélectionne la tâche de plus haute priorité marquée [ ]
3. Étudie le code source pertinent
4. Implémente la tâche
5. Lance les tests : `npm test`
6. Si les tests passent : commite et mets à jour le plan
7. Si les tests échouent : corrige (max 3 tentatives)
8. Quitte proprement

Règles :
- UNE seule tâche par itération
- Ne modifie JAMAIS le PROMPT
- Commite TOUJOURS avant de quitter

C'est tout. Pas de framework. Pas de dépendance. Un script bash et un fichier markdown.

Ce que le Ralph Loop n'est pas

Avant de te lancer, clarifions quelques idées fausses :

Ce n'est pas du vibe coding. Le vibe coding (terme d'Andrej Karpathy) consiste à décrire vaguement ce qu'on veut et laisser l'IA improviser. Le Ralph Loop est l'opposé : des specs précises, un plan détaillé, des critères de validation stricts.

Ce n'est pas du fire-and-forget. Lancer la boucle et partir n'est pas recommandé sauf pour des tâches très bien spécifiées. Le Ralph Loop est autonome, pas non supervisé. Tu dois vérifier les commits, ajuster les specs si nécessaire, et intervenir quand la boucle tourne en rond.

Ce n'est pas réservé à Claude Code. Le concept est universel. Tout agent IA capable de lire des fichiers, exécuter des commandes et commiter du code peut être utilisé. Claude Code est l'outil le plus populaire, mais Goose, Aider et d'autres fonctionnent aussi.

Ce n'est pas magique. Le Ralph Loop ne transforme pas un mauvais prompt en bon code. Si tes specs sont vagues, le code le sera aussi. Si tes tests sont insuffisants, les bugs passeront. La technique amplifie la qualité de ta préparation — elle ne la remplace pas.

J'ai tellement appris en pratiquant le Ralph Loop que j'en ai fait un livre complet : 146 pages, 19 chapitres, de la théorie à l'industrialisation. Si tu veux aller plus loin — modes Plan/Build/Reverse, subagents et parallélisme, économie du coding autonome — tout y est.

La Boucle Ralph

Guide Pratique du Coding Autonome par IA.

Découvrir →

Et si tu veux comprendre le problème fondamental que résout le Ralph Loop — la dégradation du contexte des LLMs — j'ai écrit un deuxième livre entièrement dédié à la mémoire des machines.

La Mémoire des Machines

Du KV-Cache au Context Engineering.

Découvrir →