Le noyau Linux envisage un fichier AGENTS.md pour encadrer les patchs générés par les agents IA
Le 24 septembre 2026, le mainteneur Sasha Levin a proposé d’ajouter un fichier AGENTS.md au dépôt du noyau Linux pour corriger les erreurs d’attribution commises par les agents IA qui génèrent des patchs. La proposition, débattue sur la liste LKML, pose une vraie question : faut-il guider les agents par un fichier unique ou par une documentation dédiée.
24 septembre 2026. Le mainteneur Sasha Levin publie sur la liste LKML un patch qui introduit un fichier AGENTS.md à la racine du dépôt du noyau Linux. 24 septembre 2026. Le fichier proposé ne fait qu’un lien vers le README existant et renvoie vers la documentation destinée aux assistants de codage. 24 septembre 2026. Le débat s’ouvre : certains mainteneurs jugent le fichier utile, d’autres s’inquiètent du coût en jetons pour les agents. Pourquoi c’est important : le noyau est déjà submergé de patchs produits par des agents IA, et une seule balise d’attribution mal posée peut corrompre la traçabilité juridique d’un patch.
Un fichier minuscule pour un problème de fond
Depuis plusieurs mois, le noyau Linux reçoit un flux croissant de patchs générés ou assistés par des agents IA. Sasha Levin, qui travaille déjà sur d’autres initiatives d’IA pour le noyau — comme le choix des correctifs à reporter sur les branches stables ou la résolution de conflits de fusion assistée —, propose d’y répondre avec un outil simple : un fichier AGENTS.md placé à la racine de l’arborescence.
La proposition est volontairement minimale. Le fichier ne contient pas d’instructions détaillées : il renvoie vers le README du noyau, puis vers la documentation sur les assistants de codage et les autres informations utiles aux contributeurs. L’idée est de donner aux agents un point d’entrée unique et explicite, plutôt que de les laisser deviner les conventions du projet.
L’erreur d’attribution qui justifie tout
La motivation tient en un exemple concret. Lors de tests, Sasha Levin a constaté qu’un agent IA, sans fichier AGENTS.md, ajoutait une balise Signed-off-by à un patch alors qu’il n’aurait pas dû : cette balise engage la responsabilité juridique de celui qui la pose, et elle ne doit apparaître que si un humain signe explicitement. L’agent a aussi inventé sa propre balise d’attribution au lieu d’utiliser la balise standardisée Assisted-by.
Un second agent, testé sans le fichier, n’ajoutait aucune attribution du tout. Après l’ajout de l’AGENTS.md, les deux agents se sont conformés aux standards du noyau, et le second a mieux respecté les bonnes pratiques de développement. Le gain est immédiat : un fichier de quelques lignes suffit à corriger un comportement qui, sinon, polluerait l’historique Git avec des attributions fausses.
Le vrai débat : le coût en jetons
La proposition n’est pas adoptée sans résistance. Les objections sur la LKML portent sur un point précis : faire lire aux agents l’intégralité du README du noyau, puis la documentation associée, augmente la consommation de jetons de ces agents. Chaque génération de patch devient plus coûteuse, et les modèles doivent ingérer des milliers de mots avant de produire une seule ligne.
La critique suggère une voie médiane : produire une documentation plus ciblée, réduite à ce qui concerne réellement les agents IA, plutôt que de les renvoyer vers la documentation complète. Le débat oppose donc deux philosophies — un fichier unique qui pointe vers l’existant, ou un contenu dédié et allégé. La suite de la discussion dira laquelle l’emporte.
L’issue probable est un compromis. Le noyau a tout intérêt à adopter un fichier minimal, mais aucun mainteneur ne veut payer le coût d’un README entier ingéré à chaque requête d’agent. La solution la plus plausible est un AGENTS.md de quelques lignes qui renvoie vers une documentation courte et ciblée, écrite pour être lue par une machine. C’est le même arbitrage que pour les contributeurs humains : la documentation utile n’est jamais la documentation exhaustive, et ce qui compte n’est pas la taille du fichier, mais la précision des règles qu’il énonce.
Ce que révèle le choix du noyau
L’enjeu dépasse le cas du noyau Linux. Un fichier AGENTS.md est en train de devenir la convention de fait pour indiquer à un agent IA comment se comporter dans un dépôt : comment signer, comment créditer, quoi lire en premier. Le noyau, projet parmi les plus exigeants au monde en matière de contribution, en est l’un des derniers grands absents.
L’exemple de la balise Signed-off-by illustre ce que l’on risque sans ces conventions. Une attribution fausse n’est pas un détail cosmétique : elle fausse la chaîne de responsabilité qui remonte jusqu’au contributeur, et peut invalider la valeur juridique d’un Developer Certificate of Origin. Pour un projet qui alimente la quasi-totalité des serveurs de la planète, ce niveau de rigueur n’est pas de l’excès de zèle.
# AGENTS.md — guide minimal pour les agents IA contribuant à ce dépôt
- Ne jamais ajouter une balise `Signed-off-by` sans qu'un humain l'ait signée.
- Créditer toute aide d'un agent via la balise standardisée `Assisted-by:`.
- Lire CONTRIBUTING.md avant de proposer une modification.Un tel fichier, réduit à trois lignes, suffit à éviter les deux erreurs observées — la fausse signature et l’attribution fantaisiste. C’est le paradoxe du sujet : la correction est triviale, mais elle doit être explicitée à nouveau pour chaque nouvel outil.
Une convention qui se répand vite
Le fichier AGENTS.md n’est pas une invention du noyau Linux. Il s’est imposé depuis un an comme le moyen standard d’indiquer à un agent IA les règles locales d’un dépôt : des outils comme Claude Code et d’autres assistants de codage le lisent automatiquement à l’ouverture d’un projet. L’idée est la même partout : expliciter, dans un format lisible par une machine, ce que le CONTRIBUTING.md décrit pour un humain.
La différence entre les deux fichiers est utile à comprendre. Le CONTRIBUTING.md s’adresse à un contributeur qui lit, comprend et interprète. L’AGENTS.md s’adresse à un modèle qui suit. Ce qui est implicite pour un humain — ne pas signer à la place d’un autre, créditer une aide — doit être écrit noir sur blanc pour un agent. En rejoignant ce mouvement, le noyau Linux validerait une convention que le reste de l’écosystème a déjà adoptée.
Un fichier de plus, une surface de plus
Il y a un revers à cette convention, et il est de nature sécurité. Un fichier AGENTS.md est, par construction, un ensemble d’instructions lisibles par une machine, exécutées par un agent qui détient souvent des droits d’écriture sur le dépôt. Si un acteur malveillant parvient à y glisser une directive — via un commit frauduleux, une dépendance compromise ou une pull request malveillante — il peut orienter l’agent vers des actions qu’aucun humain n’aurait validées.
Le risque est le même que celui des fichiers de configuration détournés, déjà documenté pour les agents de codage : un agent qui lit un dépôt hostile peut être poussé à exécuter une commande, à exfiltrer un secret ou à introduire une porte dérobée dans le code qu’il génère. L’AGENTS.md du noyau ne ferait pas exception. La proposition doit donc se lire à deux niveaux : un gain d’attribution, mais aussi une nouvelle surface d’attaque à surveiller. La réponse n’est pas de renoncer au fichier, mais de traiter son contenu avec la même rigueur qu’un point d’entrée de confiance.
Verdict
Si vous maintenez un dépôt qui reçoit déjà des patchs d’agents IA, ajoutez un fichier AGENTS.md minimal dès maintenant : quelques lignes sur la signature, l’attribution et le document de contribution à lire en premier coûtent moins cher que de nettoyer un historique pollué. Si vous contribuez au noyau Linux, suivez la discussion sur la LKML : la question n’est plus de savoir si le noyau adoptera un AGENTS.md, mais quelle forme il prendra — un simple lien vers le README, ou une documentation dédiée et allégée. Si vous concevez des agents de codage, retenez la leçon : les conventions d’attribution ne se devinent pas, elles s’explicitent. Un fichier de trois lignes vaut mieux que mille jetons de suppositions.