Checklist d'audit des permissions Claude Code avant le travail réel

Un audit des permissions rend Claude Code plus fiable

Claude Code devient coûteux quand chaque action demande une hésitation. L’audit des permissions transforme cette hésitation en profil court : ce que l’agent peut lire, modifier, demander et ne jamais toucher.

Faites-le après la checklist des 30 premières minutes et avant le travail plus profond sur le modèle CLAUDE.md. Le but n’est pas la bureaucratie, mais une première tâche réelle avec un risque maîtrisé.

Créer un profil de permissions

Ne commencez pas par une longue politique. Commencez par un profil que Claude Code peut suivre pendant la session.

claude_code_permission_profile:
  workspace: "repo only"
  allowed_without_approval:
    - "read files"
    - "run tests"
    - "edit content files"
  ask_first:
    - "install packages"
    - "change auth or billing code"
    - "deploy production"
  never_allow:
    - "print secrets"
    - "delete git history"
    - "rotate keys without owner approval"
definition_of_done:
  - "git diff reviewed"
  - "proof command captured"
  - "rollback note written"

La définition du terminé est essentielle. Même de bonnes permissions ne suffisent pas sans revue du diff, commande de preuve et note de rollback.

Exemple : site de contenu avec revenus

Sur un site multilingue, les MDX, les CTA et les descriptions produit sont souvent peu risqués. Les formulaires, liens de paiement, tags analytics et réglages de déploiement demandent une validation.

Audite ce dépôt avant l'implémentation.
Retourne:
1. les commandes sûres à lancer
2. les fichiers sûrs à modifier
3. les actions qui demandent validation
4. la plus petite tâche utile à finir aujourd'hui
5. la commande de preuve et la note de rollback

Ce prompt force Claude Code à proposer une tâche bornée avant l’implémentation : améliorer un CTA, vérifier le PDF gratuit, renforcer un texte Gumroad ou clarifier le chemin vers la consultation.

Échec fréquent : tout autoriser le premier jour

Le piège consiste à autoriser installation de paquets, auth, production et secrets dans la même session. C’est rapide jusqu’au moment où le rollback devient flou.

Autre piège : écrire seulement les interdits. Ne pas exposer les secrets est nécessaire, mais il faut aussi une preuve : build, tests, URL publique, formulaire et liens Gumroad.

Routine en 15 minutes

1. Exécutez “git status —short” avant la session.
2. Nommez les dossiers modifiables et protégés.
3. Séparez commandes sûres et commandes à valider.
4. Notez la commande de preuve et le rollback.

La revue porte alors sur des limites concrètes, pas sur une impression.

Prochaine étape

Prenez le cheatsheet gratuit si les commandes ne sont pas encore naturelles. Achetez le Setup Guide si le problème est permissions, CLAUDE.md, hooks ou MCP. Passez par la consultation pour un rollout d’équipe ou une stratégie de revenus.