SSO, l’approvisionnement SCIM et l’attribution de sièges sont configurés au niveau du compte Claude. Consultez le Guide de l’administrateur Claude Enterprise et l’attribution de sièges pour ces étapes.
Choisir votre fournisseur d’API
Claude Code se connecte à Claude par l’intermédiaire de l’un de plusieurs fournisseurs d’API. Votre choix affecte la facturation, l’authentification, la posture de conformité que vous héritez et les fonctionnalités de Claude Code que vos développeurs peuvent utiliser.
Certaines fonctionnalités de Claude Code nécessitent un compte claude.ai. Claude Code sur le web, Routines, Révision de code, Contrôle à distance et l’extension Chrome ne sont pas disponibles via les clés API Console ou les identifiants des fournisseurs cloud seuls. Si vous déployez via Amazon Bedrock, Google Cloud’s Agent Platform ou Microsoft Foundry, planifiez si les développeurs ont également besoin de sièges Claude for Teams ou Enterprise. Chaque page de fonctionnalité répertorie ses exigences de plan.
Pour la comparaison complète des fournisseurs couvrant l’authentification, les régions et la parité des fonctionnalités, consultez l’aperçu du déploiement en entreprise. La configuration d’authentification de chaque fournisseur se trouve dans Authentification.
Les exigences de proxy et de pare-feu dans Configuration réseau s’appliquent quel que soit le fournisseur. Si vous voulez un point de terminaison unique devant plusieurs fournisseurs ou une journalisation centralisée des demandes, consultez Passerelle LLM.
Décider comment les paramètres atteignent les appareils
Les paramètres gérés définissent une politique qui prend précédence sur la configuration locale des développeurs. Claude Code vérifie les quatre sources ci-dessous dans l’ordre de priorité et applique la première qui retourne une configuration non vide, à une exception près : un petit ensemble de clés de verrouillage entre sources, telles que les verrous de liste d’autorisation du sandbox, est honoré lorsqu’une source contrôlée par l’administrateur les définit.
Un
policyHelper configuré préempte les quatre sources : sa sortie devient la seule configuration gérée pour l’exécution. Voir Précédence des paramètres.
Les paramètres gérés par le serveur atteignent les appareils au moment de l’authentification et s’actualisent toutes les heures pendant les sessions actives, sans infrastructure de point de terminaison. La livraison via la console d’administration claude.ai nécessite un plan Claude for Teams ou Enterprise. Les déploiements sur Amazon Bedrock, Google Cloud’s Agent Platform ou Microsoft Foundry peuvent obtenir la même livraison à distance en exécutant une passerelle d’applications Claude, ou utiliser l’un des mécanismes basés sur fichier ou au niveau du système d’exploitation à la place.
Si votre organisation mélange les fournisseurs, configurez les paramètres gérés par le serveur pour les utilisateurs de claude.ai plus un secours basé sur fichier ou plist/registre afin que les autres utilisateurs reçoivent toujours la politique gérée.
Les emplacements du registre plist et HKLM fonctionnent avec n’importe quel fournisseur et résistent à la falsification car ils nécessitent des privilèges d’administrateur pour écrire. Le registre utilisateur Windows à HKCU est accessible en écriture sans élévation, donc traitez-le comme une valeur par défaut pratique plutôt que comme un canal d’application.
Par défaut, WSL lit uniquement le chemin de fichier Linux à /etc/claude-code. Pour étendre votre registre Windows et la politique C:\Program Files\ClaudeCode à WSL sur la même machine, définissez wslInheritsWindowsSettings: true dans l’une de ces sources Windows réservées aux administrateurs.
Quel que soit le mécanisme que vous choisissez, les valeurs gérées prennent précédence sur les paramètres utilisateur et projet. Les paramètres de tableau tels que permissions.allow et permissions.deny fusionnent les entrées de toutes les sources, donc les développeurs peuvent étendre les listes gérées mais pas les supprimer. Pour deux exceptions, fallbackModel et availableModels, la valeur gérée remplace les couches inférieures plutôt que de fusionner.
Consultez Paramètres gérés par le serveur et Fichiers de paramètres et précédence.
Sessions WSL dans Claude Code Desktop
Sur Windows, Claude Code Desktop peut exécuter des sessions Code à l’intérieur d’une distribution WSL 2. Le processus Claude Code de la session s’exécute à l’intérieur de la distribution, il résout donc les paramètres gérés via le chemin de découverte WSL ci-dessus : les sources réservées à Windows ne l’atteignent pas sauf siwslInheritsWindowsSettings: true est déployé.
Sur les appareils où les paramètres gérés sont présents, les sessions WSL Desktop sont indisponibles par défaut. Si votre organisation souhaite les activer, contactez votre équipe de compte Anthropic. Lorsqu’elles sont activées :
- Déployez
wslInheritsWindowsSettings: truevia le registre HKLM ou le fichierC:\Program Files\ClaudeCodeafin que les sessions WSL héritent de la même politique que les sessions hôte. - Vérifiez en exécutant
/statusà l’intérieur d’une session WSL : la ligneSetting sourcesdevrait afficherEnterprise managed settingsavec la source Windows que vous avez déployée,(HKLM)ou(file).
Décider ce qu’il faut appliquer
Les paramètres gérés peuvent verrouiller les outils, l’exécution du sandbox, restreindre les serveurs MCP et les sources de plugins, et contrôler les hooks qui s’exécutent. Chaque ligne est une surface de contrôle avec les clés de paramètres qui la pilotent.
Les organisations dont les membres s’authentifient via claude.ai ou l’API Anthropic peuvent également gouverner les modèles sans déployer de paramètres : les restrictions de modèle d’organisation désactivent les modèles individuels, un modèle par défaut d’organisation définit le modèle sur lequel les nouvelles sessions commencent, et les limites d’effort d’organisation limitent les niveaux d’effort par rôle. Les trois contrôles nécessitent un plan Claude Enterprise. Les restrictions de modèle et les limites d’effort sont appliquées côté serveur ; le modèle par défaut est un point de départ que les utilisateurs peuvent modifier, sauf si l’organisation l’applique. L’application est disponible pour un ensemble limité d’organisations ; demandez à votre équipe de compte Anthropic la disponibilité. Aucun de ces contrôles n’atteint les sessions sur Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, ou Claude Platform on AWS ; sur ces fournisseurs, utilisez
availableModels ci-dessus pour les restrictions et la clé model dans les paramètres gérés pour une valeur par défaut.
Claude Code sur le web dispose de sa propre surface d’administration : sur la page des environnements Cloud dans les paramètres d’administration, les propriétaires et administrateurs créent des environnements partagés par l’organisation qui définissent le niveau d’accès réseau, les variables d’environnement et le script de configuration pour les sessions cloud des membres, et choisissent l’environnement par défaut de l’organisation.
Les règles de permission et le sandboxing couvrent différentes couches. Refuser WebFetch bloque l’outil fetch de Claude, mais si Bash est autorisé, curl et wget peuvent toujours atteindre n’importe quelle URL. Le sandboxing ferme cette lacune avec une liste blanche de domaines réseau appliquée au niveau du système d’exploitation.
Pour le modèle de menace que ces contrôles défendent, consultez Sécurité.
Configurer la visibilité de l’utilisation
Choisissez la surveillance en fonction de ce que vous devez signaler. Les tableaux de bord, les API et les contrôles de dépenses diffèrent entre les plans Claude for Teams ou Enterprise et les organisations Claude Console, alors vérifiez la colonne Disponibilité avant de planifier votre rapport autour d’une capacité.
Sur Teams et Enterprise, les chiffres d’utilisation et de dépenses par utilisateur proviennent du rapport de dépenses dans les paramètres d’analytique de votre organisation, et non du tableau de bord analytique. Les fournisseurs cloud exposent les dépenses via AWS Cost Explorer, GCP Billing ou Azure Cost Management. Pour planifier les budgets d’entreprise sur Claude chat, Claude Code et Cowork, consultez le guide de consommation Claude Enterprise.
Examiner la gestion des données
Sur les plans Team, Enterprise, Claude API et fournisseur cloud, Anthropic n’entraîne pas les modèles sur votre code ou vos invites. Votre fournisseur d’API détermine la rétention et la posture de conformité.
Si vous avez besoin d’une journalisation d’audit au niveau des demandes ou de router le trafic par sensibilité des données, placez une passerelle entre les développeurs et votre fournisseur : une passerelle d’applications Claude auto-hébergée enregistre un journal d’audit par demande avec l’identité IdP, ou utilisez une autre passerelle LLM. Pour les exigences réglementaires et les certifications, consultez Légal et conformité.
Vérifier et intégrer
Après avoir configuré les paramètres gérés, demandez à un développeur d’exécuter/status dans Claude Code. Sur l’onglet Status, la ligne Setting sources affiche Enterprise managed settings suivie de la source entre parenthèses, l’une de (remote), (plist), (HKLM), (HKCU) ou (file). Consultez Vérifier les paramètres actifs.
Partagez ces ressources pour aider les développeurs à démarrer :
- Démarrage rapide : procédure pas à pas de la première session de l’installation au travail avec un projet
- Flux de travail courants : modèles pour les tâches quotidiennes comme l’examen du code, la refactorisation et le débogage
- Claude 101 et Claude Code in Action : cours d’Anthropic Academy à votre rythme
- Exécuter
/logoutpuis/loginpour changer de compte - Exécuter
claude updatesi l’option d’authentification d’entreprise est manquante - Redémarrer le terminal après la mise à jour
Étapes suivantes
Avec le fournisseur et le mécanisme de livraison choisis, passez à la configuration détaillée :- Paramètres gérés par le serveur : livrer la politique gérée à partir de la console d’administration Claude
- Référence des paramètres : chaque clé de paramètre, emplacement de fichier et règle de précédence
- Monorepos et grands référentiels : modèles de configuration par répertoire pour les organisations déployant dans un monorepo
- Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry : déploiement spécifique au fournisseur
- Guide de l’administrateur Claude Enterprise : SSO, SCIM, gestion des sièges et playbook de déploiement