Comment utiliser Claude Code : séparer la planification de l’exécution

(boristane.com)

86 points par GN⁺ 2026-02-23 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Cette approche reconfigure en profondeur la manière d’utiliser les outils de codage IA, en proposant un workflow qui impose une étape explicite de revue du plan avant toute écriture de code
Le principe central est : « ne pas laisser Claude écrire du code tant que le plan n’a pas été approuvé », ce qui permet d’obtenir à la fois un contrôle structurel et une utilisation plus efficace des tokens
L’ensemble du processus suit une boucle Research → Plan → Annotation → Todo List → Implementation → Feedback
À chaque étape, la collaboration s’organise autour de documents markdown (research.md, plan.md), enrichis par des annotations et des révisions successives pour améliorer le résultat
Cette méthode met l’accent sur la séparation puis la combinaison de la capacité d’exécution de l’IA et du jugement humain, afin d’obtenir des résultats stables et cohérents, même sur des systèmes complexes

Vue d’ensemble du workflow

Après environ 9 mois d’utilisation de Claude Code comme principal outil de développement, l’auteur a mis en place une procédure structurée séparant planification et exécution, au lieu du schéma classique « saisie d’un prompt → génération de code → itérations de correction »
Avant que Claude n’écrive du code, l’exécution doit toujours se faire uniquement à partir d’un document de plan (plan.md) relu et approuvé par l’auteur
Cette approche permet de réduire les essais-erreurs inutiles, de conserver la maîtrise des décisions d’architecture, et de maximiser la qualité par rapport au volume de tokens consommés

Tout travail commence par une analyse approfondie de la codebase
- Claude reçoit pour consigne de lire en profondeur un dossier ou une fonctionnalité donnée (detailed, intricacies)
- Le résultat doit impérativement être consigné dans un fichier research.md
Ce document sert de surface de revue pour vérifier le niveau de compréhension de Claude, et corriger les malentendus à ce stade
Comme une mauvaise recherche mène à un mauvais plan puis à une mauvaise implémentation, cette étape bloque à l’avance la cause d’échec la plus coûteuse
Cela permet par exemple d’éviter des problèmes comme l’ignorance d’une couche de cache, le non-respect de règles ORM ou la création de logique dupliquée

Une fois la recherche relue, Claude est chargé de rédiger un plan d’implémentation détaillé (plan.md)
- Il inclut de vrais snippets de code, les chemins de fichiers à modifier et les trade-offs
- Au lieu d’utiliser le mode plan intégré, l’auteur préfère un fichier markdown qu’il peut gérer directement
Fournir en plus une reference implementation open source améliore fortement la qualité du plan produit par Claude
Plus important encore que le document de plan lui-même : le cycle d’annotation qui suit

L’auteur ouvre plan.md et y ajoute directement des commentaires inline
- Correction d’hypothèses erronées, rejet d’une approche, ajout de connaissances métier, etc.
- Exemples : « ça doit être un PATCH », « pas besoin de cache », « le champ visibility doit passer au niveau de la liste »
Claude reçoit ensuite l’instruction de mettre à jour le document en tenant compte des annotations, sans encore implémenter quoi que ce soit
Ce cycle annotation → mise à jour est répété de 1 à 6 fois, avec la consigne don’t implement yet pour éviter toute exécution prématurée
Le document markdown fonctionne comme un état partagé plus clair et plus structuré qu’une suite d’instructions conversationnelles
Grâce à ces itérations, un plan générique évolue vers une spécification parfaitement adaptée au système réel

Avant l’implémentation, Claude ajoute une liste détaillée de tâches (todo list)
- Elle contient les sous-tâches de chaque étape afin de suivre l’avancement
- Claude peut marquer les éléments terminés, ce qui facilite le suivi même lors de longues sessions

Une fois toutes les décisions arrêtées, l’exécution est lancée à l’aide d’un prompt standardisé
- Par exemple : « ne t’arrête pas avant d’avoir terminé toutes les tâches », « pas de commentaires inutiles », « types any/unknown interdits », « typecheck en continu », etc.
Cette commande transforme l’implémentation en phase mécanique d’exécution du plan, la part de jugement créatif ayant déjà été traitée en amont
Implémenter directement sans plan revient à construire du code sur de mauvaises hypothèses ; la règle don’t implement yet est donc le garde-fou essentiel

Pendant l’exécution, l’auteur passe à un rôle de superviseur
- Les retours sont courts et explicites : « cette fonction manque », « déplacer vers l’app admin », etc.
- Pour les changements frontend, il utilise aussi des consignes brèves comme « wider », « 2px gap », ou des captures d’écran
L’auteur s’appuie souvent sur le code existant pour préserver une UI/UX cohérente
Si le travail part dans la mauvaise direction, il est plus efficace de faire un git revert puis de réessayer avec un périmètre réduit que de corriger progressivement

Claude ne reçoit jamais une autonomie totale ; la décision finale revient toujours à l’humain
L’auteur peut ne retenir qu’une partie des propositions de Claude, les modifier, les supprimer ou redéfinir les choix techniques
- Exemples : « pour le premier, utiliser Promise.all », « ignorer les quatrième et cinquième », « supprimer la fonctionnalité de téléchargement », « ne pas changer la signature de la fonction », « utiliser la méthode de cette bibliothèque »
Claude se charge de l’exécution mécanique, tandis que l’humain garde le jugement et la priorisation

De la recherche à l’implémentation, tout se déroule dans une seule longue session
- Au fil de la session, Claude accumule continuellement du contexte, avec suffisamment de mémoire grâce à l’auto-compaction
- plan.md reste conservé dans sa forme complète pendant toute la session et peut être consulté à tout moment

« Lire en profondeur, écrire le plan, l’affiner par annotations, puis exécuter d’un seul coup. »
Même sans prompts complexes ni consignes système élaborées, ce pipeline discipliné, qui sépare la réflexion (Thinking) de la frappe (Typing), permet d’obtenir une qualité élevée
La phase Research empêche les modifications faites dans l’ignorance, la phase Plan empêche les mauvaises modifications, et l’Annotation injecte le jugement humain
L’exécution finale n’est automatisée qu’une fois toutes les décisions arrêtées, ce qui aboutit à une structure de collaboration efficace