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 : 10 minutes.
La boucle en 6 étapes
Chaque session de développement suit le même cycle, toujours dans le même ordre. Cette discipline 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 avantages et inconvénients. Toi, tu choisis. Ta connaissance métier fait la différence.
Astuce : même pour les features qui te semblent simples, brainstorme d'abord. Claude repère 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. Dernier point de contrôle avant l'exécution.
Quoi vérifier dans le plan :
- L'ordre des tâches est-il logique ?
- Est-ce qu'il manque quelque chose d'évident ?
- Le scope est-il raisonnable 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). 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. Toi tu es 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 apporte 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 fait passer de "je bricole avec l'IA" à "je livre des features professionnelles à un rythme que personne ne peut égaler". Intègre-la, elle devient automatique en 2-3 sessions.
Les 4 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. Depuis 2026, quatre slash commands couvrent tout le cycle de vie d'une session, apprends-les par cœur.
/context, savoir où tu en es
Avant de relancer une grosse instruction ou de décider si tu dois compacter, tape /context (ou /usage selon ta version). Claude t'affiche le pourcentage de fenêtre de contexte utilisée, la répartition entre system prompt, outils chargés, historique et fichiers lus.
Scénario concret : tu viens de terminer une feature de 40 minutes et tu hésites à attaquer la suivante, tu tapes /context pour voir s'il reste de la marge ou s'il faut compacter d'abord.
Le réflexe : lance /context toutes les 20 minutes environ, et systématiquement avant de démarrer une nouvelle phase du cycle (nouvelle feature, nouveau brainstorm).
Les 3 seuils à connaître : sous 40%, tu es à l'aise. Entre 40% et 60%, tu surveilles. Au-dessus de 60%, il faut compacter avant d'attaquer une nouvelle feature. Au-dessus de 80%, zone rouge.
/compact, gérer son contexte
Claude Code a une fenêtre de contexte limitée. Les modèles 2026 (Opus 4.7, Sonnet 4.6, Haiku 4.5) exposent jusqu'à 1M tokens en GA, mais plus la conversation est longue, plus Claude "oublie" les instructions du début. Le phénomène "Lost in the Middle".
Scénario concret : /context t'affiche 62%, tu lances /compact avant de démarrer une nouvelle feature, Claude résume l'historique et libère de l'espace.
Le réflexe : dès que /context dépasse 60%, lance /compact. Claude résume la conversation, archive les détails non essentiels, et libère de l'espace tout en gardant les décisions clés.
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, la qualité chute. 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.
Scénario concret : Claude vient de refactorer un composant et la page affiche 12 erreurs console, tu tapes Esc Esc pour rollback code + conversation d'un coup au lieu de debugger.
Le réflexe : tape Esc Esc (double Escape) ou /rewind. Claude annule les modifications de code ET remonte la conversation à un point de sauvegarde. Un Ctrl+Z géant : le code revient à son état précédent, et la mémoire de la conversation aussi.
Pourquoi /rewind bat la correction manuelle : 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. Tu gagnes
3x en vitesse par rapport au debug.
Pas à pas : une feature qui part en vrille
Imagine : tu veux ajouter un système de filtres sur une liste de tâches.
- Tu brainstormes, tu planifies, tu lances
Exécute le plan. - Claude commence bien, puis décide de refactorer tout ton composant
TaskListpour intégrer les filtres. Il casse la pagination au passage. - Tu testes
localhost:3000, la liste est vide, la console crache 12 erreurs. Debug à chaud = piège. - Tu tapes
Esc Esc. Claude rollback le code et la conversation, ton repo revient à l'état d'avant la dérive. - Tu relances
/contextpour vérifier que tu as de la marge. 45%, nickel. - Tu replanifies en étant plus précis : "Ajoute les filtres SANS toucher à la pagination existante. Crée un composant
TaskFiltersséparé qui prendtasksen props et retournefilteredTasks." - Tu relances l'exécution. Cette fois le scope est clair, Claude livre propre en 15 minutes.
Total : 5 minutes perdues sur la première tentative, zéro dette technique, zéro debug frustrant.
/resume, reprendre une session interrompue
Ton terminal a crashé ? Tu as fermé la fenêtre sans faire exprès ? Ton Mac a redémarré en pleine session ? Avant 2026, tout le contexte était perdu.
Scénario concret : tu rouvres ton laptop le matin, tu veux reprendre la feature Stripe d'hier soir, tu tapes claude /resume, tu choisis la session d'hier dans la liste, Claude recharge tout.
Le réflexe : dans un nouveau terminal, tape claude /resume. Claude liste tes sessions récentes avec un résumé de la dernière action. Tu choisis celle qui t'intéresse, il recharge la conversation, les fichiers lus, les décisions prises.
Bonus workflow : /resume est aussi parfait pour reprendre une feature
entamée hier. Tu retrouves l'état d'avancement sans avoir à tout réexpliquer.
Combine avec /context juste après pour vérifier la marge disponible.
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 revenir
/rewindramène au dernier commit, plus tu commites, plus le filet de sécurité est fin- Signal mental aussi : "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.