--- title: "CLAUDE.md et AGENTS.md : apprendre les règles à votre agent" description: "Écrire un fichier de règles de projet qui rend votre agent constant, et le faire grandir en une skills library vivante où chaque piège devient une règle permanente" type: "lesson" locale: "fr" course: "Claude Code Mastery - Devenir power user" number: "2.1" canonical: "https://agenticschool.dev/fr/cours/claude-code-mastery/claude-md-and-agents-md-teaching-your-agent-the-rules" datePublished: "2026-06-12" dateModified: "2026-06-12" --- # CLAUDE.md et AGENTS.md : apprendre les règles à votre agent - Course: Claude Code Mastery - Devenir power user - Lesson: 2.1 - Duration: 24 min - Level: einsteiger - Status: published - Canonical URL: https://agenticschool.dev/fr/cours/claude-code-mastery/claude-md-and-agents-md-teaching-your-agent-the-rules - Locale: fr > Écrire un fichier de règles de projet qui rend votre agent constant, et le faire grandir en une skills library vivante où chaque piège devient une règle permanente ## Summary Un fichier de règles de projet est de loin l'upgrade le plus impactant pour votre agent. CLAUDE.md (pour Claude Code) et AGENTS.md (pour Codex et d'autres harness) disent à l'agent vos conventions, votre stack, vos garde-fous et votre ton une seule fois, pour qu'il cesse de les redécider à chaque tâche. Cette leçon montre comment en écrire un et le faire tourner comme un système markdown en apprentissage continu, où chaque correction que vous faites est consignée pour toujours. ## What you learn - Ce qui doit aller dans CLAUDE.md et AGENTS.md et comment l'agent les lit à chaque tour - La philosophie de la skills library : consigner chaque correction récurrente comme une règle permanente - Le faire tourner comme un système markdown en apprentissage continu, pour que l'agent s'améliore avec le temps ## Vue d'ensemble CLAUDE.md et AGENTS.md sont de simples fichiers markdown posés dans votre repository, que l'agent lit automatiquement au début de chaque session. Ils contiennent vos axiomes, votre stack, vos conventions, vos règles de sécurité et votre ton. En écrire un bon fait la différence entre corriger éternellement les mêmes cinq erreurs et un agent qui comprend simplement votre projet. L'idée plus profonde qui s'accumule est de traiter le fichier comme une skills library vivante : chaque piège que vous rencontrez migre une fois dans un fichier markdown et ne vous coûte plus jamais rien. ## Ce que vous allez apprendre Vous allez apprendre exactement ce qui doit aller dans un fichier de règles de projet, comment formuler les règles en axiomes nets que l'agent suit vraiment, la différence entre une CLAUDE.md racine et l'AGENTS.md que Codex et d'autres harness lisent, et comment faire du fichier un système en apprentissage continu où chaque correction répétée devient une règle permanente. À la fin, vous aurez un vrai fichier à insérer dès aujourd'hui dans votre propre projet. ## Prérequis Un setup Claude Code fonctionnel et la leçon de prompt engineering du Cours 1, car les axiomes que vous y avez écrits migrent directement dans ce fichier. Vous devez aussi avoir un projet sous version control issu du Cours 1, car le fichier de règles vit dans le repo et est committé aux côtés de votre code, pour que tout le projet partage les mêmes standards. ## Le problème Vous corrigez l'agent. Il utilise le mauvais gestionnaire de paquets, vous le corrigez. Il insère un em-dash, vous le corrigez. Il saute le test, vous le corrigez. Session suivante, contexte frais, les trois mêmes erreurs. Vous payez des tokens et de l'attention pour réapprendre les mêmes leçons encore et encore, parce que rien de ce que vous avez dit n'a survécu. L'agent n'est pas bête, il n'a simplement pas de mémoire entre les sessions. Un fichier de règles est cette mémoire. Sans lui, votre agent démarre chaque jour amnésique et vous êtes son surveillant à plein temps. ## Ce qu'un fichier de règles est réellement CLAUDE.md est un fichier markdown que Claude Code charge automatiquement et traite comme une instruction permanente pour toute la session. Posez-le à la racine de votre repo pour des règles à l'échelle du projet. Vous pouvez aussi en garder un personnel sous ~/.claude/CLAUDE.md pour des règles qui vous suivent sur chaque projet, et Claude Code les fusionne. AGENTS.md est le fichier équivalent que Codex et un nombre croissant d'autres harness lisent, donc une équipe multi-outils garde souvent les deux, ou les vraies règles dans l'un et un court renvoi dans l'autre. Tout ce que vous retaperiez sinon dans chaque prompt a sa place ici : langage, framework, gestionnaire de paquets, politique de tests, règles de sécurité, conventions de nommage et ton. - CLAUDE.md racine : règles de projet, committée dans le repo, partagée par tous ceux qui y travaillent. - ~/.claude/CLAUDE.md personnelle : vos propres préférences inter-projets, non committée. - AGENTS.md : le même rôle pour Codex et d'autres harness, pour que les setups multi-outils restent constants. - Elle est chargée à chaque tour, alors gardez-la serrée - un fichier de règles boursouflé mange le même context window dont votre tâche a besoin. ## Écrire les règles en axiomes Un agent suit bien mieux un absolu net qu'un paragraphe plein de nuances. Formulez chaque règle en « Toujours... », « Jamais... » ou « Chaque... doit... ». Regroupez-les par thème pour que le fichier reste scannable. Voici une vraie CLAUDE.md compacte que vous pourriez déposer aujourd'hui dans un projet. Remarquez qu'elle couvre les choses que vous corrigez sans cesse, pas tout l'imaginable. Court et suivi bat long et ignoré. ```markdown # Project Rules ## Stack - TypeScript only. No plain JavaScript files. - Package manager is bun. Never use npm or yarn. - Framework is Astro for marketing pages, React for the app. ## Conventions - Use rounded-sm for border-radius on everything. - Never use em dashes. Use a normal "-" instead. - Components are PascalCase, files are kebab-case. ## Quality - Every new feature ships with a test. - Before you say a task is done, run: bun run lint && bun run typecheck && bun run test. ## Security - Secrets live in .env, which is gitignored. Never write a key into committed code. - Default new repos to private. ## Tone - Direct and concise. No filler, no apologising, no "as an AI". ``` Une vraie CLAUDE.md que vous pouvez adapter à votre propre projet ## La philosophie de la skills library C'est la partie qui transforme un fichier de configuration en avantage concurrentiel. Traitez CLAUDE.md comme une bibliothèque grandissante de savoir durement acquis, pas comme un setup unique. Chaque fois que l'agent fait une erreur qui va se reproduire, vous ne la corrigez pas seulement sur le moment - vous l'écrivez comme une règle. L'agent a choisi le mauvais dossier pour les tests ? Ajoutez une règle. Il a mal compris le fonctionnement de votre flux d'auth ? Ajoutez une note. Sur quelques semaines, le fichier devient un modèle précis de la façon dont votre projet fonctionne vraiment, plein de pièges qu'aucun modèle générique ne pourrait connaître. L'agent a alors besoin de moins en moins de conduite à la main, parce que le savoir institutionnel vit dans le repo, pas dans votre tête. - Le déclencheur est la répétition : chaque correction que vous pouvez imaginer refaire deux fois devient une règle dès la première fois. - Consignez les pièges, pas seulement le style : « le Convex Dev Server doit tourner avant les tests » vaut plus qu'une règle de nommage. - Vous pouvez le déléguer à l'agent : « Ajoute une règle dans la CLAUDE.md pour ne plus jamais refaire cette erreur » fonctionne et est une habitude à entretenir. - Le fichier est partagé et committé, donc un piège que vous avez découvert est désormais résolu pour chaque session future et chaque membre de l'équipe. ## Le garder vivant, pas rassis Un fichier de règles pourrit si vous ne faites qu'ajouter. Passez-le en revue après les grosses tâches. Supprimez les règles qui ne valent plus parce que la stack a changé. Promouvez une instruction ponctuelle utile que vous collez sans cesse en règle permanente. Découpez un fichier énorme en sous-fichiers liés quand il devient ingérable, car vous pouvez renvoyer depuis la CLAUDE.md vers d'autres fichiers markdown et garder la racine légère. L'investissement se rembourse de la façon la plus satisfaisante : chaque tâche future démarre d'une base plus intelligente, et l'écart entre vous et quelqu'un qui pilote un agent nu grandit chaque semaine. C'est la même boucle d'apprentissage continu qui traverse le reste du cours - consigner la leçon une fois, en profiter pour toujours. ## Erreurs fréquentes Les erreurs courantes : écrire un fichier de règles de 500 lignes qui enterre les règles importantes et mange votre context window ; formuler les règles en suggestions douces (« ce serait bien si... ») que l'agent traite comme optionnelles ; le mettre en place une fois et ne jamais le mettre à jour, si bien qu'il dérive lentement du vrai projet ; et dupliquer les règles entre CLAUDE.md et AGENTS.md jusqu'à ce qu'elles se contredisent. Gardez-le serré, gardez-le absolu, gardez-le à jour et gardez une source unique de vérité. ## ROI business Un bon fichier de règles est l'upgrade de qualité et de constance le moins cher que vous achèterez jamais. Il transforme votre savoir personnel en un actif qui vit dans le repo, si bien qu'une nouvelle session d'agent - ou une nouvelle recrue, ou un freelance - est immédiatement productive et au standard, au lieu de l'être après une semaine de corrections. Pour une fondatrice, c'est la façon de cesser d'être le goulot. Le savoir institutionnel qui vivait autrefois seulement dans votre tête et sortait par la porte à chaque fin de session s'accumule désormais dans un fichier que tout votre business partage. C'est un levier que vous gardez pour toujours. ## Checklist Vous êtes prêt à avancer quand chacun de ces points est vrai. Ne sautez pas les points sur le fichier vivant - c'est là qu'est la vraie valeur. - Vous avez committé une CLAUDE.md racine dans votre projet, avec des règles sur la stack, les conventions, la qualité et la sécurité. - Vos règles sont formulées en absolus, pas en suggestions. - Vous avez consigné au moins un vrai piège que vous corrigiez auparavant à la main. - Vous savez comment demander à l'agent d'ajouter une nouvelle règle quand il dérape. ## Ressources Gardez en favoris la documentation officielle sur la mémoire de Claude Code et CLAUDE.md pour le comportement exact de chargement et de fusion, car les détails évoluent. Les axiomes que vous avez sauvegardés dans la leçon de prompting du Cours 1 sont le germe de ce fichier - insérez-les comme vos premières règles. Le template de brief de tâche d'agent dans la bibliothèque de ressources s'accorde bien avec un fichier de règles : les règles couvrent les standards constants, le brief couvre les spécificités par tâche. ## Votre mission Créez une CLAUDE.md à la racine d'un vrai projet. Remplissez-la de votre stack, de trois conventions que vous corrigez sans cesse, de votre commande de quality gate et de votre règle de gestion des secrets. La prochaine fois que l'agent fait une erreur, ne la corrigez pas seulement, chargez-le d'ajouter une règle pour que cela ne se reproduise jamais. Regardez le fichier grandir vers quelque chose que seul votre projet pourrait avoir. ## Prochaine leçon Les règles en place, l'agent connaît vos standards. La prochaine leçon empaquette vos workflows réels : skills et slash commands qui transforment un processus multi-étapes éprouvé en un unique déclencheur réutilisable, pour que le travail courant se déroule chaque fois de la même façon, sans retaper le brief. ## Transcript Un fichier de règles de projet est de loin l'upgrade le plus impactant pour votre agent. CLAUDE.md (pour Claude Code) et AGENTS.md (pour Codex et d'autres harness) disent à l'agent vos conventions, votre stack, vos garde-fous et votre ton une seule fois, pour qu'il cesse de les redécider à chaque tâche. Cette leçon montre comment en écrire un et le faire tourner comme un système markdown en apprentissage continu, où chaque correction que vous faites est consignée pour toujours.