Configuration du projet

Travailler avec Claude Code est bien plus intéressant quand vous avez un projet concret sous la main. Sur un dossier vide, l’outil ne peut rien montrer de ce qui fait sa valeur : rien à lire, rien à exécuter, aucune convention à respecter, aucun historique à consulter. La qualité de ce que vous retirerez de ce cours dépendra donc directement du projet que vous lui donnerez à explorer.

Utiliser votre propre projet

La meilleure façon de suivre ce cours est d’utiliser votre propre codebase. Claude Code brille sur du vrai code — vos fichiers, votre architecture, vos conventions, y compris celles que personne n’a jamais écrites nulle part. C’est aussi le seul moyen d’évaluer honnêtement l’outil : une démonstration sur un projet jouet ne vous dira rien de son comportement sur un dépôt de trois ans avec ses zones obscures, ses dépendances anciennes et ses deux façons contradictoires de gérer les erreurs.

Pour commencer, placez-vous dans le répertoire de votre projet :

cd /chemin/vers/votre/projet
claude

Claude Code utilise le répertoire courant comme racine de travail, et tous les chemins de fichiers seront relatifs à ce dossier. Gardez cette conséquence en tête : un lancement depuis un sous-répertoire limite d’emblée ce que Claude pourra voir, et il n’aura aucun moyen de vous signaler ce qui lui manque.

Créer un projet de démonstration

Si vous n’avez pas de projet sous la main, un bac à sable se monte en deux commandes :

mkdir demo-claude-code && cd demo-claude-code
npm init -y

Vous pouvez ensuite demander à Claude de générer une petite application :

Cree une application Express.js simple avec un endpoint GET /api/hello
qui renvoie { "message": "Bonjour le monde" }

L’exercice a un intérêt qui dépasse largement le résultat produit. Comme vous connaissez exactement l’état initial du dossier — il était vide il y a une minute —, vous pouvez observer précisément quels fichiers Claude crée, dans quel ordre, et quelles décisions il prend sans vous les demander. C’est une bonne première lecture de son comportement avant de le lâcher sur du code qui compte.

Bonnes pratiques

Quatre habitudes font une différence nette dès les premières sessions. La première est de lancer Claude Code à la racine du projet, car c’est là qu’il trouvera le package.json, le dossier .git/ et les autres fichiers de configuration. Démarré deux niveaux plus bas, il devra deviner ce qui se trouve au-dessus de lui, ou vous le demander, ce qui revient à faire manuellement le travail que vous vouliez lui confier.

La deuxième est d’avoir un dépôt Git initialisé. Claude Code s’appuie sur Git pour comprendre la structure et l’historique du projet, et vous y gagnez au passage un filet de sécurité décisif : sur un dépôt propre en début de session, un simple git diff vous montre exactement ce qui a bougé, et rien de ce qui s’est passé n’est irréversible.

La troisième consiste à garder un terminal ouvert à côté pour vérifier manuellement les changements si besoin. Relire un fichier, relancer un test, inspecter un diff dans votre propre outil : cette vérification parallèle vous évite d’accumuler des modifications que vous n’avez jamais réellement regardées, ce qui arrive vite quand tout s’enchaîne bien.

La quatrième est la plus souvent négligée : commencez petit. Demandez d’abord à Claude d’explorer et de comprendre le projet avant de lui demander des modifications. Une question d’exploration vous coûte trente secondes et vous apprend immédiatement s’il a identifié votre point d’entrée, votre framework et votre organisation de dossiers. S’il se trompe là-dessus, il se trompera sur tout le reste — et mieux vaut le découvrir avant qu’il n’ait touché un seul fichier.

Vérifier que tout fonctionne

Une fois dans votre projet, testez avec une question simple :

Decris la structure de ce projet en quelques lignes

Claude va explorer les fichiers et vous donner un aperçu de l’architecture. Lisez sa réponse attentivement au lieu de la survoler : elle vous dit ce qu’il a compris de votre projet, donc la base sur laquelle il travaillera dans toutes les leçons suivantes. Si le résumé est juste, vous êtes prêt pour la suite du cours ; s’il est approximatif, c’est le bon moment pour le corriger, pas dans trois leçons.