Aller au contenu

3. Initialiser un projet

Un projet est un dossier dans lequel vous travaillez avec Claude Code. Vous copiez le modèle, puis c'est le Tech Leader qui initialise le projet avec vous, lors de la première conversation.

flowchart LR
    A["📁 Recopier<br/>le modèle"] --> B["▶️ Ouvrir le dossier<br/>dans VS Code"] --> C["💬 Taper<br/>/nouveau-projet"] --> D["📝 Le Tech Leader remplit<br/>CLAUDE.md avec vous"] --> E["🗂️ Il fait créer<br/>l'arborescence"]

Étape 1 — Recopier le modèle

Copiez le contenu de mon-projet-claude-code\ dans le dossier de votre projet, sans oublier .env et .claude\. Vous obtenez :

mon-outil/
├── CLAUDE.md               ← le document projet, encore vierge
├── .env                    ← les secrets (vide au départ)
└── .claude/
    ├── settings.json       ← { "agent": "tech-leader" }
    └── regles-ingenierie.md ← texte fixe, chargé par CLAUDE.md

Le fichier regles-ingenierie.md contient les règles d'ingénierie communes à tous les projets du kit. Ne le modifiez pas : la première ligne du CLAUDE.md le charge automatiquement.

La ligne "agent": "tech-leader" active le Tech Leader : dans ce dossier, la session principale adopte ce rôle.

Projet déjà commencé sans le kit

Suivez plutôt Reprendre un projet existant : mise en place sans rien écraser, puis audit par le Tech Leader.

Étape 2 — Ouvrir le projet dans VS Code

Dans VS Code, faites Fichier → Ouvrir le dossier et choisissez la racine du projet, celle qui contient .claude\. Ouvrez ensuite Claude Code (icône ✱) et démarrez une conversation.

VS Code était déjà ouvert ?

Les fichiers de configuration, ceux du projet comme les globaux, ne sont pris en compte qu'après un redémarrage de VS Code. Si vous avez copié le modèle pendant que VS Code tournait, redémarrez-le avant d'ouvrir le dossier.

Étape 3 — Initialiser le projet avec le Tech Leader

Tapez la commande :

/nouveau-projet

Le Tech Leader :

  1. vérifie la mise en place : qu'il tient bien son rôle, que le CLAUDE.md est encore le modèle vierge et qu'aucun projet n'existe déjà dans le dossier. Sinon, il s'arrête et vous le dit ;
  2. se présente et vous invite à décrire votre projet : ce que vous voulez faire et pour qui, le niveau de qualité visé, et les documents de référence que vous avez déposés ;
  3. après votre réponse, remplit le CLAUDE.md rubrique par rubrique : il pose ses questions, propose des valeurs quand vous hésitez, vous montre le texte et ne l'écrit qu'après votre accord ;
  4. propose l'arborescence qui en découle (dossiers des livrables, du code et des tests, venv, .gitignore), puis la fait créer par le Developer après votre accord ;
  5. termine par un récapitulatif : ce qui existe, ce qui reste ouvert.

Ce qui compte dans votre description :

  • Le niveau de qualité visé : c'est l'information qui pèse le plus sur la suite. Une démo (poc) se prépare en quelques minutes, une livraison client (release) demande plus de rigueur. Si vous hésitez, dites-le, ou consultez Choisir son niveau.
  • Le langage courant suffit : deux ou trois phrases. Les détails viendront avec ses questions.

Votre accord sur l'arborescence vaut autorisation de créer le venv, conformément aux règles d'ingénierie. La conversation s'arrête à la préparation du projet, sans code métier : votre premier vrai besoin viendra ensuite.

Si le Tech Leader ne se reconnaît pas dans son rôle, voir la FAQ.

Ce que le Tech Leader va vous demander

Les cinq rubriques du document projet :

# Rubrique La question Pourquoi
1 Le produit Que fait ce projet, pour qui ? Quel est son niveau de qualité ? Le niveau règle toute la finesse du travail. Sans lui, l'agent choisit à votre place, souvent trop haut.
2 Documentation de référence Où est l'écrit qui fait foi : cahier des charges, format de données, règles métier ? C'est là que se lit le résultat attendu des tests, jamais dans le code (règles d'ingénierie).
3 Emplacement des livrables Où ranger la spécification, l'architecture, les ADR et le backlog ? Le Tech Leader n'invente aucun chemin.
4 Conventions et contraintes Version de Python, venv, langue, Git ou pas, ce qui est versionné… Ce qu'on ne peut pas deviner en lisant le dossier.
5 Hors-périmètre Qu'est-ce qu'on ne touche jamais ici ? C'est ce qui arrête un exécutant zélé.

Préparez vos documents

Si vous avez déjà un cahier des charges ou la description d'un format de données, déposez-le dans le dossier avant de lancer le prompt : il servira de documentation de référence.

Relisez ce qu'il propose

Un bon document projet est vérifiable (« les sorties vont dans resultats/ », pas « rangez bien »), court (moins de 200 lignes) et tranché : pas de « à définir ». L'exemple complet en montre un.

N'utilisez pas /init

Cette commande de Claude Code génère un CLAUDE.md selon son propre plan, qui ne respecte pas les cinq rubriques.

Étape 4 — Ranger les secrets dans .env

Si votre projet utilise une clé d'API, un mot de passe ou un jeton, c'est dans .env qu'il va, jamais dans le code, dans CLAUDE.md ou dans la conversation :

API_METEO_CLE=votre-clé-ici

Votre code le lit, par exemple avec python-dotenv. .env ne doit jamais être partagé : le .gitignore créé à l'étape 3 doit l'exclure. Les agents peuvent nommer un secret (« variable API_METEO_CLE dans .env »), jamais en afficher la valeur. Claude Code ne lit pas .env de lui-même : c'est une convention pour vos programmes.

Le projet est prêt. Redémarrez VS Code, pour que le document projet rempli soit pris en compte, puis décrivez votre premier besoin en langage courant : la suite du guide explique à quoi vous attendre.

Sources