Claude Code Rules : Comment écrire CLAUDE.md et gérer le contexte de codage agentique

Les règles de Claude Code se trouvent dans les fichiers CLAUDE.md — des fichiers Markdown que vous placez dans votre dépôt projet, votre répertoire personnel ou la configuration de votre organisation, et que Claude lit au début de chaque session. Combinées aux règles de portée dans .claude/rules/, à un settings.json pour les permissions et à la mémoire automatique pour les préférences apprises, ce système de règles vous offre un contrôle précis et persistant sur la façon dont l’agent de codage se comporte dans toute tâche.

Que sont les règles Claude Code ?

Chaque session Claude Code commence avec une fenêtre de contexte vide. Les règles sont la manière dont vous préchargez le contexte dont Claude a besoin pour qu’il ne parte pas de zéro — ou ne refasse pas la même erreur deux fois.

Deux systèmes complémentaires gèrent cela :

Les fichiers CLAUDE.md sont des fichiers Markdown que vous écrivez et que Claude lit au début de chaque session. Utilisez-les pour des instructions qui doivent toujours s’appliquer : commandes de build, conventions de code, décisions d’architecture, contraintes strictes.

La mémoire automatique est constituée de notes que Claude écrit lui-même en fonction des corrections et préférences que vous lui donnez pendant les sessions. Elles s’accumulent automatiquement ; Claude décide ce qui mérite d’être sauvegardé et relit ces notes dans les sessions futures.

Les deux sont chargés dans le contexte au début de la session, mais ne sont pas une configuration imposée. Ce sont des instructions que Claude suit comme contexte. Pour une application stricte — bloquer une commande spécifique quoi que Claude décide de faire — vous avez besoin d’un hook PreToolUse ou d’une règle deny dans settings.json. La distinction est importante pour les exécutions autonomes où vous voulez un comportement prévisible, pas une conformité probabiliste.

Emplacements et portée des fichiers CLAUDE.md

Claude Code charge les fichiers CLAUDE.md depuis plusieurs emplacements, chacun couvrant une portée différente. Ils sont chargés dans l’ordre, du plus large au plus spécifique :

Emplacement	Portée	À quoi ça sert
~/.claude/CLAUDE.md	Tous les projets sur votre machine	Préférences personnelles, habitudes de travail globales
./CLAUDE.md (racine du dépôt)	Toutes les sessions dans ce projet	Conventions du projet, commandes de build, règles partagées par l’équipe
./CLAUDE.local.md (racine du dépôt)	Uniquement vos sessions locales	Préférences par développeur ; à ajouter dans .gitignore
./src/CLAUDE.md (sous-répertoire)	Sessions touchant les fichiers de ce répertoire	Règles spécifiques à un module qui ne s’appliquent pas à tout le projet

Tous les fichiers découverts sont concaténés dans le contexte — ils ne se remplacent pas. Dans cette concaténation, le contenu allant de la racine du système de fichiers à votre répertoire de travail est ordonné du plus large au plus spécifique, de sorte qu’une instruction de projet apparaît après une instruction utilisateur. Cela vous donne une spécificité naturelle : une règle de projet l’emporte en cas de conflit avec une règle au niveau utilisateur.

Vous pouvez importer des fichiers supplémentaires avec des références @path dans n’importe quel CLAUDE.md :

@./docs/architecture.md
@./CONTRIBUTING.md

Les fichiers importés sont chargés au début de la session, comme le CLAUDE.md lui-même. Les imports sont utiles pour l’organisation mais n’économisent pas de contexte — le contenu importé compte dans votre budget de tokens.

Pour les équipes : engagez le fichier CLAUDE.md du projet dans le contrôle de source. Cela garantit que chaque session Claude de chaque développeur — et toute exécution d’agent basée sur CI — commence avec le même contexte partagé. Traitez-le comme .eslintrc ou pyproject.toml.

Que mettre dans CLAUDE.md

Le contenu le plus utile est ce que vous devriez autrement réexpliquer à chaque session, ou ce qu’un nouveau membre de l’équipe aurait besoin de savoir dans sa première heure.

Bons candidats :

• Les commandes de build et de test qui diffèrent des valeurs par défaut évidentes (./scripts/test.sh --ci, pas seulement npm test)
• Les conventions de code qui ne sont pas capturées par le linter (« nous utilisons des exports nommés partout ; pas d’exports par défaut dans les utilitaires partagés »)
• Les décisions d’architecture qui ne sont pas évidentes en lisant le code (« le répertoire lib/ est partagé entre les services — n’y ajoutez pas de logique propre à un service »)
• Les pièges connus (« le fichier config.ts est généré au moment du build ; ne l’éditez pas manuellement »)
• Les contraintes de workflow (« créez toujours une branche avant de faire des modifications ; poussez vers le remote avant d’ouvrir une PR »)

Choses à ne pas inclure :

• Les listes de répertoires et arborescences de fichiers — Claude les lit depuis le dépôt
• Les listes de dépendances — disponibles dans package.json, pyproject.toml et similaires
• Les descriptions en prose de ce que fait le code existant — Claude lit le code source directement
• Les changements récents — Claude utilise git log et git diff quand il a besoin de l’historique

Gardez CLAUDE.md concentré sur ce qui ne peut pas être déduit en lisant la base de code. Les fichiers de plus de 200 lignes consomment plus de contexte et réduisent la fiabilité de l’observance. La commande /doctor dans Claude Code audite un CLAUDE.md engagé et suggère de supprimer le contenu dérivable du code — un moyen utile de réduire un fichier gonflé.

Écrire des règles efficaces

La spécificité compte. Comparez :

# Vague — moins cohérent
Respectez les normes de codage du projet.

# Spécifique — plus cohérent
- Utilisez pnpm, pas npm ou yarn
- Exécutez pnpm test avant chaque commit ; ne commitez pas si les tests échouent
- Exportez tous les types partagés depuis src/types/index.ts — ne définissez pas les types en ligne dans les fichiers de composants
- Le répertoire data/ est en lecture seule dans les tests ; utilisez les fixtures de test depuis tests/fixtures/ à la place

Chaque règle doit être actionnable sans explication supplémentaire. Si vous deviez expliquer le raisonnement d’une règle à quelqu’un, ajoutez le raisonnement en ligne — cela aide Claude à appliquer la règle correctement dans les cas limites.

Règles de portée avec .claude/rules/

Le répertoire .claude/rules/ vous permet d’attacher des règles à des motifs de fichiers spécifiques sans les charger dans chaque session. Claude découvre les fichiers dans .claude/rules/ et les charge lorsque vous travaillez avec des fichiers correspondants.

Une structure typique pour un monorepo TypeScript :

.claude/rules/
  api.md             # règles pour src/api/** — validation des requêtes, formats d’erreur
  components.md      # règles pour src/components/** — types de props, conventions de style
  tests.md           # règles pour tests/** — motifs de fixtures, configuration de mock
  database.md        # règles pour migrations/ et models/ — nommage des migrations, motifs de requêtes

Chaque fichier de règle utilise un frontmatter YAML avec un champ paths pour contrôler quand il se charge :

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

# Règles de développement API

- Tous les gestionnaires de route doivent valider l’entrée avec zod avant toute logique métier
- Retournez les erreurs sous la forme `{ error: string; code: string }` — jamais de chaînes simples
- Le rate limiting est appliqué à la passerelle ; ne l’ajoutez pas à l’intérieur des gestionnaires

Les règles sans champ paths se chargent inconditionnellement au début de la session, comme le contenu du CLAUDE.md du projet. Les règles avec paths se chargent uniquement lorsque Claude ouvre des fichiers correspondant à ces motifs.

Cela permet de garder le CLAUDE.md racine du projet concis et garantit que les conventions détaillées pour une couche de la pile ne remplissent pas le contexte pendant les sessions axées sur une zone différente.

settings.json vs CLAUDE.md

CLAUDE.md contrôle ce que Claude sait et a l’intention de faire. settings.json contrôle ce que Claude est réellement autorisé à faire.

	CLAUDE.md	settings.json
Objectif	Instructions et contexte	Permissions et configuration
Appliqué ?	Non — Claude agit selon les instructions	Oui — les règles deny bloquent les appels d’outils inconditionnellement
Format	Markdown libre	JSON structuré
Emplacement	./CLAUDE.md, ~/.claude/CLAUDE.md	.claude/settings.json, ~/.claude/settings.json

Un settings.json de projet à .claude/settings.json :

{
  "permissions": {
    "allow": [
      "Bash(pnpm test)",
      "Bash(pnpm build)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)"
    ]
  }
}

La liste allow pré-approuve des commandes spécifiques afin que Claude puisse les exécuter sans invite. Cela accélère les sessions interactives pour les opérations que vous jugez fiables. La liste deny bloque les commandes inconditionnellement — quoi que Claude décide de faire, quoi que dise CLAUDE.md. Utilisez deny pour les opérations irréversibles sur les données de production ou l’infrastructure.

Les paramètres au niveau utilisateur dans ~/.claude/settings.json s’appliquent à tous les projets. Les paramètres de projet dans .claude/settings.json s’appliquent uniquement dans ce dépôt. Les paramètres de projet prennent le pas sur les paramètres utilisateur en cas de chevauchement.

Mémoire automatique : les notes de Claude

La mémoire automatique est le pendant de CLAUDE.md. Alors que CLAUDE.md est constitué d’instructions que vous écrivez, la mémoire automatique est constituée de notes que Claude écrit lui-même en fonction de ce qu’il apprend pendant vos sessions.

Lorsque vous corrigez Claude pendant une session — « nous utilisons Vitest, pas Jest dans ce projet » — il peut enregistrer cela comme une note dans ~/.claude/projects/<repo>/memory/. La session suivante, Claude relit cette note et applique la correction sans qu’on ait à la lui redire.

Le répertoire mémoire contient :

~/.claude/projects/<repo>/memory/
  MEMORY.md          # index que Claude utilise pour trouver d’autres fichiers ; les 200 premières lignes sont chargées à chaque session
  debugging.md       # motifs que Claude a découverts en résolvant des problèmes dans ce dépôt
  conventions.md     # conventions que Claude a apprises de vos corrections

C’est local à la machine et par dépôt. La mémoire automatique complète CLAUDE.md plutôt que de le remplacer : CLAUDE.md est pour les règles de projet partagées par l’équipe ; la mémoire automatique est pour les motifs personnels que Claude a appris en travaillant avec vous.

La mémoire automatique est un Markdown lisible que vous pouvez éditer ou supprimer à tout moment. Exécutez /memory dans une session pour parcourir et modifier les fichiers. Si quelque chose est obsolète ou erroné, supprimez-le — Claude cessera d’appliquer la règle obsolète.

Bonnes pratiques pour le codage agentique

Faire fonctionner Claude Code de manière autonome — via claude -p, le SDK Agent, ou des pipelines CI — augmente les enjeux de votre configuration de règles. L’agent peut effectuer des dizaines d’appels d’outils sans s’arrêter, et il n’y a pas d’échange interactif pour rattraper les malentendus en cours d’exécution.

Écrivez des contraintes explicites, pas seulement des préférences. Claude en mode interactif peut vous demander de clarifier. Une exécution autonome travaille avec ce qu’elle trouve dans le contexte. Si « ne jamais modifier les fichiers de migration sans créer d’abord un instantané de base de données » est important, cela doit figurer dans CLAUDE.md. Ne supposez pas que Claude déduira la contrainte de la structure de la base de code.

Utilisez les règles deny pour tout ce qui est difficile à inverser. Pré-approuver Bash(pnpm build) accélère les sessions interactives et présente un faible risque. Mais pour les exécutions autonomes, la liste deny est votre filet de sécurité pour les opérations qui touchent l’infrastructure de production, qui s’engagent définitivement dans l’historique git, ou qui suppriment des données.

Gardez le CLAUDE.md du projet dans le contrôle de version. Un CLAUDE.md engagé à la racine du dépôt s’applique de manière cohérente aux sessions interactives, aux exécutions CI et à tout agent local d’un membre de l’équipe. C’est le bon endroit pour les règles qui définissent ce que « correct » signifie pour votre base de code.

Utilisez .claude/rules/ pour le contenu spécifique à un domaine. Si votre projet a des couches distinctes — composants frontend, API backend, schéma de base de données, scripts d’infrastructure — placez les règles de chaque couche dans .claude/rules/ avec une portée de chemin. Un seul CLAUDE.md de 400 lignes avec tout dedans est plus difficile à naviguer pour Claude et coûte plus de contexte par session.

Déplacez le matériel de référence dans les skills. Les skills (.claude/skills/) se chargent à la demande, pas au début de la session. La documentation API longue, les procédures de déploiement en plusieurs étapes et les playbooks de dépannage appartiennent aux skills que vous invoquez avec /deploy ou /debug — pas dans CLAUDE.md où ils consomment du contexte même lorsqu’ils ne sont pas pertinents.

Revoyez périodiquement la mémoire automatique. La mémoire automatique s’accumule avec le temps. Les commandes de build changent, les conventions sont refactorisées, les motifs de test évoluent. Une note mémoire obsolète qui dit « utiliser le client API v1 » alors que vous avez migré vers v2 provoquera des bugs subtils dans les exécutions autonomes. Auditez ~/.claude/projects/<repo>/memory/ lorsque vous apportez des modifications significatives à la structure du projet.

Utiliser des modèles open-source avec votre configuration de règles

Le contexte CLAUDE.md et .claude/rules/ que vous avez construits fonctionnent de la même manière quel que soit le modèle qui gère l’inférence. Une fois vos règles écrites, le changement de backend de modèle préserve tout cela — et les modèles open-source via l’API LLM de Novita AI sont une option pratique pour le travail agentique à haut volume.

La configuration se fait avec une variable d’environnement :

export ANTHROPIC_BASE_URL="https://api.novita.ai/anthropic"
export ANTHROPIC_AUTH_TOKEN="<votre-clé-api-novita>"
export ANTHROPIC_MODEL="qwen/qwen3-coder-480b-a35b-instruct"

Avec ANTHROPIC_BASE_URL pointant vers Novita AI, Claude Code envoie toutes les demandes d’inférence au point de terminaison compatible Anthropic de Novita au lieu de api.anthropic.com. Votre CLAUDE.md, vos règles de portée et votre settings.json s’appliquent exactement comme avant — la couche de règles est en amont de la sélection du modèle.

Novita AI héberge des modèles open-weight axés sur le codage, notamment Qwen3-Coder, GLM-4.7, MiniMax M2.5 et DeepSeek V4. Ces modèles sont optimisés pour l’utilisation d’outils en plusieurs étapes et l’appel de fonctions, ce qui correspond bien aux motifs d’appel d’outils que Claude Code utilise en interne pour les éditions de fichiers, les commandes shell et la navigation dans les dépôts.

Pour les équipes qui exécutent des tâches agentiques à grande échelle — pipelines de revue de code, refactorisation automatisée dans de grands dépôts, génération de tests — les modèles open-weight sur Novita coûtent généralement beaucoup moins cher par million de tokens que les alternatives closed-source, tout en lisant et en appliquant efficacement vos règles de projet.

Si vous exécutez des agents sur une base de code de production et que vous souhaitez une couche de sécurité supplémentaire au-delà des règles deny, envisagez d’associer l’API LLM de Novita à Novita Agent Sandbox. Le sandbox offre à l’agent un environnement Linux complet pour les opérations sur fichiers et l’exécution de commandes, isolé de votre système hôte. Le contexte de votre CLAUDE.md accompagne la tâche ; le risque d’exécution reste confiné.

FAQ

Qu’est-ce que CLAUDE.md dans Claude Code ?

CLAUDE.md est un fichier Markdown qui donne à Claude Code des instructions persistantes entre les sessions. Il se charge au début de la session afin que Claude n’ait pas besoin de se faire réenseigner les conventions de votre projet à chaque fois. Vous pouvez avoir des fichiers CLAUDE.md à plusieurs niveaux : au niveau utilisateur (~/.claude/CLAUDE.md) pour les préférences personnelles qui s’appliquent partout, au niveau du projet (racine du dépôt) pour les règles partagées par l’équipe et engagées dans le contrôle de version, et au niveau du sous-répertoire pour les règles spécifiques à un module.

Que dois-je mettre dans les fichiers de règles claude md ?

Écrivez ce que vous devriez autrement réexpliquer à chaque session : commandes de build et de test, conventions de codage qui diffèrent des valeurs par défaut du framework, contraintes d’architecture et pièges connus de la base de code. Laissez de côté le contenu que Claude peut déduire de la base de code elle-même — arborescences de fichiers, listes de dépendances et descriptions de ce que fait le code existant. Gardez les fichiers sous 200 lignes pour une observance cohérente.

Quelle est la différence entre CLAUDE.md et settings.json dans Claude Code ?

CLAUDE.md est constitué d’instructions que Claude suit comme guide. settings.json est une configuration que Claude Code applique au niveau du système. Une règle dans CLAUDE.md façonne ce que Claude a l’intention de faire ; une entrée deny dans settings.json bloque un appel d’outil inconditionnellement. Pour tout ce qui ne doit pas arriver quoi que Claude décide — suppressions irréversibles, pushs forcés, opérations en environnement de production — utilisez settings.json, pas CLAUDE.md.

Qu’est-ce que le répertoire .claude/rules/ ?

.claude/rules/ contient des fichiers de règles avec portée de chemin qui ne se chargent que lorsque Claude travaille avec des fichiers correspondant à la portée de la règle. Cela vous permet d’écrire des règles détaillées et spécifiques à un domaine sans les charger dans chaque session. Les règles sont des fichiers Markdown avec un frontmatter YAML optionnel spécifiant des motifs glob paths. Les règles sans frontmatter paths se chargent inconditionnellement au début de la session, comme du contenu CLAUDE.md supplémentaire.

CLAUDE.md fonctionne-t-il dans les tâches CI et les tâches claude code automatisées ?

Oui. Toute invocation claude -p, appel SDK Agent ou pipeline CI s’exécutant dans un répertoire de dépôt charge le CLAUDE.md du projet. Cela rend CLAUDE.md efficace pour imposer un comportement cohérent dans les contextes interactifs et automatisés. L’engager dans le contrôle de version garantit que chaque exécution — locale et CI — commence avec le même contexte partagé.

Comment fonctionne le contexte de claude code et comment le gérer ?

Le contexte est le budget de tokens pour la session en cours. Les fichiers CLAUDE.md, les références importées, la mémoire automatique et l’historique de la conversation en font tous partie. Gérez-le en gardant CLAUDE.md concis, en utilisant .claude/rules/ pour charger le contenu de domaine uniquement lorsqu’il est pertinent, et en utilisant /compact pour résumer les longues sessions sans perdre la continuité. Après /compact, Claude relit le CLAUDE.md racine du projet depuis le disque et le réinjecte automatiquement dans la session.

Comment utiliser les meilleures pratiques de claude code pour le codage agentique en équipe ?

Engagez le fichier CLAUDE.md du projet dans votre dépôt afin que tous les membres de l’équipe et les agents CI partagent les mêmes règles. Utilisez .claude/rules/ avec une portée de chemin pour le contenu spécifique à un domaine. Ajoutez des règles deny à .claude/settings.json pour les opérations qui ne devraient jamais s’exécuter dans des contextes automatisés. Gardez la mémoire automatique hors de CI — elle est locale à la machine et propre à chaque développeur ; le CLAUDE.md engagé est la source de vérité pour le comportement partagé.

Novita AI est une plateforme cloud IA qui offre aux développeurs un moyen simple de déployer des modèles IA via notre API simple, tout en fournissant des GPU cloud abordables et fiables pour construire et passer à l’échelle.

Articles recommandés

• Documentation CLI Claude Code : Configuration, commandes slash et intégration API LLM
• SDK Claude Code : Construire des agents autonomes avec Python et TypeScript
• Construire un agent de codage avec Novita Agent Sandbox

---

Sources vérifiées le 21 juillet 2026 : Documentation mémoire Claude Code, Vue d’ensemble des fonctionnalités Claude Code, API LLM Novita AI