Claude Code en Équipe et Entreprise : Déployer, Sécuriser et Scaler

Mis à jour le 3 mars 2026

Tu veux déployer Claude Code pour toute ton équipe. Pas juste un dev qui l'utilise dans son coin — un vrai déploiement où tout le monde partage les mêmes conventions, les mêmes outils, les mêmes protections. Le problème : Claude Code est conçu comme un outil individuel. Chaque utilisateur a sa propre config, ses propres permissions, ses propres habitudes. Sans cadre commun, tu te retrouves avec 10 développeurs qui utilisent 10 versions différentes de l'outil.

Bonne nouvelle : Anthropic a prévu ce scénario. Claude Code embarque un système de managed settings, des fichiers de configuration partagés, et des mécanismes de sécurité pensés pour l'entreprise. Ce guide couvre tout : la hiérarchie de configuration, le contrôle admin, l'authentification cloud, l'intégration CI/CD, et un plan de déploiement concret en 4 semaines. Si tu débutes avec l'outil, commence par le guide complet Claude Code.

Les 3 niveaux de configuration

Claude Code utilise une hiérarchie à trois niveaux pour déterminer comment il se comporte. Chaque niveau peut être override par le niveau au-dessus. Comprendre cette hiérarchie est la base de tout déploiement en équipe.

Niveau 1 — User (personnel). C'est le fichier ~/.claude/settings.json sur la machine de chaque développeur. Il contient les préférences personnelles : mode de permission, outils auto-approuvés, règles de confort. Chaque dev le personnalise à sa guise. C'est le niveau le plus bas dans la hiérarchie — il est overridé par tout le reste.

Niveau 2 — Projet (partagé). C'est le fichier .claude/settings.json à la racine du repo, plus le CLAUDE.md committé. Tout le monde dans l'équipe qui clone le repo récupère automatiquement cette config. C'est là que tu définis les conventions du projet : stack technique, règles de nommage, outils autorisés, MCP servers communs. Ce niveau override les préférences utilisateur.

Niveau 3 — Managed (admin). C'est le fichier ~/.claude/managed-settings.json déployé par l'admin sur chaque poste. C'est le patron. Il a la priorité la plus haute dans la hiérarchie. Si un managed setting interdit un outil, ni le projet ni l'utilisateur ne peut le réautoriser. C'est la couche de contrôle que l'organisation utilise pour imposer ses politiques de sécurité.

En résumé : Managed > Projet > User. L'admin impose les limites. Le projet définit le cadre. Le dev personnalise le confort. Chaque couche fait son job sans empiéter sur celle au-dessus.

Managed settings : le contrôle admin

Les managed settings sont l'arme principale de l'admin. Le fichier ~/.claude/managed-settings.json se déploie sur chaque poste de l'équipe — manuellement, via un script d'onboarding, ou via MDM (Mobile Device Management) comme Jamf (Mac) ou Intune (Windows). Une fois en place, les développeurs ne peuvent pas le modifier ni le contourner.

Voici les options disponibles dans les managed settings :

{
  "permissions": {
    "allow": [
      "Bash(npm *)",
      "Bash(git *)",
      "Write(src/**)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(*--force*)",
      "Write(.env*)",
      "Write(secrets/**)"
    ]
  },
  "allowed_tools": ["Bash", "Write", "Edit", "Read", "Glob", "Grep"],
  "disallowed_tools": ["WebFetch"],
  "model": "claude-opus-4-6",
  "max_turns": 50,
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1"
  }
}

permissions — Les règles allow et deny granulaires. Exactement le même format que les permissions individuelles, mais imposées à toute l'équipe. Les deny ont toujours priorité sur les allow.

allowed_tools — La whitelist des outils utilisables. Si tu la configures, seuls ces outils sont disponibles. Tout le reste est bloqué. C'est le mode le plus restrictif.

disallowed_tools — La blacklist. Tous les outils sont disponibles sauf ceux listés. Plus souple que la whitelist — tu bloques juste ce qui pose problème.

model — Force un modèle spécifique pour toute l'équipe. Pratique pour contrôler les coûts (Sonnet 4.6 coûte moins qu'Opus 4.6) ou standardiser les résultats.

max_turns — Limite le nombre de tours par session. Empêche les sessions interminables qui explosent la facture API.

env — Variables d'environnement injectées automatiquement. C'est là que tu configures le provider cloud (Bedrock, Vertex) sans que chaque dev ait à le faire manuellement.

mcp_servers — Définit les MCP servers autorisés au niveau organisation. Garantit que tout le monde utilise les mêmes outils externes (GitHub, Jira, base de données interne) avec la même config.

Le point clé : les managed settings sont merge-proof. Ils ne se combinent pas avec les settings utilisateur — ils les écrasent. Un dev qui tente d'ajouter "Bash(rm -rf*)" dans ses allowed tools ne contourne pas le deny managed. C'est un override strict, pas un merge.

Standardiser la config projet

Les managed settings contrôlent la sécurité. Mais pour que l'équipe travaille efficacement, il faut aussi standardiser les conventions. Trois fichiers suffisent.

Le CLAUDE.md partagé

Le fichier CLAUDE.md à la racine du repo est lu automatiquement par Claude Code à chaque session. Chaque développeur qui clone le projet hérite des mêmes instructions sans rien configurer. C'est le fichier de mémoire partagée de l'équipe.

Un bon CLAUDE.md d'équipe contient :

# CLAUDE.md

## Stack technique
- Framework : Next.js 15 (App Router)
- Langage : TypeScript (strict mode)
- Styling : Tailwind CSS + shadcn/ui
- Tests : Vitest + Playwright

## Conventions
- camelCase pour les variables et fonctions
- PascalCase pour les composants et classes
- Fichiers composants : nom-du-composant.tsx
- Pas de "any" TypeScript sauf cas exceptionnels documentés

## Architecture
- /src/app/ : routes Next.js
- /src/components/ : composants réutilisables
- /src/lib/ : utilitaires et helpers
- /src/types/ : types TypeScript

## Règles métier
- Toujours valider les inputs côté serveur
- Error handling systématique (pas de catch vide)
- Logs structurés (pas de console.log en prod)

Ce fichier remplace les documents de conventions interminables que personne ne lit. Claude Code le lit à chaque session et applique ces règles automatiquement. Un nouveau dev qui arrive sur le projet obtient le contexte complet dès son premier prompt.

Le .mcp.json versionné

Le fichier .mcp.json à la racine du projet définit les MCP servers accessibles dans le contexte du projet. Il est committé dans le repo, donc tout le monde partage les mêmes connexions aux outils externes.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": ""
      }
    }
  }
}

Note : les credentials (DATABASE_URL, tokens) ne sont jamais dans le .mcp.json committé. Chaque dev configure ses propres credentials en local, via ses variables d'environnement ou via les managed settings env.

Le dossier .claude/rules/

Le dossier .claude/rules/ contient des fichiers markdown auto-chargés par Claude Code. Chaque fichier définit une règle comportementale. Par exemple : tone.md pour le style de réponse, coding-conventions.md pour les standards de code, security.md pour les règles de sécurité. Ces fichiers sont committés et partagés — toute l'équipe hérite des mêmes règles sans configuration manuelle.

Sécurité en entreprise

Déployer Claude Code en entreprise pose des questions légitimes. Où vont les données ? Qui peut faire quoi ? Comment auditer l'utilisation ? Voici les réponses concrètes.

Authentification et providers cloud

Par défaut, Claude Code utilise l'API Anthropic directement. Tes prompts et le code analysé transitent par les serveurs d'Anthropic. Pour beaucoup d'entreprises, c'est un problème de conformité.

AWS Bedrock — Configure CLAUDE_CODE_USE_BEDROCK=1 et Claude Code route tout par ton infrastructure AWS. Tes données ne quittent jamais ton compte AWS. Tu bénéficies des certifications AWS (SOC2, HIPAA, ISO 27001) et tu paies via ta facture AWS existante. C'est la solution la plus populaire en entreprise.

Google Vertex AI — Même logique avec CLAUDE_CODE_USE_VERTEX=1. Les données restent dans ton projet Google Cloud. Pratique si ton infrastructure est déjà sur GCP.

Custom OAuth (BYOK) — L'option --client-id permet de configurer un système d'authentification personnalisé. Chaque dev s'authentifie via ton identity provider (Okta, Azure AD, Auth0). Tu gères les accès et la rotation des clés depuis ton SSO existant.

Le choix dépend de tes contraintes. API Anthropic directe pour les petites équipes sans exigences de conformité. Bedrock ou Vertex pour les entreprises qui ne veulent pas que le code sorte de leur cloud. Custom OAuth pour les organisations avec un SSO existant.

Permissions restrictives par défaut

En entreprise, le principe est simple : tout interdire par défaut, autoriser au cas par cas. C'est l'inverse de l'usage individuel où tu ouvres progressivement les permissions à mesure que tu deviens confortable.

Un managed settings entreprise typique interdit les commandes destructrices (rm -rf, --force, DROP TABLE), protège tous les fichiers sensibles (.env, credentials, secrets/), bloque l'accès réseau non autorisé, et force le mode default qui demande confirmation pour chaque action. Les développeurs peuvent ensuite ajouter des règles allow dans leurs préférences personnelles — mais jamais contourner un deny managed.

Hooks d'audit

Les hooks Claude Code ne servent pas qu'à bloquer les commandes dangereuses. En entreprise, ils servent aussi à auditer. Un hook PreToolUse peut loguer chaque commande exécutée, chaque fichier modifié, chaque MCP server appelé. Ces logs alimentent ton SIEM ou tes dashboards de conformité. Tu sais exactement ce que Claude Code a fait, quand, et sur quelle machine. La traçabilité complète, sans effort supplémentaire pour les développeurs.

Intégration dans le workflow d'équipe

Claude Code ne remplace pas ton workflow. Il s'insère dedans. Voici les intégrations les plus impactantes.

PR reviews automatisées

Configure Claude Code en mode headless dans ta CI/CD pour reviewer automatiquement chaque Pull Request. Il analyse le diff, vérifie la conformité aux conventions du CLAUDE.md, détecte les problèmes de sécurité, et poste un commentaire sur la PR. Ce n'est pas un remplacement de la code review humaine — c'est un premier filtre qui attrape les problèmes évidents avant qu'un humain ne perde du temps dessus. Détail complet dans le guide CI/CD headless.

CI/CD headless

Claude Code fonctionne en mode non-interactif avec le flag --print (ou -p). Tu lui passes un prompt et il exécute sans demander de confirmation. Combiné avec --permission-mode bypassPermissions dans un container isolé, il devient un agent CI/CD autonome. Génération de code, mise à jour de dépendances, migration de base de données, génération de documentation — tout ce qui peut être automatisé dans un environnement contrôlé.

Conventions partagées

Le CLAUDE.md partagé garantit que chaque développeur génère du code qui suit les mêmes conventions. Nommage des variables, structure des fichiers, patterns d'error handling, format des commits — tout est standardisé. Fini les PR où la moitié des commentaires portent sur le style plutôt que sur la logique.

Agents custom communs

Tu peux créer des agents custom partagés pour l'équipe. Un agent code-reviewer en read-only qui analyse sans modifier. Un agent security-audit qui scanne les vulnérabilités. Un agent doc-generator qui génère la documentation technique. Ces agents sont définis dans le repo et disponibles pour tout le monde. Chaque agent a ses propres permissions, ses propres outils autorisés, et son propre périmètre d'action.

Plan de déploiement en 4 semaines

Voici le plan que je recommande pour déployer Claude Code dans une équipe de 5 à 50 développeurs. Pas de big bang — une montée en puissance progressive.

Semaine 1 — Pilote (2-3 personnes)

Choisis 2-3 développeurs motivés (pas forcément les plus seniors, mais ceux qui veulent tester). Installe Claude Code sur leurs postes avec la config par défaut. Objectif : qu'ils l'utilisent au quotidien pendant une semaine et qu'ils notent ce qui marche, ce qui manque, et ce qui fait peur. Pas de managed settings à ce stade — tu veux du feedback brut.

Semaine 2 — Config partagée

Avec le feedback du pilote, crée le CLAUDE.md du projet, le .mcp.json, et les règles dans .claude/rules/. Rédige le premier draft des managed settings : quels outils autoriser, quels chemins protéger, quel provider cloud utiliser. Déploie cette config sur les postes des pilotes et vérifie que tout fonctionne. Itère sur les règles selon les retours.

Semaine 3 — CI/CD

Intègre Claude Code dans ta pipeline CI/CD. Commence par un seul cas d'usage : les PR reviews automatiques. Configure le mode headless dans un container Docker isolé avec les permissions minimales nécessaires. Teste sur 10-15 PR avant de généraliser. Vérifie que les commentaires de review sont pertinents et ajuste le CLAUDE.md si nécessaire.

Semaine 4 — Scaling

Déploie les managed settings sur tous les postes de l'équipe via MDM ou script d'onboarding. Forme les nouveaux utilisateurs (une session de 30 minutes suffit — montre le CLAUDE.md, les commandes de base, et les règles de sécurité). Mets en place un canal Slack/Teams pour le support et le partage de tips. Planifie une review mensuelle des managed settings pour les ajuster selon l'évolution des besoins.

Piège à éviter : ne tente pas de tout configurer avant de commencer. Le meilleur managed settings, c'est celui qui émerge du terrain, pas celui qu'un architecte imagine seul dans un document de 40 pages. Commence simple, itère vite.

Meydeey

Architecte IA & Automatisation · Fondateur LE LABO IA · +25 000 abonnés YouTube