Gouvernance et roles

Pourquoi une gouvernance ?

Sans regles claires, chaque developpeur configure Claude Code a sa facon : des MCP non verifies installes en global, des permissions trop larges, des secrets potentiellement exposes. Une gouvernance legere mais explicite evite ces risques sans freiner la productivite.

Roles et responsabilites

Les 4 roles types

Permissions par niveau d'experience

Adaptez les permissions Claude Code selon le niveau du developpeur :

Profil junior (restreint)

{
  "permissions": {
    "allow": ["Read", "Glob", "Grep"],
    "deny": ["Bash", "Write"]
  }
}

Le junior peut lire le code et poser des questions, mais Claude Code ne modifie rien directement. Les modifications passent par des suggestions que le dev applique manuellement.

Profil senior (permissif)

{
  "permissions": {
    "allow": ["Read", "Write", "Glob", "Grep", "Bash"],
    "deny": []
  }
}

Le senior a acces a tous les outils. Claude Code peut lire, ecrire et executer des commandes. La confirmation reste active pour les actions sensibles.

Profil lead (complet)

{
  "permissions": {
    "allow": ["Read", "Write", "Glob", "Grep", "Bash"],
    "deny": []
  },
  "allowedTools": ["mcp__github__*", "mcp__slack__*", "mcp__context7__*"]
}

Le lead a acces complet, y compris aux MCP d'equipe (GitHub, Slack, Context7). Il peut aussi modifier la configuration du projet.

Profil DevOps/CI (headless)

{
  "permissions": {
    "allow": ["Read", "Write", "Glob", "Grep", "Bash"],
    "deny": []
  }
}

Utilise en mode --print dans les pipelines CI/CD, avec des permissions strictement definies par le workflow.

Gestion centralisee des configurations

La hierarchie des fichiers de configuration

Claude Code lit les configurations dans un ordre precis, du plus general au plus specifique :

1. Organisation : ~/.claude/settings.json (deploye par votre outil de gestion de postes)
2. Projet : .claude/settings.json a la racine du repo (commite dans git)
3. Utilisateur : overrides locaux dans ~/.claude/settings.local.json

Les niveaux inferieurs heritent des niveaux superieurs. Un deny au niveau organisation ne peut pas etre annule par un allow au niveau projet.

CLAUDE.md : la source de verite du projet

Chaque repo devrait avoir un CLAUDE.md a la racine qui definit :

• Le contexte du projet (stack, architecture, conventions)
• Les regles de codage specifiques
• Les fichiers interdits d'acces
• Les workflows preferes (TDD, naming, structure de commits)

# CLAUDE.md - Projet MonApp

## Stack
- Next.js 14, TypeScript strict, Tailwind CSS, Prisma

## Regles
- Jamais de `any` en TypeScript
- Tests obligatoires pour chaque nouvelle fonction
- Ne jamais lire .env, .env.local ou credentials/
- Commit messages en francais, format conventionnel

## MCP autorises
- github, context7, playwright (pour les tests E2E)

Les sous-dossiers peuvent avoir leur propre CLAUDE.md qui complete (pas remplace) le fichier racine.

Gestion des secrets

Principes

• Les secrets ne sont jamais dans le code : variables d'environnement ou gestionnaire de secrets
• Claude Code ne doit jamais lire les fichiers de secrets : configurez une deny list explicite
• Rotation reguliere : changez les cles API tous les 90 jours minimum

Integration avec un gestionnaire de secrets

Pour les equipes qui utilisent un gestionnaire de secrets (Vault, AWS Secrets Manager, Google Secret Manager), l'integration se fait via les variables d'environnement :

# Exemple avec AWS Secrets Manager
export ANTHROPIC_API_KEY=$(aws secretsmanager get-secret-value \
  --secret-id claude-api-key \
  --query SecretString \
  --output text)

Pour les pipelines CI/CD, injectez la cle via les secrets du runner (GitHub Actions secrets, GitLab CI variables).

Deny list recommandee

Dans votre settings.json organisation :

{
  "permissions": {
    "deny": [
      "Read:.env",
      "Read:.env.*",
      "Read:**/credentials*",
      "Read:**/*.pem",
      "Read:**/*.key",
      "Read:**/secrets*"
    ]
  }
}

Allow list MCP et plugins

Pourquoi une allow list ?

Sans restriction, n'importe quel developpeur peut installer n'importe quel MCP, y compris des MCP non verifies qui pourraient exfiltrer du code. L'allow list garantit que seuls les MCP approuves par l'equipe securite sont utilises.

Configuration

Dans le settings.json organisation :

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "context7": {
      "command": "npx",
      "args": ["-y", "@context7/mcp"]
    }
  }
}

Les MCP non listes dans la configuration organisation sont automatiquement bloques si vous utilisez un outil de gestion de configuration qui empeche la modification du fichier.

Audit : quoi loguer, ou, retention

Quoi loguer

Ou stocker les logs

• Local : ~/.claude/ contient l'historique des sessions (par defaut)
• Centralise : configurez un hook PostToolUse pour envoyer les evenements vers votre SIEM, ELK Stack, Datadog ou un simple webhook

Retention recommandee

• Logs d'audit : 12 mois minimum (obligation reglementaire courante)
• Historique des sessions : 3 mois (suffisant pour le debugging)
• Metriques d'usage : 24 mois (pour les analyses de tendance et le reporting)

Politique de mise a jour

Frequence

Claude Code se met a jour regulierement (parfois plusieurs fois par semaine). Recommandations :

• Environnement de dev : mises a jour automatiques (comportement par defaut)
• Pipelines CI/CD : version fixe, mise a jour manuelle apres validation
• Equipes sensibles : retardez les mises a jour de 1 a 2 semaines pour laisser la communaute identifier les bugs

Desactiver les mises a jour automatiques

export DISABLE_AUTOUPDATER=1

Ajoutez cette variable dans le profil shell de vos machines de CI ou dans la configuration des postes de travail si vous voulez controler les versions.

Changelog

Suivez les notes de version sur le blog d'Anthropic et dans le changelog de Claude Code pour anticiper les changements qui pourraient impacter vos workflows.

Prochaines etapes

• Securite et conformite : protection des donnees et certifications
• Guide d'adoption d'equipe : mettre en place les roles dans le cadre du deploiement
• FAQ Enterprise : reponses aux questions frequentes sur la gouvernance