NeuralOS
GuideIntermediate

Un seul fichier pour gouverner tous tes agents · maîtrise AGENTS.md

Il arrive un jour où ton projet a des règles — comment il démarre, avec quelle commande il se teste, ce qu'on NE touche PAS, comment s'écrivent les commits — et plus d'un cerveau artificiel y passe : tu construis avec l'un, tu révises avec un autre, et demain tu changes de modèle pour dépenser moins de crédits. Le problème, c'est que cette connaissance vit dans ta tête, et chaque nouvel agent part de zéro : tu lui expliques tout, tu fermes la session, et une semaine plus tard tu recommences (ou tu le réexpliques à une autre IA). AGENTS.md tue ce péage. C'est un standard ouvert — un « README pour agents » — que lisent aujourd'hui plus de 25 outils (OpenAI Codex, Cursor, GitHub Copilot, Gemini CLI, Aider, Zed, Windsurf, Devin, Claude Code…) et qu'utilisent plus de 60 000 projets. Un fichier Markdown brut, sans configuration bizarre, à la racine de ton projet : tu écris tes règles UNE fois et tous les agents les obéissent, aujourd'hui et demain. Ici tu comprendras pourquoi tu en as besoin, ce qu'il contient, la nuance entre AGENTS.md et CLAUDE.md sans rien dupliquer, et le prompt qui te le génère parfait en regardant vraiment ton code. Zéro fumée.

Jul 19, 202613 min
Pour qui est-ce ?
Pour celui qui construit déjà avec l'IA et utilise plus d'un agent — ou pense en utiliser plusieurs — et en a assez de répéter les mêmes règles à chaque session. Si vous avez déjà expliqué à l'IA comment se testent votre projet, ce qu'il ne faut PAS toucher et comment écrire un commit… et que la semaine suivante vous avez dû tout réexpliquer (ou l'expliquer à une autre IA), voici votre remède. C'est la suite naturelle de [Claude dans VS Code](/recursos/claude-en-vscode-ramas-paralelas) : là vous avez mis plusieurs IA au travail ; ici vous leur imposez une seule loi que toutes obéissent.

Le moment exact où vous en avez besoin

Le besoin apparaît le jour où votre projet a des règles et où plus d'un cerveau artificiel y passe. Vous utilisez peut-être Claude Code pour construire, un autre outil pour réviser, et de temps en temps vous ouvrez Cursor ou Copilot pour un point précis. Ou bien demain vous changez d'agent pour économiser des crédits. Dans tous ces cas, il existe une connaissance qui ne vit pas dans le code : comment démarrer l'environnement, avec quelle commande lancer les tests, quels dossiers sont sacrés et ne se touchent pas, comment vous voulez que soient rédigés les messages de sauvegarde. Cette connaissance vit aujourd'hui dans votre tête — et chaque nouvel agent part de zéro, sans rien en savoir.

Imaginez-le ainsi · le manuel du poste
Quand un nouvel employé entre dans une entreprise sérieuse, on ne lui explique pas tout de vive voix en priant pour qu'il s'en souvienne. On lui donne le manuel du poste : ici on pointe comme ça, le café est là-bas, ça on n'y touche pas, voici comment se font les choses. AGENTS.md, c'est exactement ça, mais pour les IA qui travaillent dans votre projet. Un fichier à la porte que tout agent lit avant de toucher à quoi que ce soit — et tous, quelle que soit la marque, en ressortent en sachant la même chose.

La douleur d'où il naît · le contexte qui s'évapore

La douleur est silencieuse et se paie par mensualités. La session d'aujourd'hui avec votre IA sait parfaitement comment fonctionne votre projet parce que vous le lui avez expliqué pendant des heures. Mais cette connaissance n'est enregistrée nulle part : quand vous fermez la conversation, elle s'évapore. Demain vous ouvrez une nouvelle session — ou vous changez de modèle pour dépenser moins — et vous voilà de nouveau à la case départ, à répéter « souviens-toi que les tests se lancent avec cette commande », « ne touche pas au dossier des paiements », « les commits vont dans ce format ».

Pourquoi cela arrive-t-il ? Parce que chaque agent démarre à l'aveugle : il ne voit que votre code, pas vos règles ni vos habitudes. Et comme chaque outil enregistrait ses instructions à sa façon — Claude dans un fichier, Cursor dans un autre, Copilot dans un autre — vous deviez maintenir la même connaissance écrite trois ou quatre fois. Un chaos qui se désynchronise tout seul : vous changez une règle dans un fichier et vous l'oubliez dans les autres.

Ce qui se passe si vous ne le faites PAS · un accident, pas une apocalypse
Sans ce fichier, rien ne s'écroule — vous allez simplement plus lentement et avec plus de frictions. L'IA lance les tests avec la mauvaise commande et vous signale de fausses erreurs. Elle touche un fichier que vous croyiez intouchable parce que personne ne lui a dit non. Elle écrit les commits n'importe comment et votre historique devient un désastre. Aucune de ces choses n'est une catastrophe ; ce sont des frictions qui s'accumulent. Multipliez-les par chaque nouvelle session et par chaque agent différent, et le péage est énorme. AGENTS.md transforme toute cette connaissance volatile en quelque chose qui s'écrit une fois et que tous obéissent.

Qu'est-ce qu'AGENTS.md ? (en clair)

AGENTS.md est un README pour agents. Tout comme le README de toujours raconte à un humain de quoi parle votre projet, AGENTS.md raconte à n'importe quelle IA de code comment se comporter à l'intérieur. C'est un fichier de texte brut (Markdown) que vous placez à la racine de votre projet, et c'est tout. Sans configuration bizarre, sans code, sans cérémonies.

Ce qui le rend puissant, ce n'est pas le format — c'est qu'il est devenu un standard ouvert que lisent aujourd'hui plus de 25 outils différents : OpenAI Codex, Cursor, GitHub Copilot, Gemini CLI, Google Jules, Aider, Zed, Windsurf, Devin, JetBrains Junie, Warp, goose et plus encore. Plus de 60 000 projets open source l'utilisent déjà. Vous écrivez vos règles UNE fois, et elles fonctionnent avec l'IA que vous utilisez aujourd'hui et avec celle que vous utiliserez demain. Vous cessez d'être marié à un seul outil.

Qui le soutient · ce n'est pas une invention isolée
AGENTS.md n'est pas le caprice d'une entreprise. Il est né d'une collaboration entre OpenAI (Codex), Google (Jules), Cursor, Amp et Factory, et aujourd'hui il est entretenu par l'Agentic AI Foundation, sous l'égide de la Linux Foundation — la même fondation qui gouverne Linux. Autrement dit : c'est un standard neutre, communautaire, pensé pour qu'aucun agent ne soit propriétaire de vos règles. C'est exactement ce que vous voulez pour quelque chose d'aussi important que le manuel de votre projet.
agentsmd/agents.md
REPO

Le standard ouvert AGENTS.md — le « README pour agents » que lisent aujourd'hui plus de 25 outils de code avec IA. Guide, exemples et la spécification complète. Administré par l'Agentic AI Foundation (Linux Foundation). ~23k★.

TypeScriptMITView on GitHub

L'anatomie réelle · ce qu'il contient

Voici la meilleure nouvelle : il n'y a pas de format rigide à apprendre. AGENTS.md, c'est du Markdown tout ce qu'il y a de normal — des titres avec #, des listes avec des tirets, du texte. Il ne comporte pas cet en-tête technique rempli de deux-points et d'accolades (ce que les programmeurs appellent le YAML frontmatter) : rien de tout ça n'est obligatoire. Vous écrivez en sections avec le nom que vous voulez, et l'agent lit ce que vous y mettez. Point.

Cela dit, il y a cinq blocs que presque tout bon AGENTS.md inclut — parce que ce sont justement la connaissance qui s'évapore entre les sessions. Voyez-les comme les cinq tiroirs du manuel du poste :

Les 5 tiroirs d'un bon AGENTS.md
Préparer l'environnement — comment démarrer le projet de zéro. Quoi installer, quelle commande lance tout. Pour que l'IA ne devine pas.
Comment se lancent les tests — la commande exacte des tests et de la vérification des types/erreurs. Ainsi l'IA vérifie son propre travail avant de crier victoire (au lieu de vous signaler de fausses erreurs).
Règles de style — comment vous voulez que le code se présente et la langue dans laquelle il s'écrit. Guillemets, indentation, noms. Ce qui vous ferait froncer les sourcils lors d'une revue.
Convention de commits et PR — comment s'écrit un message de sauvegarde et comment se propose un changement. Pour que votre historique ne devienne pas un Frankenstein.
Les limites · ce qu'on ne touche PAS — le tiroir le plus important. Les dossiers et fichiers sacrés (paiements, configuration, secrets) qu'aucun agent ne doit modifier sans permission. Vos no-touch surfaces.
Le monorepo · une loi générale et des lois locales
Si votre projet est grand et comporte plusieurs parties (un dossier pour le web, un autre pour le serveur…), vous pouvez placer un AGENTS.md dans chaque dossier. Les agents lisent automatiquement celui qui est le plus proche du fichier qu'ils sont en train de toucher. C'est comme une constitution nationale (l'AGENTS.md de la racine) plus les arrêtés de chaque ville (ceux de chaque sous-dossier) : la règle locale l'emporte sur la générale sur son territoire. Vous n'avez rien de spécial à faire — juste placer le fichier au bon endroit.

L'habitude · écrivez-le une fois, gardez-le vivant

Cette ressource n'est pas de celles qui s'appliquent tous les jours — c'est de celles qui se font bien une fois et se retouchent de temps en temps. La constance ici n'est pas dans la fréquence, mais dans deux moments concrets où vous ne pouvez pas l'oublier :

Les deux moments où vous touchez à votre AGENTS.md
Au début d'un projet (ou en lisant ceci, si vous en avez déjà un en route) : asseyez-vous 15 minutes et écrivez le fichier. C'est l'investissement le plus rentable de votre semaine.
Quand une règle change — vous découvrez qu'il faut lancer une nouvelle commande, vous décidez qu'un certain dossier ne se touche plus, vous changez votre format de commits. C'est le moment de mettre à jour le fichier, pas votre mémoire. Si la règle n'est pas dans AGENTS.md, pour l'IA elle n'existe pas.
Le piège du fichier mort
Le seul échec possible avec AGENTS.md est de le laisser vieillir. Un fichier qui dit « les tests se lancent avec telle commande » alors que cette commande a déjà changé est pire que pas de fichier du tout : vous envoyez l'IA avec une vieille carte droit dans le ravin. La règle : chaque fois que vous expliquez quelque chose de nouveau à votre agent par chat et que vous notez que « ça, je vais en avoir besoin de nouveau », c'est le signal que ça va dans l'AGENTS.md. Si vous le dites deux fois, écrivez-le une fois.

La nuance que presque personne n'explique · AGENTS.md vs CLAUDE.md vs .cursorrules

C'est là que les gens s'embrouillent, alors soyons clairs. Avant que le standard n'existe, chaque outil a inventé son propre fichier de règles : Claude Code lit un CLAUDE.md, Cursor lisait un .cursorrules, et ainsi chacun. Le problème évident : si vous utilisiez trois outils, vous mainteniez trois fichiers avec la même connaissance, se désynchronisant tout seuls. AGENTS.md est né justement pour en finir avec ce désordre : une seule source de vérité que toutes lisent.

La règle d'or pour ne pas dupliquer
L'astuce élégante est celle-ci, et c'est celle que nous recommandons : AGENTS.md comme source unique de vérité. Si votre outil principal a son propre fichier (comme Claude Code avec CLAUDE.md), ne copiez pas les règles deux fois — faites que ce fichier pointe vers l'AGENTS.md avec une ligne d'importation. Ainsi vous écrivez les règles UNE fois dans AGENTS.md, et CLAUDE.md dit seulement « lis ça ». Rien n'est dupliqué, rien ne se désynchronise.
markdown
# CLAUDE.md

# Las reglas del proyecto viven en AGENTS.md (fuente única).
# Claude Code las carga con esta línea de importación:

@AGENTS.md

# Debajo, solo lo específico de Claude Code que NO aplica
# a los demás agentes (si es que hay algo).

Quand utiliser lequel ? Facile : AGENTS.md pour tout ce que vous voulez que n'importe quel agent obéisse (95 % de vos règles). Le fichier propre à un outil (CLAUDE.md, .cursorrules) uniquement pour ce qui est exclusif à cet outil — une commande que lui seul comprend, un réglage qui ne sert qu'à lui. En cas de doute, ça va dans AGENTS.md. La règle mentale : écrivez pour tous par défaut ; écrivez pour un seul par exception.

Point & contrepoint · et si la spec dit déjà quoi construire ?

Si vous venez de l'idée d'écrire une spécification avant de construire (le quoi vous voulez construire), AGENTS.md est l'autre moitié de la paire — et ils ne se marchent pas dessus, ils se complètent. La spec gouverne QUOI se construit : la fonctionnalité, l'objectif, le résultat. AGENTS.md gouverne COMMENT se comporte n'importe quel agent pendant qu'il le construit : avec quelles commandes, quelles règles, quoi ne pas toucher. L'une est le plan du bâtiment ; l'autre, les consignes de sécurité du chantier. Vous avez besoin des deux.

Imaginez-le ainsi · le plan et le règlement de chantier
Le plan (la spec) dit ce qu'on érige : trois étages, fenêtres ici, escalier là. Le règlement de chantier (AGENTS.md) dit comment on travaille sur le site : casque obligatoire, cette zone ne se piétine pas, voici comment se signe chaque livraison. Vous pouvez avoir le meilleur plan du monde, mais si chaque ouvrier travaille à sa guise, le chantier est un chaos. Et vous pouvez avoir le meilleur règlement, mais sans plan vous ne savez pas quoi construire. AGENTS.md est votre règlement de chantier — et il s'applique à tous les ouvriers, quelle que soit leur équipe.

Le prompt maître · génère ton AGENTS.md parfait

Voici le raccourci. Vous n'avez pas à écrire le fichier à la main ni à réfléchir à chaque section : vous donnez ce prompt à votre agent de code à l'intérieur de votre projet, et il le rédige pour vous en regardant comment votre code est réellement construit. Vous n'avez qu'à réviser et ajuster. Copiez-le tel quel, remplissez les crochets avec ce que vous savez, et laissez-le travailler :

Colle-le à ton agent · crée l'AGENTS.md de ton projettexte
Je veux créer un fichier AGENTS.md à la racine de mon projet : le « README pour agents » du standard ouvert (agents.md) que lisent les outils d'IA de code. C'est du Markdown brut, SANS en-tête YAML. Guide-moi en langage simple, en supposant que je ne suis pas programmeur.

D'abord, EXPLORE mon projet pour de vrai (examine la structure des dossiers, le package.json ou équivalent, et comment c'est organisé) pour NE rien inventer. Ensuite rédige un AGENTS.md avec ces sections, en Markdown propre :

1. Résumé du projet — 2 ou 3 phrases sur ce que c'est et quelles technologies il utilise (déduis-le du code).
2. Préparer l'environnement — les commandes réelles pour installer et démarrer le projet de zéro.
3. Comment se lancent les tests — la commande exacte des tests et de la vérification des erreurs/types, pour que n'importe quel agent vérifie son travail avant de le donner pour bon.
4. Règles de style — la langue du code et les conventions que tu détectes (guillemets, noms, format).
5. Commits et PR — voici mon format de messages de commit : [décris-le, ou dis-moi si je n'en ai pas et propose-en un bon].
6. Limites · ce qu'on ne touche PAS — marque comme INTOUCHABLES sans permission explicite ces dossiers/fichiers sacrés : [liste ici ce qui est sensible : paiements, secrets, configuration, migrations… ce que tu as]. Précise bien qu'un agent doit S'ARRÊTER et demander avant de les modifier.

Règles pour le rédiger :
- N'affirme que des choses que tu peux vérifier en regardant mon code. Si tu ne sais pas quelque chose, mets un marqueur [À CONFIRMER] au lieu de l'inventer.
- Que ce soit concis et actionnable, pas un roman. Un agent le lit en entier avant de travailler.
- Si mon outil principal a déjà son propre fichier de règles (par exemple CLAUDE.md), NE duplique PAS le contenu : fais que ce fichier importe l'AGENTS.md avec une seule ligne, et laisse-moi AGENTS.md comme source unique de vérité.

À la fin, montre-moi le fichier complet et explique-moi en une phrase ce que tu as mis dans chaque section, pour que je le révise.
N'apprends rien · tu ne fais que réviser
Notez le détail : le prompt ordonne à l'IA d'explorer votre code avant d'écrire et de mettre [À CONFIRMER] quand elle n'est pas sûre — pas de fumée, pas de règles inventées. Votre travail se réduit à lire le brouillon et à corriger ce qui ne colle pas avec votre façon de travailler. D'expert à réviseur : exactement le rôle qui vous revient.

Le chemin le plus facile · par chat vs. à la main

Comme dans toute la série, il y a deux façons de faire ça et aucune ne vous oblige à toucher le terminal si vous ne voulez pas :

Vos deux chemins
Par chat (recommandé) : vous collez le prompt maître ci-dessus à votre agent, dans votre projet. Il explore, rédige et vous montre le fichier. Vous révisez et approuvez. Zéro commande.
À la main (si vous aimez le contrôle) : vous créez un fichier nommé AGENTS.md dans le dossier racine de votre projet, et vous écrivez les cinq sections vous-même en copiant le modèle ci-dessous. Ça marche aussi — ce n'est que du texte.

Si vous prenez le chemin manuel, voici le modèle minimal prêt à copier et à remplir. Changez-le à votre goût : rappelez-vous qu'il n'y a pas de format obligatoire.

markdown
# AGENTS.md

## Résumé du projet
[Ce que c'est et avec quoi c'est fait. 2-3 phrases.]

## Préparer l'environnement
[Commandes pour installer et démarrer de zéro.]

## Comment se lancent les tests
- Tests : [commande exacte]
- Vérification des erreurs/types : [commande exacte]
> Lance ça et laisse-le au vert avant de considérer un changement comme terminé.

## Règles de style
[Langue du code, conventions de noms/format.]

## Commits et pull requests
[Ton format de messages de commit. Exemple d'un bon.]

## Limites · NE PAS toucher sans permission
- [Dossier ou fichier sacré 1 — pourquoi il est sensible]
- [Dossier ou fichier sacré 2]
> Devant l'un de ceux-ci : ARRÊTE-toi et demande avant de modifier.
Range-le bien · il va au contrôle de versions
Un dernier détail qui fait la différence : AGENTS.md se sauvegarde avec votre projet sur GitHub, comme un fichier de plus. Ainsi il voyage avec le code, toute votre équipe le voit (humains et agents), et son historique de changements est conservé. Si votre projet n'est pas encore sauvegardé sur GitHub, commencez par là — c'est la base de tout le reste.

La routine en or · le résumé que vous emportez

L'habitude, en cinq lignes
Un fichier, tous les agents : écrivez vos règles une fois dans AGENTS.md, à la racine. Cessez de vous répéter à chaque session.
Les cinq tiroirs : environnement, tests, style, commits, et surtout les limites de ce qu'on ne touche PAS.
Source unique : si un outil a son propre fichier (CLAUDE.md), qu'il importe l'AGENTS.md — ne dupliquez jamais les règles.
Gardez-le vivant : quand une règle change, mettez à jour le fichier, pas votre mémoire. Un vieil AGENTS.md ment.
Sauvegardez-le sur GitHub : il voyage avec votre code, tous le voient, son historique est conservé.
Dans NeuralOS · le contexte qui ne s'évapore pas
Toute cette ressource attaque une seule douleur de fond : le contexte qui se perd entre les sessions et entre les modèles. AGENTS.md le résout pour le code de votre projet. Dans NeuralOS, cette même obsession de ne pas perdre le fil est tissée dans l'interface : chaque conversation avec laquelle vous construisez est sauvegardée dans votre bibliothèque, avec ses fichiers et son historique, prête à rouvrir là où vous l'avez laissée — même si vous changez de modèle en chemin. C'est la même idée qu'AGENTS.md, appliquée à votre travail avec l'IA : ce que vous avez construit et appris ne disparaît pas quand vous fermez la fenêtre. Cette continuité est, aujourd'hui, la vision déjà tangible dans le produit.
Sauvegarde tout sur GitHub · la base de tout ceci
Ton AGENTS.md vit à l'intérieur de ton projet sur GitHub. Si tu ne sauvegardes pas encore ton code là-bas, commence par ce guide.
Claude dans VS Code · plusieurs IA en parallèle
Quand tu mets plusieurs sessions (ou plusieurs agents) au travail en même temps, un seul AGENTS.md les gouverne toutes. Le combo parfait.
#agents-md#claude-code#standard-ouvert#contexte-ia#productivite
Ready to build?

Start building in
under 3 minutes

Join 4,200+ builders. No credit card. Build your first app with AI in minutes.