Dans cet article, nous allons voir comment fonctionnent les modes de permission de Claude Code, à quel moment utiliser chacun d'eux, quels sont les bénéfices et les risques associés, et comment contrôler ou changer le mode actif dans votre session.

Quand on commence à utiliser Claude Code, on se retrouve très vite face à une petite question qui revient en permanence : "Claude peut-il exécuter cette commande ?", "Claude peut-il modifier ce fichier ?". Ces demandes sont une protection précieuse, mais elles peuvent aussi devenir une source de ralentissement quand on enchaîne un gros travail. Heureusement, Claude Code propose plusieurs modes de permission qui permettent de choisir précisément le niveau d'autonomie laissé à l'agent.

Nous verrons notamment ce qu'est concrètement un mode de permission, les cinq modes disponibles avec leurs cas d'usage et leurs risques, mais aussi comment basculer d'un mode à l'autre ou configurer celui qui s'applique par défaut à vos sessions.

Tutoriel - Installation et prise en main de Claude Code

Un mode de permission, c'est quoi ?

Le dilemme : contrôle total ou la validation permanente

Un agent de code comme Claude Code peut faire énormément de choses sur votre machine : lire des fichiers, en modifier, en supprimer, exécuter des commandes shell, pousser du code sur un dépôt distant, interroger des serveurs… Donner carte blanche à un LLM (Large Language Model) sur ces actions serait pour le moins imprudent, puisque le modèle peut se tromper, mal interpréter une consigne ou être induit en erreur par le contenu d'un fichier qu'il vient de lire (ce qu'on appelle une injection de prompt). On a donc un problème de sécurité potentiel.

À l'inverse, valider manuellement chaque action est épuisant. Si vous demandez à Claude de refactoriser dix fichiers et qu'une pop-up s'affiche à chaque écriture, vous allez vite jeter l'éponge. Le mode de permission est le curseur qui permet d'arbitrer entre ces deux extrêmes selon le contexte.

Comment Claude Code décide d'afficher une demande

À chaque fois que Claude veut utiliser un outil (lire un fichier, lancer une commande shell, écrire du code…), Claude Code passe par une petite logique d'autorisation :

Est-ce que l'action est explicitement interdite par une règle (une deny rule) ? Si oui, elle est bloquée.
Est-ce que l'action est explicitement autorisée par une règle (une allow rule) ? Si oui, elle passe sans demander.
Sinon, le mode de permission actif décide : il faut demander, laisser passer, ou passer via un contrôle secondaire.

Les modes de permission ne remplacent donc pas les règles fines que vous pouvez définir dans votre fichier settings.json, mais permettent de gérer le comportement par défaut quand aucune règle particulière ne s'applique.

L'astuce du classifieur

Deux de ces modes (plan et surtout auto) s'appuient sur un mécanisme intéressant qu'il faut comprendre avant d'aller plus loin : le classifieur. C'est un second modèle, plus petit et plus rapide, qui joue le rôle que vous jouez vous-même en mode manuel : regarder chaque action proposée et décider si elle est raisonnable ou non.

Concrètement, quand Claude Code veut exécuter une commande dangereuse en mode auto, le classifieur l'examine en arrière-plan. S'il estime que l'action est acceptable (lire un fichier, lancer un test, créer un dossier), elle passe sans vous déranger. S'il repère quelque chose qui lui semble louche (un rm -rf, une commande qui touche des chemins protégés, une tentative de contournement), il vous repasse la main avec une demande d'autorisation.

Attention toutefois, le classifieur reste un modèle et peut, lui aussi, se tromper. Il offre un filet de sécurité utile, mais pas infaillible. C'est pour cela que les modes autonomes restent déconseillés sur des données sensibles ou sur une machine où une erreur serait difficile à rattraper.

Les cinq modes disponibles

Passons à présent au cœur du sujet : les cinq modes que Claude Code met à votre disposition. Pour chacun, nous verrons son principe, les cas d'usage et les risques à garder en tête.

default (Manual) : tout est validé par vous

Le mode default, aussi appelé Manual dans l'interface, est le mode le plus strict. Dans ce mode, Claude n'exécute aucune action sans vous demander, à l'exception des lectures de fichiers qui restent libres.

Chaque modification de fichier, chaque commande, chaque appel à un outil MCP (Model Context Protocol) déclenche une petite pop-up dans laquelle vous pouvez approuver l'action une fois, l'approuver et créer une règle pour toujours l'autoriser, ou la refuser.

Quand l'utiliser : c'est le mode idéal quand vous travaillez sur une base de code sensible, sur un environnement de production, ou simplement quand vous souhaitez garder un œil attentif sur ce que fait Claude. Je l'active aussi systématiquement sur des projets que je ne connais pas encore, le temps de me familiariser avec la façon dont l'agent raisonne.

Risques : aucun côté sécurité. En revanche, la fatigue des pop-ups est réelle sur les grosses sessions, et il peut être tentant de valider mécaniquement sans lire, ce qui annule l'intérêt du mode.

Illustration du mode manual/default dans ClaudeCode.

Exemple intéressant ci-dessus. Je demande à Claude de supprimer un répertoire, il n'a pas besoin de ma permission pour lire son contenu (1), me le liste et me demande si je suis sûr de vouloir le supprimer (2). Cette confirmation demandée dans la conversation n'est pas suffisante et pourrait ne pas exister, il faut vraiment passé par la validation de la commande en elle-même pour autoriser l'exécution (3).

acceptEdits : laisser passer les éditions de fichiers

Le mode acceptEdits est un cran plus permissif. Il autorise automatiquement les modifications de fichiers ainsi que les commandes shell courantes de manipulation du système de fichiers (mkdir, touch, mv, cp, etc.). Les lectures restent libres. Pour tout le reste (commandes shell plus sensibles, appels réseau, outils MCP), une demande d'autorisation est affichée.

Quand l'utiliser : c'est le mode à choisir pour une session où vous êtes en train de relire et de guider un travail d'édition. Vous laissez Claude écrire du code sans vous interrompre, mais vous reprenez la main dès qu'il veut lancer une commande qui touche à autre chose qu'à vos fichiers.

Risques : si Claude se trompe dans une édition, le fichier est modifié. Pensez à travailler avec un gestionnaire de version (Git) et à commiter régulièrement.

Par exemple, sur un travail de développement d'une application web, Claude va pouvoir créer, éditer les fichiers et les lire (1), mais il ne pourra pas lancer l'application web sans me demander la permission (2), car cela nécessite l'exécution d'une commande qui ne porte pas sur le système de fichier :

Illustration du mode acceptEdits dans ClaudeCode.

plan : explorer avant d'agir

Le mode plan est un peu particulier. Dans ce mode, Claude ne peut ni modifier de fichier ni lancer de commande destructrice, seulement lire. Son objectif n'est pas de produire du code, mais de vous présenter un plan d'action détaillé que vous validerez avant tout passage à l'action.

En gros il permet de réfléchir avant d'agir.

Dans les faits, vous décrivez votre besoin, Claude explore votre dépôt, analyse l'existant, puis vous propose une marche à suivre. Vous relisez, vous ajustez, et quand c'est bon, vous basculez dans un autre mode pour l'exécution.

Quand l'utiliser : avant un gros refactor, une migration de dépendance, l'ajout d'une nouvelle fonctionnalité qui touche plusieurs modules. Bref, dès qu'une mauvaise première direction coûterait cher en tokens et en nerfs.

Voici un exemple parlant :

Sortie de Claude Code en mode plan.

Le plan est clair, on voit bien comment Claude va répondre à mon besoin, mais il n'a encore rien fait. Il me demande si je veux switcher en mode manual ou auto pour passer à l'action. Mais je peux aussi lui demander de revoir son plan si j'estime que c'est nécessaire.

auto : l'autonomie supervisée

Le mode auto est le mode par défaut depuis la version 2.1.283 de Claude Code (sur les plans Pro, Max et Team sur les versions antérieures). Dans ce mode, Claude peut exécuter la plupart des actions sans vous demander, mais chaque action passe au préalable par le classifieur dont nous avons parlé plus haut.

Concrètement, les lectures, écritures, créations de dossiers, lancements de tests et commandes shell ordinaires se font sans validation. En revanche, dès que le classifieur repère une action qui lui semble à risque (une commande destructrice, un appel réseau sortant inhabituel, une écriture dans un chemin protégé…), la main vous est repassée avec une pop-up classique.

Quand l'utiliser : c'est le bon compromis au quotidien pour la plupart des tâches de développement. Il laisse Claude travailler de façon fluide tout en gardant un garde-fou. C'est le mode que je recommande par défaut, quand on maîtrise l'outil, que l'on donne des instructions claires dans un environnement hors production ou non sensible.

Risques : le classifieur n'est pas parfait. Il peut laisser passer une action qui, dans votre contexte précis, est problématique (par exemple une modification dans un dossier auquel vous teniez particulièrement). Deux bonnes pratiques pour s'en prémunir : travailler sous Git, et définir des règles explicites (allow/deny) dans votre settings.json pour les cas sensibles.

bypassPermissions : le mode sans filet

Enfin, le mode bypassPermissions est le mode le plus permissif de tous : toutes les actions passent sans aucun contrôle, ni demande utilisateur, ni classifieur. Claude peut tout faire, immédiatement.

Dans quels cas l'utiliser ? Honnêtement, dans très peu de cas sur votre machine de travail. Ce mode est pensé pour des environnements isolés, sans interaction utilisateur : un conteneur Docker jetable, une machine virtuelle dédiée, un environnement de CI (Continuous Integration). Bref, un endroit où une erreur de Claude n'aura aucune conséquence durable.

Attention, ce mode est à utiliser avec une extrême prudence. Sur une machine de travail standard, il n'y a aucun garde-fou. Une commande malheureuse peut supprimer des fichiers, pousser du code non voulu, exfiltrer des données ou déclencher à peu près n'importe quelle action que votre compte utilisateur est autorisé à faire. Ne l'activez jamais sur un environnement de production ou sur votre poste principal sans savoir exactement ce que vous faites.

Pour éviter les activations accidentelles, Claude Code n'inclut d'ailleurs pas ce mode dans le cycle de bascule Shift+Tab par défaut. Il faut explicitement le demander au démarrage (via --permission-mode bypassPermissions ou --dangerously-skip-permissions). Ces options sont d'ailleurs interdites lorsque l'on est sous root (sous Linux) :

# claude  --dangerously-skip-permissions
--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Voici un petit résumé graphique de ce que nous venons de voir :

En pratique : contrôler et changer de mode

Maintenant que nous avons fait le tour des cinq modes, voyons comment les manipuler lorsque l'on est dans Claude Code.

Repérer le mode actif

Le mode actif est en permanence affiché dans la barre d'état sous l'invite de Claude Code, comme vous pourrez le voir en bas de chacune des images précédentes. Chaque mode a son symbole et sa couleur, ce qui permet de voir d'un coup d'œil où vous en êtes.

Le visuel de chacun des modes de permission.

Basculer en cours de session avec Shift+Tab

Le moyen le plus rapide de changer de mode en cours de session est le raccourci Shift+Tab. Chaque pression fait tourner le cycle :

auto → default → acceptEdits → plan → auto …

Vous verrez le libellé en bas de l'écran changer à chaque pression. C'est pratique quand vous avez démarré en auto et que vous arrivez à une étape sensible où vous préférez tout valider à la main : un ou deux Shift+Tab et vous êtes en default.

Notez que bypassPermissions n'est pas dans le cycle par défaut pour éviter d'y basculer par mégarde. Il faut explicitement les activer au démarrage.

Démarrer dans un mode précis

Si vous savez d'avance dans quel mode vous voulez travailler, vous pouvez le préciser au lancement avec l'option --permission-mode :

# Démarrer en mode plan pour analyser une base inconnue
claude --permission-mode plan

# Démarrer en mode manuel pour un travail sensible
claude --permission-mode default

# Démarrer en mode auto (si ce n'est pas déjà le défaut)
claude --permission-mode auto

Pour les exécutions non interactives (option -p), c'est aussi là que vous choisirez votre mode. Par exemple, pour une tâche en CI dans un conteneur isolé :

# Exécution unique dans un conteneur, sans aucune pop-up possible
claude -p "Lance la suite de tests" --dangerously-skip-permissions

Fixer le mode par défaut dans settings.json

Si vous voulez qu'un mode soit systématiquement activé au démarrage, le plus propre est de passer par le fichier de configuration. La clé à renseigner est permissions.defaultMode, dans le fichier settings.json.

Trois emplacements sont possibles, par ordre de priorité :

Fichier

Portée

.claude/settings.json (dans le projet)

Toutes les sessions ouvertes dans ce projet

~/.claude/settings.json (utilisateur)

Toutes vos sessions sur la machine

Managed settings

Toute votre organisation (déployée par l'admin)

Un settings.json au niveau utilisateur qui force le mode manuel ressemblera par exemple à ceci :

# Fichier ~/.claude/settings.json
{
  "permissions": {
    "defaultMode": "default"
  }
}

Les valeurs acceptées sont les noms des modes vus plus haut : default, acceptEdits, plan, auto, bypassPermissions. À noter qu'il existe quelques subtilités : les valeurs auto et bypassPermissions ne sont pas acceptées dans un .claude/settings.json de projet (pour éviter qu'un dépôt partagé n'impose un mode permissif à toute l'équipe), elles doivent être posées dans votre fichier utilisateur ou dans les managed settings.

Si vous travaillez à plusieurs sur un même dépôt, il est souvent préférable de laisser le mode default à chacun et de ne pas le fixer dans le settings.json du projet. Chaque membre pourra ainsi régler son propre curseur selon sa sensibilité.

Conclusion

Nous avons vu dans cet article les cinq modes de permission de Claude Code, leurs cas d'usage respectifs, leurs risques, et comment basculer de l'un à l'autre aussi bien en live que par configuration.

Comme toujours en sécurité, le bon mode est celui qui correspond à la fois à la criticité de l'environnement et à la confiance que vous accordez à l'agent sur la tâche en cours. Ces deux curseurs évoluent au fil d'une session, donc n'hésitez pas à basculer de l'un à l'autre avec Shift+Tab plutôt que de garder un mode unique pour tout le travail de la journée.

Il y a encore beaucoup à dire sur les règles fines de permission (allow et deny rules), sur l'isolement via sandbox et sur l'intégration de Claude Code en CI, mais nous aurons l'occasion d'y revenir dans d'autres articles.

N'hésitez pas à partager dans les commentaires le mode que vous utilisez au quotidien, ou à venir en discuter sur notre serveur Discord !

Ajouter IT-Connect à mes
sources préférées

Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.

Claude Code : comprendre les modes de permission et choisir le bon