Une feature lancée sans plan finit souvent en refonte. On voit la méthode en 2
documents que j'utilise, puis le plan mode natif, opusplan et /goal pour
aller au bout du plan.
Pourquoi planifier avant
La plus grosse erreur des débutants : demander directement "construis-moi cette feature". Sans plan, Claude fait des choix techniques sans te consulter, que tu découvres trop tard, parfois après qu'il a cassé une fonctionnalité existante sans s'en rendre compte. Ou il comprend ta demande de travers, et il faut tout refaire.
Le ratio : 10 minutes de planification = 2 heures de retravail évitées. Je l'ai vérifié sur des dizaines de features construites.
La méthode en 2 documents
On part d'un exemple concret : un système de streak de publication pour freelances. On le tire du brainstorm initial jusqu'au plan exécutable.
Document 1, le Design Doc (le quoi)
La vision produit. Il répond à : qu'est-ce qu'on construit, pour qui, et pourquoi ?
Tu démarres par un brainstorm :
"Brainstorme un système de streak de publication. Contexte : les freelances publient 1-2 fois puis abandonnent. Je veux un système gamifié qui les pousse à publier régulièrement."
Claude propose 3-4 approches avec les avantages et inconvénients de chacune :
Streak quotidien (style Duolingo)
Simple à comprendre mais punitif, un jour raté = tout perdu. Inadapté aux freelances qui ne peuvent pas publier tous les jours.
Streak hebdomadaire (recommandé par Claude)
Plus flexible, adapté au rythme freelance (1-2 posts/semaine). Peu importe le jour, il suffit de publier chaque semaine.
Système de points + niveaux
Gamification riche avec progression visible, mais plus complexe à implémenter et potentiellement distrayant par rapport au cœur de l'app.
Le choix te revient : c'est toi qui sais ce qui motivera tes utilisateurs. Claude rédige ensuite le design doc final avec l'option retenue.
Ce que contient le design doc
Exemple concret pour le streak hebdomadaire :
- Problème : 80% des freelances qui s'inscrivent arrêtent de publier après 2 semaines. On veut installer une habitude.
- Solution choisie : streak hebdomadaire, se valide avec 1 publication par semaine du lundi au dimanche.
- User stories : "Quand je publie un contenu, mon compteur passe à +1. Quand j'atteins 4 semaines consécutives, je reçois un badge. Quand je rate une semaine, le compteur repart à 0 mais je vois mon best streak."
- Règles métier : une semaine = lundi 00h à dimanche 23h59 (fuseau user). Le streak se casse si aucune publication valide sur une semaine complète.
- Hors périmètre : pas de classement entre users, pas de notification push, pas de rewards monétaires. Reporté en v2.
Document 2, le Plan d'implémentation (le comment)
La feuille de route technique. Il répond à : quelles tâches, dans quel ordre, avec quelles vérifications ?
Tu demandes :
"Écris le plan d'implémentation détaillé pour le streak hebdomadaire décrit dans docs/plans/2026-03-01-streak-design.md. Liste chaque tâche avec les fichiers à créer ou modifier, les commandes de vérification, et l'ordre d'exécution."
Claude produit un plan numéroté :
Tâche 1 : Migration SQL, créer la table streaks avec colonnes user_id, current_streak, best_streak, last_publication_date
Fichier : supabase/migrations/20260301_streaks.sql
Vérification : npx supabase migration up --local
Tâche 2 : Régénérer les types TypeScript
Commande : npx supabase gen types typescript --local > src/lib/types/database.types.ts
Vérification : npm run typecheck
Tâche 3 : Server Action, calculer et mettre à jour le streak courant
Fichier : src/lib/actions/streak.ts
Vérification : npm run typecheck && npm run lint
Tâche 4 : Composant UI, flamme animée + compteur
Fichier : src/components/dashboard/publishing-streak.tsx
Vérification : npm run typecheck + vérification visuelle
Tâche 5 : Intégration dans le dashboard
Fichier : src/app/app/page.tsx
Vérification : tester visuellement sur localhost:3000
Tâche 6 : Tests unitaires
Fichier : tests/unit/actions/streak.test.ts
Vérification : npm run test
Ce qui fait un bon plan
- Chaque tâche a un seul objectif clair
- L'ordre respecte les dépendances (la base de données avant la logique, la logique avant l'UI)
- Chaque tâche a une commande de vérification spécifique
- Les tâches indépendantes sont identifiées (peuvent tourner en parallèle)
Où sauvegarder les plans ?
Crée un dossier docs/plans/ dans ton projet. Nomme chaque fichier avec la date et le nom de la feature :
docs/plans/
2026-03-01-streak-design.md ← le design doc
2026-03-01-streak-plan.md ← le plan d'implémentation
2026-02-28-notifications-design.md
2026-02-28-notifications-plan.md
Ces fichiers restent dans le repo et documentent le projet au fil de l'eau. Quand tu te demandes "pourquoi on a fait ce choix ?", la réponse est dans le design doc.
Alternative rapide : le plan mode natif
Pour les features de taille moyenne, Claude Code a un plan mode qui évite de créer des fichiers séparés.
Un mode de permission où Claude lit ton code, explore, pose ses questions et rédige un plan, sans modifier un seul fichier. Il ne passe à l'action qu'une fois le plan approuvé par toi. Pratique quand tu veux valider l'approche avant qu'il touche au code.
- Appuie sur Shift+Tab jusqu'à voir
plan mode ondans la barre d'état, ou tape/plansuivi de ta description. - Décris la feature comme d'habitude.
- Claude te présente son plan et attend ton feu vert.
Ctrl+Gouvre le plan dans ton éditeur si tu veux le retoucher à la main. - Tu choisis : "Yes, and use auto mode" (il exécute en auto mode), "Yes, manually approve edits" (tu valides chaque modification), ou "No, keep planning" pour lui dire quoi changer.
Plus rapide que la méthode design doc + plan pour les features qui n'ont pas besoin de documentation durable. Et entrer ou sortir du plan mode ne casse pas le cache : ses consignes s'ajoutent à la fin de la conversation et le modèle ne change pas.
Quand utiliser quoi ? Feature complexe ou structurante → design doc + plan
dans docs/plans/. Feature moyenne ou correction → plan mode natif
(Shift+Tab).
opusplan : Opus réfléchit, Sonnet exécute
L'alias de modèle opusplan fait tourner Opus 5.5 pendant le plan mode et bascule sur Sonnet 5.5 pour l'exécution. L'idée : payer le modèle le plus cher seulement pour la réflexion, et laisser le moins cher taper le code.
/model opusplan
Attention au cache. Avec opusplan, chaque entrée et chaque sortie du
plan mode change de modèle, et ce qu'Opus a mis en cache ne sert pas à Sonnet.
Le message suivant relit donc toute la conversation sans cache. Sur une
session courte avec un seul plan, ça vaut le coup. Sur une longue session où
tu fais dix allers-retours entre plan et exécution, reste sur un seul modèle.
Le calcul est au chapitre 19.
Exécuter le plan
Une fois le plan validé (fichier ou chat), une seule phrase suffit :
"Exécute le plan dans docs/plans/2026-03-01-streak-plan.md"
Claude lit le plan, exécute chaque tâche séquentiellement, vérifie entre chaque étape, et te demande validation aux moments clés (typiquement : choix de design UI, logique métier ambiguë).
Ton rôle pendant ce temps : relire ce qu'il fait et répondre à ses questions.
Aller jusqu'au bout avec /goal
Sur un plan long, Claude s'arrête parfois à mi-chemin pour te faire un point. Si tu veux qu'il enchaîne jusqu'à la fin, donne-lui une condition d'arrêt avec /goal :
/goal toutes les tâches de docs/plans/2026-03-01-streak-plan.md sont faites, npm run typecheck et npm run test passent
Après chaque tour, un modèle évaluateur vérifie la condition et décide si Claude continue :
L'évaluateur est un petit modèle rapide, son coût en tokens est en général négligeable. Il ne lance aucune commande et ne lit aucun fichier : il juge d'après ce que Claude a montré dans la conversation. Écris donc une condition que la sortie de Claude peut prouver ("npm run test passe" plutôt que "le code est propre"). Pour borner la boucle, ajoute une clause du type "ou arrête-toi après 20 tours".
/goal ne change pas les permissions : en mode manuel, Claude te demandera quand même avant les commandes. Pour le laisser travailler seul, combine-le avec l'auto mode. Et pense au /goal clear : le 3 octobre 2026, un goal que j'avais laissé tomber a relancé Claude 20 fois. Le reste de l'autonomie (/loop, routines, workflows) est au chapitre 18.
Gérer les imprévus pendant l'exécution
Un plan bouge toujours un peu en route. Les cas courants :
| Situation | Réaction |
|---|---|
| Une vérification échoue | Claude corrige automatiquement et recommence. Si ça échoue 2 fois, il te demande de l'aide. |
| Tu changes d'avis sur un choix de design | Dis-le immédiatement. Claude s'adapte et ajuste le reste du plan en conséquence. |
| Une tâche est plus complexe que prévu | Claude la découpe en sous-tâches et continue. |
| Tu découvres un besoin non prévu | Ajoute-le au plan : "Ajoute une tâche 7 : envoyer un email de félicitations quand le streak atteint 4 semaines." |
Question
Tu as mis /model opusplan. Dans une longue session, tu fais dix allers-retours entre plan mode et exécution. Que se passe-t-il côté cache ?
Choisis une réponse pour voir l'explication.
À retenir
Brainstorm, design doc, plan, exécution : c'est la séquence qui m'évite le plus de retravail. Pour une feature moyenne, le plan mode (Shift+Tab) suffit et garde le cache.
opusplanéconomise sur l'exécution, mais chaque bascule de modèle relit toute la conversation sans cache./goalfait enchaîner Claude jusqu'à une condition vérifiable. Pense au/goal clear.