Cadrer et documenter son projet

Si vous ne deviez retenir qu’un seul module de toute la formation, ce serait celui-ci. Le temps que vous investissez à cadrer votre projet vous est rendu au centuple pendant le développement. Un projet bien préparé se déroule dix fois plus vite qu’un projet lancé dans l’improvisation. Voici comment préparer le terrain, dans l’ordre.

Définir le projet avant d’ouvrir Claude

Avant d’écrire le moindre prompt, prenez trente minutes pour répondre par écrit à quelques questions simples. Ce n’est pas un cahier des charges de cinquante pages : c’est une page qui vous évitera de tourner en rond.

• Que fait ce projet, en une phrase ? Si vous ne pouvez pas le résumer, l’IA ne le pourra pas non plus.
• Qui va l’utiliser ? Un site vitrine local et un SaaS B2B n’ont ni les mêmes priorités ni la même architecture.
• Quelles sont les 3 à 5 fonctionnalités essentielles ? Distinguez le « indispensable au lancement » du « ce serait bien un jour ».
• Quelles contraintes ? Budget, délai, hébergement gratuit, besoin d’une base de données, gestion de comptes utilisateurs.

Choisir sa stack (et laisser Claude conseiller). Si vous débutez, ne choisissez pas votre stack au hasard : demandez conseil à Claude en lui donnant votre contexte. Pour un site moderne, rapide et bien référencé, une base éprouvée est Next.js (React) + TypeScript + Tailwind CSS, avec Supabase si vous avez besoin d’une base de données et de comptes, et un déploiement sur Vercel. C’est notre fil rouge. L’important : choisir une stack populaire et documentée, que l’IA maîtrise d’autant mieux qu’elle est répandue.

Le CLAUDE.md : la mémoire de votre projet

C’est le levier le plus sous-estimé du vibe coding. Le fichier `CLAUDE.md`, placé à la racine du projet, est lu automatiquement par Claude Code au démarrage. Il contient tout ce que l’IA doit savoir avant d’écrire la moindre ligne. Il transforme Claude d’un assistant amnésique en un collaborateur qui connaît votre projet — vous n’avez plus à répéter le contexte à chaque conversation.

# CLAUDE.md — Site vitrine « Mon Restaurant »

## Contexte du projet
Site vitrine pour un restaurant local. Objectif : présenter le menu,
donner les infos pratiques et permettre la réservation en ligne.
Public : clients locaux, souvent sur mobile. Rapidité et clarté priment.

## Stack technique
- Next.js 14 (App Router) + TypeScript
- Tailwind CSS pour le style
- Pas de base de données : les réservations partent par e-mail (API route).
- Déploiement sur Vercel.

## Conventions de code
- Composants React en PascalCase, un composant par fichier.
- Textes centralisés dans lib/constants.ts (jamais en dur).
- Toujours utiliser le composant Button existant, ne pas en recréer.
- Style : classes Tailwind uniquement, pas de CSS en ligne.

## Règles importantes
- Ne jamais modifier plus d'un composant à la fois sans me prévenir.
- Toujours m'expliquer en une phrase ce qui a changé et pourquoi.
- Le site doit rester accessible (contrastes, navigation clavier).
- Ne pas ajouter de dépendance sans me demander d'abord.

## À éviter
- Ne pas réécrire des fichiers entiers pour une petite modification.
- Ne pas inventer de composants qui existent déjà (voir /components).

Chaque ligne de ce fichier vous fera gagner du temps. Décortiquons les sections les plus stratégiques :

Contexte & Stack.

Elles orientent toutes les décisions de l’IA. Une IA qui sait que le public est « surtout mobile » proposera spontanément un design pensé pour le mobile.

Conventions.

Elles garantissent la cohérence. « Toujours utiliser le composant Button existant » évite la multiplication de boutons divergents — l’un des désordres les plus fréquents.

Règles importantes & À éviter.

C’est le garde-fou anti-comportements pénibles. « Ne pas réécrire un fichier entier pour une petite modification » vous épargnera des dizaines de frustrations (nous y revenons au Module 4).

Conventions et architecture

Au-delà du `CLAUDE.md`, formalisez vos conventions : nommage des fichiers et des variables, structure des dossiers, façon de gérer les erreurs. Peu importe *lesquelles* vous choisissez ; ce qui compte, c’est la cohérence. Une base de code cohérente est infiniment plus facile à maintenir — pour vous comme pour l’IA. Sur un projet qui grossit, un court document d’architecture (l’arborescence, où vit la logique, où se trouve la configuration) sert de carte et évite que le projet ne devienne un labyrinthe.

Organiser son projet dès le départ

Une bonne organisation n’est pas un luxe esthétique : c’est ce qui permet à l’IA de retrouver et de réutiliser l’existant au lieu de tout réinventer. Trois principes suffisent :

• Une structure de dossiers claire et prévisible (ex. `components/`, `lib/`, `app/`). Quand chaque chose est à sa place, l’IA la trouve.
• Séparer le contenu, la logique et la présentation : les textes dans un fichier de constantes, la logique dans des fonctions dédiées, l’affichage dans les composants. Chaque modification devient plus sûre.
• Nommer explicitement : `AppointmentForm.tsx` se comprend d’un coup d’œil ; `comp2.tsx` est un piège pour votre futur vous.

Découper le projet en lots livrables

Vous l’avez vu au Module 2 : le découpage est la clé. Avant de coder, écrivez la liste ordonnée des étapes. Chaque étape doit être petite (réalisable et vérifiable en une session courte), autonome (testable indépendamment) et ordonnée (les fondations d’abord, les fonctionnalités ensuite). Cette liste devient votre feuille de route : vous avancez étape par étape, vous testez, vous committez, puis vous passez à la suivante. À aucun moment vous ne vous retrouvez avec 2 000 lignes non relues sur les bras.