Gaëtan Wittebolle.EN
guides / claude-code / ch. 9
Chapitre 9 · Les outils avancés

🔒 Les permissions

5 min de lecture

🎯

Ce chapitre t'explique comment fonctionne le système de permissions de Claude Code, ce qu'il peut faire seul et ce qui nécessite ton accord. Tu gardes toujours le contrôle. Temps de lecture : 5 minutes.

Claude demande toujours avant d'agir

Claude Code ne fera jamais quelque chose de risqué sans te demander explicitement. C'est une règle de sécurité fondamentale.

Mais il y a un problème pratique : par défaut, il demande confirmation pour chaque commande, même les plus banales. Lancer un typecheck ? Confirmation. Lancer le lint ? Confirmation. Lire un fichier ? Confirmation. Après 50 confirmations en 1 heure, tu deviens fou.

La solution : pré-autoriser les commandes sûres tout en gardant la validation pour les actions risquées.

Les 3 niveaux de risque

🟢

Sûr, automatique

Claude fait ça librement, sans rien te demander :

  • Lire des fichiers
  • Naviguer dans le code
  • Analyser le projet
  • Chercher des patterns dans le code
🟡

Modéré, demande confirmation

Claude te montre ce qu'il va faire et attend ton OK :

  • Modifier des fichiers
  • Installer des packages
  • Exécuter des commandes (tests, build, migrations)
  • Créer de nouveaux fichiers
🔴

Risqué, toujours demandé

Claude explique en détail et attend ta validation explicite :

  • Pousser du code sur GitHub (git push)
  • Supprimer des fichiers ou des branches
  • Actions irréversibles (reset de base de données, etc.)
  • Commandes inconnues ou inhabituelles

Pré-autoriser les commandes sûres

Pour éviter de cliquer "Oui" 50 fois par session, crée un fichier de configuration qui autorise automatiquement les commandes répétitives et sans risque.

Créer le fichier

Crée le fichier .claude/settings.local.json à la racine de ton projet :

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npx supabase *)",
      "Bash(npx vitest *)",
      "Bash(git status*)",
      "Bash(git diff*)",
      "Bash(git log*)",
      "Bash(git add *)",
      "Bash(git commit*)"
    ]
  }
}
💡

Syntaxe wildcard : utilise * comme joker. Bash(npm run *) autorise npm run dev, npm run build, npm run test, etc. en une seule règle. Pas besoin de lister chaque variante.

Ce que ça autorise

CommandePourquoi c'est sûr
npm run typecheckVérifie les types, ne modifie rien
npm run lintVérifie le style, ne modifie rien
npm run testLance les tests, ne modifie rien
npm run buildCompile l'app, ne modifie pas le code source
npx supabaseCommandes Supabase locales
git status/diff/logLecture seule de l'état Git
git add/commitSauvegarde locale (pas de push)

Ce qui continue de demander confirmation

  • git push (envoyer du code en ligne)
  • npm install (ajouter des dépendances)
  • Suppression de fichiers
  • Commandes inconnues

Le mode trust

Si tu es en session de développement intensif et que tu fais totalement confiance à Claude, tu peux passer en mode "trust" depuis l'interface. Claude ne demandera plus de confirmation pour rien.

⚠️

Attention : le mode trust est puissant mais risqué. Utilise-le seulement quand tu sais exactement ce que Claude va faire (ex: exécuter un plan que tu as validé). Ne le laisse pas activé en permanence.

L'expérience au quotidien

Avec un fichier de permissions bien configuré, voici ce que ça donne en pratique :

  • Claude écrit du code → tu vois les fichiers se modifier en temps réel dans VS Code
  • Claude lance typecheck → passe automatiquement, pas de confirmation
  • Claude lance lint → passe automatiquement
  • Claude veut installer un package → te demande "Installer framer-motion ?" → tu valides
  • Claude veut commiter → passe automatiquement avec le bon message
  • Claude veut pusher → te demande "Pousser sur la branche feat/streak ?" → tu valides

Le résultat : tu ne cliques que sur les décisions qui comptent vraiment.

Le filet de sécurité : la deny list

Plus puissant que l'allowlist : la deny list (liste noire). Elle bloque des commandes dangereuses même en mode trust total. C'est ton garde-fou ultime.

Dans ton ~/.claude/settings.json (global, pour tous les projets) :

{
  "permissions": {
    "deny": [
      "Bash(rm -rf*)",
      "Bash(sudo*)",
      "Bash(supabase db reset*)",
      "Bash(git push --force*)",
      "Bash(git push -f*)",
      "Bash(git reset --hard*)",
      "Bash(git clean -f*)"
    ]
  }
}
🛡️

Ces commandes sont bloquées quoi qu'il arrive, même si tu es en mode trust, même si Claude pense que c'est nécessaire. rm -rf peut supprimer ton projet entier. supabase db reset détruit toutes les données et credentials. git push --force peut écraser le travail de ton équipe. Mieux vaut prévenir que guérir.

La différence allow vs deny :

  • allow (.claude/settings.local.json projet) : commandes autorisées sans confirmation
  • deny (~/.claude/settings.json global) : commandes interdites partout, même en mode trust
💡

À retenir : configure l'allowlist une seule fois par projet et la deny list une seule fois globalement. Tu élimines 90% des confirmations inutiles tout en bloquant les commandes dangereuses. C'est l'équilibre parfait entre fluidité et sécurité.

← Chapitre 8

⚡ Les raccourcis qui accélèrent tout

Chapitre 10 →

💾 La mémoire entre les sessions

📖 Retour au sommaire