Permissions Claude Code en équipe : décider avant le pilote

Pour choisir les permissions d'un pilote Claude Code, décidez tâche par tâche ce qui s'exécute sans validation, ce qui demande un accord et ce qui reste interdit, puis écrivez ces choix dans un fichier partagé et relu. Une consigne dans CLAUDE.md ne suffit pas : la documentation officielle précise que les règles de permission sont appliquées par Claude Code, pas par le modèle. Les instructions orientent ce que Claude tente ; elles ne changent pas ce que Claude Code autorise.

Ce guide s'adresse au responsable technique qui prépare un essai à plusieurs. Il propose une matrice de décision, un fichier de départ et des critères d'acceptation. Il s'appuie sur la documentation consultée le 9 octobre 2026 ; il ne rapporte ni test client ni résultat chiffré. Pour la mécanique générale des fichiers de réglages, voyez d'abord notre guide de configuration Claude Code.

1. Vérifier le mode dans lequel les sessions démarrent

Première décision, souvent oubliée : le mode de permission. Selon la documentation, depuis la version 2.1.283, une session lancée dans un terminal ou depuis l'extension VS Code démarre par défaut en mode auto, lorsque ce mode est disponible et qu'aucun réglage n'en choisit un autre. Dans ce mode, les validations courantes disparaissent : avant l'exécution d'actions comme les commandes shell ou les requêtes réseau, un classifieur vérifie en arrière-plan qu'elles correspondent à votre demande.

Ce n'est pas forcément le bon point de départ pour une équipe qui découvre l'outil. Choisissez le mode selon ce que le pilote doit vous apprendre :

Trois précisions comptent pour une politique d'équipe :

• Le dépôt peut fixer un mode prudent, pas un mode permissif. "defaultMode": "default" dans .claude/settings.json fait démarrer en Manual les sessions terminal du projet. En revanche, les valeurs auto et bypassPermissions ne prennent pas effet depuis les réglages du projet ou les réglages locaux. Attention : l'extension VS Code ne lit pas les réglages du projet pour choisir le mode de départ.
• Un mode de départ n'est pas un verrou. Même fixé par l'organisation, il laisse chacun basculer ensuite vers le mode auto. Pour retirer ce mode, l'organisation positionne permissions.disableAutoMode à "disable".
• Le mode sans contrôle se désactive aussi. Dans le bloc permissions, la clé disableBypassPermissionsMode à "disable" empêche bypassPermissions. Ces deux clés fonctionnent depuis n'importe quel fichier, mais elles sont surtout utiles dans les réglages gérés, que les utilisateurs ne peuvent pas surcharger.

2. Répartir les décisions entre organisation, dépôt et poste

Claude Code combine plusieurs niveaux de réglages. Pour un pilote, donnez un propriétaire à chacun :

Quatre règles de combinaison, tirées de la documentation, structurent la politique :

• Une interdiction l'emporte partout. Les règles sont évaluées dans l'ordre deny, puis ask, puis allow, et la première correspondance décide. Un deny posé à un niveau n'est levé par aucun allow d'un autre niveau.
• Les autorisations s'additionnent. Les listes permissions.allow des différents fichiers se cumulent au lieu de se remplacer, sauf si l'organisation active allowManagedPermissionRulesOnly.
• Les autorisations du dépôt attendent la confiance. Les règles allow d'un .claude/settings.json ne s'appliquent qu'après acceptation, par chaque participant, de la boîte de dialogue de confiance du dossier. Les règles deny et ask s'appliquent immédiatement.
• Les « ne plus demander » restent locaux. Pour une commande Bash ou un domaine web, répondre « Yes, and don't ask again » enregistre une règle allow dans .claude/settings.local.json, que Claude Code garde hors des commits. Cette règle ne prime pas sur un ask du projet ou de l'organisation.

Conséquence pratique : ce qui doit valoir pour tous se place en deny ou en ask, dans le fichier partagé ou dans les réglages gérés. Les allow servent à fluidifier le travail, en sachant que chaque poste peut en ajouter localement.

3. La matrice : une ligne par tâche, pas par outil

Raisonner outil par outil (« autoriser Bash ? ») mène à des réglages trop larges ou trop bloquants. Partez plutôt des tâches que le pilote doit couvrir, des systèmes qu'elles touchent et de la preuve qui permettra d'accepter le résultat. Voici la grille que nous proposons, à adapter à votre dépôt :

Deux colonnes font la différence avec une simple liste de règles. « Qui valide » évite qu'une autorisation large entre dans le fichier partagé sans arbitrage. « Retour arrière » oblige à vérifier, avant d'ouvrir un accès, que ses effets peuvent être annulés. Les cases vides de cette dernière colonne signalent les accès à ne pas ouvrir pendant le pilote.

Si une tâche ne demande que de la relecture, un subagent de revue en lecture seule restreint les outils pour cette mission précise, sans changer les droits de la conversation principale.

4. Un fichier de départ pour le dépôt du pilote

Voici une traduction de la matrice pour un projet Node.js. Le fichier est valide en JSON ; adaptez les commandes à vos scripts réels avant de le versionner dans .claude/settings.json.

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm install *)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)",
      "Bash(curl *)",
      "Bash(wget *)",
      "mcp__*"
    ]
  }
}

Ce que fait chaque bloc, selon la syntaxe documentée :

• allow : Bash(npm run test *) couvre aussi la commande seule npm run test, car une étoile finale précédée d'un espace inclut la commande nue. Placez l'étoile après la sous-commande : Bash(npm *) autoriserait toutes les commandes npm.
• ask : la correspondance porte sur le texte écrit. Bash(npm install *) ne vise donc pas l'abréviation npm i. Listez les variantes que votre équipe utilise.
• deny : un nom de fichier seul, comme .env, s'applique à toute profondeur sous le répertoire courant. Dans les versions récentes, une interdiction de lecture bloque aussi la modification et l'écriture de ce chemin. Enfin, mcp__* en interdiction retire tous les outils MCP.

5. Ce que ces règles ne garantissent pas

La documentation est explicite : une règle Bash ne constitue pas une frontière de sécurité autour d'un programme. Elle couvre la forme de commande que Claude produit habituellement, pas toutes les manières d'appeler le même programme.

De même, les interdictions de lecture s'appliquent aux outils de fichiers de Claude et aux commandes Bash reconnues comme cat ou head. Elles ne couvrent pas un script Python ou Node qui ouvre lui-même un fichier. C'est pourquoi la matrice exclut les secrets réels du dépôt du pilote, plutôt que de compter sur une règle seule.

Pour une protection qui ne dépend pas du texte de la commande, la documentation renvoie au sandbox : il restreint au niveau du système l'accès aux fichiers et au réseau des commandes shell et de leurs processus enfants. Pour appliquer votre propre logique avant chaque appel d'outil, un hook PreToolUse peut refuser une action ; notre tutoriel sur les hooks Claude Code montre la structure d'un script de contrôle. Un hook ne contourne pas vos interdictions : les règles deny et ask restent évaluées quoi qu'il réponde.

Deux protections existent sans configuration. Les écritures dans certains dossiers sensibles, dont .git, .claude, .vscode et .husky, ne sont jamais approuvées automatiquement en dehors de bypassPermissions et de cas particuliers du mode plan : elles sont soumises à validation en Manual et acceptEdits, examinées par le classifieur en mode auto et refusées en dontAsk. Une règle allow ne les préautorise pas. À l'inverse, bypassPermissions lève ces protections : la documentation rappelle qu'il n'offre aucune protection contre l'injection de prompt ou les actions non voulues.

Enfin, la protection de la branche principale chez votre hébergeur de code reste votre dernier contrôle avant production. Elle ne dépend ni de l'assistant ni du poste.

6. Accepter la configuration, puis la faire évoluer

Avant le premier jour, faites vérifier la configuration par une personne qui ne l'a pas écrite :

1. Dans Claude Code, ouvrez /permissions. La boîte de dialogue liste chaque règle et le fichier dont elle provient. Comparez-la à la matrice.
2. Lancez /status. La ligne des sources de réglages indique si des réglages gérés par l'organisation s'appliquent.
3. Faites trois essais sur un dépôt d'exercice, avec un fichier .env contenant une valeur fictive : demander sa lecture doit être refusé, une demande de git push doit déclencher une validation, et les tests doivent se lancer sans interruption. Notez le résultat obtenu dans votre version ; ce protocole est à exécuter chez vous, nous n'en publions pas de résultat.
4. Notez le mode affiché au démarrage sur chaque type de poste et d'interface utilisée par l'équipe.

Pendant le pilote, consacrez un point hebdomadaire de quinze minutes aux permissions :

Chaque validation affichée mobilise l'attention d'une personne. Comptez ces interruptions dans le temps humain du pilote, comme le propose notre grille de budget d'un pilote Claude Code : une politique trop stricte se voit dans ce poste, une politique trop large dans les incidents.

Si vous comparez un autre assistant de code, reprenez la même matrice de tâches. Ses modes, ses fichiers et son ordre de priorité ne se transposent pas : relisez sa propre documentation avant de reporter une décision.

La politique d'une page

À la fin de la préparation, tenez sur une page : mode de départ et modes désactivés, propriétaire de chaque niveau de réglages, matrice des tâches, règles du fichier partagé, exceptions locales tolérées, essais d'acceptation et date de la prochaine revue.

Une bonne politique de permissions n'est pas celle qui supprime toutes les demandes. C'est celle dont chaque accès a un propriétaire, une preuve d'acceptation et un retour arrière connu.

Pour définir cette politique avec vos équipes et l'intégrer à vos processus de livraison, notre accompagnement à l'intégration IA est le point d'entrée adapté. Pour former les personnes qui maintiendront ces réglages, consultez notre formation Claude Code.

Sources et limites

• Claude Code : configurer les permissions, consultée le 9 octobre 2026 : ordre d'évaluation, syntaxe des règles, limites des règles Bash, règles de lecture, hooks, sandbox, confiance du dossier.
• Claude Code : choisir un mode de permission, consultée le 9 octobre 2026 : modes disponibles, mode de départ, chemins protégés.
• Claude Code : fichiers de réglages et priorité, consultée le 9 octobre 2026 : niveaux de réglages, fusion des listes, fichier local.
• La matrice, le point hebdomadaire et les critères d'acceptation sont une méthode proposée par Kairia. Le fichier JSON a été vérifié syntaxiquement ; son comportement n'a pas été exécuté pour cet article et dépend de votre version de Claude Code.