Ma méthode pour développer avec Claude Code

Mon workflow de développement avec Claude Code a pas mal évolué ces derniers mois. J’ai convergé vers une méthode en trois documents markdown, posés à la racine du projet. Pas d’usine à gaz. Juste une répartition claire entre ce que je gère, ce que Claude gère, et ce qu’on construit ensemble.

Le PRD : le cahier des charges humain

Le PRD (Product Requirements Document), c’est le seul document que je rédige entièrement moi-même. Avant de lancer Claude sur quoi que ce soit.

Il contient la vision du produit, les fonctionnalités attendues, les contraintes techniques et les priorités. Un markdown structuré avec des sections claires suffit - pas besoin de 50 pages.

Rédiger ce document soi-même oblige à réfléchir au projet avant d’écrire la moindre ligne de code. Si vous n’arrivez pas à expliquer clairement ce que vous voulez construire, Claude ne le devinera pas à votre place. Le PRD sert de contrat entre vous et l’agent. Il y a accès en permanence et s’y réfère dès qu’il hésite sur une décision.

J’y mets aussi les non-objectifs : ce que le projet ne doit pas faire. Ça évite que Claude parte dans des directions non souhaitées.

Les TASKS : la feuille de route de Claude

Une fois le PRD posé, je demande à Claude de générer un fichier TASKS.md. C’est sa feuille de route.

Claude décompose le PRD en tâches concrètes. Il met à jour ce fichier au fur et à mesure.

Je n’ai pas à micro-manager. Je donne une direction, Claude découpe le travail et avance. Je consulte régulièrement TASKS.md pour suivre la progression et réorienter si besoin.

Le piège : laisser Claude avancer trop longtemps sans relecture. Les tâches peuvent dériver du PRD initial. Je fais un point après chaque bloc de 4-5 tâches terminées.

L’ARCHITECTURE : le document collaboratif

ARCHITECTURE.md, c’est la partie qu’on construit à deux. Je pose les grandes orientations techniques - stack, patterns, structure du projet - et Claude propose, challenge, affine.

Le document décrit la structure des dossiers, les choix de librairies, les conventions de nommage. Il sert de référence pour toutes les décisions d’implémentation. C’est la même logique que j’appliquais quand j’utilisais Claude pour développer mes workflows n8n : poser le cadre technique en amont pour que l’agent reste cohérent.

L’intérêt de co-construire ce document : Claude connait les contraintes de chaque approche et peut alerter sur des incompatibilités. De mon côté, je garde la main sur les choix de préférence et la cohérence avec l’écosystème existant.

Le CHANGELOG : l’historique des tâches terminées

Quand Claude termine une tâche, il la déplace de TASKS.md vers CHANGELOG.md. Le fichier de tâches ne contient donc que ce qui reste à faire. Pas de bruit, pas de tâches “completed” qui s’accumulent.

Le CHANGELOG garde la trace de tout ce qui a été fait, avec la date et un résumé des modifications. Ça permet de revenir sur un projet après quelques semaines et de comprendre ce qui s’est passé sans fouiller l’historique Git.

L’autre avantage : TASKS.md reste court. Claude charge ce fichier en contexte à chaque session. Moins il est long, moins il consomme de tokens, et plus Claude reste concentré sur le travail restant.

Si vous devez reprendre le projet de zéro, le PRD suffit comme point de départ. Le CHANGELOG sert alors de base de connaissances : les problèmes rencontrés, les contournements trouvés, les décisions abandonnées. On capitalise au lieu de refaire les mêmes erreurs.

Le PRD comme source de vérité

Le PRD a un autre rôle que je n’avais pas anticipé au départ. À tout moment, je peux demander à Claude de comparer le PRD avec le code existant pour identifier les écarts. Fonctionnalités manquantes, comportements qui ont dévié de la spec, endpoints prévus mais jamais implémentés.

C’est un audit rapide qui prend quelques secondes. Ça remplace les réunions de synchro qu’on ferait avec une équipe humaine.

Les TESTS : le chantier en cours

C’est la pièce qui manque encore à cette méthode. Je réfléchis à comment intégrer les tests dans ce workflow sans alourdir le processus.

Le workflow complet

En pratique :

1. Je rédige le PRD
2. Je demande à Claude de proposer une architecture
3. On itère ensemble sur ARCHITECTURE.md
4. Claude génère les TASKS depuis le PRD
5. Claude travaille tâche par tâche, met à jour TASKS.md
6. Je review et réoriente après chaque bloc de tâches

Sur un petit script, cette méthode est overkill. Dès qu’un projet dépasse quelques fichiers, ces trois documents changent la qualité du travail produit.

Plus le contexte est structuré en amont, moins vous corrigez en aval 🏗️