Claude Code : règles de permissions pour toute l’équipe

Pour déployer Claude Code dans une équipe, commencez par un fichier .claude/settings.json versionné qui contient peu de règles allow (lint, tests), quelques règles deny (fichiers de secrets) et un permissions.defaultMode choisi sciemment : en novembre 2026, le mode de départ intégré des sessions interactives (version 2.1.283 et plus) est auto, et le mode manuel s’obtient avec la valeur default. Ensuite, l’organisation verrouille le reste avec des paramètres gérés. Voici comment la documentation de Claude Code décrit ces mécanismes (état en novembre 2026) et ce que nous vérifierions d’abord.

Comment Claude Code décide-t-il de demander la permission?

Le tableau de la documentation décrit le mode manuel. Dans ce mode, la lecture de fichiers dans le répertoire de travail ne demande rien. Les commandes Bash et les modifications de fichiers demandent une approbation, sauf pour un petit ensemble de commandes en lecture seule. Les recherches web demandent aussi une approbation, tout comme WebFetch, sauf pour un ensemble de domaines de documentation préapprouvés.

Trois types de règles ajustent ce comportement : allow, ask et deny. L’ordre compte. La documentation précise que les règles sont évaluées dans l’ordre « deny, puis ask, puis allow », et que la première correspondance décide, peu importe la précision de la règle.

1. 1Règles deny
2. 2Règles ask
3. 3Règles allow
4. 4Mode et approbation

La première règle qui correspond détermine le résultat (documentation Claude Code, novembre 2026).

Conséquence pratique : une règle large comme Bash(aws *) dans deny bloque aussi aws s3 ls, même si une règle allow plus précise existe. Une règle allow ne peut pas faire exception à un deny. Concevez donc vos règles par catégorie : refus étroits, demandes ciblées, autorisations pour les commandes banales.

Quelles règles écrire en premier?

Un point de départ réaliste pour un dépôt SaaS :

• allow : les commandes de vérification que les développeurs lancent à longueur de journée, par exemple Bash(npm run lint) et Bash(npm run test *).
• deny : la lecture des fichiers de secrets, par exemple Read(./.env) et Read(./.env.*). Ces deux exemples figurent dans la page des paramètres.
• ask : les actions difficiles à annuler, comme Bash(git push *).

Placez l’astérisque après la sous-commande. Selon la documentation, Bash(git log *) n’autorise que les commandes git log, alors que Bash(git *) autorise toutes les commandes git. L’espace avant l’astérisque final compte : Bash(ls *) ne correspond pas à lsof, mais Bash(ls*) oui.

Pourquoi une règle Bash n’est-elle pas une frontière de sécurité?

Parce qu’elle compare le texte de la commande telle que Claude l’écrit. La documentation donne des exemples : Bash(curl *) bloque curl https://example.com, mais pas /usr/bin/curl https://example.com ni sh -c 'curl ...'. De même, Bash(git push *) ne couvre pas git -C . push origin main.

Claude Code gère les commandes composées (&&, ||, ;, |) : chaque sous-commande doit être autorisée. Il retire aussi quelques enveloppes comme timeout ou nohup avant la comparaison. Mais les règles qui contraignent les arguments, comme limiter curl à certaines URL, sont fragiles selon la documentation.

Que retenir? À notre avis, les règles servent surtout à réduire les demandes d’approbation et les erreurs, et la documentation les décrit comme un contrôle sur la commande telle qu’écrite. Pour limiter l’endroit où les commandes shell écrivent, la documentation renvoie au bac à sable (sandboxing). Elle indique aussi que le mode bypassPermissions ne devrait servir que dans des environnements isolés, comme des conteneurs ou des machines virtuelles.

Où mettre les règles pour que toute l’équipe les ait?

Claude Code lit quatre fichiers de paramètres, plus la ligne de commande pour une session. Voici la portée des fichiers :

La précédence, de la plus forte à la plus faible : paramètres gérés, ligne de commande, projet local, projet partagé, utilisateur. Les listes comme permissions.allow ne s’écrasent pas : elles se fusionnent entre les fichiers.

Deux détails évitent des surprises :

• Les règles allow du fichier partagé n’entrent en vigueur qu’après que chaque développeur a accordé sa confiance au dossier. Les règles deny et ask, elles, s’appliquent tout de suite. Attention aux exécutions sans interface (claude -p, SDK), qui n’affichent jamais ce dialogue de confiance : ces règles allow n’y sont pas appliquées.
• Les valeurs auto et bypassPermissions de permissions.defaultMode sont ignorées dans les fichiers de projet. En revanche, default (le mode manuel) peut être défini dans le fichier partagé. Les deux autres se règlent dans les paramètres utilisateur ou gérés.

Comment verrouiller ce qui ne doit pas bouger?

Les paramètres gérés se déploient par la console claude.ai, une politique MDM ou un fichier système, et personne ne peut les contourner depuis ses propres fichiers. Selon la documentation (permissions et paramètres), vous pouvez notamment :

• désactiver les modes à risque avec permissions.disableBypassPermissionsMode et permissions.disableAutoMode réglés à "disable";
• n’appliquer que les règles gérées avec allowManagedPermissionRulesOnly;
• empêcher les outils Write, Edit et NotebookEdit d’écrire hors du répertoire de travail avec permissions.blockWritesOutsideWorkingDirectories, une clé ajoutée dans la version 2.1.314 de Claude Code (journal des changements). La documentation précise que cette clé ne limite pas les commandes shell, les outils MCP ni les programmes lancés par les hooks.

Cette dernière clé est particulière : une valeur true posée à n’importe quel niveau est respectée, même si une source gérée dit false. Une équipe peut donc ajouter cette restriction dans son propre fichier, sans attendre l’administrateur.

Que vérifier avant d’étendre l’adoption?

1. Lancez /status dans une session : la ligne des sources de paramètres montre quels fichiers sont réellement chargés.
2. Relisez le fichier partagé comme du code : chaque allow ajouté est un changement de risque. Passez-le en revue par demande de tirage.
3. Testez les contournements : essayez la même commande avec un chemin absolu ou dans sh -c, et notez ce que vos règles laissent passer.
4. Regardez l’environnement : quels secrets et quels accès le poste ou le conteneur où l’agent travaille expose-t-il?
5. Mesurez les demandes d’approbation : si les développeurs répondent « oui » sans lire, trop d’actions demandent une approbation : ajoutez des allow précis. S’ils contournent les règles, vos deny et ask sont peut-être trop larges.

Chez Korvaed, nous commencerions par cet inventaire : quels secrets sont lisibles depuis le poste, quelles commandes sont irréversibles, quels paramètres sont déjà gérés. Puis nous écririons le fichier partagé le plus court possible. Si vous voulez un avis senior sur l’adoption des agents de code dans votre équipe, voyez notre offre de CTO fractionnel.

Information générale, pas un avis de sécurité. Les fonctions et versions de Claude Code évoluent vite : confirmez-les dans la documentation officielle et consultez un professionnel de la sécurité avant de déployer.