Configuration des autorisations : c'est vous qui décidez du degré de liberté

📚 Navigation dans la série : L'article précédent 19 Gestion du contexte vous a appris comment gérer le « plan de travail » de Claude et éviter qu'il n'encombre sa mémoire. Cet article change de dimension — on ne gère plus « ce dont il se souvient », mais « ce qu'il ose faire » : de vous demander l'autorisation pour chaque ligne de commande à une autonomie totale, c'est vous qui tenez les rênes.

« Comment oses-tu activer --dangerously-skip-permissions ? Le nom lui-même dit que c'est dangereux. »

« Je suis dans un bac à sable (sandbox), qu'est-ce que je risque ? Même s'il supprime tout le répertoire avec un rm -rf, il ne supprime qu'un conteneur jetable, il suffit d'en recréer un. »

J'ai moi-même tenu ces deux discours : lors de refactorisations en masse dans un conteneur isolé sur le cloud, je laisse activé le mode de danger le plus permissif tout le temps, supprimer et recommencer ne me cause aucun stress psychologique ; mais de retour sur ma machine locale dans le répertoire contenant le vrai code de l'équipe, j'hésite même deux secondes avant de faire un acceptEdits. En fin de compte, il n'y a pas de "bien" ou de "mal" en matière d'autorisations, seulement "où vous les utilisez". Ce même mode dangereux, très lâche, est un « accélérateur » dans un conteneur isolé, mais une « bombe à retardement » sur la machine où se trouve le code de production de votre entreprise.

Dans l'article 07 précédent, nous avons eu un avant-goût — Claude s'arrête pour vous demander avant de modifier un fichier. Ce n'était que la partie émergée de l'iceberg. Aujourd'hui, nous allons soulever tout l'iceberg : quels sont les différents modes d'autorisation de Claude Code, comment basculer entre eux en un clic, et comment utiliser les fichiers de configuration pour définir précisément "ceci est autorisé, cela est absolument interdit".

Après avoir lu cet article, vous saurez :

• Ce que sont les six modes d'autorisation et dans quels scénarios les utiliser, expliqués dans un tableau récapitulatif.
• Le raccourci clavier Shift+Tab pour basculer de mode par mémoire musculaire, et comment forcer un mode spécifique au démarrage.
• La syntaxe pour écrire des règles allow / ask / deny dans settings.json, afin de contrôler précisément les autorisations par outil ou par commande.
• Deux modèles de configuration prêts à copier-coller : « souple pour les projets de test, strict pour les projets de production ».
• Quand ose-t-on vraiment activer --dangerously-skip-permissions, et où est la ligne rouge.

---

01 Pour commencer : que contrôle le système d'autorisations ?

Commençons par la conclusion : Claude Code est par défaut un stagiaire qui « demande d'abord, agit ensuite », et la configuration des autorisations correspond au « code de conduite » que vous lui définissez.

Il divise toutes les opérations en trois catégories, avec un traitement par défaut totalement différent. Ce tableau de classification tiré de la documentation officielle est la base pour comprendre tout le reste :

Type d'outil	Exemple	Approbation requise par défaut
Lecture seule	Lire un fichier, recherche Grep	Non, autorisation directe
Commande Bash	Exécuter une commande shell	Oui
Modification de fichier	Modification Edit / Écriture Write d'un fichier	Oui

Analogie : le stagiaire vous demande-t-il avant d'agir ? Un stagiaire fiable, si on lui dit « jette un œil à ce code », il va le lire sans broncher (lecture seule, zéro risque) ; mais s'il doit « modifier la configuration de production » ou « lancer une commande de suppression », il devrait normalement lever la tête et vous demander « chef, je peux toucher à ça ? ». Claude Code fonctionne de la même manière par défaut — il lit à volonté, mais signale ses intentions avant de passer à l'action.

Il y a une notion clé ici, et j'y ai moi-même trébuché : les autorisations sont imposées par le programme Claude Code, et non par la « conscience du modèle ».

À l'époque, j'avais écrit spécifiquement dans CLAUDE.md : « n'exécute pas de git push », en pensant que cela le bloquerait définitivement. Résultat ? À une occasion, il a quand même poussé proprement le code — parce que CLAUDE.md n'est qu'une indication douce qui « influence ses intentions », les vraies contraintes strictes doivent être écrites dans les règles d'autorisation. C'est seulement lorsque j'ai déplacé cette règle dans les deny qu'il s'est tenu à carreau. La documentation officielle est très franche :

Les règles d'autorisation sont appliquées par Claude Code, et non par le modèle. Vos prompts ou les instructions dans CLAUDE.md influenceront ce que Claude essaie de faire, mais ils ne changeront pas ce que Claude Code permet de faire.

Gardez cela à l'esprit pour savoir où construire vos « défenses ».

💡 En résumé : La lecture seule est libre, l'action requiert l'approbation est le code par défaut ; pour vraiment bloquer une action, il faut rédiger une règle d'autorisation, de simples recommandations dans CLAUDE.md ne suffisent pas.

---

02 Six modes d'autorisation : de « demander à chaque pas » à « quartier libre »

Le mode d'autorisation (permission mode) contrôle une seule chose : la « fréquence » à laquelle Claude s'arrête pour vous poser une question avant d'agir. D'« attendre votre accord pour chaque étape » à « ne rien demander et tout faire tout seul », il y a un spectre continu.

Analogie : pour reprendre le stagiaire, le mode correspond à son « niveau d'autonomie ». Son premier jour, il demande la permission pour tout (default) ; une fois habitué, il n'a plus besoin de demander pour modifier du code, mais il doit toujours vous appeler avant d'effacer la base de données (acceptEdits) ; quand vous êtes en déplacement, vous lui faites totalement confiance et vous le laissez gérer seul (bypassPermissions).

La documentation officielle propose six modes. J'ai résumé leur comportement concernant le « va-t-il vous demander en premier » et leurs « scénarios d'utilisation » dans un tableau — c'est le tableau le plus important à retenir de cet article :

Mode	Ce qu'il peut faire sans demander	Vous demandera-t-il d'abord ?	Meilleur scénario
default	Uniquement lecture seule	Il demande pour tout, modification et commandes	Débutants, tâches sensibles
acceptEdits	Lecture seule + modif fichiers + commandes de système de fichiers courantes (mkdir, mv, cp, etc.)	Il ne demande pas pour éditer des fichiers et ces commandes système, mais il demande pour les autres commandes Bash	Itérer sur du code que vous êtes en train de vérifier
plan	Uniquement lecture seule (étudie, planifie, ne touche au code)	Mêmes règles de prompt que default	Explorer et faire un plan avant de modifier
auto	Toutes les actions, avec un classificateur de sécurité en arrière-plan	Il ne demande presque pas, le classificateur bloque ce qui dépasse les bornes	Tâches longues, moins d'interruptions (version aperçu/research)
dontAsk	Uniquement les outils pré-approuvés	Ne demande pas et ne s'arrête pas, refuse directement ce qui n'est pas approuvé	CI verrouillée, scripts
bypassPermissions	Toutes les opérations, saute toutes les vérifications	Ne demande jamais rien	Uniquement pour des conteneurs isolés / VM

Voici quelques points sur lesquels les débutants s'emmêlent le plus souvent :

plan (Mode plan) n'est pas « relâché », c'est le plus prudent. Il permet à Claude de lire uniquement les fichiers et d'exécuter des commandes en lecture seule pour comprendre la situation, puis de vous rédiger un plan : « Voici comment je compte procéder ». Il ne touchera pas à une seule ligne de votre code source. Lors de la reprise d'un projet inconnu, je recommande de passer d'abord en plan pour qu'il lise tout et fasse un bilan, c'est beaucoup plus sûr que de le laisser tout modifier d'entrée de jeu.

acceptEdits est la zone de confort pour le développement quotidien. Il approuve automatiquement l'édition de fichiers dans votre répertoire de travail et quelques commandes de système de fichiers courantes (mkdir, touch, rm, rmdir, mv, cp, sed), mais les autres commandes shell et les écritures en dehors du répertoire de travail nécessiteront toujours votre approbation. C'est comme dire : « Pas besoin de cliquer "accepter" pour modifier le code, mais garde le frein pour les actions dangereuses ».

auto et bypassPermissions semblent tous deux « ne pas demander », mais la sécurité est radicalement différente. auto est une version d'étude avec un modèle classificateur indépendant en arrière-plan qui examine chaque opération ; les actions hors limites (comme curl | bash, pousser sur main, supprimer du stockage cloud) seront bloquées ; bypassPermissions c'est la véritable absence de protection, qui ne prévient même pas des injections de prompt. La documentation officielle l'explique très clairement :

bypassPermissions ne protège pas contre les injections de prompt ni les actions accidentelles. Pour des vérifications de sécurité en arrière-plan sans confirmation (prompt), veuillez plutôt utiliser auto mode.

Donc, pour la « tranquillité d'esprit avec une ligne de fond », priorisez auto, et ne sautez pas directement sur bypassPermissions.

💡 En résumé : default demande à chaque pas, acceptEdits modifie le code sans demander, plan ne fait que regarder, auto a un classificateur en filet de sécurité, bypassPermissions n'a aucune protection — retenez ce spectre de strict à lâche, et choisissez en conséquence.

Cette image ordonne les six modes sur un spectre allant de « plus strict » à « plus lâche » : la zone verte à gauche correspond à plan / default (lecture seule, demande à chaque pas, le plus sûr), vers la droite on passe par acceptEdits (modifications sans demander), auto (filet de sécurité), jusqu'à la zone rouge à droite bypassPermissions (totalement débridé) — plus on va vers la droite, plus c'est rouge, pour vous rappeler que « plus c'est lâche, plus vous devez savoir où vous l'utilisez ».

---

03 Changer de mode : une pression sur Shift+Tab pour boucler

Maintenant que vous connaissez les modes, comment passer de l'un à l'autre ? Le raccourci le plus courant : Shift+Tab.

Dans une conversation, appuyer sur Shift+Tab vous fait parcourir les trois modes principaux en boucle :

default → acceptEdits → plan → (retour à default)

Pour savoir dans quel mode vous êtes, regardez la barre d'état (statusline). Par exemple, si vous basculez sur acceptEdits, la barre d'état affichera ⏵⏵ accept edits on.

Faites attention à un détail officiel pour éviter de chercher un mode en vain : seuls default / acceptEdits / plan font partie de la boucle par défaut. Les trois autres modes ont des moyens d'accès spécifiques : auto s'ajoute à la boucle automatiquement si votre compte remplit les conditions ; bypassPermissions nécessite de démarrer avec l'option --permission-mode bypassPermissions pour être dans la boucle ; dontAsk n'apparaît jamais dans la boucle et ne peut être défini que par le paramètre de démarrage --permission-mode dontAsk (expliqué plus bas).

Analogie : le commutateur « Sonnerie / Vibreur / Silencieux » du téléphone. En appuyant sur le bouton près du volume, vous passez d'un profil à l'autre. Shift+Tab, c'est ce même bouton pour Claude Code, passant par « demander à chaque pas / modifier sans demander / regarder sans toucher ».

Si vous ne voulez pas changer de mode manuellement à chaque fois, il y a deux façons de « verrouiller » un mode :

Méthode 1 : Spécifier via un paramètre au démarrage (valable pour cette session uniquement) :

claude --permission-mode plan

Remplacez plan par acceptEdits, dontAsk, ou n'importe quel autre nom de mode. bypassPermissions est particulier — --permission-mode bypassPermissions et --dangerously-skip-permissions sont équivalents, mais au quotidien on préfère ce dernier nom qui « porte un avertissement », on en reparle section 05.

Méthode 2 : Le définir dans settings.json comme mode par défaut (actif à chaque démarrage). Dans le fichier .claude/settings.json de votre projet :

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

⚠️ Une restriction officielle à noter : lorsque defaultMode est défini sur "auto", les paramètres du projet et locaux seront ignorés (pour éviter qu'un dépôt active discrètement le mode automatique pour lui-même), pour avoir auto par défaut il faut l'inscrire dans le niveau utilisateur ~/.claude/settings.json.

Une recommandation habituelle : ne pas verrouiller le mode dans le projet, mais utiliser uniquement Shift+Tab pour changer manuellement. En effet, pour le même projet, parfois vous voulez le laisser faire (acceptEdits), parfois vous voulez seulement un plan d'action (plan), donc figer la valeur peut être gênant. On n'utilise defaultMode avec default que lorsque « ce projet nécessite une prudence absolue ».

💡 En résumé : Dans la session, Shift+Tab boucle entre « demander à chaque pas / modifier sans demander / regarder sans toucher », la barre d'état affiche le mode en cours ; pour le verrouiller, utilisez l'argument de lancement --permission-mode ou defaultMode dans settings.json.

---

04 Contrôle fin : les trois règles allow / ask / deny

Le mode donne le « gros réglage », fixant la tonalité de base. Le vrai « réglage fin » qui dicte « cette commande passe, celle-là est interdite » s'effectue via trois règles dans settings.json.

Chaque règle se traduit par l'une des trois actions suivantes :

Action	Effet	Utilisation type
allow	Aucune approbation requise, passage automatique	Actions fréquentes à faible risque, comme git status, npm run build
ask	Affiche une notification pour que vous décidiez	Actions à risque modéré nécessitant confirmation, comme git push
deny	Bloque directement, sans exécution ni notification	Actions dangereuses strictement interdites, comme rm -rf, lecture de .env

La priorité est absolue : deny → ask → allow, la première règle correspondante gagne. Ainsi, deny a toujours la préséance sur les deux autres — si vous écrivez à la fois allow et deny, c'est deny qui l'emporte. Cette conception est logique : une « interdiction » doit avoir plus de poids qu'une « permission ».

La syntaxe des règles est NomDeLOutil ou NomDeLOutil(Spécificateur). Regardez ces exemples pour comprendre :

Règle	Ce qu'elle cible
Bash	Toutes les commandes Bash
Bash(npm run build)	Cible exactement et uniquement cette commande npm run build
Bash(npm run *)	Cible les commandes commençant par npm run (build, test…)
Read(./.env)	Lecture du fichier .env dans le répertoire courant
WebFetch(domain:github.com)	Requêtes réseau vers github.com

Le joker * a un piège d'espacement pour les débutants, souligné par la documentation officielle :

Bash(ls *) cible ls -la mais pas lsof, tandis que Bash(ls*) cible les deux.

Un espace de différence et le sens change. ls * (avec espace) exige qu'il y ait un espace après ls, ce qui exclut lsof ; ls* (sans espace) inclut aussi lsof. Si vous voulez être précis, mettez l'espace.

Voici à quoi ressemble une configuration complète — autoriser npm et git commit, mais bloquer absolument git push :

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Enfin, un point de sécurité crucial à souligner : la règle deny sur Read / Edit ne bloque pas les « lectures/écritures détournées » via un processus enfant Bash.

Qu'est-ce que cela signifie ? Vous avez écrit deny: Read(./.env) pour empêcher Claude de lire directement .env, mais s'il exécute un script Python open('.env').read(), ce deny ne pourra rien y faire — car c'est le processus enfant qui lit, en contournant l'outil de gestion de fichiers intégré de Claude. La documentation prévient :

Elles ne s'appliquent pas aux processus enfants arbitraires qui lisent ou écrivent indirectement dans les fichiers, comme un script Python ou Node qui ouvre le fichier lui-même. Pour obtenir une application au niveau de l'OS afin d'empêcher tous les processus d'accéder à un chemin, veuillez activer le sandboxing (bac à sable).

C'est surprenant — on croyait être à l'abri avec un deny .env. C'est pourquoi pour verrouiller véritablement un fichier sensible, il faut combiner les règles d'autorisation avec un Sandbox (bac à sable) pour obtenir une défense en profondeur (le bac à sable isole au niveau de l'OS, ce sera détaillé dans le prochain article sur la « Sécurité »).

💡 En résumé : deny → ask → allow, la correspondance suit cette priorité et deny gagne toujours ; l'espace dans une règle modifie son sens ; mais deny ne bloque pas les accès détournés via des scripts, pour les fichiers sensibles, utilisez le bac à sable (Sandbox).

---

05 Souple pour le bac à sable, strict pour la prod : deux modèles + la ligne rouge du « mode dangereux »

Après toutes ces explications, retenez une chose en pratique : plus le projet est un « bac à sable » (toy project), plus vous pouvez être souple ; plus c'est de la « production », plus vous devez être strict.

Voici deux configurations prêtes à l'emploi, à choisir selon la nature du projet.

Modèle 1 : Projets personnels ou de test (souple pour la vitesse). Si ça casse on recrée, pas besoin de s'arrêter à chaque pas. On utilise acceptEdits pour qu'il modifie sans demander, et on ne bloque que ce qui est vraiment dangereux :

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)"
    ]
  }
}

Modèle 2 : Projets de production / d'entreprise (strict pour le contrôle). Par défaut on demande à chaque étape. On autorise la lecture pour faciliter la recherche, mais l'écriture et les commandes dangereuses requièrent votre validation, et on bloque l'accès aux fichiers sensibles :

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

En écrivant ces deny, souvenez-vous de la section précédente : un deny sur .env ne protège pas contre un script qui contourne la règle. Pour un environnement de production solide, il faut rajouter un Sandbox (bac à sable) par-dessus. Ne prenez pas un simple deny pour un mur infranchissable.

Enfin, parlons de cette ligne rouge, protagoniste du dialogue d'introduction — --dangerously-skip-permissions (équivalent au mode bypassPermissions).

Cette option désactive toutes les vérifications d'autorisation et de sécurité, les appels d'outils s'exécutent instantanément. Le terme dangerously (dangereusement) n'est pas là pour faire peur. La documentation officielle délimite strictement son utilisation :

N'utilisez ce mode que dans des environnements isolés (comme des conteneurs, des VM ou des dev containers sans accès à internet) où Claude Code ne peut pas endommager votre système hôte.

Voici les règles d'or à appliquer directement :

Scénario	Osez-vous activer --dangerously-skip-permissions ?
Conteneur isolé / VM / dev container	✅ Oui, ce qu'il supprime est jetable
Tâche unique dans une CI	✅ Oui, mais avec deny en filet de sécurité
Sur votre machine de développement locale	❌ Non, préférez perdre du temps plutôt que la sécurité
Machine avec le code de production de l'entreprise	❌ Absolument pas, c'est une bombe à retardement

Deux « assurances » conçues officiellement pour vous rassurer : premièrement, même dans ce mode, des opérations comme rm -rf / ou rm -rf ~ (suppression de la racine ou du répertoire utilisateur) déclencheront une alerte, pour éviter les erreurs de frappe fatales ; deuxièmement, sur Linux / macOS, il refuse de démarrer ce mode si vous êtes root ou utilisez sudo. Mais ne comptez pas trop là-dessus — l'essentiel est : « ne l'activer que dans un environnement isolé où la suppression n'a pas d'importance ».

💡 En résumé : Modèle acceptEdits pour accélérer sur les petits projets, default pour contrôler en prod, copiez-les selon vos besoins ; --dangerously-skip-permissions s'active uniquement en conteneur isolé, jamais sur une machine locale ou de production.

---

06 En pratique : configurez vos premières règles en 5 minutes

Observer ne remplace pas l'action. Voici comment configurer des autorisations sur un projet test, pour voir de vos propres yeux comment fonctionnent allow et deny. Aucune installation complexe n'est requise.

Étape 1 : Créer le projet et le répertoire de configuration (Mac / Linux)

mkdir perm-demo
cd perm-demo
mkdir .claude

Résultat attendu : Le dossier perm-demo contient un répertoire vide .claude. Tapez ls -a pour voir que .claude est bien là.

Étape 2 : Rédiger le settings.json

Ouvrez votre éditeur préféré et collez ceci dans perm-demo/.claude/settings.json :

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Ce que fait cette règle : demander pour chaque action par défaut, mais git status passe sans demander, et git push est bloqué sans appel.

Étape 3 : Lancer Claude et vérifier les règles

claude

Une fois dedans, tapez :

/permissions

Résultat attendu : L'interface de gestion des permissions s'ouvre, montrant les règles que vous venez d'écrire — git status * dans la liste Allow, git push * dans Deny, avec l'indication de quel settings.json elles proviennent. Si vous voyez ces deux lignes, la configuration est correctement chargée.

Étape 4 : Vérifier que deny bloque vraiment

Demandez-lui dans la zone de saisie de faire l'action interdite :

Aide-moi à faire un git push origin main

Résultat attendu : Claude n'exécutera pas la commande, et ne demandera pas non plus votre approbation — il vous informera directement que cette opération a été refusée par les règles d'autorisation. C'est la puissance de deny : pas d'exécution, pas de confirmation, blocage total.

Étape 5 : Comparer avec la fluidité de allow

Demandez-lui maintenant de faire l'action autorisée :

Aide-moi à vérifier le git status

Résultat attendu : Ayant rencontré allow: Bash(git status *), il exécute la commande directement sans afficher de demande d'approbation (comme le répertoire n'a pas encore eu de git init, la commande dira « n'est pas un dépôt git », mais ça c'est le problème de git — le point clé est qu'il ne s'est pas arrêté pour vous demander, ce qui prouve que allow fonctionne).

En passant ces cinq étapes, vous avez vérifié par vous-même la chaîne complète « Rédiger règle → Charger → deny bloque → allow autorise ». Toute configuration future des autorisations reposera fondamentalement sur ce mécanisme.

💡 En résumé : Créez .claude/settings.json pour écrire les règles, /permissions pour vérifier le chargement, puis demandez à Claude d'exécuter une commande bloquée et une autorisée — valider cette chaîne par vous-même est plus utile que d'apprendre dix règles de syntaxe.

---

07 Résumé

Dans cet article, nous avons décortiqué les « rênes des autorisations » de Claude Code — le fait qu'il soit très libre ou très contraint dépend entièrement de vous et de quelques lignes de configuration.

Récapitulatif des points clés :

Ce que vous voulez faire	Ce que vous utilisez	Point clé
Ajuster la « fréquence des demandes »	Les six modes	De default (demande toujours) à bypassPermissions (totalement libre)
Changer de mode rapidement	Shift+Tab	Boucle entre default / acceptEdits / plan
Verrouiller le mode par défaut	defaultMode	Dans settings.json ; auto doit être au niveau utilisateur
Contrôle fin de chaque opération	allow / ask / deny	Priorité : deny → ask → allow, deny gagne toujours
Verrouiller les fichiers sensibles	deny + Sandbox	Un simple deny ne bloque pas les scripts qui contournent la règle

Maintenant, vous devriez être capable de : comprendre quel mode d'autorisation utiliser dans quel scénario, basculer facilement avec Shift+Tab, écrire des règles allow / deny par outil et commande dans settings.json, configurer des autorisations adaptées aux projets de test comme de production, et savoir que --dangerously-skip-permissions est une ligne rouge à ne pas franchir en dehors d'un environnement isolé. Cette maîtrise des autorisations vous donne l'assurance de laisser Claude travailler de manière autonome sans risquer la catastrophe.

---

Article suivant 21 « Sécurité et frontières de risques » — Cet article vous a appris « comment configurer les autorisations », mais la configuration n'est qu'un outil. Le niveau au-dessus est : Devez-vous vraiment faire confiance à l'IA pour toucher à votre code et votre système ? Quels sont les vrais domaines à haut risque ? À quoi ressemblent les pièges des injections de prompt ou des fuites de données sensibles ? Maintenant que vous tenez les rênes, nous parlerons dans le prochain article de votre jugement sur « quand serrer et quand relâcher ».

---

Lectures recommandées

• Guide d'utilisation de CLAUDE.md : graver les règles du projet dans sa mémoire
• Dépannage FAQ (FAQ / Troubleshooting)
• Agent Skills : doter Claude de compétences spécifiques à la demande