Mon setup Claude Code au quotidien — ce qui marche vraiment

Claude Code est devenu mon outil de travail principal depuis quelques mois. Pas juste pour générer du code — pour tout : exploration de codebases, debugging, prototypage d’agents, rédaction de specs.

Voici ce qui fonctionne vraiment dans mon setup, et ce qui m’a déçu.

Ce que j’utilise vraiment

Pour explorer une codebase inconnue

La première chose que je fais sur un nouveau projet client : je lance Claude Code et je lui demande de m’expliquer l’architecture. Pas “génère-moi du code”, mais “explique-moi comment ce module fonctionne et quelles sont les dépendances critiques”.

C’est d’une efficacité redoutable. En 20 minutes j’ai une vue d’ensemble que j’aurais mis 2 heures à construire seule en lisant le code.

Pour prototyper des prompts systèmes

Quand je dois concevoir un prompt système pour un agent, je commence toujours par en discuter avec Claude Code. Je lui décris le comportement attendu, il me propose une structure, je critique, on itère.

Ce n’est pas lui qui écrit le prompt final — c’est moi. Mais la conversation m’aide à clarifier mes idées beaucoup plus vite qu’en travaillant seule.

Pour les revues de specs

Avant de valider une spec avec une équipe de dev, je la fais passer par Claude Code avec un rôle de “développeur senior sceptique”. La question : “Qu’est-ce qui manque dans cette spec ? Qu’est-ce qui va poser problème à l’implémentation ?”

Le résultat est souvent surprenant — il identifie des ambiguïtés que j’avais manquées.

Ma configuration CLAUDE.md

Le fichier CLAUDE.md à la racine du projet, c’est la clé. Voici ce que j’y mets systématiquement :

# Contexte projet
[Description du projet, stack technique, contraintes]

# Conventions
- Langue : français pour les commentaires et la doc
- Style : [vos conventions de code]

# Ce que tu ne dois pas faire
- Ne pas modifier les fichiers de configuration sans validation
- Ne pas toucher aux migrations de base de données
- Toujours demander confirmation avant de supprimer du code

# Contexte métier
[Glossaire des termes spécifiques au domaine]

Ce dernier point est souvent oublié. Si votre domaine a un vocabulaire spécifique (“dossier” veut dire quelque chose de précis chez vous), le définir dans CLAUDE.md évite beaucoup d’erreurs.

Ce qui m’a déçu

Les longs contextes. Au-delà d’une certaine taille de codebase, les performances dégradent. Claude Code peut perdre le fil sur des projets très larges. Je segmente maintenant mes sessions par module.

La génération de tests. Les tests générés automatiquement sont souvent trop superficiels — ils testent le happy path sans vraiment challenger les cas limites. Je les utilise comme point de départ, pas comme livrable final.

La tendance à l’overengineering. Sans instruction explicite de simplicité, Claude Code va parfois produire une solution générique et extensible là où on voulait quelque chose de simple et direct. L’instruction “préfère la solution la plus simple” dans CLAUDE.md aide beaucoup.

Ce que je recommande si vous démarrez

1. Commencez par bien configurer CLAUDE.md — c’est l’investissement qui rapporte le plus
2. Utilisez-le d’abord pour comprendre et explorer, pas pour générer
3. Traitez les sorties comme des propositions à critiquer, pas comme des vérités
4. Définissez des contraintes explicites sur ce qu’il ne doit pas faire

Claude Code est un outil remarquable. Mais comme tous les outils puissants, son efficacité dépend de la façon dont vous l’utilisez.