LLM Tools · 8 November 2026

AGENTS.md, SKILL.md, MCP : le contrat d’interface qui décide vraiment de la fiabilité de vos agents

En 2026, un agent qui échoue en production n’est presque jamais un agent mal câblé techniquement : c’est un agent qui n’a pas reçu les bonnes instructions, au bon endroit, au bon moment. La couche de fichiers Markdown versionnés qui vit à côté du code — AGENTS.md, SKILL.md, règles Cursor, manifestes MCP — est devenue le vrai contrat d’interface entre vos modèles et votre base de code. Panorama de ce qui tient, de ce qui casse, et de ce qu’il faut faire dès maintenant.

Le fichier qui parle à l’agent : pourquoi 2026 marque un basculement

Pendant deux ans, la question de l’ingénierie agentique s’est posée en termes de modèle et de schéma d’outil. On comparait les fenêtres de contexte, on discutait du JSON Schema d’un inputSchema MCP, on mesurait des scores de tool calling. C’était nécessaire, et c’est désormais insuffisant. Le basculement de 2026 est ailleurs : dans une poignée de fichiers texte, versionnés dans Git, qui expliquent à l’agent comment travailler dans ce dépôt précis.

Les signaux convergent. Un dépôt GitHub communautaire documente ainsi AGENTS.md comme le fichier de configuration d’OpenAI Codex, aux côtés de CLAUDE.md pour Claude Code et GEMINI.md pour Gemini CLI — trois noms pour une même idée : un fichier Markdown à la racine qui décrit le projet à l’agent. Le même dépôt décrit SKILL.md comme le format de définition de compétences, activable automatiquement ou via une commande /skills, et déjà repris par plusieurs de ces outils. Un article de jsonmin.com daté du 17 septembre 2026 constate que « Cursor, Claude Code et Codex scannent SKILL.md » et que ces mêmes produits se connectent par ailleurs à MCP. Trois couches différentes, trois rôles différents, un seul écosystème.

Le mouvement n’est pas seulement technique, il est éditorial et organisationnel. Hoko Blog, dans une analyse comparative de ce qu’il appelle le context engineering, observe une convergence des outils — Claude Code, Cursor, GitHub Copilot, Mistral Vibe/Code, Google Antigravity — vers des patterns communs : fichiers Markdown d’instructions, compétences modulaires, support MCP, modes agentiques. Autrement dit : les éditeurs se disputent le marché, mais ils se sont tacitement accordés sur la forme du contrat.

Ce contrat a une propriété dérangeante : il est écrit par des humains, pour des modèles, et il est lu à chaque session. C’est à la fois sa force — il est modifiable en une pull request — et sa faiblesse — il n’est soumis à aucun test tant que personne n’en écrit. C’est précisément là que se joue la fiabilité réelle des agents en production. Les chiffres du magazine sur les agents non surveillés donnent le ton : un agent de support client non supervisé échoue sur plus de 30 % des tâches après trois semaines d’exploitation. Un agent correctement architecturé coûte 29 à 50 dollars par mois ; un agent mal conçu dépasse les 200 dollars. L’écart ne se joue pas dans le choix du modèle : il se joue dans la qualité de la couche de contexte.

AGENTS.md, SKILL.md, CLAUDE.md, .mdc : anatomie comparée des formats

Il faut d’abord poser les briques, parce que la confusion entre ces formats est la première cause de mauvaise architecture.

AGENTS.md est le format le plus simple et le plus interopérable : un fichier Markdown à la racine du dépôt, sans schéma imposé, qui décrit le projet, les conventions, les commandes de test, les pièges connus. Sa force est sa faiblesse : rien n’est obligatoire, donc rien n’est garanti. Il est lu par plusieurs outils, ce qui en fait candidat au rôle de « fichier canonique ».

CLAUDE.md est l’équivalent côté Anthropic, mais avec une machinerie plus élaborée. D’après le blog Hoko, qui cite la documentation Anthropic, Claude Code utilise une hiérarchie à quatre niveaux : un fichier enterprise (/etc/claude-code/CLAUDE.md sous Linux), un fichier projet (./CLAUDE.md ou ./.claude/CLAUDE.md), un fichier utilisateur (~/.claude/CLAUDE.md), et des fichiers de sous-répertoires chargés à la demande. Les CLAUDE.md sont injectés automatiquement dans le system prompt à chaque session, et Claude traverse récursivement l’arborescence du répertoire courant vers la racine — un comportement pensé pour les monorepos. S’y ajoute un système d’import @path/to/file avec inclusion récursive limitée à 5 niveaux, et une commande /init pour générer un fichier initial.

SKILL.md est d’une autre nature. Là où AGENTS.md décrit un contexte permanent, SKILL.md décrit une compétence : une procédure activable à la demande. jsonmin.com le résume par une distinction nette — Skill = « how » (le manuel, les étapes), MCP = « access » (le bus de capacités partagées entre hôtes), API/Function Calling = « le contrat de ce saut » (l’interface dure en JSON Schema). Un SKILL.md contient donc des étapes procédurales ; les sources disponibles ne détaillent pas explicitement les champs frontmatter obligatoires (nom, description), ni les scripts ou ressources embarqués — c’est une lacune documentaire qu’il faut assumer. Ce que l’on peut dire avec certitude, c’est que son intérêt est le chargement progressif : on n’injecte pas la procédure complète dans le contexte de chaque session, on l’expose comme une compétence que l’agent va chercher quand il en a besoin.

Les règles Cursor (.mdc) ont connu une trajectoire révélatrice. Hoko rapporte que Cursor a connu trois générations de systèmes de contexte et que .cursorrules — le fichier unique à la racine — est officiellement déprécié dans la documentation Cursor. Le format actuel repose sur des fichiers .mdc avec frontmatter YAML (description, globs, alwaysApply), mais les extraits disponibles ne détaillent pas le mécanisme complet. Ce qui est sûr : la bascule du fichier unique vers des règles modulaires et ciblées par globs est actée.

Les manifestes MCP sont d’une autre espèce encore : ce ne sont pas des instructions mais des déclarations d’outils. Le Tool Schema JSON (inputSchema, description, parameters) est l’interface dure ; jsonmin.com insiste sur un point de discipline : les Skills ne doivent pas remplacer le schéma par de la prose. Autrement dit, ne décrivez pas dans un SKILL.md ce qu’un inputSchema doit déclarer formellement.

La différence de philosophie est nette. L’approche « fichier unique à la racine » (AGENTS.md, CLAUDE.md, copilot-instructions.md) parie sur la simplicité : un fichier, lisible par un humain, que tout le monde comprend. L’approche « compétences modulaires » (SKILL.md) parie sur l’économie de contexte : ne charger que ce qui est nécessaire, quand c’est nécessaire. Les deux ne s’opposent pas — elles se complètent, et c’est précisément là que naissent les conflits.

Qui gagne quand tout le monde parle : hiérarchie, héritage et résolution des conflits

Dès qu’un dépôt contient un AGENTS.md à la racine, un CLAUDE.md dans .claude/, un fichier utilisateur dans ~/.claude/, des règles Cursor dans .cursor/rules/ et des SKILL.md dans .claude/skills/, la question devient inévitable : qui gagne ?

Sur Claude Code, la réponse est partiellement documentée : précédence décroissante entreprise → projet → utilisateur, avec traversée récursive des sous-répertoires. Mais le blog Hoko lui-même signale une incohérence interne dans sa présentation — un tableau annonce « quatre niveaux » et n’en liste que trois. C’est un symptôme : même les sources qui prétendent décrire la hiérarchie la décrivent imparfaitement.

Pour Cursor, Copilot et Codex, les extraits disponibles ne documentent pas l’ordre de précédence officiel. C’est une zone d’ombre réelle, pas un détail. En pratique, les équipes la contournent par convention interne : un fichier canonique unique, des références croisées, des sections délimitées, et l’interdiction de dupliquer une règle dans deux fichiers.

Comment le modèle arbitre-t-il des instructions contradictoires ? Il n’y a pas de réponse documentée dans nos sources. L’observation pratique — non chiffrée — est que l’arbitrage est implicite : le modèle tend à suivre l’instruction la plus proche dans le contexte, ou la plus spécifique, sans que cela soit garanti. C’est exactement le type de comportement qu’un test de régression devrait verrouiller, et que presque personne ne teste.

Les bonnes pratiques qui émergent tiennent en trois règles simples. Un : un seul fichier canonique par dépôt, les autres le référencent. Deux : des sections délimitées par des titres explicites, pour que le modèle puisse distinguer les domaines (tests, style, sécurité, déploiement). Trois : éviter la duplication — une règle présente dans deux fichiers est une règle qui divergera, et un agent qui reçoit deux versions d’une même consigne n’a aucun moyen fiable de savoir laquelle prime.

La dérive du contexte : fichiers qui gonflent, règles enterrées, agents qui n’écoutent plus

Le problème le plus documenté — et le plus sous-estimé — est la dérive. Un AGENTS.md commence à 40 lignes. Six mois plus tard, il en fait 400, parce que chaque incident a laissé une trace, chaque nouvelle recrue a ajouté sa règle, et personne n’a jamais supprimé les instructions obsolètes.

Anthropic a publié un article officiel, « Effective context engineering for AI agents », qui définit le context engineering comme la progression du prompt engineering : gérer l’ensemble des tokens — instructions système, outils, MCP, données externes, historique — plutôt que seulement le prompt. Anthropic y affirme observer que « les LLM, comme les humains, perdent le focus ou connaissent de la confusion à un certain point » quand le contexte grandit. L’extrait disponible est tronqué avant les études citées, donc aucun chiffre précis n’est extractible — mais l’affirmation qualitative est officielle et recoupée.

La bonne pratique chiffrée qui circule en 2026 est attribuée à HumanLayer et Builder.io : un CLAUDE.md devrait contenir moins de 300 lignes, et privilégier les références file:ligne plutôt que des copies de code. Attention à la traçabilité : ce chiffre est rapporté par un seul blog agrégateur, les sources primaires ne sont pas fournies. Il faut le traiter comme un ordre de grandeur empirique, pas comme un seuil mesuré.

Ce que l’on sait vraiment, et ce qui manque : il n’existe, dans les sources disponibles, aucune étude chiffrée sur la corrélation entre la longueur d’un fichier de contexte et le taux de respect des instructions. Aucun retour d’expérience d’équipe documentant la dérive concrète — fichiers qui grossissent, instructions obsolètes, règles enterrées ignorées — n’est recoupé par deux sources indépendantes. C’est un angle mort majeur : on demande aux équipes de traiter ces fichiers comme du code, sans leur fournir les métriques qui le justifieraient.

La réponse raisonnable est donc celle de l’ingénierie logicielle classique : revue, tests, CI, versioning. Un fichier de contexte qui n’est pas relu est un fichier qui pourrit. Un fichier qui n’est pas testé est un fichier dont personne ne sait s’il fonctionne.

Tester un fichier de contexte comme on teste du code : patterns d’évaluation au-delà des benchmarks

Les benchmarks de tool calling — BFCL, τ-bench, MCP-Universe — mesurent le modèle. Ils ne mesurent pas votre couche de contexte. Un modèle qui score haut sur un benchmark d’appel d’outils peut parfaitement ignorer la règle « ne jamais modifier les migrations existantes » parce qu’elle est enterrée à la ligne 280 de votre AGENTS.md.

Les patterns concrets qui émergent, faute de framework standardisé, relèvent du bricolage raisonné :

Constituer un jeu de tâches représentatives du dépôt. Pas des tâches génériques : des tâches réelles, tirées de l’historique des pull requests. « Ajoute un endpoint de facturation », « corrige le bug de pagination », « refactorise ce service ». C’est le seul jeu de test qui mesure ce qui compte.

Écrire des tests de régression sur les instructions critiques. Chaque règle critique — sécurité, migrations, conventions d’API — devrait être associée à une tâche qui échoue si la règle n’est pas suivie. Modifier le fichier de contexte sans faire tourner ces tests revient à modifier du code sans faire tourner la CI.

Vérifier l’application des règles de sous-dossiers. C’est le test le plus souvent oublié : un agent qui travaille dans backend/ applique-t-il bien les instructions spécifiques à backend/, et pas celles de frontend/ ?

Détecter les instructions mortes. Une règle qui n’est jamais invoquée dans aucune tâche de test est probablement une règle obsolète. La supprimer réduit le contexte et augmente le taux de respect des règles restantes.

Revue de PR sur AGENTS.md, lint de règles, CI de cohérence. Le minimum vital : un check qui vérifie qu’aucune règle n’est dupliquée entre AGENTS.md et CLAUDE.md, et qu’aucune instruction ne contredit une instruction existante.

Les limites sont réelles : peu de frameworks standardisés, aucune métrique de « taux de respect de consigne » universellement acceptée, et beaucoup de bricolage. Mais l’alternative — ne rien tester et découvrir la dérive en production — est plus coûteuse. Les chiffres du magazine sont sans ambiguïté sur ce point : un agent en production connaît une chute significative de performances au passage de 12 à 13 outils déclarés, et un agent avec huit appels d’outils séquentiels dépasse les six secondes de latence avant première réponse à 800 ms par appel. Autrement dit, l’agent qui doit chercher sa règle dans un contexte saturé paie deux fois : en tokens et en latence.

La surface d’attaque cachée : injection indirecte, instructions persistantes, permissions

Un AGENTS.md ou un SKILL.md est une instruction persistante chargée à chaque session. C’est exactement ce qui en fait un vecteur d’attaque de premier choix.

Trois scénarios sont documentés ou plausibles. Le premier est l’injection indirecte : un contenu malveillant glissé dans une dépendance, un ticket, un fichier de données que l’agent lit, et qui contient des instructions déguisées. Le deuxième est le prompt poisoning : un fichier de contexte compromis — ou simplement une contribution malveillante à un AGENTS.md open source — qui modifie durablement le comportement de l’agent. Le troisième est l’escalade de permissions via .claude/settings.json ou les manifestes MCP : un serveur MCP qui déclare des outils plus larges que nécessaire, ou un fichier de paramètres qui accorde des droits d’écriture là où la lecture suffirait.

Le magazine a documenté un cadre de référence utile, l’Agent Control Standard, structuré en quatre contrôles. Le contrôle 1 exige un manifeste versionné déclarant les outils, domaines et effets de bord autorisés par agent. Le contrôle 2 impose des scopes granulaires — read:orders n’est pas write:orders, qui n’est pas refund:orders. Le contrôle 3 exige une allowlist de couples outil+paramètres (montant ≤ X, order_id de l’utilisateur courant, devise ∈ {EUR, USD}). Le contrôle 4 impose sandbox d’exécution, journalisation traçable (agent, outil, paramètres, résultat, décision, timestamp, trace de session) et validation humaine pour les actions à fort impact.

Ce cadre s’applique directement aux fichiers de contexte : un SKILL.md qui déclare allowed-tools doit être relu comme un manifeste de permissions, pas comme une simple documentation. Les bonnes pratiques qui en découlent sont simples : principe de moindre privilège par défaut, séparation stricte entre les fichiers de confiance (versionnés, relus en PR) et les contenus non fiables (données, tickets, dépendances), revue obligatoire de tout fichier de contexte en pull request, et audit régulier des serveurs MCP et de leurs descriptions d’outils.

L’actualité récente montre que le risque n’est pas théorique. Le 19 septembre 2026, un consultant publiait une analyse intitulée « LLM pipelines et MCP : la surface d’attaque que personne ne surveille », et le 20 septembre, forkast.news révélait que Safari 27 embarque un serveur MCP natif exposant 17 outils d’automatisation — sans aucun contrôle MDM permettant aux entreprises de le désactiver. Le 17 septembre, l’étude Lasso montrait que le filigrane texte modifie les refus des LLM et les appels d’outils. La surface d’attaque s’élargit plus vite que les garde-fous.

Ce qui relève du standard naissant : les scopes granulaires, les allowlists, la journalisation. Ce qui reste à inventer : la détection automatique d’instructions malveillantes dans un fichier de contexte, et la séparation formelle entre contexte de confiance et contexte non fiable — aujourd’hui, tout arrive dans le même sac au moment de la construction du prompt.

Gouvernance d’équipe : qui possède AGENTS.md, qui le relit, qui le supprime

Dernier étage, et probablement le plus déterminant : l’organisation. Un fichier de contexte sans propriétaire est un fichier qui pourrit. Un fichier avec cinq propriétaires est un fichier qui devient incohérent.

Les équipes qui obtiennent des agents fiables appliquent une recette qui ressemble furieusement à celle du code. Un propriétaire désigné — souvent l’équipe plateforme ou un « AI champion » — inscrit dans CODEOWNERS. Un cycle de revue : toute modification d’AGENTS.md ou de SKILL.md passe en PR, avec un reviewer qui connaît le domaine concerné. Une politique de dépréciation : les règles obsolètes sont supprimées, pas commentées. Un changelog, parce que savoir pourquoi une règle existe évite de la supprimer par erreur. Et une CI qui vérifie la cohérence entre fichiers.

À l’inverse, les équipes qui empilent des prompts dans un wiki — ou dans un Notion que personne ne relit — obtiennent ce que l’on peut attendre : des agents qui fonctionnent en démo et échouent en production. Le wiki-prompt pourrit parce qu’il n’a ni version, ni test, ni propriétaire, ni conséquence.

Le rôle des éditeurs dans cette gouvernance est ambigu. Anthropic documente sa hiérarchie CLAUDE.md, ce qui aide. Cursor déprécie .cursorrules et impose sa nouvelle génération, ce qui force la migration. OpenAI pousse AGENTS.md via Codex. GitHub Copilot a son propre copilot-instructions.md. Chacun standardise à sa manière, et le risque de lock-in par convention d’éditeur est réel : une équipe qui investit massivement dans un format propriétaire se retrouve dépendante des décisions de cet éditeur.

La contre-tendance existe : l’Agentic AI Foundation, créée en décembre 2025 sous l’égide de la Linux Foundation, avec Block et OpenAI comme cofondateurs et le soutien de Google, Microsoft, AWS et Cloudflare, témoigne d’une volonté d’ancrage institutionnel. Mais l’AAIF ne standardise pas encore les fichiers de contexte — elle standardise les agents.

Ce qui restera : standard durable ou convention d’éditeur ?

Le verdict doit être nuancé, parce que la situation l’est.

Ce qui semble solide. Le Markdown versionné à la racine est un choix robuste : lisible par un humain, diffable, compatible avec tous les outils, sans dépendance à un format binaire. La séparation entre instructions (AGENTS.md, CLAUDE.md, SKILL.md) et outils (MCP, JSON Schema) est conceptuellement juste et devrait survivre. MCP comme bus d’accès aux outils, avec une adoption projetée par Forrester (via Studeria) de 30 % des éditeurs SaaS en 2026 à 60 % en 2027, s’installe comme standard de facto.

Ce qui reste fragile. La multiplicité des formats — AGENTS.md, CLAUDE.md, GEMINI.md, .mdc, copilot-instructions.md — n’est pas résolue. La précédence entre fichiers est mal spécifiée, et les sources qui prétendent la décrire se contredisent. SKILL.md est encore jeune : son anatomie exacte (frontmatter, scripts, ressources) n’est pas documentée dans les sources accessibles. Et il n’existe aucun test standardisé de ces fichiers — pas de benchmark de « respect d’instruction », pas de framework d’évaluation unanimement reconnu.

Les précédents absorbés ou concurrencés. .cursorrules a été déprécié par son propre éditeur au profit des règles .mdc. llms.txt a été proposé comme standard de fait et reste une convention sans adoption massive documentée. copilot-instructions.md coexiste avec AGENTS.md sans que l’on sache lequel prime quand les deux existent. L’histoire de cette couche est une succession de propositions communautaires, d’adoptions éditeurs, et de dépréciations silencieuses.

Ce que cela change pour vous, aujourd’hui. Vous n’avez pas à parier sur un format unique. Vous avez à construire une couche portable : un fichier canonique en Markdown à la racine, des compétences modulaires pour les procédures longues, des manifestes MCP pour les outils, et surtout — des tests. La règle qui tient en 2026 est simple : traitez vos fichiers de contexte comme du code de production. Parce que dans les faits, c’est exactement ce qu’ils sont devenus.

Sources

• Grand modèle de langage — Wikipédia
• LLM Updates (November 2026) – AI Model Releases & Provider Activity
• Large language model – Wikipedia
• AI Updates Today (November 2026) – Latest AI Model Releases
• LLM : fonctionnement, limites et modèles clés en 2026 | Brief IA
• Top 9 Large Language Models as of November 2026
• Classement des meilleurs LLM en novembre 2026 : le top 15
• Which LLM is Best for Which Use Cases in 2026 | Deepak Gupta
• Warning Over High-Risk Vulnerabilities in Widely Used LLM Gateway Tool
• Qu’est-ce que l’IA agentique ? | IBM
• 11 Best AI Agents for Productivity in 2026 (Ranked & Tested)
• What Is Agentic AI? Definition, 6 Levels & Examples (2026)
• Best Agentic AI Platforms: Guide and Tools for 2026 | Slack
• AI agent – Wikipedia
• Hoko Blog — Context engineering : analyse comparative
• jsonmin.com — Skills, MCP, API : comment choisir (17/09/2026)
• OpenSkills — Best practices
• Polydesk — Guide complet Codex
• Apidog — Convertir un agent IA entre 10 IDE (Claude, Cursor, Aider)
• Journal du Net — MCP : quand l’IA entre dans vos logiciels de gestion par la porte de service (12/10/2026)
• forkast.news — MCP Events Complete the Agent Communication Model (29/09/2026)
• forkast.news — Safari 27 Ships a Native MCP Server (20/09/2026)
• ayinedjimi-consultants.fr — LLM pipelines et MCP : la surface d’attaque que personne ne surveille (19/09/2026)
• unite.ai — L’étude Lasso sur le filigrane texte et les appels d’outils (17/09/2026)
• jsonsort.com — OpenAI Agents API 2026 : JSON Schema, Tool Calling (20/09/2026)
• bird.com — Qu’est-ce que le tool calling ? (08/09/2026)
• lefilia.fr — Meilleurs frameworks d’agents open source pour LLM locaux (18/09/2026)
• hoton.ai — Meilleurs harnais d’agents Open Source pour les LLM locaux (18/09/2026)
• promptquorum.com — Semantic Kernel : fonctionnalités et alternatives (06/09/2026)
• agence-synqro.fr — MCP Webflow : comment les IA lisent et modifient un site (07/09/2026)
• theairankings.com — What Is MCP? The Model Context Protocol Explained (2026)
• render.ru — Maxon intègre un serveur MCP dans Cinema 4D 2026.4 (30/09/2026)
• blogdumoderateur.com — Les meilleurs modèles pour le code en octobre 2026 (05/10/2026)

Article recherché et rédigé automatiquement · Magazine Electrosens