Contrôles d'administration Claude Code : guide complet pour les équipes IT et DevOps (2026)
Rama Adi Nugraha
Katelin Teen
Dernière modification June 9, 2026
Pourquoi Claude Code a besoin de contrôles d'administration
Lorsque vous déployez un agent de codage dans une organisation d'ingénierie, le profil de risque est différent de celui du déploiement d'un outil de chat. Claude Code peut exécuter des commandes shell, lire des fichiers dans une base de code entière, ouvrir des pull requests et — avec les bonnes permissions — accéder à internet ou écrire dans des fichiers de secrets. Sans contrôles, deux modes d'échec apparaissent : les développeurs s'installent dans une utilisation prudente et confirment chaque action manuellement, ou ils accordent des permissions générales et se retrouvent avec un agent qui peut techniquement tout faire.
Aucune de ces deux options n'est ce que vous voulez. Ce que vous voulez réellement, c'est quelque chose de similaire à Group Policy pour l'IA : vous définissez ce que l'outil est autorisé à faire au niveau organisationnel, les développeurs obtiennent un environnement productif dans ces limites, et vous disposez d'une capacité d'audit si quelque chose tourne mal.
C'est pour cela que les contrôles d'administration de Claude Code sont conçus. Parcourons chaque couche du système.
La hiérarchie de configuration à quatre niveaux
Chaque paramètre de Claude Code est résolu via une pile de priorité. De la priorité la plus haute à la plus basse :
- Managed — déployé par l'IT, priorité maximale, ne peut être remplacé par rien
- Arguments CLI — remplacements pour la session uniquement (
--model sonnet,--permission-mode plan) - Projet local (
.claude/settings.local.json) — remplacements personnels pour ce dépôt, dans gitignore - Projet partagé (
.claude/settings.json) — partagé par l'équipe, validé dans git - Utilisateur (
~/.claude/settings.json) — valeurs par défaut globales personnelles
La couche gérée est le plafond et les paramètres utilisateur sont le plancher. Les paramètres de projet sont l'endroit où les équipes standardisent les outils. Les paramètres à valeur de tableau comme permissions.allow se fusionnent entre les portées plutôt que de se remplacer mutuellement — une règle allow dans les paramètres utilisateur s'empile avec une règle allow dans les paramètres de projet. Les valeurs scalaires suivent la règle du gagnant-prend-tout depuis la portée la plus haute qui les définit.
Une nuance à connaître : le mode auto est ignoré lorsqu'il est défini dans des paramètres de projet ou locaux à partir de la v2.1.142. Si vous définissez defaultMode: "auto" dans une configuration de projet et vous demandez pourquoi cela n'a aucun effet, voilà pourquoi — cela doit provenir des paramètres utilisateur ou gérés.
Déployer les paramètres gérés
Quatre mécanismes de livraison, tous lisant le même format JSON :
Géré par serveur (Teams/Enterprise) : Poussez les paramètres depuis la console d'administration dans claude.ai. Nécessite un plan Claude for Teams ou Enterprise. Utilisez forceRemoteSettingsRefresh: true pour bloquer le démarrage de la session jusqu'à ce que le push soit confirmé — utile lorsque votre mise à jour de politique doit prendre effet avant que tout développeur puisse continuer à travailler.
MDM macOS (Jamf, Kandji, Mosyle) : Déployez un profil de configuration ciblant le domaine plist com.anthropic.claudecode. Les clés de niveau supérieur reflètent les noms de champs JSON ; les paramètres imbriqués utilisent des dictionnaires plist, les tableaux utilisent des tableaux plist. Approche standard pour les organisations qui gèrent déjà des Macs avec MDM.
Windows Group Policy / Intune : Écrivez du JSON dans HKLM\SOFTWARE\Policies\ClaudeCode avec une valeur Settings de type REG_SZ. Déployez via un objet de stratégie de groupe ou un profil de configuration Intune. Pour la politique uniquement au niveau utilisateur (lorsqu'aucune source de niveau administrateur n'est présente), utilisez HKCU\SOFTWARE\Policies\ClaudeCode.
Basé sur des fichiers : Déposez managed-settings.json dans :
- macOS :
/Library/Application Support/ClaudeCode/ - Linux / WSL :
/etc/claude-code/ - Windows :
C:\Program Files\ClaudeCode\
Le mode basé sur des fichiers prend également en charge un répertoire drop-in managed-settings.d/ au même emplacement. Les fichiers sont triés alphabétiquement et fusionnés profondément — les scalaires des fichiers ultérieurs l'emportent, les tableaux sont concaténés et dédupliqués. Utile si plusieurs outils de sécurité ou équipes doivent contribuer des fragments de politique séparés sans s'écraser mutuellement.
Pour une politique dynamique dérivée de la posture de l'appareil ou d'un service de conformité distant, la clé policyHelper pointe vers un exécutable qui calcule les paramètres JSON au démarrage. Le binaire écrit une enveloppe JSON (avec les paramètres sous une clé managedSettings) sur stdout, et Claude Code la récupère avant le démarrage de la session. Disponible depuis la v2.1.136.
Pour vérifier ce qui est actif, exécutez /status dans Claude Code. L'onglet Statut affiche une ligne Setting sources répertoriant chaque couche active, avec le canal de livraison entre parenthèses : Enterprise managed settings (remote), (plist), (HKLM), (file).
Permissions : règles allow, ask et deny
Le système de permissions exprime ce que Claude peut faire sans demander et ce qu'il ne peut pas toucher du tout. Trois types de règles :
- Allow — Claude exécute l'outil automatiquement, sans invite
- Ask — Claude invite le développeur avant d'exécuter (par défaut pour la plupart des outils)
- Deny — Claude ne peut pas utiliser l'outil du tout
Les règles suivent le format Tool ou Tool(specifier). Un deny simple comme "Bash" supprime l'outil entier du contexte de Claude, de sorte que Claude n'essaie jamais de l'utiliser. Un deny délimité comme "Bash(rm *)" maintient l'outil disponible mais bloque les appels correspondants à l'exécution.
L'ordre d'évaluation est toujours deny en premier, puis ask, puis allow — et la première règle correspondante l'emporte quel que soit le périmètre dont elle provient. Un deny dans les paramètres utilisateur bloque un allow au niveau projet. Un deny géré ne peut être déverrouillé par aucune portée inférieure.
Une base pratique dans .claude/settings.json pour un environnement d'équipe :
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)",
"Bash(git diff *)",
"Bash(git log *)",
"Bash(git status)",
"Bash(git stash *)"
],
"deny": [
"Bash(curl *)",
"Bash(wget *)",
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"WebFetch"
]
}
}
Cela approuve automatiquement les commandes de développement courantes tout en bloquant les outils réseau et les lectures de fichiers sensibles.
Modèles de règles de permission à connaître
Les wildcards correspondent à travers les arguments. Bash(npm run *) correspond à npm run test --watch — le * s'étend sur plusieurs arguments y compris les espaces. Bash(git *) correspond à git log --oneline --all. Un espace avant * impose une limite de mot : Bash(ls *) correspond à ls -la mais pas à lsof.
Le curl contraint par URL est fragile. Bash(curl http://github.com/ *) échoue avec curl -X GET http://github.com/... (options avant l'URL), curl https://github.com/... (protocole différent), ou des variables d'environnement contenant l'URL. Pour une restriction de domaine fiable, utilisez WebFetch(domain:github.com) pour les domaines autorisés et refusez entièrement les outils réseau Bash. L'explication complète se trouve dans la référence des permissions.
Les commandes composées sont divisées avant la correspondance. Une règle allow pour npm test ne couvre pas npm test && curl evil.com. Claude Code divise sur &&, ||, ;, | et vérifie chaque sous-commande indépendamment.
Les modèles Read/Edit suivent la syntaxe gitignore. Read(./.env) et Read(**/.env) sont équivalents — les deux bloquent tout .env dans ou sous le répertoire actuel. Utilisez Read(//**/.env) pour bloquer les fichiers .env n'importe où sur le système de fichiers.
Modes de permission
Six modes de permission changent la façon dont les appels d'outils non correspondants sont gérés :
| Mode | Ce qu'il fait |
|---|---|
default | Inviter à la première utilisation de chaque outil |
acceptEdits | Approuver automatiquement les modifications de fichiers et les commandes de système de fichiers sûres |
plan | Lecture seule — pas de modifications de fichiers |
auto | Les vérifications de sécurité en arrière-plan approuvent automatiquement les appels alignés (aperçu de recherche) |
dontAsk | Refus automatique sauf si pré-approuvé via des règles allow |
bypassPermissions | Ignorer toutes les invites — pour les conteneurs/VM isolés uniquement |
Définissez defaultMode dans les paramètres pour verrouiller le mode de démarrage. Pour empêcher le mode bypassPermissions de jamais s'activer, ajoutez à vos paramètres gérés :
{
"permissions": {
"disableBypassPermissionsMode": "disable"
}
}
Cela ferme complètement le flag --dangerously-skip-permissions — les développeurs voient une erreur s'ils essaient de l'utiliser. Même modèle pour le mode auto : "disableAutoMode": "disable".
Paramètres uniquement gérés : les contrôles de verrouillage réservés aux administrateurs
Plusieurs paramètres ne prennent effet que lorsqu'ils sont déployés via des paramètres gérés. Les placer dans des fichiers utilisateur ou de projet n'a aucun effet — ils sont véritablement réservés aux administrateurs :
| Paramètre | Ce qu'il applique |
|---|---|
allowManagedPermissionRulesOnly | Empêche les paramètres utilisateur et de projet de définir des règles allow/ask/deny. Seules les règles gérées s'appliquent. |
allowManagedHooksOnly | Seuls les hooks des paramètres gérés ou des plugins activés de force s'exécutent. Les hooks utilisateur et de projet sont bloqués. |
allowManagedMcpServersOnly | Seuls les serveurs MCP dans allowedMcpServers des paramètres gérés sont utilisés. |
strictKnownMarketplaces | Contrôle quels marketplaces de plugins les utilisateurs peuvent ajouter. Un tableau vide bloque toutes les nouvelles additions de marketplaces. |
strictPluginOnlyCustomization | Force les compétences, agents, hooks et/ou serveurs MCP à provenir uniquement de plugins. |
forceLoginMethod | Restreindre la connexion aux comptes claudeai ou aux comptes console. |
forceLoginOrgUUID | Exiger la connexion à un UUID d'organisation Anthropic spécifique. |
requiredMinimumVersion | Bloquer le démarrage si la version de Claude Code est inférieure à ceci. |
requiredMaximumVersion | Bloquer le démarrage si la version de Claude Code est supérieure à ceci. |
claudeMd | Injecter des instructions à l'échelle de l'organisation qui apparaissent dans chaque session. |
channelsEnabled | Activer ou désactiver les canaux (intégrations) à l'échelle de l'organisation. |
forceRemoteSettingsRefresh | Bloquer le démarrage jusqu'à ce que les paramètres gérés soient fraîchement récupérés depuis le serveur. |
La combinaison de allowManagedPermissionRulesOnly: true + allowManagedHooksOnly: true vous donne un périmètre solide : aucun développeur ne peut élargir ce que Claude est autorisé à faire au-delà de ce que vos paramètres gérés définissent. Tout passe par des règles et des hooks approuvés par l'IT, rien de plus.
Sandbox : isolement du système de fichiers et du réseau au niveau du système d'exploitation
Le sandbox est une couche de sécurité séparée des permissions. Les permissions régissent ce que Claude essaie de faire. Le sandbox applique ce que les commandes Bash peuvent réellement atteindre au niveau du système d'exploitation — en utilisant l'isolation de processus native de macOS (Seatbelt) et Linux seccomp/namespaces pour appliquer les limites de lecture/écriture du système de fichiers et les règles d'accès réseau.
Une configuration sandbox de base pour une machine de développeur :
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"filesystem": {
"denyRead": [
"~/.aws/credentials",
"~/.ssh/id_rsa",
"~/.ssh/id_ed25519"
],
"allowWrite": ["/tmp/build", "~/.kube"]
},
"network": {
"allowedDomains": [
"github.com",
"*.npmjs.org",
"registry.yarnpkg.com",
"api.anthropic.com"
]
}
}
}
Avec autoAllowBashIfSandboxed: true (la valeur par défaut), les commandes Bash qui restent dans les limites du sandbox s'exécutent sans invite — la limite du sandbox se substitue aux boîtes de dialogue de confirmation par commande. Les développeurs bénéficient d'un flux plus rapide ; vous obtenez l'application des règles.
Trois flags sandbox réservés aux administrateurs valent la peine d'être connus pour les environnements plus stricts :
sandbox.network.allowManagedDomainsOnly: true— seuls les domaines dansallowedDomainsgérés sont accessibles ; les ajouts au niveau du projet sont ignoréssandbox.filesystem.allowManagedReadPathsOnly: true— seuls les cheminsfilesystem.allowReadgérés sont respectéssandbox.network.allowUnixSockets— requis sur macOS pour permettre l'accès au socket Docker (/var/run/docker.sock)
Le sandbox s'applique uniquement aux commandes Bash et à leurs processus enfants. Il ne restreint pas les outils Read/Write intégrés de Claude — ceux-ci sont régis par les règles de permission ci-dessus. Utilisez les deux couches ensemble pour la défense en profondeur : les règles de permission empêchent Claude d'essayer d'accéder sans autorisation, et le sandbox empêche tout ce qui passe à travers au niveau du système d'exploitation.
Pour les environnements de conteneurs, CI et WSL, consultez le guide de sandboxing d'Anthropic — la configuration diffère dans ces environnements.
Hooks pour l'application des politiques
Les Hooks sont des commandes shell, des endpoints HTTP ou des prompts évalués par LLM qui se déclenchent à des points de cycle de vie spécifiques. Pour l'usage administratif, PreToolUse est l'événement clé : il se déclenche avant tout appel d'outil et peut bloquer l'appel avant qu'il ne se produise — même si une règle allow l'autoriserait autrement.
Un hook de sécurité basé sur shell qui bloque les commandes destructives :
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "/usr/local/bin/claude-security-check.sh",
"args": []
}
]
}
]
}
}
Le hook reçoit l'appel d'outil complet au format JSON sur stdin. Pour bloquer :
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "deny",
"permissionDecisionReason": "rm -rf bloqué par la politique de sécurité de l'organisation"
}
}
Le code de sortie 0 sans sortie signifie « aucune décision » — le flux normal de permissions continue. Le hook peut refuser, mais le silence n'approuve pas.
Pour une politique centralisée basée sur HTTP, utilisez type: "http" pour envoyer des événements d'appels d'outils à votre service de sécurité et lire la décision dans la réponse. Cela permet à une équipe centrale d'exécuter l'évaluation des politiques sans distribuer des scripts shell à chaque machine de développeur.
Deux autres événements utiles pour la gouvernance :
ConfigChange— se déclenche lorsqu'un fichier de paramètres change en cours de session. Utilisez-le pour détecter quand les développeurs modifient leurs règles de permission pendant une session, et postez sur votre SIEM ou Slack pour la visibilité.SessionStart— se déclenche à l'ouverture de la session. Utile pour injecter des métadonnées d'audit, vérifier les exigences de version, ou confirmer que l'utilisateur est sur le réseau avant d'autoriser des opérations sensibles.
Avec allowManagedHooksOnly: true dans les paramètres gérés, seuls les hooks déployés via votre canal géré s'exécutent. Les hooks écrits par les développeurs dans le projet .claude/settings.json sont silencieusement ignorés. Consultez la référence complète des hooks pour tous les événements disponibles.
Configuration réseau et proxy
Pour les environnements qui acheminent le trafic via un proxy d'entreprise, Claude Code lit les variables d'environnement proxy standard :
HTTPS_PROXY=https://proxy.example.com:8080
HTTP_PROXY=http://proxy.example.com:8080
NO_PROXY="localhost,192.168.1.1,.internal.example.com"
Définissez-les dans le bloc env des paramètres gérés pour qu'ils s'appliquent à chaque session sans configuration du développeur :
{
"env": {
"HTTPS_PROXY": "https://proxy.example.com:8080",
"NO_PROXY": "localhost,.internal.example.com"
}
}
Pour l'inspection TLS d'entreprise (CrowdStrike Falcon, Zscaler), Claude Code fait confiance à la fois à son ensemble CA Mozilla intégré et au magasin de certificats du système d'exploitation par défaut. Si votre proxy utilise une CA personnalisée qui n'est pas dans le magasin du système d'exploitation :
{
"env": {
"NODE_EXTRA_CA_CERTS": "/etc/ssl/certs/enterprise-ca.pem"
}
}
Pour l'authentification TLS mutuelle :
{
"env": {
"CLAUDE_CODE_CLIENT_CERT": "/etc/ssl/certs/claude-client.pem",
"CLAUDE_CODE_CLIENT_KEY": "/etc/ssl/private/claude-client-key.pem"
}
}
Votre liste d'autorisation de pare-feu nécessite au minimum ces URLs :
| URL | Requis pour |
|---|---|
api.anthropic.com | Appels à l'API Claude |
claude.ai | Authentification du compte Claude.ai |
platform.claude.com | Authentification du compte console |
downloads.claude.ai | Téléchargements de plugins et mise à jour automatique |
bridge.claudeusercontent.com | Extension Claude in Chrome |
raw.githubusercontent.com | Notes de version et marketplace de plugins |
Lors du déploiement via Amazon Bedrock, Google Vertex AI ou Microsoft Foundry, le trafic du modèle va vers votre fournisseur de cloud plutôt que vers api.anthropic.com. Définissez CLAUDE_CODE_USE_BEDROCK=1 (ou l'équivalent) dans le bloc env et configurez ANTHROPIC_BEDROCK_BASE_URL si vous acheminez via une passerelle LLM. La configuration complète du fournisseur cloud se trouve dans le guide des intégrations tierces d'Anthropic.
Gouvernance MCP et plugins
Les serveurs MCP étendent Claude avec des intégrations d'outils externes — Jira, Notion, GitHub, bases de données internes. Du point de vue de la gouvernance, le risque est que les développeurs se connectent à des serveurs non fiables ou installent des plugins de marketplace non vérifiés.
Contrôler l'accès MCP via les paramètres gérés :
{
"allowedMcpServers": [
{ "serverName": "github" },
{ "serverName": "jira" }
],
"deniedMcpServers": [
{ "serverName": "filesystem" }
],
"allowManagedMcpServersOnly": true
}
Avec allowManagedMcpServersOnly: true, les fichiers .mcp.json de projet sont ignorés — seuls les serveurs dans la liste d'autorisation gérée s'exécutent. Les entrées de liste de refus se fusionnent toujours depuis toutes les portées, de sorte que n'importe quelle portée peut bloquer un serveur même lorsque la liste d'autorisation est en vigueur.
Contrôler les marketplaces de plugins :
{
"strictKnownMarketplaces": [
{ "source": "github", "repo": "acme-corp/approved-claude-plugins" }
],
"blockedMarketplaces": [
{ "source": "github", "repo": "untrusted-org/plugins" }
]
}
strictKnownMarketplaces avec une liste spécifique signifie que les développeurs ne peuvent ajouter que des marketplaces sur cette liste. Un tableau vide [] bloque complètement toutes les nouvelles additions de marketplaces. blockedMarketplaces est appliqué avant les opérations réseau ou de système de fichiers — les sources bloquées ne touchent jamais le disque.
strictPluginOnlyCustomization va plus loin, exigeant que toutes les compétences, agents, hooks et serveurs MCP proviennent de plugins plutôt que de fichiers utilisateur ou de projet :
{
"strictPluginOnlyCustomization": ["skills", "hooks"]
}
Passez true pour verrouiller les quatre surfaces (compétences, agents, hooks, MCP) ou un tableau ne nommant que ceux que vous souhaitez verrouiller. Cela garantit que toute la personnalisation de Claude Code dans votre organisation passe par des plugins approuvés et distribués plutôt que par une configuration ad-hoc des développeurs. Consultez la vue d'ensemble du plugin Claude Code pour comprendre ce que le système de plugins permet.
CLAUDE.md comme contexte à l'échelle de l'organisation
Les fichiers CLAUDE.md sont la couche d'instructions — ils indiquent à Claude ce qu'il faut prioriser, tandis que les fichiers de paramètres définissent ce qu'il est autorisé à faire. Le paramètre géré claudeMd injecte des instructions à l'échelle de l'organisation dans chaque session, quel que soit le contenu de CLAUDE.md au niveau du projet :
{
"claudeMd": "Toujours exécuter `make lint` avant de valider. Ne jamais modifier les fichiers dans /vendor. Sécurité : utiliser des requêtes paramétrées, ne jamais enregistrer les credentials. Documentation interne sur wiki.internal/engineering."
}
Contrairement à un CLAUDE.md au niveau du projet que les développeurs pourraient remplacer localement, le claudeMd géré ne peut être exclu ni ignoré. C'est un canal fiable pour les standards de codage à l'échelle de l'organisation, les exigences de sécurité et les liens vers les ressources internes qui doivent être présentes dans chaque session.
Pour un contexte spécifique au projet, validez CLAUDE.md à la racine du dépôt — chaque collaborateur reçoit les mêmes instructions, et le guide de déploiement de Claude Code explique comment les structurer pour les grands monorepos. Le paramètre claudeMdExcludes vous permet de sauter les fichiers CLAUDE.md des répertoires vendor ou du code tiers que vous ne souhaitez pas polluer le contexte de Claude.
Surveiller l'utilisation de Claude Code
Claude Code exporte la télémétrie via OpenTelemetry, qui s'intègre à n'importe quelle pile compatible OTLP — Datadog, Honeycomb, Grafana :
{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp",
"OTEL_EXPORTER_OTLP_ENDPOINT": "https://your-collector:4318",
"OTEL_RESOURCE_ATTRIBUTES": "service.name=claude-code"
}
}
Les métriques disponibles incluent l'activité de session, les comptages d'utilisation des outils par type, l'utilisation du modèle et les taux d'erreur. Pour les sessions cloud, toutes les opérations sont enregistrées automatiquement pour la conformité.
Le hook ConfigChange (décrit ci-dessus) fournit des signaux en temps réel lorsque les fichiers de paramètres changent en cours de session. L'associer à votre SIEM donne une piste d'audit des modifications de configuration.
Pour les rapports d'utilisation au niveau de l'équipe, le blog usage-analytics-claude-code propose un guide complet sur la configuration des analyses d'utilisation de Claude Code, incluant les métriques OTLP disponibles et ce que chacune vous indique.
Teams vs Enterprise : ce que chaque plan ajoute pour les administrateurs
| Capacité | Teams | Enterprise |
|---|---|---|
| Paramètres de projet (.claude/settings.json) | Oui | Oui |
| Paramètres gérés basés sur MDM/fichier | Oui | Oui |
| Paramètres gérés par serveur (push de console admin) | Limité | Complet |
| SSO et capture de domaine | Non | Oui |
Application de forceLoginOrgUUID | Non | Oui |
| Paramètres de politique gérés à l'échelle de l'organisation | Partiel | Complet |
| Contrôle à distance et contrôles d'administration de session web | Oui | Oui |
| Accès à l'API de conformité (SOC 2 / ISO 27001) | Non | Oui |
| Tableau de bord d'utilisation centralisé | Oui | Oui |
| Support dédié / SLA | Non | Oui |
Pour le déploiement de Claude Code auprès d'équipes d'environ moins de 50 personnes, Claude for Teams avec des paramètres gérés basés sur fichiers ou MDM couvre généralement l'essentiel. Enterprise ajoute le SSO, forceLoginOrgUUID pour imposer l'appartenance à l'organisation, et des paramètres gérés par serveur poussés depuis une console centrale — la bonne option pour les organisations avec Active Directory, Okta ou une gestion des identités similaire, ou avec des exigences de conformité nécessitant la documentation du Anthropic Trust Center (SOC 2 Type 2, ISO 27001 tous deux certifiés à partir de 2026).
Le guide complet de Claude Code Enterprise couvre l'approvisionnement, le provisionnement des utilisateurs et les étapes de configuration SSO.
Un modèle de démarrage rapide pour les paramètres gérés
Voici un managed-settings.json de base qui couvre l'essentiel pour la plupart des organisations d'ingénierie soucieuses de la sécurité. Déployez-le dans /Library/Application Support/ClaudeCode/managed-settings.json (macOS), /etc/claude-code/managed-settings.json (Linux), ou poussez-le via MDM/Group Policy :
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)",
"Bash(git diff *)",
"Bash(git log *)",
"Bash(git status)",
"Bash(git stash *)",
"Bash(make *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(//home/**/.ssh/*)",
"Read(//root/.ssh/*)"
],
"disableBypassPermissionsMode": "disable"
},
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"filesystem": {
"denyRead": [
"~/.aws/credentials",
"~/.ssh/id_rsa",
"~/.ssh/id_ed25519",
"~/.ssh/id_ecdsa"
]
},
"network": {
"allowedDomains": [
"github.com",
"*.github.com",
"*.npmjs.org",
"registry.yarnpkg.com",
"api.anthropic.com",
"*.anthropic.com"
]
}
},
"claudeMd": "Suivre le CLAUDE.md du projet pour les standards de codage. Ne jamais enregistrer les credentials, tokens ou secrets. Utiliser des requêtes paramétrées. Documentation interne : wiki.internal/engineering",
"companyAnnouncements": [
"La politique Claude Code Enterprise s'applique à toutes les sessions. Questions : security@yourcompany.com"
],
"requiredMinimumVersion": "2.1.100",
"availableModels": ["opus", "sonnet", "haiku"]
}
Ce modèle ferme --dangerously-skip-permissions, bloque les lectures de clés SSH et de credentials AWS, active le sandbox avec Bash sandboxé approuvé automatiquement, restreint le réseau sortant aux domaines approuvés, injecte une politique de sécurité minimale, et fixe une version minimale.
Après avoir exécuté cela pendant une semaine et audité ce dont vos développeurs ont réellement besoin dans la liste d'autorisation, envisagez d'ajouter "allowManagedPermissionRulesOnly": true pour le verrouillage le plus strict possible. Ce paramètre est intentionnellement omis ici — il ne doit être ajouté qu'une fois que vous êtes sûr que la liste d'autorisation couvre le vrai flux de travail de votre équipe.
La référence complète settings.json couvre toutes les ~80 clés disponibles si vous avez besoin d'affiner davantage, et le guide des meilleures pratiques de Claude Code couvre la configuration côté développeur qui complète cette couche d'administration.
Essayez eesel.ai
Si vous réfléchissez attentivement à la gouvernance de l'IA pour votre organisation d'ingénierie, vous répondez probablement aux mêmes questions dans le support, les opérations et d'autres équipes. eesel.ai déploie des agents IA autonomes directement dans les outils que ces équipes utilisent déjà — Zendesk, Freshdesk, Slack, Jira et 100+ autres — avec la même approche que le système de permissions de Claude Code : les agents opèrent dans des limites claires que vous configurez, l'équipe reste maître de ce qu'ils peuvent et ne peuvent pas faire, et la configuration prend quelques minutes à partir de l'historique de connaissances existant. Pas de nouvelle interface à adopter, pas d'ingénierie de prompt requise.
Questions fréquemment posées
Quelle est la différence entre les paramètres gérés de Claude Code et les paramètres de projet ?
.claude/settings.json, sont validés dans git et s'appliquent à tous les collaborateurs du dépôt, mais peuvent être remplacés par des paramètres locaux ou utilisateur. Utilisez les paramètres gérés pour la politique de conformité ; utilisez les paramètres de projet pour les conventions d'équipe.Puis-je restreindre quels modèles Claude les développeurs peuvent utiliser dans Claude Code ?
availableModels à vos paramètres gérés pour limiter quels modèles les utilisateurs peuvent sélectionner via /model ou --model — par exemple ["sonnet", "haiku"] pour exclure Opus. Associez-le à la clé model pour définir une valeur par défaut spécifique à l'organisation. Pour les déploiements Bedrock ou Vertex, la variable d'environnement ANTHROPIC_DEFAULT_SONNET_MODEL fixe les versions exactes du modèle.Comment déployer les contrôles d'administration de Claude Code sur toutes les machines des développeurs ?
com.anthropic.claudecode), Windows Group Policy ou Intune (écriture de JSON dans HKLM\SOFTWARE\Policies\ClaudeCode), ou un fichier déposé dans /Library/Application Support/ClaudeCode/managed-settings.json sur macOS ou /etc/claude-code/managed-settings.json sur Linux. Les trois lisent le même format JSON. Pour les paramètres gérés par serveur sur les plans Team/Enterprise, utilisez la console d'administration.Que fait allowManagedPermissionRulesOnly dans les contrôles d'administration de Claude Code ?
true dans les paramètres gérés, cela empêche les paramètres utilisateur et projet de définir des règles allow, ask ou deny de permissions. Seules les règles de vos paramètres gérés s'appliquent. C'est le verrouillage de permissions le plus strict disponible — utile lorsque la politique de sécurité exige qu'aucun développeur ne puisse auto-autoriser un outil que Claude Code n'a pas été pré-approuvé à utiliser.
Comment empêcher les développeurs d'utiliser --dangerously-skip-permissions dans Claude Code ?
permissions.disableBypassPermissionsModesur"disable"dans vos paramètres gérés de Claude Code. Comme les paramètres gérés se trouvent au sommet de la pile de priorité, ils ne peuvent pas être remplacés par une configuration utilisateur ou projet, ni même par des arguments de ligne de commande. Consultez la référence des permissions d'Anthropic pour la syntaxe complète.