Guide de collaboration d'équipe avec Claude Code : passation, revue et permissions
Flux Claude Code concret pour CLAUDE.md, permissions, revues PR, passations et onboarding.
Claude Code accélère déjà le travail individuel : exploration du code, corrections et tests deviennent plus rapides. En équipe, le vrai sujet change. Il faut savoir qui a approuvé quelle commande, quels fichiers Claude a lus, quels risques restent non vérifiés et quelles suggestions de l’IA ont été validées par une personne.
Ce guide propose un flux opérationnel pour les petites et moyennes équipes. Il couvre la passation, la pré-revue de PR, les règles CLAUDE.md, les limites de permissions, l’onboarding, la passation d’incident et les échecs de communication. Une limite de permissions désigne ce que Claude Code peut lire, modifier ou exécuter. Un reçu de revue est une courte trace dans la PR indiquant comment l’équipe a traité les suggestions de l’IA.
flowchart LR
A["Demande du développeur"] --> B["CLAUDE.md et règles"]
B --> C["Travail de Claude Code"]
C --> D["Tests et diff"]
D --> E["Reçu de revue"]
E --> F["Revue humaine de PR"]
Quatre emplacements partagés
Un flux d’équipe stable ne peut pas dépendre de prompts mémorisés par une seule personne. Les règles doivent vivre dans des fichiers réutilisables.
| Emplacement | Objectif | Dans Git |
|---|---|---|
CLAUDE.md | Conventions, interdits, commandes de test | Oui |
.claude/settings.json | Permissions partagées, règles deny, hooks | Oui |
.claude/settings.local.json | URLs personnelles, réglages temporaires | Non |
.claude/prompts/*.md | Modèles de passation, revue, investigation | Oui |
La documentation officielle décrit la mémoire de Claude Code, les réglages, les permissions et la sécurité. Pour compléter, consulte aussi les bonnes pratiques CLAUDE.md, le guide des hooks Claude Code et GitHub Actions avancé.
Cas 1 : passation du développeur au reviewer
L’échec le plus courant consiste à remettre une PR avec seulement “Claude l’a corrigé”. Le reviewer doit savoir quels fichiers ont été inspectés, quelles commandes ont été approuvées, quels tests ont échoué et quelles décisions restent humaines.
Crée .claude/prompts/handoff.md :
# Rédiger une note de passation d'équipe
Lis le diff actuel et rédige la passation au format suivant.
## Objectif
- Problème que ce changement doit résoudre:
## Périmètre
- Fichiers modifiés:
- Fichiers non modifiés mais possiblement impactés:
## Vérification
- Commandes exécutées:
- Résultat:
- Résumé des logs d'échec:
## Points à regarder par le reviewer
- Décision produit:
- Sécurité:
- Performance:
- Tests manquants:
## Prochaine personne responsable
- À vérifier en premier:
- Peut attendre:
Après avoir préparé le diff, exécute :
claude -p "Lis git diff et crée une note de passation avec le format .claude/prompts/handoff.md"
Colle le résultat dans le corps de la PR. Le reviewer commence alors par les risques connus au lieu de reconstruire tout le contexte.
Cas 2 : pré-revue de PR avec IA
Claude Code ne doit pas remplacer l’approbation humaine. Il est plus utile comme première lecture pour détecter bugs évidents, tests manquants, risques de sécurité et changements incohérents.
Crée .claude/prompts/pr-review.md :
# Pré-revue de PR
Relis le diff avec ces critères:
1. Branches, null/undefined et valeurs limites pouvant créer des bugs
2. Autorisation, validation, exposition de secrets
3. Requêtes N+1, rerenders inutiles, traitements synchrones lourds
4. Violations des règles CLAUDE.md
5. Cas de test manquants
Format de sortie:
- Gravité: haute / moyenne / basse
- Fichier:
- Ligne ou fonction:
- Raison:
- Proposition de correction:
Marque les constats spéculatifs comme “à confirmer”.
En local, utilise GitHub CLI :
gh pr diff 123 | claude -p "$(cat .claude/prompts/pr-review.md)"
Avec GitHub Actions, limite l’automatisation à un commentaire. La décision de merge reste humaine.
name: Claude PR pre-review
on:
pull_request:
types: [opened, synchronize]
jobs:
pre-review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Install tools
run: npm install -g @anthropic-ai/claude-code
- name: Run Claude Code review
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
PR_NUMBER: ${{ github.event.pull_request.number }}
run: |
gh pr diff "$PR_NUMBER" > /tmp/pr.diff
claude -p "$(cat .claude/prompts/pr-review.md)
Diff:
$(cat /tmp/pr.diff)" > /tmp/claude-review.md
gh pr comment "$PR_NUMBER" --body-file /tmp/claude-review.md
La page officielle des flux courants couvre aussi les revues et les tests. La règle d’équipe doit être nette : les commentaires IA aident, les personnes approuvent.
Cas 3 : onboarding d’un nouveau membre
Un nouveau membre se bloque rarement sur la syntaxe. Il se demande plutôt quelle commande est sûre, où se trouvent les règles métier et quels fichiers lire en premier. Claude Code peut générer une première carte du dépôt.
claude -p "
Explique ce dépôt à une nouvelle personne de l'équipe.
Inclue:
- Répertoires principaux et responsabilités
- Commandes pour lancer, lint, test et build
- 3 premiers fichiers à lire
- Règles métier à vérifier avant de modifier
- Erreurs fréquentes et façons de les éviter
- Tâche d'entraînement réalisable en 30 minutes
N'invente pas. Liste les inconnues comme à confirmer.
"
Ne publie pas la sortie brute. Demande à une personne expérimentée d’ajouter contraintes de production, décisions passées et risques opérationnels. Pour les recherches larges, les patrons avec subagents aident à séparer exploration et synthèse.
Cas 4 : passation d’incident
Pendant un incident, Claude Code peut résumer des logs et organiser les hypothèses. Les risques sont sérieux : coller des secrets, présenter une hypothèse non vérifiée comme un fait, ou perdre ce qui a déjà été tenté lors d’un changement de responsable.
Enregistre ceci dans .claude/prompts/incident-handoff.md :
# Passation d'incident
## Symptôme
- Depuis quand:
- Périmètre:
- Impact utilisateur:
## Faits observés
- Logs:
- Métriques:
- Étapes de reproduction:
## Déjà tenté
- Commandes:
- Résultat:
- Hypothèses écartées:
## Risque restant
- Corruption de données:
- Impact sécurité:
- État du rollback:
## Prochaine personne responsable
- Premier écran/log à vérifier:
- Commandes à ne pas exécuter:
Avant de donner des logs à Claude Code, masque emails, jetons et identifiants clients. La documentation de sécurité officielle rappelle aussi les risques liés aux permissions et à l’injection de prompt.
Règles CLAUDE.md utiles
CLAUDE.md doit contenir les faits que l’équipe répète souvent. Les instructions doivent rester courtes, concrètes et vérifiables.
# Instructions du projet pour Claude Code
## Avant de travailler
- Exécuter `git status --short` avant toute modification.
- Ne jamais revenir sur les changements existants d'une autre personne.
- Si le comportement produit est flou, écrire “à confirmer” dans la PR.
## Règles de code
- Valider toutes les entrées API.
- Rendre explicites les limites de transaction pour les écritures base de données.
- Réutiliser les clés de traduction existantes avant d'ajouter du texte UI.
## Tests
- Ajouter des tests unitaires pour les changements de logique.
- Ajouter un test de non-régression pour chaque correction de bug.
- Si les tests n'ont pas pu être exécutés, expliquer pourquoi.
## PR
- Inclure résumé, vérification et risque restant.
- N'utiliser les suggestions de Claude Code qu'après revue humaine.
Si le dépôt possède déjà AGENTS.md, importe-le au lieu de dupliquer.
@AGENTS.md
## Spécifique à Claude Code
- Utiliser plan mode pour facturation, authentification et suppressions.
- Les humains gèrent `git push`, déploiements production et migrations.
Fixer les limites de permissions
Le plus grand risque est d’élargir les permissions parce que c’est pratique. Commence par une liste deny claire et un allow minimal.
{
"permissions": {
"allow": [
"Bash(npm run lint)",
"Bash(npm test)",
"Bash(git diff *)",
"Bash(git status *)",
"Edit(src/**)",
"Edit(tests/**)"
],
"ask": [
"Bash(npm install *)",
"Bash(git commit *)",
"Write(.github/**)"
],
"deny": [
"Read(.env*)",
"Read(**/secrets/**)",
"Bash(git push --force*)",
"Bash(rm -rf *)",
"Bash(npm publish*)"
]
}
}
Les hooks peuvent lancer des contrôles après modification ou bloquer des commandes risquées. Lis la référence officielle des hooks avant de les généraliser.
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "npm run lint -- --quiet"
}
]
}
]
}
}
Cet exemple suppose que npm run lint existe. Dans un grand monorepo, préfère des contrôles par fichier ou laisse le travail lourd à CI.
Ajouter un reçu de revue
La revue IA devient risquée si personne ne note quelles suggestions ont été acceptées. Ajoute ceci au modèle de PR :
## Reçu de revue Claude Code
- Prompt utilisé:
- Diff relu par Claude Code:
- Suggestions acceptées:
- Suggestions rejetées et raison:
- Vérifications humaines supplémentaires:
- Tests exécutés:
- Risque restant:
Responsable de la décision finale:
Si Claude Code n’a pas été utilisé, écris “non utilisé”. Le but est que le travail assisté par IA soit au moins aussi transparent que le travail habituel.
Échecs concrets et corrections
| Échec | Impact | Correction |
|---|---|---|
CLAUDE.md obsolète | Anciennes commandes et API retirées reviennent | Le revoir chaque mois avec de vrais incidents |
| Permissions trop larges | Secrets et actions production deviennent trop proches | Écrire deny d’abord puis allow minimal |
| Approbation IA seule | Décisions produit et responsabilité disparaissent | Approbation humaine obligatoire |
| Passation orale | Le lendemain, la raison n’est plus traçable | Coller la note dans PR ou Issue |
/clear efface le contexte | Le pourquoi du changement disparaît | Sauver un résumé avant reset ou compact |
| Hooks trop lourds | L’équipe les contourne | Hooks par fichier ou CI |
La communication échoue aussi avec des demandes vagues. “Corrige proprement” force Claude Code à deviner la cible. Préfère des limites courtes : “seulement cette fonction”, “ne pas toucher au schema”, “lire d’abord le log du test en échec”.
Checklist minimale d’équipe
CLAUDE.mdcontient commandes, interdits et règles PR.claude/settings.jsonsépare allow, ask et deny.claude/settings.local.jsonest dans.gitignore- Les prompts de passation, PR et incident sont partagés
- Le modèle de PR contient un reçu de revue
- La personne responsable de la décision finale est claire
- Une tâche d’onboarding de 30 minutes existe
ClaudeCodeLab améliore en continu ce type de modèles pour les équipes assistées par IA. Pour accélérer un déploiement interne, consulte les produits ClaudeCodeLab.
Conclusion
Utiliser Claude Code en équipe ne consiste pas à trouver un prompt magique. Il faut des instructions partagées, des permissions étroites, des passations durables et des reçus de revue auditables.
En solo, quelques prompts utiles peuvent suffire. En équipe, une autre personne doit pouvoir reproduire le flux, retracer les échecs et distinguer les suggestions de Claude Code des décisions humaines.
Après avoir testé ce flux dans un petit dépôt de validation de Masa, l’amélioration la plus visible est venue des notes de passation et des reçus de revue dans les PR. Les reviewers posaient moins de questions du type “qu’as-tu vérifié ?”. Le pire réglage était un lint complet après chaque édition via hook : trop lent, donc mieux placé dans CI. Commence par CLAUDE.md, le prompt de pré-revue et le reçu de revue.
PDF gratuit: cheatsheet Claude Code
Saisissez votre email et téléchargez une page avec commandes, habitudes de review et workflow sûr.
Nous protégeons vos données et n'envoyons pas de spam.
À propos de l'auteur
Masa
Ingénieur spécialisé dans les workflows pratiques avec Claude Code.
Articles liés
Workflow Obsidian vers CLAUDE.md avec Claude Code
Transformer des notes Obsidian en notes CLAUDE.md concises pour reprendre les sessions sans réexpliquer.
Claude Code Revenue CTA Routing : relier articles, PDF, Gumroad et consultation
Un workflow Claude Code pour orienter les lecteurs vers PDF gratuit, Gumroad ou consultation selon l'intention.
Règles de handoff Claude Code en équipe: preuves, permissions, rollback et revenus
Un format concret pour transmettre un travail Claude Code avec preuves, permissions, rollback, PDF gratuit, Gumroad et consultation.