Claude Code + Ralph Loop : mon workflow de développeur en 2026

Patrice Huetz6 avril 202611 min

Il est 23h. Je ferme mon laptop, je lance une commande bash, et je vais dormir. Au réveil, 42 commits m'attendent. Les tests passent. Le code est propre. La feature est implémentée. Ce n'est pas de la science-fiction — c'est mon workflow quotidien depuis que j'ai adopté Claude Code et le Ralph Loop.

Je vais te montrer exactement comment c'est organisé. Pas la théorie — le workflow réel, avec les fichiers de configuration, les commandes, et les résultats concrets.

La journée type

7h-8h : Le plan dans CLAUDE.md

Ma journée commence par un fichier. Pas du code — un plan. Le fichier CLAUDE.md est le cerveau persistant de chaque projet. C'est le seul fichier que l'IA lit à chaque démarrage de session. Il contient tout ce qu'un agent doit savoir pour travailler de manière autonome.

Voici la structure que j'utilise sur chaque projet :

markdown

# CLAUDE.md

## Architecture
- Framework : Next.js 16, App Router
- Base de données : PostgreSQL via Prisma
- Déploiement : Vercel

## Conventions
- Composants : PascalCase, un par fichier
- API routes : camelCase, validation Zod
- Tests : Vitest, coverage > 80 %
- Commits : conventional commits (feat:, fix:, chore:)

## Commandes
- `npm run dev` — serveur de développement
- `npm run test` — lancer les tests
- `npm run build` — build de production
- `npx vercel --prod` — déployer

## Plan d'implémentation
- [x] Setup initial Next.js + Tailwind
- [x] Page d'accueil avec grille responsive
- [ ] API admin articles (CRUD)
- [ ] Système de tags avec filtrage
- [ ] Page article avec rendu MDX
- [ ] Intégration Patreon (niveaux d'accès)

Le plan d'implémentation est la clé. Chaque tâche est une checkbox. L'agent lit le plan, trouve la prochaine tâche non cochée, l'implémente, la coche, et passe à la suivante. Quand il n'y a plus de tâches, il s'arrête.

ℹ️

Le CLAUDE.md n'est pas de la documentation — c'est un protocole de communication entre toi et tes agents. Chaque ligne doit être exploitable. Pas de prose, pas de philosophie. Des faits, des conventions, des commandes. L'agent n'a pas besoin de comprendre pourquoi — il a besoin de savoir quoi et comment.

8h-12h : Les agents parallèles

C'est là que la magie opère. Au lieu de travailler sur une seule tâche à la fois, je lance 3-4 agents en parallèle, chacun dans un worktree Git séparé. Chaque agent travaille sur une branche isolée avec sa propre copie du code.

bash

# Terminal 1 : API articles
cd worktrees/api-articles
claude --dangerously-skip-permissions "Implémente l'API CRUD articles selon CLAUDE.md"

# Terminal 2 : Système de tags
cd worktrees/tags-system
claude --dangerously-skip-permissions "Implémente le filtrage par tags selon CLAUDE.md"

# Terminal 3 : Page article
cd worktrees/article-page
claude --dangerously-skip-permissions "Crée la page article avec rendu MDX selon CLAUDE.md"

Trois agents, trois tâches, zéro conflit. Chaque agent a son propre répertoire de travail, son propre historique Git, sa propre vision du projet. Ils ne se marchent jamais dessus parce qu'ils ne travaillent jamais sur les mêmes fichiers.

Quand un agent termine, je revois sa branche, je merge si c'est bon, et je lance un nouvel agent sur la tâche suivante. En une matinée, je traite 8-12 tâches au lieu de 2-3.

💡

Utilise `git worktree add` pour créer des copies légères de ton repo. Un worktree ne duplique pas le `.git` — il partage l'historique avec le repo principal. C'est instantané et ça ne prend presque pas de place disque. Beaucoup plus efficace que cloner le repo N fois.

12h-14h : Review et merge

L'après-midi commence par la review. Je parcours les branches créées le matin, je lis les diffs, je teste manuellement les fonctionnalités, et je merge ce qui est bon.

Mon workflow de review :

bash

# Voir ce que l'agent a fait
git log --oneline main..api-articles

# Lire les diffs
git diff main..api-articles

# Tester
git checkout api-articles
npm run test
npm run build

# Merger si OK
git checkout main
git merge api-articles

En pratique, environ 80 % des branches sont mergées telles quelles. 15 % nécessitent des ajustements mineurs (renommage, style, edge case manqué). 5 % sont jetées et relancées avec des instructions plus précises.

14h-17h : Le travail humain

L'après-midi est réservé au travail que l'IA ne peut pas faire :

•Architecture : décider comment les composants s'articulent, quelles abstractions créer
•UX : tester le flux utilisateur, ajuster les interactions, peaufiner les animations
•Debugging complexe : les bugs qui nécessitent une compréhension du contexte métier
•Écriture : articles de blog, documentation, contenus marketing

C'est la partie la plus importante de ma journée — et c'est celle que l'IA m'a libéré le temps de faire. Avant Claude Code, je passais 60 % de mon temps à écrire du boilerplate, des tests CRUD, des configurations Webpack. Maintenant, ce temps est compressé dans les 4 heures du matin.

23h : Le mode nuit — le Ralph Loop

Le soir, je prépare le plan pour la nuit. Je mets à jour CLAUDE.md avec les tâches restantes, je vérifie que les tests passent sur main, et je lance le Ralph Loop.

bash

#!/bin/bash
# loop.sh — Ralph Loop minimal
while true; do
    claude --dangerously-skip-permissions \
           --max-turns 30 \
           -p "Lis CLAUDE.md. Implémente la prochaine tâche non cochée. \
               Teste. Committe. Coche la tâche. Quitte." \
    || break

    # Pause entre les itérations
    sleep 5
done

Chaque itération du loop :

1.Démarre Claude Code avec un contexte frais (zéro historique)
2.L'agent lit CLAUDE.md et identifie la prochaine tâche
3.Il implémente la tâche, lance les tests, committe
4.Il coche la tâche dans CLAUDE.md et quitte
5.Le script relance une nouvelle itération

Le contexte est détruit à chaque itération. C'est le principe fondamental du Ralph Loop : ne jamais laisser le contexte se remplir. Après 30 minutes, les LLM commencent à oublier, à se contredire, à halluciner. En redémarrant à chaque tâche, l'agent travaille toujours avec un contexte frais et des instructions claires.

⚠️

Le Ralph Loop nécessite un filet de sécurité. Sans tests automatisés, l'agent peut casser le code existant sans s'en rendre compte. Règle absolue : pas de Ralph Loop sans une suite de tests qui couvre les cas critiques. Les tests sont ta backpressure — si un test échoue, l'agent doit corriger avant de passer à la suite.

Le fichier AGENTS.md

Pour les agents parallèles, j'utilise un fichier AGENTS.md complémentaire au CLAUDE.md. Il contient des instructions spécifiques à chaque type d'agent.

markdown

# AGENTS.md

## Agent API
Tu travailles sur les routes API dans `src/app/api/`.
- Utilise toujours Zod pour la validation des entrées
- Retourne des codes HTTP standards (200, 201, 400, 404, 500)
- Écris un test Vitest pour chaque route

## Agent Frontend
Tu travailles sur les composants React dans `src/components/`.
- Utilise Tailwind CSS, jamais de CSS inline
- Chaque composant a son fichier de test
- Accessible : aria-labels, rôles ARIA, navigation clavier

## Agent Tests
Tu écris des tests pour le code existant.
- Vitest + Testing Library
- Un describe par fichier testé
- Coverage cible : 80 % minimum

Chaque agent lit CLAUDE.md pour le contexte global et AGENTS.md pour ses instructions spécifiques. C'est un système de délégation hiérarchique : le plan global dans CLAUDE.md, les détails opérationnels dans AGENTS.md.

Les hooks : le garde-fou automatique

Claude Code supporte les hooks — des scripts qui s'exécutent automatiquement avant ou après certaines actions. J'utilise trois hooks systématiquement.

Pre-commit hook : vérifie que le code passe le linting et les tests avant de committer.

bash

#!/bin/bash
# .githooks/pre-commit
npm run lint --silent || exit 1
npm run test --silent || exit 1

Post-build hook : vérifie que le build de production fonctionne après chaque changement significatif.

bash

#!/bin/bash
# Vérification post-build
npm run build 2>&1 | tail -5
if [ $? -ne 0 ]; then
    echo "Build failed — reverting last commit"
    exit 1
fi

Les hooks sont essentiels pour le Ralph Loop nocturne. Sans eux, un agent pourrait committer du code qui compile mais qui casse le build. Le hook pre-commit empêche ça : si les tests échouent, le commit est rejeté, et l'agent doit corriger avant de continuer.

ℹ️

Les hooks ne remplacent pas la CI/CD — ils la complètent. Le hook pre-commit est un filtre rapide (10-30 secondes). La CI/CD est le filtre complet (2-5 minutes) qui tourne sur le serveur après le push. Les deux sont nécessaires.

Les résultats en chiffres

Après six mois de ce workflow, voici les métriques :

Métrique	Avant Claude Code	Avec Claude Code + Ralph Loop
Commits/jour	3-5	12-18
Tâches/jour	2-3	8-15
Temps de debugging	40 % du temps	8 % du temps
Temps sur le boilerplate	30 % du temps	2 % du temps
Temps sur l'architecture	10 % du temps	35 % du temps
Temps sur le contenu	20 % du temps	55 % du temps

Le chiffre le plus significatif : 80 % de debugging en moins. Ce n'est pas que Claude Code écrit du code sans bugs — c'est qu'il corrige ses propres bugs dans la même session. L'agent écrit le code, lance les tests, voit l'échec, corrige, relance. La boucle feedback est de 30 secondes au lieu de 30 minutes.

Le deuxième chiffre important : 55 % de mon temps sur le contenu (écriture, articles, documentation) au lieu de 20 %. C'est un changement de nature, pas juste de degré. Je suis passé de « développeur qui écrit un peu » à « créateur de contenu qui a un site qui se construit tout seul ».

Les limites du workflow

Ce workflow n'est pas parfait. Voici les problèmes que je rencontre régulièrement :

Les tâches interdépendantes. Si la tâche B dépend du résultat de la tâche A, tu ne peux pas les lancer en parallèle. Le plan dans CLAUDE.md doit refléter cet ordre. En pratique, 30-40 % des tâches ont des dépendances qui empêchent la parallélisation totale.

Les tâches ambiguës. Si ta description de tâche est floue (« améliorer les performances »), l'agent va faire quelque chose — mais pas forcément ce que tu voulais. La qualité du plan détermine la qualité de l'exécution. « Améliorer les performances » → « Ajouter le lazy loading sur les images de la page d'accueil avec Next/Image ». Plus c'est précis, mieux c'est.

Le coût API. Trois à quatre agents en parallèle pendant 4 heures + un Ralph Loop de 8 heures = beaucoup de tokens. Mon budget Claude Code est significatif. C'est un investissement rentable en termes de productivité, mais ce n'est pas gratuit.

La review reste nécessaire. Tu ne peux pas merger aveuglément. Environ 5 % des branches contiennent des choix architecturaux discutables (une abstraction inutile, une dépendance ajoutée alors qu'une solution native existait). La review humaine est le dernier filtre.

💡

Pour réduire les coûts API, utilise le Ralph Loop uniquement pour les tâches bien définies et mécaniques (CRUD, tests, configurations). Garde les agents interactifs pour les tâches créatives et architecturales où le feedback humain a de la valeur. Le ratio idéal pour moi : 60 % Ralph Loop nocturne, 40 % agents interactifs en journée.

Comment démarrer

Si tu veux adopter ce workflow, voici le plan en 5 étapes :

1.Installe Claude Code et lance-le sur un petit projet existant. Familiarise-toi avec les commandes de base.

1.Crée ton premier CLAUDE.md. Commence simple : architecture, conventions, 5 tâches. Teste avec un agent unique en mode interactif.

1.Ajoute les tests. Avant de lancer le Ralph Loop, assure-toi d'avoir une suite de tests qui couvre les cas critiques. Sans tests, pas de backpressure, pas de filet de sécurité.

1.Lance ton premier Ralph Loop. Un soir, prépare 3-4 tâches simples dans CLAUDE.md, lance le loop, et va dormir. Au réveil, vérifie les commits. C'est le moment eureka.

1.Passe aux agents parallèles. Apprends git worktree, configure AGENTS.md, et commence à lancer 2 agents en parallèle. Augmente progressivement.

Le plus dur n'est pas technique — c'est psychologique. Lâcher le contrôle. Accepter qu'un agent fasse le travail « à sa manière ». Résister à l'envie de tout réécrire. Si le code passe les tests, si le build fonctionne, si la feature est conforme au plan — c'est suffisant. Le perfectionnisme est l'ennemi de la productivité.

J'ai documenté l'architecture complète du Ralph Loop, ses variantes avancées (mode plan, mode build, mode reverse), et ses patterns d'industrialisation multi-projets dans mon guide.