Claude Code : Guide Permissions et Sécurité Complet

Mis à jour le 3 mars 2026

Claude Code a accès à ton terminal, tes fichiers, tes commandes. C'est ce qui le rend puissant. C'est aussi ce qui rend la sécurité importante. Un outil qui peut créer des fichiers, en supprimer, exécuter des commandes shell et accéder au réseau doit être encadré. Sinon tu confies les clés de ta machine à une IA sans filet.

Bonne nouvelle : Claude Code a un système de permissions granulaire qui te donne le contrôle total sur ce que l'IA peut et ne peut pas faire. Pas un toggle on/off basique. Un vrai modèle multicouches avec des règles par outil, par chemin de fichier, par domaine réseau, et même par projet.

Ce guide couvre les 4 couches de sécurité de Claude Code : le modèle de permissions utilisateur, la sandbox système, les hooks de sécurité, et les managed settings pour les équipes. Si tu utilises Claude Code dans un contexte professionnel — ou simplement si tu veux dormir tranquille — c'est l'article à lire. Pour les bases de l'outil, commence par le guide complet Claude Code.

Le modèle de permissions Claude Code

Claude Code utilise un modèle de permissions à trois niveaux : les actions en lecture (toujours autorisées), les commandes Bash (demandent confirmation), et les modifications de fichiers (demandent confirmation). Tu contrôles exactement ce que l'IA peut faire.

Quand tu lances Claude Code, il a accès à ton projet. Mais "accès" ne veut pas dire "carte blanche". Chaque action est classée dans un niveau de risque :

Niveau 1 — Lecture (toujours autorisé). Claude Code peut lire tes fichiers, analyser la structure de ton projet, consulter le contenu de tes dossiers. C'est la base. Sans lecture, il ne peut rien comprendre. Ce niveau ne modifie rien, ne supprime rien, n'exécute rien. Il regarde, c'est tout.

Niveau 2 — Modification de fichiers (demande confirmation). Dès que Claude Code veut créer, modifier ou supprimer un fichier, il te demande la permission. Il affiche exactement ce qu'il va changer : quel fichier, quelles lignes, quel contenu. Tu vois le diff (la comparaison avant/après) et tu décides : accepter, refuser, ou demander une modification.

Niveau 3 — Exécution de commandes (demande confirmation). Les commandes shell — npm install, git commit, rm, ou n'importe quel programme — sont le niveau le plus sensible. Claude Code te montre la commande exacte avant de l'exécuter. Tu vois ce qui va se passer dans ton terminal. Un npm install express est bénin. Un rm -rf / est catastrophique. Les deux passent par la même demande de confirmation.

Ce modèle à trois niveaux est le comportement par défaut. Il est conçu pour un équilibre entre productivité et sécurité : l'IA peut explorer librement (niveau 1), mais chaque action qui modifie ton environnement passe par ton approbation (niveaux 2 et 3).

Les 5 modes de permission

Le modèle à trois niveaux est le comportement par défaut. Mais tu peux le changer. Claude Code propose 5 modes de permission qui ajustent le degré d'autonomie de l'IA. Chaque mode correspond à un cas d'usage précis.

default — Le mode standard

C'est le mode actif quand tu lances Claude Code sans configuration particulière. La lecture est libre. Les modifications de fichiers et les commandes Bash demandent confirmation une par une. C'est le mode recommandé pour le travail quotidien. Tu gardes le contrôle total, Claude Code ne fait rien sans ton accord explicite.

acceptEdits — Auto-approuve les éditions de fichiers

Ce mode laisse Claude Code modifier les fichiers sans demander. Les commandes Bash continuent à demander confirmation. C'est pratique quand tu fais confiance à Claude Code pour les modifications de code (il te montre toujours ce qu'il a changé après coup), mais tu veux garder le contrôle sur les commandes système. Beaucoup de vibecoders passent en acceptEdits après quelques semaines d'utilisation, une fois qu'ils sont à l'aise avec le fonctionnement de l'outil.

plan — Lecture seule, aucune modification

Le mode le plus restrictif. Claude Code peut lire, analyser, et proposer. Mais il ne peut rien modifier. Aucun fichier créé, aucun fichier modifié, aucune commande exécutée. C'est le mode idéal pour l'exploration d'un projet existant, la planification d'une refactorisation, ou l'analyse de code. Tu obtiens les recommandations de Claude Code sans risque de modification accidentelle. C'est ce mode qui est utilisé par le Plan Mode quand tu veux réfléchir avant de coder.

dontAsk — Refuse automatiquement les outils non autorisés

Ce mode inverse la logique. Au lieu de demander confirmation pour les outils non autorisés, il les refuse directement. Pas de popup, pas de question : l'action est bloquée silencieusement. Tu combines ce mode avec des règles granulaires (voir section suivante) pour créer un environnement où seules les actions explicitement autorisées sont possibles. Tout le reste est interdit par défaut. C'est le mode le plus restrictif après plan.

bypassPermissions — Aucune vérification

Le mode sans filet. Claude Code peut tout faire, sans demander, sans vérifier, sans attendre. Lecture, écriture, suppression, commandes shell — tout passe automatiquement. Ne l'utilise jamais sur ton poste de travail principal. Ce mode existe pour un cas précis : les agents autonomes qui tournent dans un environnement isolé (container Docker, VM dédiée, CI/CD pipeline). Si l'environnement est jetable et contrôlé, bypassPermissions maximise la productivité. Partout ailleurs, c'est un risque inutile.

Les règles granulaires

Les modes de permission sont des réglages globaux. Les règles granulaires sont des réglages chirurgicaux. Elles te permettent d'autoriser ou bloquer des actions spécifiques, outil par outil, chemin par chemin, domaine par domaine.

Règles par outil

Chaque outil de Claude Code (Bash, Write, Edit, Read, WebFetch, etc.) peut avoir sa propre règle. Tu peux autoriser Write sur certains fichiers et le bloquer sur d'autres. Tu peux autoriser Bash pour npm et git mais le bloquer pour tout le reste. Le format de configuration est en JSON, dans le fichier .claude/settings.json de ton projet ou dans ~/.claude/settings.json pour des règles globales.

{
  "permissions": {
    "allow": [
      "Bash(npm install*)",
      "Bash(git *)",
      "Write(src/**)"
    ],
    "deny": [
      "Bash(rm *)",
      "Write(.env*)"
    ]
  }
}

Dans cet exemple : Claude Code peut lancer les commandes npm install et git sans confirmation, écrire dans le dossier src/ librement, mais ne peut jamais exécuter rm ni toucher aux fichiers .env. Chaque règle utilise le format Outil(pattern) avec support des wildcards (* pour tout, ** pour les sous-dossiers).

Règles par chemin

Les règles basées sur les chemins sont les plus utiles au quotidien. Tu peux autoriser Claude Code à modifier librement tout ce qui est dans src/ mais protéger config/, .env, et le dossier scripts/. Le pattern ** inclut récursivement tous les sous-dossiers. Le pattern * matche n'importe quelle chaîne dans un seul niveau de dossier.

Règles par domaine réseau

Quand Claude Code utilise WebFetch ou des MCP Servers qui accèdent au réseau, tu peux contrôler les domaines autorisés. Par exemple, autoriser l'accès à api.github.com et registry.npmjs.org mais bloquer tout le reste. C'est une couche de protection réseau qui empêche l'IA d'envoyer ou de récupérer des données vers des destinations non prévues.

Priorité des règles

Les règles deny prennent toujours priorité sur les règles allow. Si tu autorises Write(src/**) mais refuses Write(src/secrets/**), le dossier secrets est protégé malgré la règle plus large. C'est un modèle "deny wins" — en cas de conflit, la restriction l'emporte. C'est un choix de sécurité délibéré.

La sandbox système

Les permissions utilisateur sont la première ligne de défense. La sandbox système est la deuxième. Elle opère au niveau de l'OS (le système d'exploitation), indépendamment des permissions Claude Code.

L'isolation du filesystem — la sandbox limite les dossiers auxquels Claude Code peut accéder sur ta machine. Même si une règle de permission autorise l'écriture quelque part, la sandbox peut restreindre l'accès au niveau OS. C'est une défense en profondeur : si les permissions échouent (bug, mauvaise config), la sandbox attrape ce qui reste.

Les restrictions réseau — la sandbox contrôle aussi les connexions réseau sortantes. Elle peut bloquer les requêtes vers des domaines non autorisés au niveau système, pas seulement au niveau application. C'est important pour empêcher l'exfiltration de données : même si Claude Code essaie d'envoyer du contenu vers un serveur externe, la sandbox peut bloquer la connexion.

Pourquoi la sandbox est importante même avec des permissions ? Parce que les permissions sont configurées par l'utilisateur et elles peuvent contenir des erreurs. La sandbox est une couche de sécurité indépendante qui fonctionne même si les permissions sont mal configurées. C'est le principe de la défense en profondeur — plusieurs couches indépendantes, chacune capable de bloquer une menace que les autres auraient laissé passer.

La sandbox s'active automatiquement. Tu n'as rien à configurer. Elle fonctionne en arrière-plan et tu ne la remarques que quand elle bloque quelque chose qui dépasse les limites prévues.

Les hooks de sécurité

Les hooks sont des scripts qui se déclenchent automatiquement à des moments précis du cycle de vie de Claude Code. En matière de sécurité, deux types de hooks sont essentiels.

PreToolUse — Bloquer les commandes dangereuses

Le hook PreToolUse s'exécute avant chaque utilisation d'outil par Claude Code. Il reçoit en entrée le nom de l'outil et les paramètres. Il peut analyser la commande, décider si elle est autorisée, et retourner un code de sortie pour autoriser (exit code 0) ou bloquer (exit code 2) l'action.

Exemple concret : un hook PreToolUse qui bloque les commandes destructrices.

#!/bin/bash
# Hook: security-guard
# Bloque rm -rf, force push, DROP TABLE

COMMAND="$1"

if echo "$COMMAND" | grep -qE "rm\s+-rf|--force|force push|DROP TABLE|truncate"; then
  echo "BLOCKED: commande dangereuse détectée"
  exit 2
fi

exit 0

Ce hook inspecte chaque commande Bash avant son exécution. S'il détecte rm -rf, --force, force push, DROP TABLE ou truncate, il bloque l'action avec exit code 2. Claude Code reçoit le message de blocage et adapte son comportement. Il ne réessaie pas la commande bloquée — il cherche une alternative ou te demande quoi faire.

File Protection — Protéger les fichiers sensibles

Un autre pattern courant : un hook PreToolUse sur les outils Write et Edit qui vérifie si le fichier cible est un fichier sensible. Les fichiers .env, credentials.json, secrets/, les clés SSH — tout ce qui contient des données confidentielles peut être protégé par un hook qui demande une confirmation supplémentaire ou bloque directement la modification.

La puissance des hooks, c'est qu'ils sont automatiques. Tu les configures une fois, et ils s'appliquent à chaque session, sans que tu aies besoin d'y penser. C'est une sécurité par construction, pas par vigilance. Tu n'as pas besoin de te rappeler de vérifier chaque commande — le hook le fait pour toi.

Pour une explication complète des hooks (pas seulement sécurité : aussi formatage automatique, notifications, logs), lis le guide complet des hooks Claude Code.

Managed settings pour les équipes

Tout ce qu'on a vu jusqu'ici concerne l'utilisation individuelle. Mais si tu déploies Claude Code dans une équipe ou une entreprise, tu as besoin d'un contrôle centralisé. C'est le rôle des managed settings.

Déploiement via MDM

Les managed settings se déploient via MDM (Mobile Device Management) — c'est l'outil que les entreprises utilisent pour configurer les logiciels sur les machines des employés (comme Jamf sur Mac ou Intune sur Windows). Tu crées une policy de sécurité Claude Code et elle s'applique automatiquement à chaque poste. Les développeurs n'ont pas besoin de configurer quoi que ce soit — et ils ne peuvent pas contourner les restrictions.

Allowlist et denylist pour les MCP Servers

Les MCP Servers connectent Claude Code à des outils externes (bases de données, APIs, services cloud). En entreprise, tu veux contrôler quels MCP Servers sont autorisés. Les managed settings permettent de définir une allowlist (seuls les serveurs listés sont accessibles) ou une denylist (tout est accessible sauf les serveurs listés). L'allowlist est recommandée — elle garantit que seuls les outils validés par l'équipe sécurité sont utilisables.

Politiques de permissions centralisées

Au-delà des MCP Servers, les managed settings permettent d'imposer des modes de permission, des règles granulaires, et des hooks de sécurité à l'échelle de l'organisation. Un admin sécurité configure la policy une fois, et chaque développeur hérite des mêmes contraintes. Pas de risque qu'un développeur désactive une protection par mégarde.

Les managed settings ont la priorité la plus haute dans la hiérarchie de permissions. Si l'organisation dit "deny Write(.env*)", aucune configuration locale — ni projet, ni utilisateur — ne peut contourner cette règle. C'est la couche de sécurité ultime pour les environnements sensibles.

Pour le détail complet du déploiement en équipe, consulte le guide Claude Code en entreprise.

Bonnes pratiques sécurité

Voici les règles que je recommande à tous les utilisateurs, que tu sois solo ou en équipe.

Commence en mode default. Ne change pas les permissions tant que tu n'es pas à l'aise avec le fonctionnement de Claude Code. Lis chaque demande de confirmation. Comprends ce que l'outil fait avant de l'autoriser. Après quelques semaines, tu sauras quelles actions tu peux auto-approuver sans risque.

Mets en place un hook security-guard dès le jour 1. Même en mode default, un hook qui bloque rm -rf, force push et DROP TABLE est une assurance gratuite. Ça prend 5 minutes à configurer et ça peut te sauver une journée de travail.

Protège tes fichiers sensibles. Un hook sur .env, credentials, et les clés SSH. Toujours. Même si tu es seul sur le projet. C'est une habitude qui te protège le jour où tu partages ton projet ou tu travailles dans un environnement moins contrôlé.

Utilise git systématiquement. Les permissions empêchent les mauvaises actions. Git te permet de revenir en arrière si une action autorisée produit un résultat inattendu. Les deux sont complémentaires. Comme expliqué dans le guide Claude Code pour entrepreneurs, un git init au début de chaque projet est non négociable.

Ne mets jamais bypassPermissions sur ta machine de travail. Ce mode existe pour les containers Docker et les CI/CD pipelines. Si tu te retrouves à vouloir l'activer sur ton poste, c'est que tes règles granulaires sont mal configurées. Affine les règles plutôt que de tout ouvrir.

Revois tes permissions régulièrement. Les besoins changent. Un projet qui n'avait besoin que de src/ peut maintenant toucher config/. Fais un audit rapide de ton .claude/settings.json tous les mois. Supprime les règles obsolètes. Ajoute les protections pour les nouveaux dossiers sensibles.

Meydeey — Architecte IA & Automatisation

+110 entrepreneurs formés au Vibe Coding et à l'automatisation IA avec N8N. Fondateur du Labo IA.