Claude Code en équipe : CLAUDE.md, sous-agents, hooks et revue de code

Claude Code en entreprise ne se résout pas en installant un outil sur les postes : c’est un cadre d’équipe qu’il faut poser. Le fichier CLAUDE.md partagé, les permissions et les hooks, la répartition en sous-agents et une revue de code adaptée aux changements écrits par l’IA décident si l’outil accélère votre équipe ou s’il ajoute de la dette. 39 % des développeurs déclarent utiliser Claude Code au travail (enquête JetBrains, août 2026) : dans beaucoup d’équipes, l’adoption a donc déjà eu lieu, souvent sans règles écrites.

Un agent de code se comporte autrement qu’un copilote dans l’éditeur. Il lit le dépôt, modifie plusieurs fichiers, lance des commandes et prépare des branches. Il touche donc à ce qui engage l’équipe entière : conventions, tests, secrets, dépendances. Ce déplacement, du fichier ouvert vers le projet complet, rend le cadre obligatoire.

Que change Claude Code pour une équipe de développement ?

L’outil ne change rien tout seul, ce sont les règles partagées qui changent le résultat. Sur un poste isolé, chacun apprend les commandes du projet à ses dépens. À l’échelle d’une équipe, ces apprentissages en double coûtent du temps et produisent du code hétérogène.

Trois effets apparaissent dès que l’outil se généralise :

1. Les conventions cessent d’être implicites : ce que l’agent doit savoir, il faut l’écrire, sinon il l’invente de façon plausible.
2. Les changements grossissent : une session bien menée peut produire plusieurs centaines de lignes sur cinq fichiers, ce qui déplace la charge vers la relecture.
3. Les coûts deviennent variables : chaque session consomme des tokens, et les tâches longues sur un gros dépôt se voient dans la facture.

Le cadre décrit ici vaut pour Claude Code comme pour les autres agents installés sur les postes, Cursor, GitHub Copilot ou Codex.

À quoi sert un CLAUDE.md et comment l’écrire ?

Un fichier CLAUDE.md est lu automatiquement au démarrage d’une session : c’est la mémoire du projet que l’agent consulte avant d’agir. Trois sections suffisent pour commencer :

• les commandes : installation, tests, lint, lancement local, avec la commande exacte ;
• les conventions : nommage, structure des dossiers, frameworks et versions en place ;
• les interdits : modules à ne pas toucher, migrations à ne pas modifier, fichiers de secrets à ne jamais lire.

Ce fichier appartient au dépôt, donc à l’équipe : il se versionne, se relit en revue et se corrige. La règle de maintenance la plus efficace est simple : chaque erreur répétée deux fois par l’agent devient une ligne du fichier. C’est le principe appliqué aux prompts versionnés comme du code.

Sur un dépôt volumineux, mieux vaut un fichier court à la racine et des fichiers plus précis dans les sous-ensembles du projet, plutôt qu’un document unique de plusieurs centaines de lignes que personne ne maintient.

Quels garde-fous poser avant d’ouvrir l’outil à toute l’équipe ?

Trois réglages couvrent l’essentiel : permissions, hooks et portée des accès.

• Permissions : l’agent demande une validation avant une commande sensible. Listez ce qui passe sans confirmation (tests, lint, lecture) et ce qui exige un accord humain (publication de branche, suppression de fichiers, requête sur la base de production).
• Hooks : des commandes déclenchées à un moment précis du travail de l’agent, par exemple après une édition de fichier. Ils font respecter une règle sans dépendre de la vigilance de chacun : formatage automatique, refus d’une écriture hors du dépôt, blocage de la lecture des fichiers d’environnement.
• Accès et secrets : clés d’API dans un gestionnaire de secrets, jamais dans un prompt ni dans un fichier du dépôt. Les connexions aux outils internes passent par MCP (Model Context Protocol), le standard qui expose vos outils à un agent. Chaque serveur MCP se déclare avec le minimum de droits utiles : un accès en lecture seule à la documentation ou au support vaut mieux qu’un accès en écriture général.

Tout ce que l’agent lit peut contenir des instructions : un ticket, une page web, un fichier récupéré dans le dépôt peuvent tenter de détourner la session. Les garde-fous réduisent la portée d’une injection de prompt, et la méthode de prévention des injections dans vos agents détaille les contrôles. Règle d’équipe utile : un agent propose, l’humain confirme ce qui engage (fusion, envoi, modification de données).

Sous-agents et revue de code : qui relit quoi ?

Un sous-agent est une instance lancée pour une tâche précise, avec son propre contexte et, idéalement, une liste d’outils restreinte. En équipe, cela sert à garder la session principale lisible (explorer un dépôt inconnu, chercher l’origine d’un bug, exécuter une suite de tests) et à séparer les rôles : un sous-agent de revue en lecture seule, un sous-agent qui exécute les tests, un sous-agent qui prépare la documentation.

La revue devient alors le point de passage critique. Quand les changements grossissent, la tentation est de valider sur la foi de la démonstration faite par l’agent. Cinq règles tiennent mieux :

1. Taille cible : des modifications courtes, du même ordre que ce que l’équipe relisait avant l’IA.
2. Un test par correction : le changement arrive avec le test qui échoue sans lui.
3. Intégration continue obligatoire : build, tests et analyse statique passent avant la relecture humaine, par exemple avec GitHub Actions.
4. Grille de relecture stable : le changement fait-il ce que le ticket demande, les erreurs sont-elles gérées, les droits d’accès sont-ils vérifiés, le périmètre des données est-il le bon.
5. Traçabilité : un humain reste responsable de la branche et de la fusion.

La vérification devient le vrai goulot. Le constat vaut pour l’ensemble des assistants de code : les gains réels et les limites des copilotes sont du même ordre.

Combien coûte Claude Code en équipe et comment le suivre ?

Le coût se lit sur deux lignes : l’accès (abonnement par développeur ou clés d’API facturées à l’usage) et la consommation de tokens générée par le travail, qui dépend de la taille du dépôt, de la longueur des sessions et du modèle.

Trois pratiques évitent les mauvaises surprises. Suivre la consommation par projet dans les traces de l’agent (Langfuse, ou LangSmith selon votre pile) pour voir quel usage pèse. Réserver les modèles les plus puissants à la conception et aux bugs retors, et garder les plus légers pour le travail mécanique, y compris un modèle Mistral hébergé en Europe quand la souveraineté compte. Mesurer la qualité, pas seulement le volume : un jeu d’évaluations rejoué à chaque évolution, avec Promptfoo par exemple, indique si un changement de modèle a dégradé les résultats. Evals, intégration continue et suivi de coût relèvent de la même discipline d’ingénierie, décrite sur la page evals, CI/CD et observabilité.

Par où commencer cette semaine

1. Écrire un CLAUDE.md de vingt lignes : commandes du projet, conventions, interdits.
2. Ouvrir les permissions utiles, et en garder deux ou trois derrière une validation humaine (publication, base de production, suppression).
3. Ajouter un premier hook, le plus simple : formatage et lint après chaque édition.
4. Fixer une taille cible de changement et une grille de relecture, puis les appliquer aux trois prochaines modifications.
5. Activer le suivi de consommation avant d’élargir l’usage à toute l’équipe.

Si ces sujets doivent être posés rapidement, des développeurs qui travaillent déjà ainsi peuvent installer ce cadre dans votre équipe : règles de revue, gestion des accès et des coûts. Et lorsque le code produit doit ensuite tenir en production, l’étape suivante consiste à reprendre un produit construit avec Claude Code avant d’empiler de nouvelles fonctionnalités.