Ce chapitre t'apprend la routine de développement en 6 étapes que j'utilise à chaque session. Une fois intégrée, elle devient un réflexe et ta vitesse de création est multipliée par 10. Temps de lecture : 8 minutes.
La boucle en 6 étapes
Chaque session de développement suit le même cycle, toujours dans le même ordre. C'est cette discipline qui garantit la qualité et la vitesse.
Étape 1, brainstormer (5 min)
Objectif : explorer les options avant de s'engager.
"Brainstorme un système de [ta feature] pour [ton projet]. Contexte : [pourquoi tu la veux, quel problème elle résout]."
Claude explore 3-4 approches et compare les avantages et inconvénients de chacune. Toi, tu choisis. C'est là que ta connaissance métier fait la différence, tu sais ce qui est mieux pour tes utilisateurs.
Astuce : même pour les features qui te semblent simples, brainstorme d'abord. Claude voit souvent des cas limites ou des opportunités que tu n'aurais pas envisagés.
Étape 2, planifier (10 min)
Objectif : transformer le choix en plan d'action.
"Écris le plan d'implémentation pour l'approche qu'on a choisie."
Claude produit un plan tâche par tâche avec les fichiers concernés et les commandes de vérification. Tu relis et tu valides. C'est ton dernier point de contrôle avant l'exécution.
Quoi vérifier dans le plan :
- Est-ce que l'ordre des tâches est logique ?
- Est-ce qu'il manque quelque chose d'évident ?
- Est-ce que le scope est raisonnable (pas trop ambitieux pour une session) ?
Étape 3, exécuter (20-40 min)
Objectif : Claude code, tu supervises.
"Exécute le plan."
Claude travaille tâche par tâche, en autonomie. Entre chaque étape, il lance automatiquement les vérifications (typecheck, lint) pour s'assurer que le code est valide. Si une vérification échoue, il corrige avant de continuer.
Pendant ce temps, toi :
- Tu observes la progression dans le chat
- Tu interviens si Claude te pose une question
- Tu ne touches à rien dans les fichiers, laisse-le finir
Piège : ne pas interrompre Claude en plein milieu d'une tâche. Si tu as une correction, attends qu'il ait fini l'étape en cours. Les interruptions peuvent créer des incohérences.
Étape 4, vérifier visuellement (5-10 min)
Objectif : tester dans le navigateur.
Ouvre localhost:3000 et teste toi-même. Claude ne voit pas ton écran. C'est toi le testeur final.
Voici ce que tu vérifies :
- La feature fonctionne comme prévu (cas nominal)
- Les cas d'erreur sont gérés (mauvaise saisie, données manquantes)
- Le design est cohérent avec le reste de l'app
- Le responsive fonctionne (réduis la fenêtre pour simuler mobile)
- Les textes sont en français avec les bons accents
Si quelque chose ne va pas, dis-le précisément :
"Le bouton est trop petit sur mobile, le texte déborde de la card à droite, et la couleur du badge 'Brouillon' devrait être grise au lieu de bleue."
Étape 5, review et commit (5 min)
Objectif : valider la qualité et sauvegarder.
/review→ Claude relit tout le code modifié et signale :
- Les bugs potentiels
- Les failles de sécurité (ex: données exposées côté client)
- Les incohérences avec le reste du code
- Le code mort ou inutile
/commit→ Claude analyse les changements et crée un commit Git propre avec un message descriptif. Tu n'as plus à écrire de messages de commit.
Pourquoi la review est importante : même si Claude a écrit le code, il
peut contenir des erreurs subtiles. La commande /review utilise un "regard
neuf" sur le code, comme demander à un collègue de relire ton travail. Sur
Panettone, j'ai un commit entier de corrections trouvées par /review.
Étape 6, sauvegarder le contexte (2 min)
Objectif : préparer la prochaine session.
"Mets à jour la mémoire projet avec les décisions de cette session."
Claude sauvegarde :
- Les décisions architecturales prises et leur justification
- Les patterns confirmés comme fonctionnels
- Les erreurs rencontrées et leurs solutions
- L'état d'avancement du projet
La prochaine session démarrera avec tout ce contexte.
Le timing typique d'une session
| Étape | Durée | Qui fait quoi |
|---|---|---|
| Brainstorm | 5 min | Claude propose, tu choisis |
| Planification | 10 min | Claude rédige, tu valides |
| Exécution | 20-40 min | Claude code, tu supervises |
| Vérification visuelle | 5-10 min | Tu testes dans le navigateur |
| Review + commit | 5 min | Claude relit et sauvegarde |
| Mémoire | 2 min | Claude met à jour le contexte |
| Total | 45-70 min | 1 feature complète livrée |
La boucle complète : Brainstormer → Planifier → Exécuter → Vérifier → Review/Commit → Sauvegarder le contexte. Répéter pour chaque feature. En une journée de 8h, tu peux livrer 6 à 10 features complètes.
Quand sauter des étapes ?
Le cycle complet est idéal pour les features moyennes à grosses. Pour les petits ajustements, adapte :
| Type de tâche | Étapes à suivre | Exemple |
|---|---|---|
| Bug fix simple | Exécuter → Vérifier → Commit | "Le bouton 'Sauvegarder' ne fonctionne pas" |
| Ajustement UI | Exécuter → Vérifier → Commit | "Augmente l'espacement entre les cards" |
| Feature moyenne | Planifier → Exécuter → Vérifier → Review → Commit | "Ajoute un filtre par statut sur la liste" |
| Feature majeure | Brainstorm → Planifier → Exécuter → Vérifier → Review → Commit → Mémoire | "Système de paiement Stripe complet" |
À retenir : la discipline du cycle en 6 étapes est ce qui fait passer de "je bricole avec l'IA" à "je livre des features professionnelles à un rythme que personne ne peut égaler". Intègre-le et il devient automatique en 2-3 sessions.
Les 3 réflexes de survie
Ces réflexes viennent des best practices partagées par Boris Cherny (créateur de Claude Code) et la communauté. Ils font une différence massive sur la qualité des sessions longues.
/compact, gérer son contexte
Claude Code a une fenêtre de contexte limitée. Plus la conversation est longue, plus Claude "oublie" les instructions du début. C'est le phénomène "Lost in the Middle".
Le réflexe : surveille le pourcentage de contexte (visible dans la status line ou via /context). Quand tu dépasses 60%, lance /compact. Claude résume la conversation et libère de l'espace.
La zone de danger : au-delà de 80% de contexte, Claude devient notablement moins bon. Il oublie des règles, fait des choix incohérents, et la qualité chute. C'est ce que la communauté appelle la "dumb zone". Ne laisse JAMAIS le contexte dépasser 80% sans compacter.
Après un /compact : relis les fichiers clés de ta tâche en cours. Le résumé est bon mais pas parfait, relire les fichiers restaure le contexte précis.
/rewind, revenir en arrière
Parfois Claude part dans une mauvaise direction : mauvaise approche technique, code qui casse tout, ou bug en cascade. Ne corrige pas dans le même contexte, le contexte est déjà pollué par la mauvaise approche.
Le réflexe : tape Esc Esc (double Escape) ou /rewind. Claude annule les modifications de code ET revient en arrière dans la conversation. C'est comme un Ctrl+Z géant.
Pourquoi /rewind > corriger manuellement : quand Claude corrige un bug qu'il vient de créer, il a les mauvaises instructions en mémoire. Avec /rewind, il repart du bon contexte et prend un chemin différent. C'est 3x plus rapide que debugger.
Commiter souvent
Le créateur de Claude Code recommande de commiter au moins une fois par heure, dès qu'une tâche est terminée. Pourquoi ?
- Chaque commit est un point de sauvegarde vers lequel tu peux revenir
/rewindramène au dernier commit, plus tu commites, plus le filet de sécurité est fin- C'est aussi un signal mental : "cette tâche est finie, je passe à la suivante"
Après chaque feature ou correction :
/reviewpuis/commit. Pas besoin d'attendre d'avoir fini 3 features.