Les réglages qui changent tout

Permissions : arrête d'approuver sans cesse

Par défaut, Claude demande la permission avant chaque commande shell et chaque modification de fichier. C'est le bon réglage de départ : tant que tu ne sais pas ce que l'outil fait, chaque action mérite un regard. Mais au bout d'une heure, tu auras approuvé trente fois ls, cat et git status — des commandes de lecture qui ne peuvent rien casser. Cette friction a un coût réel : elle interrompt ta concentration et, pire, elle t'entraîne à cliquer « oui » mécaniquement, ce qui ruine l'intérêt même du contrôle.

La solution : autoriser une fois pour toutes les commandes non destructives, et garder la validation manuelle pour celles qui modifient l'état de ton système ou touchent au réseau de façon sensible. Le système de permissions de Claude Code repose sur des listes d'autorisation par outil et par motif de commande, stockées dans des fichiers de configuration. Tu peux les consulter et les modifier à tout moment avec la commande /permissions.

Le plus simple pour démarrer : colle ce prompt dans Claude Code — il mettra à jour ton fichier .claude/settings.local.json, là où vivent tes permissions locales :

ajoute des permissions à ce projet claude code pour autoriser les commandes bash non destructives : WebSearch, WebFetch, source, export, curl, jq, cat, ls, grep, echo, which, wc, file, pwd, mkdir, touch, head, tail, find, sort, tree, diff, node, npm, npx, git status, git diff, git log

Anatomie des fichiers de configuration

Claude Code lit ses réglages à trois niveaux, du plus général au plus spécifique : ~/.claude/settings.json (tes réglages personnels, valables partout), .claude/settings.json (les réglages du projet, à versionner dans Git pour les partager avec une équipe), et .claude/settings.local.json (tes réglages locaux pour ce projet, ignorés par Git). Les permissions accordées « pour ce projet » atterrissent dans ce dernier.

{
  "permissions": {
    "allow": [
      "Bash(ls:*)",
      "Bash(cat:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "WebSearch",
      "WebFetch(domain:docs.anthropic.com)"
    ],
    "deny": [
      "Bash(rm -rf:*)"
    ]
  }
}

Lis ce fichier une fois pour comprendre la logique : chaque entrée combine un outil (Bash, WebFetch…) et un motif. Bash(git diff:*) autorise git diff avec n'importe quels arguments, mais pas git push. La liste deny l'emporte toujours sur allow : c'est ta ceinture de sécurité, même si une règle d'autorisation est trop large.

Modes : Plan vs Auto-Edit

Au-delà des permissions commande par commande, Claude Code a des modes de permission qui contrôlent son degré d'autonomie global. Dans le terminal, tu passes de l'un à l'autre avec Shift+Tab ; dans l'extension, un sélecteur fait la même chose. La pratique des utilisateurs expérimentés : passer la majorité du temps en Plan Mode ou Ask Before Edits pendant la phase de réflexion.

En Plan Mode, Claude ne touche à rien : il lit, analyse, et te présente un plan d'action détaillé. C'est là que tout se joue. Tu lis ce qu'il propose, tu débats, tu demandes des révisions : « pourquoi cette approche plutôt que telle autre ? », « ajoute une étape de vérification ici ». Tant que le plan n'est pas validé, tu restes en mode restrictif. Une fois le plan figé, tu bascules en Auto-Edit (acceptation automatique des modifications) et tu le laisses exécuter vite, sans t'interrompre à chaque fichier.

• Plan Mode → phase de conception : Claude lit et planifie, ne modifie rien. Idéal pour les tâches complexes ou nouvelles.
• Ask Before Edits (par défaut) → Claude propose chaque modification et attend ton accord. Bon compromis au quotidien.
• Auto-Edit → phase d’exécution : le plan est validé, Claude avance sans t’interrompre sur les éditions de fichiers.

flowchart LR
  A["Plan Mode : Claude propose"] --> B{"Plan validé ?"}
  B -->|"Non : on débat, on révise"| A
  B -->|"Oui"| C["Auto-Edit : exécution rapide"]
  C --> D["Relecture du résultat"]
  D --> E["/clear puis tâche suivante"]

Le mode YOLO : à manier avec précaution

Il existe un cran au-dessus : lancer Claude Code avec claude --dangerously-skip-permissions, qui désactive toutes les demandes de permission. Le nom est explicite — c'est volontairement intimidant. Ce mode a des usages légitimes : des tâches longues et bien cadrées (corriger des erreurs de lint sur 50 fichiers, générer du boilerplate) où chaque interruption ruine l'intérêt de l'automatisation.

Mais comprends ce que tu signes : Claude peut alors exécuter n'importe quelle commande sans te consulter. La recommandation d'Anthropic est de réserver ce mode à des environnements isolés — un conteneur Docker, une machine virtuelle, un dossier sans données sensibles. Sur ton poste de travail principal, avec tes vrais fichiers clients, contente-toi des listes d'autorisation : tu obtiens 95% de la fluidité avec 5% du risque.

Contexte : repartir propre avec /clear et /compact

Chaque conversation avec Claude vit dans une fenêtre de contexte : la mémoire de travail du modèle. Tout y entre — tes messages, ses réponses, le contenu des fichiers lus, les sorties de commandes. Cette fenêtre est grande mais finie, et surtout : plus elle se remplit de choses sans rapport avec ta tâche actuelle, plus les réponses se dégradent. Le modèle se met à mélanger les sujets, à ressortir des décisions d'une tâche précédente, à perdre le fil.

Quand tu démarres une nouvelle tâche (nouvelle fonctionnalité, correction, sujet différent), nettoie la conversation pour repartir d'un contexte propre. Deux commandes existent, et elles ne font pas la même chose :

Le bon réflexe : /clear par défaut entre les tâches, /compact seulement quand tu es au milieu de quelque chose de long et que Claude t'avertit que le contexte se remplit. Note que Claude Code déclenche aussi une compaction automatique quand la fenêtre approche de la saturation — mais une compaction choisie au bon moment (après une étape terminée, pas au milieu d'un raisonnement) préserve mieux la qualité.

Le raccourci qui recharge ton contexte

« Mais si je fais /clear, Claude oublie tout mon projet ! » Exact — et c'est pour ça que le chapitre 8 existe. Le fichier CLAUDE.md, lu automatiquement au démarrage de chaque session, contient le contexte permanent de ton projet. /clear efface le bruit conversationnel ; CLAUDE.md garantit que l'essentiel revient toujours.

Astuce d'expert en attendant : crée un raccourci (par exemple une petite commande qnew) qui demande à Claude de relire ton CLAUDE.md et de résumer où en est le projet. Ainsi chaque session redémarre avec tout le contexte projet, sans le bruit des conversations passées. Tu verras au chapitre 8 comment construire ce fichier proprement.