Claude MD : les bonnes consignes pour toute l’équipe

L’intérêt : moins de temps passé à réexpliquer le contexte. Prenons un budget temps hypothétique : quatre développeurs qui répètent trois minutes de mise en contexte au début de cinq sessions chacun y consacrent 60 minutes par semaine. Un fichier d’instructions partagé centralise ces informations. Comparez le temps gagné sur les répétitions au temps consacré à sa maintenance : aucune économie n’est garantie.

Claude MD : à quoi sert le fichier CLAUDE.md ?

CLAUDE.md est un fichier Markdown qui contient les instructions que Claude Code lit pour votre projet, votre workflow personnel ou votre organisation. Voyez-le comme les consignes permanentes de l’équipe. La mémoire automatique, elle, est le carnet de travail que Claude tient à côté. Vous rédigez les consignes ; Claude alimente le carnet. Les deux contribuent au contexte sur lequel il fonde ses décisions. Guide de la mémoire d’Anthropic

Le bon critère est ce qui doit rester valable d’une session à l’autre. Une commande de test obligatoire a sa place dans les consignes. Votre remarque sur une explication trop détaillée peut devenir une préférence mémorisée. La tâche en cours, elle, relève de la conversation.

Cette répartition suit le guide officiel du répertoire. Inutile de créer un gros dossier .claude pour commencer. Rédigez d’abord les consignes, puis ajoutez un fichier seulement s’il répond à un besoin précis.

Où placer CLAUDE.md : projet, utilisateur ou organisation ?

Dans une petite équipe, versionnez un fichier de projet à la racine du dépôt. Gardez vos préférences personnelles dans votre fichier utilisateur pour éviter que vos collègues n’en héritent par inadvertance.

Il s’agit des portées et emplacements documentés. Les fichiers gérés par l’organisation ne peuvent pas être exclus au moyen des paramètres individuels, mais leur contenu reste de l’ordre de la consigne.

Au lancement, Claude charge les fichiers d’instructions du répertoire de travail et de ses répertoires parents. Il charge ceux des sous-répertoires lorsqu’il travaille sur les fichiers qu’ils contiennent. Ces instructions se cumulent : ajouter un fichier plus ciblé n’efface donc pas les consignes contradictoires présentes ailleurs. Veillez à la cohérence entre vos instructions utilisateur et celles du projet. Fonctionnement du chargement

Un exemple de CLAUDE.md pour une petite équipe produit

Notez les décisions qui évitent de répéter les mêmes erreurs. L’exemple ci-dessous suppose un produit en TypeScript utilisant pnpm, avec des scripts lint, typecheck et test déjà définis. Avant de versionner ce fichier, remplacez les commandes et les chemins par ceux que vous avez vérifiés dans votre dépôt.

Chaque section commence par une ligne qui explique son utilité. Ce sont des propositions de conventions d’équipe, pas les réglages par défaut d’Anthropic.

# Product Team Instructions

## Product Intent
Why: Keep implementation tied to the customer problem.
- Read the task's acceptance criteria before changing code.
- Ask when missing product behavior would change the solution.

## Working Commands
Why: Make verification repeatable across teammates and sessions.
- Use pnpm for this repository; keep pnpm-lock.yaml consistent.
- Run pnpm lint and pnpm typecheck for application changes.
- Run pnpm test for behavior changes; report any checks not run.

## Change Boundaries
Why: Keep reviews small and dependencies deliberate.
- Follow nearby patterns before adding a new abstraction.
- Ask before adding a runtime dependency or changing public APIs.
- Keep unrelated cleanup out of the change.

## Data and Migrations
Why: Make data changes reviewable and reversible where possible.
- Add schema changes through the existing migration workflow.
- Describe compatibility and rollback concerns in the handoff.
- Use synthetic data in examples and tests.

## Quality
Why: Catch user-visible regressions before review.
- Add a focused regression test when fixing a behavior bug.
- Check loading, empty and error states when changing UI flows.
- State remaining uncertainty instead of calling unchecked work done.

## Project References
Why: Point to maintained decisions without copying the whole wiki.
- Read docs/product-decisions.md when product behavior is unclear.
- Read docs/release-checklist.md before preparing a release.

Les références de cet exemple sont de simples consignes invitant à consulter des documents lorsque c’est pertinent. Créez ces documents ou remplacez les chemins. Le choix de ne pas en faire des imports automatiques est délibéré.

Enregistrez le fichier, lancez une session depuis le dépôt et exécutez /context pour vérifier la liste des fichiers de mémoire chargés au démarrage. Utilisez /memory pour ouvrir et modifier le fichier d’instructions. Confiez ensuite à Claude une petite tâche réelle et vérifiez si les commandes et les limites définies l’aident à travailler. Inspecter la mémoire

Sortez les règles propres à certains fichiers des consignes générales

Déplacez une règle dans .claude/rules/ lorsque la plupart des tâches n’en ont pas besoin. Une modification du frontend, par exemple, ne devrait pas embarquer toutes les conventions de vos gestionnaires de requêtes d’API.

Créez .claude/rules/api.md avec un en-tête paths. Un glob est un motif de nom de fichier : src/api/**/*.ts sélectionne les fichiers TypeScript de ce répertoire et de ses sous-répertoires.

---
paths:
  - "src/api/**/*.ts"
---

# API Rules
- Validate external input before passing it to application logic.
- Use the existing error response format.
- Add a focused test when changing an endpoint's behavior.

Ce motif détermine à quel moment l’instruction entre dans le contexte. Sans paths, la règle se charge systématiquement au démarrage. Découper de longues consignes en plusieurs fichiers de règles ne réduit pas le contexte si leur chargement n’est pas limité à un périmètre précis. Règles ciblées par chemin

Les imports partagent du texte, sans réduire son coût en contexte

Un import comme @docs/team-conventions.md dans CLAUDE.md charge ce fichier dans le contexte au lancement. Les chemins relatifs sont résolus à partir du fichier qui contient l’import. Placez l’import en dehors des accents graves et des blocs de code Markdown, qui le conserveraient comme du texte littéral. Les imports de projet situés hors de votre répertoire de travail déclenchent une demande d’autorisation. Syntaxe des imports

Importez une courte convention déjà tenue à jour par une autre équipe si elle est utile à chaque session. Pour une longue checklist de publication, préférez une simple référence, comme dans le modèle ci-dessus. Un import réorganise les consignes ; il ne réduit pas la quantité de texte que Claude lit au démarrage.

Vous avez déjà un AGENTS.md ? Gardez une seule source de consignes

Claude Code peut utiliser directement AGENTS.md à la place de CLAUDE.md à partir de la version 2.1.277, lorsque cette prise en charge est disponible. Son comportement par défaut comporte une condition importante : aucun fichier CLAUDE.md, .claude/CLAUDE.md ou CLAUDE.local.md ne doit se trouver dans votre répertoire de travail ni dans ses répertoires parents. Vos fichiers d’instructions utilisateur et d’organisation n’empêchent pas ce chargement de remplacement. Chargement d’AGENTS.md

CLAUDE.local.md peut donc facilement prêter à confusion. L’ajout de notes personnelles au projet peut changer le fichier d’instructions partagé qui se charge pour vous.

Si vous avez besoin des deux fichiers, ouvrez /config et réglez Project instructions sur claude-md-and-agents-md. Vous pouvez aussi placer @AGENTS.md dans un CLAUDE.md situé à côté : cet import fonctionne également lorsque la prise en charge directe d’AGENTS.md n’est pas disponible. Évitez de maintenir deux copies des règles de l’équipe. Notre guide de configuration d’AGENTS.md détaille ce choix.

Mémoire de Claude Code : laissez la mémoire automatique retenir les enseignements

La mémoire automatique permet à Claude de conserver les préférences, corrections et éléments de contexte utiles d’une conversation à l’autre. Il décide de ce qui mérite d’être retenu et peut ne rien enregistrer au cours d’une session. Elle est activée par défaut dans les sessions locales. Mémoire automatique

Par défaut, les fichiers se trouvent dans ~/.claude/projects/<project>/memory/. Les worktrees et les sous-répertoires d’un même dépôt partagent ce dossier de mémoire sur votre machine. Un worktree est une autre copie de travail du dépôt : y travailler sur une branche ne vous donne donc pas un carnet indépendant. Ces fichiers ne sont pas automatiquement partagés avec vos collègues, d’autres machines ou des environnements cloud. Emplacement de stockage

MEMORY.md sert d’index. Au début d’une session, Claude en charge les 200 premières lignes ou les premiers 25KB, selon la limite atteinte en premier. Les fichiers thématiques détaillés sont lus au besoin. Ce seuil concerne le chargement initial de l’index, pas la quantité totale de mémoire que vous pouvez stocker. Chargement de la mémoire automatique

Commencez par /memory : cette commande recense les emplacements de mémoire, ouvre les fichiers dans votre éditeur, donne accès au dossier de mémoire automatique et permet d’activer ou de désactiver celle-ci. Utilisez /context pour vérifier quels fichiers CLAUDE.md et quelles règles ont été chargés au lancement. Commandes de gestion de la mémoire

Précisez où l’information doit aller. « Retiens que je préfère des comptes rendus plus courts » demande une note mémorisée. « Ajoute notre commande de test obligatoire à CLAUDE.md » demande une consigne tenue à jour. Une règle utile à toute l’équipe ne devrait pas dépendre d’une note dans le répertoire personnel d’un seul développeur.

Ne partez pas du principe qu’un sous-agent ordinaire reçoit ce carnet. La mémoire automatique de la conversation principale n’est pas chargée dans les sous-agents ordinaires ; les forks qui héritent de la conversation parente font exception, et les sous-agents peuvent disposer de leur propre mémoire configurée. Consultez notre guide des sous-agents de Claude Code lorsque vous répartissez le travail entre agents. Comportement de la mémoire pour les sous-agents

Comment désactiver la mémoire automatique ?

Choisissez le réglage qui correspond à votre besoin :

• Pour votre utilisateur : ouvrez /memory et désactivez la mémoire automatique. Le bouton enregistre autoMemoryEnabled dans ~/.claude/settings.json.
• Pour un projet : définissez "autoMemoryEnabled": false dans ses paramètres. Utilisez .claude/settings.json pour un réglage partagé du projet ou .claude/settings.local.json pour votre configuration locale.
• Pour un lancement piloté par l’environnement : définissez CLAUDE_CODE_DISABLE_AUTO_MEMORY=1.

Ce sont les moyens de désactivation et les emplacements des paramètres documentés. Désactiver la mémoire automatique laisse disponible le mécanisme distinct d’instructions CLAUDE.md. Pour supprimer aussi les anciennes notes, examinez puis supprimez explicitement les fichiers Markdown concernés.

Faites le ménage dans la mémoire automatique chaque mois

Voyez cette opération comme une courte relecture éditoriale de ce que Claude emportera dans ses prochains travaux. Le rythme mensuel est une habitude d’équipe proposée ici, pas une exigence du produit.

1. Ouvrez /memory et parcourez le dossier de mémoire automatique. Lisez MEMORY.md, puis suivez ses références pour consulter les notes elles-mêmes.
2. Supprimez le contexte périmé. Retirez les échéances passées, les plans abandonnés et les exceptions qui ne s’appliquent plus. Vérifiez les notes incertaines à la lumière de l’état actuel du projet.
3. Regroupez les corrections répétées. Gardez une formulation exacte plutôt que plusieurs versions légèrement différentes.
4. Intégrez les décisions durables aux consignes d’équipe. Déplacez les conventions utiles à tous dans le CLAUDE.md versionné ou dans une règle ciblée, puis supprimez la note personnelle devenue redondante.
5. Raccourcissez l’index. Gardez de brefs renvois dans MEMORY.md et les détails dans les fichiers thématiques. Vérifiez le nombre de lignes et la taille en octets par rapport au seuil de chargement initial.
6. Testez une nouvelle session. Contrôlez la liste des instructions avec /context et repérez les éventuels conseils périmés lors de la prochaine tâche réelle.

Les fichiers de mémoire automatique sont du Markdown modifiable, et la politique de conservation des transcriptions ne les nettoie pas automatiquement. Il faut donc toujours que quelqu’un retire les notes obsolètes. Modification et conservation

Cinq situations où cette organisation est utile

Commencez là où les corrections répétées ralentissent déjà les revues. Voici des workflows proposés, classés selon leur utilité probable pour une petite équipe produit.

Deux pistes de services ou d’outils à développer

La piste la plus solide est l’audit des instructions d’un dépôt. Une petite équipe pourrait payer pour une revue qui vérifie les commandes, repère les consignes contradictoires et propose un fichier concis accompagné de règles ciblées. Le livrable minimal utile serait une pull request relue et une checklist d’audit réutilisable. DataForSEO estime à 260 le nombre de recherches mensuelles aux États-Unis pour « claude project instructions ». Cette requête large couvre des usages au-delà de Claude Code : elle signale un intérêt à explorer, pas un nombre d’acheteurs. Un modèle générique se copie facilement ; la valeur payante devrait donc résider dans une analyse propre au dépôt.

Un rapport local sur l’état de la mémoire pourrait aider les équipes qui travaillent sur de nombreux dépôts actifs. Une première version pourrait signaler les index trop volumineux, les références vers des fichiers thématiques absents et les notes potentiellement périmées, puis laisser le développeur examiner les modifications. DataForSEO estime à 1,300 le nombre de recherches mensuelles aux États-Unis pour « claude code memory ». Cela traduit un intérêt pour le problème, pas une demande pour cet outil précis. La difficulté est réelle : l’âge d’un fichier ne permet pas de savoir si une décision est obsolète. Laissez les décisions sur le fond à la personne qui connaît le projet.

Ces deux estimations proviennent de résultats de l’outil d’aperçu des mots-clés, pour les États-Unis et en anglais, récupérés le 11 octobre 2026 via l’intégration de recherche DataForSEO du site. Il s’agit de propositions de produits, pas de fonctionnalités intégrées à Claude Code. Pour un seul petit dépôt, commencez par le fichier et la revue mensuelle avant d’acheter ou de développer l’une de ces solutions.

La mémoire donne du contexte ; elle ne fait pas respecter les règles

Écrire « ne fais jamais cela » dans CLAUDE.md ne rend pas une action impossible. Il en va de même pour la mémoire automatique et les consignes rédigées à l’échelle de l’organisation. Claude peut mal interpréter une instruction vague ou rencontrer des consignes contradictoires. Mise en garde d’Anthropic

Utilisez un hook PreToolUse, un contrôle exécuté avant l’action d’un outil, lorsque vous devez bloquer cette action indépendamment de la décision de Claude. Un rappel sur les fichiers protégés peut expliquer l’intention de l’équipe ; le blocage exige un contrôle effectivement mis en place. Notre guide de configuration des hooks de Claude Code explique comment le configurer.

Pour maîtriser la taille du contexte, visez des consignes qu’une personne pourra réellement maintenir. Anthropic recommande de garder chaque fichier CLAUDE.md sous les 200 lignes, mais cette recommandation est distincte de la limite de chargement initial de MEMORY.md. N’allongez pas votre modèle pour atteindre un quota supposé, et ne déplacez pas tout dans des imports en pensant réduire le coût. Rédiger des instructions efficaces

Les questions concrètes d’une petite équipe

Dès lundi : reprenez les corrections de vos dernières sessions, rassemblez les décisions récurrentes de l’équipe dans un CLAUDE.md relu et testez-le sur une petite tâche. Inscrivez la revue mensuelle de la mémoire au calendrier de l’équipe.

Pour transformer ces conventions en un workflow de développement fiable, découvrez notre service de systèmes de production avec l’IA.