Registre de risque des permissions Claude Code : décider avant que l'agent agisse

Pourquoi créer un artefact dédié

Cet article construit un registre de risque des permissions pour équipes qui passent d’un usage solo de Claude Code à des règles d’approbation partagées. L’échec fréquent est simple : l’équipe parle permissions après que l’agent a déjà modifié, déployé ou demandé une commande risquée. Un workflow Claude Code ne s’arrête pas à une réponse confiante. Il doit laisser un artefact qu’une autre personne peut contrôler. Ici, cet artefact est un petit registre avec action, décision par défaut, preuve et owner.

Traitez l’artefact comme un contrat entre prompt, ligne de commande et page publique. Il doit montrer ce que Claude Code a lu, ce qu’il a changé, quelle commande prouve le résultat et quel chemin de revenus le lecteur voit ensuite. C’est lié à harness engineering, getting started et permissions.

La boucle opérationnelle

La boucle a cinq passages : définir l’action, choisir la preuve, laisser Claude Code faire le plus petit travail utile, vérifier la sortie, puis noter la prochaine action de revenu. Ici, la preuve utile n’est pas seulement le code qui tourne. Surveillez nombre d’approvals, commandes refusées, notes rollback, preuve deploy et intention consultation. Quand ces champs sont visibles, l’amélioration cesse d’être une devinette.

1. Le mapping read-only du repo peut être autorisé si la note finale liste ce qui a été lu.

2. Les éditions de contenu sont acceptables quand diff review, build et URL publique sont obligatoires.

3. Secrets, billing, données client et force push restent owner-approved même si l’agent est précis.

Starter à copier

permission_risk_register:
  - action: "read repository files"
    default: "allow"
    proof: "list files read in the final note"
  - action: "edit content files"
    default: "allow after diff review"
    proof: "build passes and URL matches the slug"
  - action: "deploy production"
    default: "ask first"
    proof: "build log, deploy URL, rollback note"
  - action: "touch secrets or billing"
    default: "never without owner approval"
    proof: "human approval id"

Trois exemples terrain

Exemple 1. Le mapping read-only du repo peut être autorisé si la note finale liste ce qui a été lu.

Exemple 2. Les éditions de contenu sont acceptables quand diff review, build et URL publique sont obligatoires.

Exemple 3. Secrets, billing, données client et force push restent owner-approved même si l’agent est précis.

Checklist d’auto-revue

Avant de transformer ce workflow en habitude, relisez l’article comme une note de release. Le premier contrôle est le scope : le lecteur doit savoir quand utiliser un registre de risque des permissions et quand une checklist plus petite suffit. Le deuxième contrôle est la preuve : chaque recommandation doit pointer vers une commande, une URL, un diff ou une métrique. Le troisième contrôle est le routing : PDF gratuit, guide Gumroad et consultation doivent répondre à des urgences différentes.

Ajoutez une petite règle d’ownership. Une personne possède l’artefact, une autre la vérification, une autre la prochaine expérience CTA. En solo, ce peut être la même personne, mais les rôles doivent être nommés dans la note. Cela empêche Claude Code de mélanger publication, mesure et vente dans une tâche floue. La prochaine exécution sait aussi où reprendre.

La question utile est : qu’est-ce qui rendra cet article plus facile à vérifier demain matin ? Si la réponse est une capture, gardez-la. Si c’est un prompt plus fort, ajoutez-le au prompt pack. Si c’est une limite plus claire, ajoutez-la aux notes de setup. un petit registre avec action, décision par défaut, preuve et owner n’a de valeur que s’il survit à la session suivante.

Échecs fréquents

Le premier échec consiste à prendre les pages vues comme seul score. Le deuxième est d’approuver sans commande de preuve. Le troisième est d’envoyer tous les lecteurs vers le même produit payant alors qu’un PDF gratuit ou une consultation convient mieux. Écrivez la règle de routing avant de changer le CTA.

Chemin de revenus

Routez par blocage. Si la personne manque de fluidité commande, envoyez-la vers le PDF gratuit ou le cheatsheet Gumroad gratuit. Si elle répète le même travail chaque semaine, proposez 50 Prompt Templates ou Setup Guide. Si le sujet est rollout, risque ou revenu, proposez la consultation. Pour cet article, Setup Guide donne la base de policy, et la consultation aide quand production ou revenus dépendent des approvals.

Métriques de vérification

Après publication, HTTP 200 ne suffit pas. Vérifiez h1, canonical, hero image, début du corps, liens CTA, mobile layout et langue. Ensuite, suivez nombre d’approvals, commandes refusées, notes rollback, preuve deploy et intention consultation. Si rien ne bouge, corrigez d’abord le CTA près du premier exemple concret.