Règles de handoff Claude Code en équipe: preuves, permissions, rollback et revenus

Pourquoi le handoff d’équipe compte

Utiliser Claude Code seul peut encore fonctionner avec de la mémoire personnelle. En équipe, ce n’est pas assez. Dès qu’une autre personne doit reviewer un patch produit par IA, il faut savoir qui a approuvé l’action sensible, quelle URL publique a été vérifiée, quelles preuves peuvent être répétées et quel chemin de revenus a été protégé.

C’est particulièrement important pour les articles, landing pages, pages produit, liens Gumroad et formulaires de consultation. Un build peut passer alors que le lien du PDF gratuit pointe vers la mauvaise langue. Une page peut être mieux écrite tout en modifiant une promesse commerciale. Un formulaire peut sembler correct mais échouer après l’envoi.

Le but du handoff n’est pas de créer un long journal d’activité. Le but est de laisser un contrat de review court: ce qui a changé, quelle preuve existe, quelle permission a été utilisée, comment revenir en arrière, ce qu’il ne faut pas toucher et si les chemins PDF gratuit, Gumroad et consultation ont été vérifiés.

À lire avec le template de handoff de session, le Permission Budget Loop et la checklist de review. Pour le contexte produit, gardez aussi la documentation officielle Claude Code.

Échecs fréquents de transmission

Le premier échec consiste à transmettre seulement un log: “article allongé”, “liens corrigés”, “build lancé”. Cela ne dit pas au reviewer quelle preuve croire, quelle page ouvrir ni quel chemin de conversion a vraiment été contrôlé. Une review a besoin de preuves, pas seulement d’un récit.

Le deuxième échec consiste à garder les règles d’approbation à l’oral. Une personne pense demander une petite correction de texte, puis Claude Code touche le prix, la destination du CTA, le déploiement ou un formulaire public. Si la limite de permission n’est pas écrite, le reviewer doit deviner l’intention à partir du diff.

Le troisième échec est l’absence de rollback. Si un changement IA casse la page après publication, l’équipe doit connaître le point de restauration, la commande de retour arrière et l’ordre de récupération. Sans cela, les premières minutes partent en clarification de responsabilité au lieu de restaurer la page ou le chemin d’achat.

Le quatrième échec est de laisser les revenus à “quelqu’un d’autre”. Dans une opération de contenu, le trafic n’est pas le résultat final. Le lecteur doit pouvoir recevoir le PDF gratuit, acheter le matériel Gumroad ou envoyer une demande de consultation. Ces chemins font partie de la surface fonctionnelle.

Dans le workflow de Masa, le problème n’était pas seulement l’existence d’articles trop courts. Le problème plus profond était que le reviewer ne voyait pas vite si l’article restait connecté au bon parcours d’apprentissage et d’achat. En ajoutant preuves, permissions, rollback et revenus au handoff, les commentaires sont passés de “que dois-je regarder ?” à “cette preuve suffit” ou “il manque encore la vérification Gumroad”.

Les preuves à donner au reviewer

Une bonne preuve est concrète et reproductible. Le reviewer doit pouvoir exécuter la même commande, ouvrir la même URL et comprendre la même frontière de risque. Pour un article, les preuves habituelles sont longueur du corps, nombre de h2, liens internes, liens externes, blocs de code, heroImage, qualité de localisation et destination du CTA.

Pour une page produit, il faut ajouter l’affichage mobile, la soumission de formulaire, le texte de prix, le lien d’achat, la canonical et la page de remerciement. Pour une tâche de développement, il faut tests, type check, build, fichiers touchés et risques restants. La checklist change, mais la question reste la même: que peut vérifier le reviewer sans deviner ?

Un minimum de trace de commandes peut ressembler à ceci:

npm run build
node scripts/check-updated-article-quality.mjs

Si une commande n’a pas été exécutée, n’écrivez pas seulement “non testé”. Notez la raison et le prochain endroit de vérification: dépendances manquantes, clé API absente, environnement disponible seulement en CI ou besoin d’une preview en ligne. Ainsi, le trou devient visible et reviewable.

Les captures d’écran aident, mais elles ne suffisent pas seules. Une capture prouve qu’un viewport était correct à un instant donné. Elle ne prouve pas la destination du lien, l’achat ni le rollback. Associez-la toujours à une URL, une commande et une note de risque.

Kit minimal à copier-coller

Collez ce bloc Markdown dans la description de PR, une issue, Slack ou Notion. Il est volontairement court: un handoff qui prend vingt minutes à remplir ne tiendra pas dans un usage quotidien.

# Claude Code team handoff

## Change made
- 

## Proof
- build:
- public URL:
- screenshot:

## Revenue path checked
- free PDF:
- Gumroad:
- consultation:

## Next owner
- reviewer:
- decision needed:
- do not touch:

Les permissions gagnent à rester lisibles par une machine. Ce JSON ne remplace pas une politique de sécurité, mais il donne à Claude Code et à l’équipe le même vocabulaire.

{
  "approval_rules": {
    "safe": ["read files", "search", "small copy edit"],
    "review_required": ["pricing", "CTA links", "deployment"],
    "blocked": ["secrets", "force push", "delete customer data"]
  }
}

Fixez aussi le prompt du reviewer. Sans périmètre clair, la review part vite vers des préférences de style, d’anciens débats produit ou des refactorings hors sujet.

You are receiving a Claude Code handoff.
Check the proof first.
Then review only:
1. whether the stated goal was met
2. whether protected links still work
3. whether the next owner has one clear action

Template permissions, rollback et revenus

En équipe, permissions, rollback et revenus doivent être dans le même template. Beaucoup d’incidents commencent quand une permission est donnée oralement, aucun point de restauration n’est nommé et tout le monde suppose que le CTA fonctionne encore.

handoff:
  owner: "Masa"
  reviewer: "team-reviewer"
  permission:
    safe:
      - "copy edit inside the article body"
      - "run local quality checks"
    needs_review:
      - "price copy"
      - "CTA destination"
      - "deployment setting"
    blocked:
      - "secrets"
      - "customer data"
      - "force push"
  rollback:
    restore_point: "commit or branch before Claude Code work"
    command: "git revert <commit>"
    priority_path:
      - "public article page"
      - "free PDF signup"
      - "Gumroad purchase"
      - "consultation form"
  revenue:
    free_pdf: "checked"
    gumroad: "checked"
    consultation: "checked"

Ce template n’est pas une bureaucratie. Pour une petite modification d’article, il se remplit en cinq minutes. Si le changement touche prix, achat, formulaire, données client ou déploiement, ces champs doivent être remplis avant la demande de review.

Quatre cas d’usage concrets

Premier cas: publication d’article. Un rédacteur enrichit le texte avec Claude Code, puis un éditeur ou un ingénieur vérifie le script qualité, la page publique, les liens internes, le lien externe, heroImage et le CTA du PDF gratuit. Le reviewer ne relit pas tout le site; il vérifie que l’amélioration promise et le chemin de conversion fonctionnent.

Deuxième cas: copy produit. Un PM peut demander à Claude Code de réécrire la description d’un produit Gumroad, mais prix, conditions, destination du CTA et lien d’achat restent en review_required. Cela évite qu’un texte plus fluide change une promesse commerciale sans validation.

Troisième cas: amélioration de la page de consultation. Claude Code peut clarifier les titres, reformuler les questions et supprimer les répétitions. Le handoff doit tout de même prouver que le formulaire s’envoie, que les erreurs s’affichent et que la page de remerciement s’ouvre. Sinon, l’équipe améliore les mots mais casse l’acquisition de leads.

Quatrième cas: maintenance de la politique de permissions. Si le lead décide que lecture et recherche sont safe, prix et déploiement demandent review, secrets et données client sont blocked, cette règle doit être transmise comme un diff. La prochaine session Claude Code pourra recevoir le même contexte.

Comment le reviewer doit lire le handoff

Le reviewer commence par les preuves, pas par le diff. Il vérifie build ou script qualité, ouvre l’URL preview ou publique, regarde la capture si elle existe et teste les liens protégés. Si les preuves manquent, il renvoie le handoff comme incomplet au lieu d’inférer le résultat depuis le code.

Ensuite vient le périmètre de permission. Si le changement reste dans safe, une review normale suffit. S’il touche prix, CTA, déploiement, formulaires ou copy de revenus, l’owner concerné doit confirmer. S’il touche blocked, il ne doit pas être mergé même si le résultat semble utile.

Enfin vient le rollback. Un handoff sans rollback n’est pas prêt pour l’exploitation. Pour un simple article, revert un commit peut suffire. Pour produit, checkout, tracking ou consultation, l’ordre compte: restaurer d’abord la page publique, puis PDF gratuit, Gumroad et formulaire de consultation.

Chemin naturel vers contenus et consultation

Pour une adoption individuelle, commencez par le cheatsheet gratuit Claude Code. Il suffit quand le blocage principal est la mémoire des commandes et les habitudes sûres. Quand les prompts de review, debugging, amélioration d’article ou documentation se répètent, utilisez 50 Claude Code Prompt Templates.

Pour un setup d’équipe, la Claude Code Setup Guide aide à standardiser CLAUDE.md, hooks, permissions, MCP et commandes de vérification. Elle convient quand l’équipe peut exécuter en interne mais a besoin d’une structure.

Si la partie coûteuse est de décider qui approuve, quels liens protéger et comment relier AdSense, Gumroad et consultation, comparez la page produits et utilisez la page consultation. La consultation ne sert pas à écrire un prompt isolé; elle sert à concevoir responsabilités, preuves, rollback et priorités de revenus.

Le chemin naturel est simple: PDF gratuit pour les habitudes, Gumroad pour les workflows répétables, consultation pour les règles propres à l’équipe. La recommandation reste alors utile sans forcer tous les lecteurs vers la même étape.

Ce que j’ai vérifié pour cet article

Cet article contient un handoff Markdown, des règles JSON, un prompt reviewer et un template YAML pour permissions, rollback et revenus. L’objectif est que le travail Claude Code soit reviewable par une autre personne, pas seulement compréhensible par celle qui a lancé la session. En pratique, le handoff fonctionne quand le prochain owner peut répondre vite: ce qui a changé, quelle preuve existe et quel chemin doit rester protégé.