Un développeur solo avec Claude Code, c'est une histoire de productivité. Une équipe avec Claude Code, c'est une question d'operating model.

La plupart des gains (et la plupart des échecs) que je vois à l'échelle d'une équipe n'ont rien à voir avec le modèle. Ils tiennent au vocabulaire partagé, aux contraintes partagées et aux rituels de revue partagés.

Voici ce qui marche, ce qui ne marche pas, et les patterns que je volerais.

Le dossier .claude/ partagé est le déclic

Committez .claude/ dans le repo. Tout son contenu.

• CLAUDE.md — contexte projet, conventions, liste « ne jamais modifier ».
• .claude/settings.json — allowlist / denylist d'outils.
• .claude/agents/*.md — votre équipe de sub-agents.
• .claude/commands/*.md — vos slash commands.

Toute l'équipe récupère le même operating model au git pull. L'onboarding passe de « laisse-moi te montrer mes prompts » à « lis .claude/, tu vas piger ».

Propriété des agents — désignez un mainteneur

Chaque sub-agent doit avoir un owner dans l'équipe. Pas parce que les agents sont complexes (c'est un fichier .md), mais parce que les agents dérivent.

Un code-reviewer écrit pour une équipe de 5 ingénieurs au mois 1 sera faux au mois 6. Quelqu'un doit :

• Lire les retours de revue que l'agent remonte.
• Repérer quand il rate une catégorie de bug.
• Mettre à jour le system prompt.

Traitez les sub-agents comme de l'infrastructure. Owned, versionnés, revus en PR.

Les rituels de PR qui changent avec Claude Code

Trois rituels que j'ai vu fonctionner :

1. Les PR écrites par l'IA le déclarent

Ajoutez un label ou une section dans le template de PR :

## Assistée par IA

- Implementer : oui / non
- Auteur des tests : humain / IA
- Code reviewer (pré-PR) : n/a / agent `code-reviewer`

Ce n'est pas de la bureaucratie. C'est du signal. Quand un truc casse, vous voulez savoir quelle catégorie d'auteur enquêter.

2. Revue à deux niveaux

Pour les PR > 200 lignes ou qui touchent des chemins critiques :

• Niveau 1 : agent code-reviewer (pré-push).
• Niveau 2 : reviewer humain (post-push).

Pour tout le reste, la passe de l'agent + la revue du diff par l'auteur suffisent. Arrêtez de prétendre lire chaque ligne de chaque PR de moins de 50 lignes.

3. Revue de code « diff-first »

Les reviewers arrêtent d'ouvrir les fichiers. Ils lisent le diff dans gh pr diff et font confiance à la suite de tests. Ça paraît imprudent jusqu'au moment où l'on réalise que c'est le bon comportement depuis des années — les humains étaient simplement mauvais à l'exécuter.

La review-as-agent de Claude Code rend le modèle diff-first honnête : un agent séparé a déjà vérifié l'évident avant qu'un humain n'y touche.

Ce qui ne marche PAS

Une courte liste de patterns qui ressemblent à des gains mais n'en sont pas :

• Une seule licence Claude Code, partagée par toute l'équipe. Tue la personnalisation, tue les pistes d'audit, crée un cauchemar de permissions. Licences par utilisateur, point.
• Les « démos sprint IA » où les managers cherry-pick les meilleures PR. Biais du survivant. Suivez des métriques agrégées, pas des highlight reels.
• Bannir Claude Code des services « critiques ». L'inverse du bon mouvement. Les services critiques ont besoin des sub-agents les plus disciplinés et des allowlists les plus étroites, mais ce sont eux qui bénéficient le plus du workflow.
• Forcer tout le monde à utiliser les mêmes prompts. Encouragez des .claude/commands/ partagés ; résistez à imposer le style personnel. Les gens promptent différemment, et c'est très bien.

Ce qui change pour les managers d'ingénierie

Trois choses bougent vraiment :

1. La vélocité devient plus lisible

Vous pouvez sortir des stats depuis ~/.claude/sessions/ (ou son équivalent côté log shipping). Temps moyen par feature, nombre moyen de tours d'agent avant le vert, fraction des PR qui passent la revue du premier coup.

Ces données sont bonnes. Utilisez-les pour du diagnostic (« l'équipe galère sur la feature X »), pas pour des évaluations de performance (« tu as moins utilisé l'agent »).

2. L'onboarding s'aligne sur la codebase

Un nouveau recruté devient productif plus vite — pas parce qu'il est plus malin, mais parce que .claude/CLAUDE.md et les sub-agents préchargent tout le savoir tribal de la codebase.

J'ai onboardé des ingénieurs en 2 jours là où il en aurait fallu 2 semaines avant Claude Code. La codebase est désormais auto-documentée sous instruction.

3. Le temps des seniors se réalloue

Les ingénieurs seniors arrêtent de taper le boilerplate. Ils revuent plus de diffs, écrivent plus de CLAUDE.md, conçoivent plus d'ADR. L'agent gère la frappe ; le senior gère l'architecture.

C'est un vrai changement. Certains seniors adorent. D'autres regrettent la frappe. Les deux sont légitimes. Reconnaissez juste que le changement a lieu.

L'erreur d'équipe la plus courante

Laisser Claude Code entrer dans la codebase sans .claude/ partagé d'abord.

Chaque ingénieur finit avec ses propres settings, son propre CLAUDE.md, sa propre équipe. La sortie de l'équipe paraît incohérente parce que, eh bien, elle l'est.

Passez deux jours à écrire le .claude/ partagé. Faites-le passer à l'équipe. Committez-le. Ensuite déployez Claude Code.

Un plan de déploiement de 30 jours qui marche

• Semaine 1 : 2-3 ingénieurs seniors utilisent Claude Code sur des tickets opt-in. Ils écrivent la première version de .claude/.
• Semaine 2 : ouvrez-le au reste de l'équipe. Bannissez-le sur les migrations prod et les PR infra. Stand-up quotidien de 15 min « ce qui a marché / ce qui n'a pas » dédié au workflow agent.
• Semaine 3 : sub-agents codifiés. Rituels de revue adoptés. Métriques en place.
• Semaine 4 : levez le ban prod pour les ingénieurs qui ont livré 3+ PR assistées par IA. Gardez le ban infra pour le moment.

Au mois 2, Claude Code n'est plus que « notre façon de travailler ». Plus personne n'en parle spécifiquement. C'est l'objectif.

---

Article suivant : Patterns avancés — hooks, serveurs MCP, outils custom, et system prompts. Ce qu'on construit une fois qu'on a dépassé les valeurs par défaut.