Le setup Claude que j’aurais voulu avoir dès le premier jour : les 7 réglages qui changent tout

Vous ouvrez Claude Code pour la première fois. Vous tapez une question, obtenez une réponse précise et vous vous dites que c’est enfin un outil qui comprend votre contexte. Puis vient la deuxième session. Puis la troisième. Claude ne sait plus rien de votre stack, de vos conventions de nommage, de vos règles de commit. Vous re-expliquez les mêmes contraintes. Vous collez les mêmes instructions dans chaque conversation. Vous avez l’impression de faire tourner 14 prompts différents éparpillés dans des Notion sans jamais trouver le bon au bon moment.

Ce guide couvre les 7 réglages à poser dès l’installation. Comptez 45 minutes pour tout configurer. Une fois en place, Claude conserve votre contexte entre sessions et respecte vos règles sans rappel. La délégation aux sous-agents spécialisés ne demande plus aucune intervention manuelle.

Pourquoi la configuration par défaut est un piège

Claude Code installé sans configuration fonctionne en mode amnésique. Chaque session repart d’un context window vide. Aucune règle ne persiste et aucun outil externe n’est connecté. C’est fonctionnel pour tester, pas pour produire.

Le contraste avec un setup structuré est documenté : selon le Pragmatic Engineer Survey 2026 sur 906 développeurs, 95% des ingénieurs sondés utilisent des outils IA au moins chaque semaine. Parmi les utilisateurs de Claude Code, ceux qui ont configuré des règles persistantes et des hooks rapportent en moyenne 3 à 5 heures gagnées par semaine, avec les équipes du top quartile qui atteignent 5 à 8 heures. La différence entre ces deux groupes tient rarement au modèle utilisé. Elle tient à la configuration.

Les 7 réglages décrits ici correspondent aux couches documentées dans la configuration officielle d’Anthropic et aux pratiques observées chez les équipes qui ont atteint un ROI de 4:1 sur leurs outils IA (données Faros AI, 2026). Chaque réglage est accompagné de la commande ou du fichier exact à créer.

Réglage 1 : le CLAUDE.md global, votre contexte universel

Le fichier ~/.claude/CLAUDE.md est chargé automatiquement dans toutes vos sessions Claude Code, quel que soit le projet ou le répertoire de travail. C’est le seul endroit où placer ce qui ne change pas selon le projet : votre langue de travail et vos règles globales.

Créez-le s’il n’existe pas :

1. Ouvrez un terminal.
2. Tapez mkdir -p ~/.claude && nano ~/.claude/CLAUDE.md.
3. Ajoutez vos règles globales : langue de réponse, style de code préféré, conventions de nommage transversales.
4. Sauvegardez. Claude lira ce fichier à chaque démarrage.

Restez sous 400 lignes. Au-delà, le fichier consomme une part significative du context window à chaque session et dilue les instructions qui comptent vraiment. Si vous dépassez cette limite, c’est que des règles projet ont glissé dans votre CLAUDE.md global.

Réglage 2 : le CLAUDE.md projet, le contexte qui connaît votre stack

Le réglage précédent définit vos règles universelles. Celui-ci les complète avec ce qui ne doit s’appliquer qu’à un seul projet. Le fichier ./CLAUDE.md à la racine d’un projet est chargé uniquement quand Claude travaille dans ce répertoire. C’est là que vont les informations spécifiques : architecture du projet, dépendances critiques, commandes de lancement, règles de test, conventions de commit propres au repo.

La distinction entre global et projet est celle que la plupart des guides omettent. En pratique, elle fait toute la différence : vos règles Python n’ont aucune raison d’apparaître dans un projet Node.js et votre stack data n’a pas à polluer le contexte d’un projet front. Sans cette séparation, le CLAUDE.md global finit par devenir un fourre-tout illisible que Claude interprète de moins en moins correctement au fil des sessions.

Contenu type pour un CLAUDE.md projet efficace :

• Stack technique (versions précises : pas « React » mais « React 18.3 + Vite 5.2 »)
• Commandes courantes : npm run dev, pytest -v, script de build, commande de migration DB
• Conventions de commit (Conventional Commits, préfixes imposés, scope autorisés)
• Fichiers ou dossiers à ne jamais modifier sans confirmation explicite (ex : db/migrations/, .env.production)
• Points d’entrée de l’architecture pour orienter la lecture du code

Lancez /init depuis Claude Code dans le répertoire du projet pour générer un premier brouillon automatique. Claude lit les fichiers existants, détecte la stack et propose une structure. Affinez-le manuellement : supprimez ce qui est inexact, ajoutez les règles que vous avez dû rappeler plus de deux fois en session. Ce que vous avez eu à re-expliquer une troisième fois appartient au CLAUDE.md projet.

Réglage 3 : le system prompt custom, l’identité permanente de l’agent

Le system prompt configure la personnalité et les contraintes de comportement de Claude au niveau le plus bas. Dans Claude Code, il s’injecte via le fichier ~/.claude/settings.json ou via les Projects sur claude.ai. C’est différent du CLAUDE.md : le system prompt agit avant tout contexte de session, le CLAUDE.md s’injecte dans le fil de conversation.

Cas d’usage typiques pour un system prompt custom :

• Forcer Claude à toujours demander confirmation avant une opération destructive
• Imposer une langue de réponse indépendamment de la langue de la question
• Définir un niveau de verbosité par défaut (réponses courtes vs explicatives)
• Désactiver certaines formules de politesse répétitives qui consomment des tokens inutilement

Dans settings.json, ajoutez la clé "systemPrompt" avec votre texte. La documentation officielle Anthropic (juin 2026) précise que ce champ est concaténé avec le system prompt natif de Claude Code, pas substitué. Vos instructions s’ajoutent, elles ne remplacent pas les garde-fous de sécurité intégrés.

Réglage 4 : les permissions, ce que Claude peut faire sans vous demander

Par défaut, Claude Code demande confirmation pour chaque action sensible : écriture de fichier, exécution de commande shell, lecture de fichier hors du répertoire courant. C’est sécurisé mais lent.

Le fichier ~/.claude/settings.json (scope global) ou .claude/settings.json (scope projet) contient un bloc permissions avec deux listes : allow et deny. La règle d’évaluation : les deny sont vérifiées en premier, puis ask, puis allow. La première correspondance gagne.

Un exemple fonctionnel pour une équipe dev :

• allow: ["Bash(npm run *)", "Bash(git status)", "Bash(git diff)", "Read(**/*)", "Write(src/**/*)", "Write(tests/**/*"]
• deny: ["Bash(rm -rf *)", "Bash(git push --force *)", "Bash(curl * | bash *)"]

Le pattern Bash(commande *) accepte les wildcards. Une permission mal calibrée coûte du temps à chaque session ; une permission trop large sur des commandes destructives coûte du code perdu. Calibrez sur votre workflow réel, pas sur un idéal théorique.

Réglage 5 : les hooks, les réflexes automatiques de votre workflow

Les hooks sont des scripts shell qui s’exécutent automatiquement à des moments précis du cycle de vie de Claude Code : avant qu’un outil s’exécute (PreToolUse), après (PostToolUse), quand Claude s’arrête (Stop), quand une notification est déclenchée. Ce sont les automatismes que ni le CLAUDE.md ni les permissions ne peuvent gérer.

Trois hooks à mettre en place dès le premier jour :

1. PreToolUse sur Bash : intercepter les commandes dangereuses avant exécution. Si la commande contient rm -rf ou DROP TABLE, bloquer et demander confirmation explicite.
2. PostToolUse sur Write : lancer un linter ou un formateur automatiquement après chaque écriture de fichier. Plus jamais de code non formaté committé par accident.
3. Stop : envoyer une notification (Slack, ntfy, signal sonore) quand Claude a terminé une tâche longue. Vous n’avez plus à surveiller le terminal.

Configuration dans settings.json sous la clé "hooks". Chaque hook spécifie l’événement ("event": "PreToolUse"), un matcher optionnel sur le nom de l’outil et la commande shell à exécuter. Claude Code recharge les settings.json en temps réel, sans redémarrage pour tester une modification de hook.

Réglage 6 : les serveurs MCP, ce que Claude peut voir et toucher

Le protocole MCP (Model Context Protocol) est le système de plugins de Claude Code. Un serveur MCP expose des outils que Claude peut appeler comme ses outils natifs : lire une base de données, interroger une API, naviguer dans un navigateur, chercher dans Notion ou Linear.

Sans MCP, Claude n’a accès qu’à ce que vous collez dans la conversation. Avec 3 ou 4 serveurs bien choisis, il peut cross-référencer vos tickets Linear pendant qu’il écrit du code, vérifier un endpoint API en temps réel ou lire la documentation d’une librairie dans sa version exacte.

Les serveurs MCP se déclarent dans settings.json sous la clé "mcpServers". Chaque entrée contient la commande de lancement du serveur et ses arguments. Quelques serveurs utiles dès le départ :

• filesystem (officiel Anthropic) : accès en lecture/écriture contrôlé à vos répertoires locaux
• github : lecture des issues, PRs et commits sans quitter Claude
• fetch : requêtes HTTP vers des APIs ou de la documentation web
• sqlite ou postgres : requêtes directes sur vos bases de données locales

La liste officielle des serveurs MCP certifiés est disponible sur github.com/modelcontextprotocol/servers. Des centaines de serveurs supplémentaires sont recensés sur les registres communautaires tiers (mcp.so, Smithery). Commencez par deux ou trois : ajouter trop de serveurs MCP charge le context window inutilement à chaque session.

Réglage 7 : les skills et les sous-agents, la délégation structurée

Un skill est un workflow réutilisable décrit dans un fichier Markdown que Claude exécute à la demande. Un sous-agent (subagent) est une instance Claude séparée avec son propre context window, lancée pour une tâche isolée (recherche, audit qualité, rédaction d’un rapport) sans polluer la session principale.

Ces deux mécanismes répondent à un problème que personne ne formule clairement : sans délégation, le context window de la session principale se remplit rapidement avec des tâches hétérogènes et la qualité des réponses se dégrade. Les skills et sous-agents permettent de traiter chaque type de travail avec le bon niveau de contexte et les bonnes règles.

Structure pratique :

• Skills dans ~/.claude/skills/ (globaux) ou .claude/skills/ (projet) : un dossier par skill, un fichier SKILL.md avec les instructions
• Sous-agents dans ~/.claude/agents/ ou .claude/agents/ : chaque agent a ses propres règles et outils autorisés
• Invocation : /nom-du-skill argument depuis Claude Code ou déclenchement programmatique depuis un autre agent

En pratique, la combinaison skills + sous-agents fait passer Claude Code d’un assistant réactif à un orchestrateur de workflow. Vous décrivez une tâche de haut niveau (« audite ce module et propose les refactorings »). Claude délègue l’analyse à un sous-agent et vous restitue un plan d’action synthétisé. Selon Anthropic (Code with Claude, mai 2026), le développeur moyen qui utilise pleinement ces mécanismes passe 20 heures par semaine avec l’outil. C’est le signe d’un usage qui a dépassé le stade du prompting ad hoc.

Ces 7 réglages donnent à Claude votre contexte et vos règles dans chaque session, sans répétition. La configuration transforme un LLM capable en agent fiable. La distinction est là depuis le premier jour.