L’article pas sexy. Celui qui décide si Claude Code devient de l’infrastructure ou l’histoire que vous racontez en postmortem.

Voici la règle autour de laquelle vous bâtissez tout le reste :

Cette seule règle clarifie 90 % des décisions de permissions. Tout le reste, c’est l’opérationnaliser.

Réversibilité, pas « ça fait peur »

La plupart des équipes configurent leurs allowlists au feeling. « Les tests, ça paraît safe ; les deletes, ça fait peur. » C’est faux.

Recadrez autour du blast radius :

• Réversible : éditer un fichier dans votre working tree, lancer des tests, lancer pnpm install, créer une feature branch. Si quelque chose casse, git checkout/git stash vous sauve.
• Irréversible : git push, npm publish, migrations DB en prod, terraform apply, envoyer des emails, prélever une carte, supprimer des ressources cloud.

La première liste doit aller dans l’allowlist de l’agent. La seconde liste doit exiger une frappe humaine à chaque fois, sans exception.

Le .claude/settings.json minimal pour un repo de prod

{
  "tools": {
    "shell": {
      "allow": [
        "pnpm test",
        "pnpm test:watch",
        "pnpm lint",
        "pnpm build",
        "pnpm db:migrate:dev",
        "pnpm db:reset:dev",
        "pnpm install",
        "git status",
        "git diff *",
        "git log *",
        "git stash *",
        "git checkout *",
        "git branch",
        "git add *",
        "git commit *",
        "ls *",
        "rg *",
        "cat *"
      ],
      "deny": [
        "git push *",
        "git rebase *",
        "git reset --hard *",
        "rm -rf *",
        "npm publish *",
        "pnpm publish *",
        "docker push *",
        "kubectl apply *",
        "terraform apply *",
        "aws *",
        "gcloud *",
        "psql -h prod*"
      ]
    }
  }
}

Quelques points à noter :

• git commit est autorisé ; git push non. L’agent peut stager un changement localement ; vous le publiez.
• pnpm db:migrate:dev est autorisé ; la variante prod non — et les migrations de prod ne devraient de toute façon pas être lançables depuis une machine de dev.
• aws * et gcloud * sont refusés en bloc. Si vous avez besoin d’un sub-agent qui appelle des APIs cloud, donnez-lui une commande spécifique, pas tout le CLI.

La liste « fichiers que l’agent ne doit jamais éditer »

Même si vous faites confiance à l’agent, certains fichiers doivent exiger une édition humaine. Verrouillez-les dans CLAUDE.md :

# Ne jamais modifier
- /infra/terraform/   (humains uniquement)
- /.github/workflows/release.yml
- Le champ "version" de /package.json
- Tout fichier dans /db/migrations/ déjà appliqué
- /SECURITY.md

Claude Code respecte fortement les instructions de CLAUDE.md. Combiné à la review du git diff, ça suffit pour 99 % des équipes.

Séparation des rôles des sub-agents = vraie défense en profondeur

On a couvert les 11 sub-agents dans l’article 5. Pourquoi la séparation des rôles compte pour la sécurité :

• code-reviewer ne peut pas éditer. Donc même s’il « décide » que tout va bien, il ne peut pas livrer.
• test-writer ne peut pas toucher le code de prod. Donc un test qui échoue est une preuve réelle, pas une sortie flaky.
• migration-runner ne peut lancer que pnpm db:migrate. Même compromis, le blast radius est d’une seule commande.

C’est ça la vraie défense en profondeur — bâtie à partir de fichiers de contraintes, pas de security theatre.

Choses qu’il ne faut pas automatiser

Petite liste « non, même si ça marche » :

• Poster dans des canaux publics (Slack, Discord, Twitter). La latence n’est pas un problème ; un message au mauvais ton dans #engineering, si.
• Emails clients. Du contenu généré, oui en brouillon. L’envoi reste humain.
• L’argent. Prélèvements, remboursements, payouts. Ne pas automatiser. Jamais.
• Auth & identité. Ajouter un utilisateur, accorder admin, rotation de clés.
• Force pushes. Même sur des branches de feature. Le coût d’un force-push accidentel est trop élevé.

Règle empirique : si le pire scénario est un postmortem, un email d’excuses ou un courrier du régulateur, gardez une frappe humaine entre intention et exécution.

Audit trail — la fonctionnalité sous-cotée

Chaque session Claude Code écrit un transcript dans ~/.claude/sessions/. En équipe, expédiez ces transcripts vers du durable :

• Un bucket S3 privé.
• Un flux de logs Datadog.
• Un simple git log de .claude/transcripts/ commité dans le repo.

Vous ne les lirez pas souvent. Mais le jour où vous le ferez — quand un truc bizarre arrive dans la base de code et que vous voulez savoir qui/quoi l’a changée — c’est de l’or.

Checklist pratique de sécurité

Avant de laisser Claude Code tourner sur une base réelle :

• .claude/settings.json a des allow et deny explicites.
• CLAUDE.md a une section « Ne jamais modifier ».
• .claude/agents/ inclut au minimum code-reviewer et test-writer.
• git push n’est dans aucune allowlist.
• Un coéquipier a relu l’allowlist.
• Vous avez d’abord lancé claude --dry-run (ou l’équivalent dans votre version) sur une branche de feature.

Six items. Vingt minutes de travail. La plupart des incidents prod viennent du fait qu’on en saute au moins trois.

---

Article suivant : Pipelines multi-agents — chaîner des sub-agents, les lancer en parallèle, et les patterns pour « review-en-codant » sans perdre la tête.