Le dossier .claude que personne ne regarde (et qui change tout)

Le dossier .claude est le cerveau invisible de Claude Code. La plupart des gens ne l'ouvrent jamais.

Ce que les 90% des utilisateurs ne savent pas

Quand vous lancez Claude Code pour la première fois, il crée silencieusement un dossier .claude dans votre répertoire de projet. Et un autre dans votre home directory. La plupart des développeurs ne touchent jamais à ces fichiers.

C'est une erreur. Ce dossier, c'est l'interface de configuration la plus puissante de Claude Code. Pas un fichier CLAUDE.md vaguement documenté, pas juste des permissions. Tout le système de personnalisation.

Le dossier .claude, c'est la différence entre utiliser Claude Code à 10% et le faire travailler vraiment pour vous.

Les deux dossiers .claude : projet vs personnel

Premier truc à comprendre : il y a deux dossiers .claude distincts, avec des rôles très différents.

Le dossier .claude dans votre projet contient les règles, commandes, skills et agents spécifiques à ce projet. C'est ce que vous partagez avec votre équipe via Git. Tout le monde travaille avec les mêmes règles, les mêmes commandes slash, les mêmes skills.

Le dossier ~/.claude dans votre home directory est votre playbook personnel. Vos préférences, vos shortcuts, et surtout : toute l'historique de vos sessions. Chaque conversation Claude Code est stockée dans un fichier JSON quelque part dans ce dossier. Si vous cherchez une session d'il y a trois semaines, c'est là.

Pour voir ce que contient chacun, une commande bash rapide dans Claude Code :

!ls .claude/
!ls ~/.claude/

CLAUDE.md : pensez routeur, pas encyclopédie

C'est l'erreur la plus fréquente : transformer CLAUDE.md en un pavé de 300 lignes qui documente absolument tout. Architecture, conventions de code, style d'email, format des rapports financiers, tout dans un seul fichier.

Problème : Claude lit ce fichier intégralement à chaque session. Plus il est long, plus vous consommez de contexte pour rien.

La bonne approche : CLAUDE.md comme routeur. 50 lignes maximum. Le fichier dit à Claude où chercher pour chaque type de tâche :

# Pour la rédaction d'emails : voir .claude/rules/email-drafting.md
# Pour les rapports financiers : voir .claude/rules/financial-reports.md
# Pour le style des briefs : voir .claude/rules/brief-writing.md

Claude ne charge les règles spécifiques que quand elles sont pertinentes. Résultat : contexte préservé, instructions plus précises, moins de dérive entre les sessions.

C'est la même logique que pour AutoDream et la mémoire persistante entre sessions : ne charger que ce qui est nécessaire au bon moment.

Les règles : compartimentez chaque workflow

Le dossier .claude/rules/ est l'endroit le moins connu et le plus utile de tout l'écosystème Claude Code.

Chaque fichier Markdown dans ce dossier est une règle dédiée à un type de tâche. Email, brief, rapport, code review, format de commit, rédaction de documentation... autant de fichiers séparés.

Pourquoi c'est puissant : ces règles sont itératives. Chaque fois que Claude fait quelque chose qui ne correspond pas à ce que vous vouliez, vous ouvrez le fichier de règle concerné et vous ajoutez une ligne. La règle s'améliore avec l'usage.

Mes meilleures règles, c'est 6 mois d'itérations condensées en 30 lignes. Aucun prompt ne peut reproduire ça.

Pour inspecter une règle rapidement sans quitter Claude Code :

!head -15 .claude/rules/email-drafting.md

Commandes slash : transformez n'importe quel workflow en raccourci

Règle simple : si un fichier Markdown existe dans .claude/commands/, il devient une commande slash invocable instantanément. Le fichier s'appelle process-meeting.md : vous avez /process-meeting. Il s'appelle weekly-summary.md : vous avez /weekly-summary.

Ce qui rend les commandes vraiment flexibles, c'est l'argument wildcard. Dans votre fichier de commande, vous pouvez utiliser $ARGUMENTS comme placeholder. Ce qui vous permet de faire :

/process-meeting latest
/process-meeting abc123-meeting-id

La commande sait alors si elle doit chercher la dernière réunion ou une réunion spécifique par ID. Fireflies, Notion, Linear, peu importe votre stack : les commandes slash transforment n'importe quelle opération répétitive en un raccourci déterministe.

Skills vs Commandes : quelle différence concrète ?

C'est la confusion la plus fréquente chez les utilisateurs intermédiaires.

Les skills ont des trigger words dans leur description. Quand Claude traite un transcript et détecte les mots "action items", le skill action-tracker se déclenche automatiquement. Sans que vous ayez à le demander.

Un tip expert : si vous commencez à accumuler beaucoup de skills similaires, désactivez l'invocation automatique sur les plus spécialisés avec disable-model-invocation: true dans le fichier skill. Cela évite que Claude utilise le mauvais skill dans un cas ambigu.

Pour construire une équipe d'agents complète avec des skills sur Claude Code, cet article sur l'équipe marketing IA détaille le workflow complet.

Agents spécialisés : cristalliser vos sub-agents récurrents

Les sub-agents deviennent de plus en plus puissants. Mais si vous utilisez les mêmes configurations d'agents encore et encore, il est temps de les cristalliser dans .claude/agents/.

Chaque fichier d'agent définit son nom, sa description, ses outils autorisés, et surtout : le modèle à utiliser. C'est là que ça devient intéressant. Pour un agent qui analyse des transcripts de réunion, Haiku suffit largement. Pour un security auditor qui fait de l'analyse de vulnérabilités, vous voulez Sonnet avec plus de puissance de raisonnement.

J'ai lancé 10 sub-agents en parallèle pour explorer une codebase entière. Chacun spécialisé sur un module. Rapport unifié en retour. Ce qui prend une heure à la main.

Un tip avancé : vous pouvez activer context: fork pour laisser un skill s'exécuter dans sa propre fenêtre de contexte, isolée du contexte principal. Idéal pour les tâches lourdes qui risquent de polluer votre session principale.

Settings.json et hooks : le filet de sécurité

Le fichier settings.json dans .claude/ contrôle ce que Claude peut faire sur votre machine. Commandes bash autorisées, fichiers accessibles, outils activés.

Trois niveaux de permission :

• Tout autorisé : Claude exécute sans demander (mode yolo, déconseillé pour les projets sensibles)

• Demander d'abord : Claude demande confirmation avant d'exécuter (mode par défaut)

• Jamais : certaines commandes sont bloquées quoi qu'il arrive

Les hooks fonctionnent au niveau settings.json. Un hook pre-tool-use s'exécute avant chaque appel d'outil. Utile pour protéger un fichier .env, loguer les actions, ou vérifier une condition avant modification.

Pour voir tous vos paramètres actuels :

!cat .claude/settings.json

Le mental model complet : comment tout s'articule

Voici comment tous ces éléments fonctionnent ensemble sur un exemple concret : un workflow de traitement de réunions avec l'API Fireflies.ai.

• 1. La réunion se termine. Fireflies capture le transcript automatiquement.

• 2. Vous lancez /process-meeting latest dans Claude Code.

• 3. Claude charge la commande process-meeting.md et appelle l'API Fireflies.

• 4. Dans le transcript, il détecte des action items : le skill action-tracker se déclenche automatiquement.

• 5. Les action items sont structurés selon les règles dans .claude/rules/action-items.md.

• 6. Le skill auto-follow-up prend le relais et rédige les emails selon .claude/rules/email-drafting.md.

• 7. Tout est stocké dans Supabase. Settings.json a autorisé les appels API réseau au préalable.

Un seul fichier CLAUDE.md de 50 lignes orchestre tout ça. Il ne fait que pointer vers les bonnes pièces au bon moment.

Par où commencer

Si vous n'avez jamais configuré votre dossier .claude, voici l'ordre d'importance :

• D'abord : CLAUDE.md propre, court, orienté routeur (pas d'encyclopédie)

• Ensuite : une ou deux règles pour les tâches que vous faites souvent (email, commit messages, code review)

• Puis : une commande slash pour le workflow le plus récurrent de votre projet

• Optionnel mais puissant : un skill pour les patterns que vous voulez automatiser

• En dernier : settings.json pour verrouiller les permissions selon votre niveau de confiance

Commencez simple. Itérez. Le dossier .claude s'améliore avec l'usage, pas avec la planification.