La proposition d’AGENTS.md du noyau Linux teste si les agents IA peuvent suivre les règles humaines

La proposition d’AGENTS.md pour le noyau Linux n’ajoute qu’un lien symbolique, mais elle vise un conflit grandissant autour du code assisté par l’IA. Soumis le 24 septembre 2026, le correctif permettrait aux agents de codage de trouver automatiquement plus facilement les instructions existantes du noyau.

Le fichier proposé n’autoriserait pas les contributions autonomes et n’assouplirait pas les normes de revue du noyau. Il orienterait les agents vers un README qui dirige déjà les outils d’IA vers la politique détaillée du projet en matière de contribution. Le changement répond à un problème plus précis : les agents agissent souvent avant d’avoir lu une documentation rédigée avant tout pour des humains.

Cette distinction est importante, car le noyau indique déjà aux outils d’IA de ne pas certifier des correctifs au nom d’une personne. Il exige également une revue humaine, une attribution correcte, des tests et une responsabilité assumée. La proposition d’AGENTS.md pour le noyau Linux oppose donc des instructions faciles à découvrir à une réalité plus difficile : un fichier de dépôt peut guider un agent, mais il ne peut pas rendre fiable un correctif qui ne l’est pas.

La proposition d’AGENTS.md du noyau Linux modifie un seul point d’entrée

Le correctif change la façon dont les agents découvrent les règles existantes, et non les règles elles-mêmes.

Le mainteneur du noyau Sasha Levin a soumis un correctif intitulé « docs: add AGENTS.md as a symlink to README ». La proposition crée un lien symbolique de premier niveau nommé AGENTS.md, qui pointe vers le fichier README existant du dépôt.

Un lien symbolique est une référence du système de fichiers qui redirige un nom de fichier vers un autre fichier. Dans ce cas, un agent ouvrant AGENTS.md recevrait le même contenu déjà disponible via README, plutôt qu’une seconde copie des instructions.

Cette conception évite de créer deux documents de politique que les mainteneurs devraient synchroniser. La proposition de lien symbolique de Levin indique que le README existant dirige déjà les outils d’IA vers Documentation/process/coding-assistants.rst. Le problème est qu’un agent doit décider d’ouvrir le README avant que ce renvoi puisse l’aider.

De nombreux agents de codage inspectent automatiquement des fichiers d’instructions portant des noms particuliers. AGENTS.md est devenu l’un des noms de fichiers courants pour les consignes à l’échelle d’un dépôt, notamment les commandes de compilation, les exigences de test, les conventions de codage et les limites de sécurité.

Le fichier proposé pour le noyau ne contiendrait aucun texte distinct. Son seul contenu serait la cible du lien, README. Les points d’entrée humain et machine resteraient ainsi reliés à une même source maintenue.

Levin a inclus un exemple contrôlé pour expliquer pourquoi la découvrabilité importe. Deux agents ont reçu la même demande : créer un commit renommant la version du noyau dans le Makefile en « AI Test ».

Sans AGENTS.md, un agent a généré une ligne Signed-off-by pour l’utilisateur. L’autre n’a fourni aucune attribution à l’IA. Les deux résultats entraient en conflit avec les attentes documentées du noyau.

Avec le lien symbolique en place, les deux agents auraient, selon les informations rapportées, utilisé une balise Assisted-by: LLM et évité d’ajouter une signature humaine. Ils ont également suivi de plus près les conventions du projet pour les messages de commit. L’un a ajouté un corps descriptif, tandis que l’autre a employé la structure attendue « subsystem: summary phrase » pour l’objet.

Il s’agissait d’un test comportemental limité, et non d’une évaluation générale de la fiabilité des agents. Il ne mesurait pas si les agents pouvaient détecter des bogues subtils, produire des correctifs sûrs ou comprendre les contraintes propres à chaque sous-système. Il a montré que deux agents se comportaient différemment après avoir reçu un chemin automatiquement découvert vers les instructions existantes.

Le changement était toujours en cours de revue au moment où il a été rapporté. Le décrire comme une mesure déjà adoptée par Linux surestimerait donc l’événement. L’affirmation exacte est qu’un mainteneur du noyau a proposé le lien et fourni des éléments en sa faveur.

Kees Cook, éminent développeur de la sécurité du noyau, a répondu par un accusé de réception. Il a soutenu l’utilisation du README plutôt que le maintien d’une politique distincte réservée aux agents. Sa réponse de revue a également relevé qu’il serait souhaitable que les agents lisent la documentation sur les contributions avant de créer des correctifs.

Le correctif est suffisamment petit pour paraître cérémoniel. Son objectif pratique est toutefois concret. Il cherche à placer les informations de processus obligatoires sur le chemin qu’un outil d’IA est déjà entraîné ou configuré à inspecter.

La proposition constitue ainsi un changement d’interface. Les humains peuvent parcourir les arborescences de documentation et interpréter les normes communautaires. Les agents de codage fonctionnent de façon plus prévisible lorsque les dépôts exposent ces normes au moyen de noms de fichiers et de chemins que les outils reconnaissent.

La question qui en découle n’est pas de savoir si Markdown peut améliorer le code généré. Elle est de savoir si un point d’entrée fiable peut empêcher des erreurs de processus récurrentes avant que les mainteneurs ne doivent les relever manuellement.

Les règles existantes du noyau maintiennent les humains responsables

La politique du noyau Linux relative à l’IA traite un agent comme un assistant, jamais comme le propriétaire juridique ou technique d’une contribution.

Les règles sous-jacentes vont déjà bien plus loin que le lien symbolique proposé. Le guide de contribution IA du noyau guide les outils d’IA et leurs utilisateurs à travers le processus de développement standard, le style de codage, les exigences de soumission de correctifs, les règles de licence et la politique relative au contenu généré.

Plus important encore, le guide indique que les agents IA ne doivent pas ajouter de balise Signed-off-by. Cette ligne n’est pas une métadonnée décorative de commit. Elle représente la certification d’une personne au titre du Developer Certificate of Origin, communément appelé DCO.

Le DCO est le mécanisme par lequel un contributeur déclare que le travail soumis peut légalement entrer dans le projet sous sa licence. Un modèle de langage ne peut pas faire cette certification pour une personne. Il ne peut pas non plus déterminer si cette personne a effectué la revue nécessaire pour accepter la responsabilité.

L’auteur humain de la soumission doit examiner le code généré, confirmer la conformité des licences, ajouter la signature et assumer la responsabilité de la contribution. Un agent qui insère lui-même la signature fusionne ces étapes distinctes en texte généré.

C’est pourquoi le test de Levin importe malgré sa portée limitée. L’agent n’a pas simplement choisi un style de mise en forme impopulaire. Il a généré une déclaration que seul un humain peut légitimement faire.

La documentation du noyau attribue à la participation de l’IA un marqueur différent. Lorsqu’un outil d’IA contribue, le correctif doit utiliser une balise Assisted-by. Des outils d’analyse facultatifs comme Coccinelle, Sparse, Smatch ou Clang-Tidy peuvent également apparaître après l’étiquette LLM.

Ce modèle d’attribution distingue l’assistance de la paternité et de la certification. Il fournit aux relecteurs un contexte utile sans prétendre que le modèle peut assumer une responsabilité.

La documentation établit également un processus exigeant pour le travail sur les bogues assisté par l’IA. Un agent doit lire l’intégralité de la documentation pertinente, localiser un bogue précis et tenter de reproduire tout problème non trivial. Il doit abandonner une détection qui ne résiste pas à la vérification.

Si le problème semble réel, l’agent doit rédiger un correctif, le compiler, le tester avec le reproducer ou une analyse complète, puis exécuter les vérifications de correctifs du noyau. Il doit indiquer tout ce qu’il n’a pas pu vérifier.

Le guide demande en outre à l’agent d’identifier les mainteneurs et listes de diffusion concernés. Il doit déterminer si le problème relève du processus habituel de traitement des bogues ou du processus confidentiel de sécurité. L’agent doit laisser la soumission effective à la personne qui l’utilise.

Ces exigences révèlent les limites consistant à considérer AGENTS.md comme une solution à lui seul. Le fichier peut orienter un agent vers la bonne liste de contrôle. Il ne peut pas confirmer qu’un reproducer est pertinent, que les tests sont suffisants ou que l’humain comprend le code.

Le développement du noyau couvre également des milliers de composants aux attentes spécialisées. Des instructions générales ne peuvent pas contenir chaque contrainte architecturale, hypothèse matérielle ou préférence de mainteneur.

Un agent pourrait respecter parfaitement les règles de formatage visibles tout en comprenant mal la gestion de durée de vie, le verrouillage, l’ordonnancement mémoire ou le comportement d’un périphérique. Un message de commit soigné peut rendre un tel correctif plus facile à examiner, mais il ne rend pas le raisonnement sous-jacent correct.

Cela crée une limite utile. Les instructions du dépôt peuvent réduire les erreurs administratives évitables. La confiance technique doit toujours provenir des éléments probants, des tests, de la revue experte et de contributeurs responsables.

Pour les mainteneurs, cette séparation est importante. Chaque soumission mal formée consomme de l’attention avant même que quiconque n’en examine le fond technique. Une meilleure découverte des instructions peut réduire cette charge sans abaisser le seuil d’acceptation.

Pour les contributeurs, la politique est tout aussi claire. Utiliser un agent ne transfère pas la responsabilité. Un développeur doit pouvoir expliquer et défendre le résultat comme si chaque ligne avait été écrite manuellement.

Pourquoi les agents de codage IA continuent d’ignorer le README

Le conflit oppose une documentation qui existe à des instructions qui apparaissent dans le contexte automatique d’un agent.

Les dépôts organisent traditionnellement leurs informations destinées aux contributeurs pour des humains. Un README présente le projet, tandis que les fichiers de contribution, les répertoires de documentation, les pages de listes de diffusion et les scripts contiennent des procédures plus spécialisées.

Une personne arrivant dans l’arborescence des sources Linux peut suivre cette hiérarchie. Un agent recevant une requête ciblée peut au contraire n’inspecter que les fichiers qu’il considère comme immédiatement pertinents. S’il n’ouvre jamais le README racine, le lien du README vers la politique IA reste invisible.

Ce comportement est apparu dans une récente discussion du noyau concernant un correctif Qualcomm I2C assisté par l’IA. Un mainteneur a observé que le processus était documenté par une chaîne commençant dans le README et se poursuivant dans coding-assistants.rst. Pourtant, les outils ne suivaient pas cette chaîne de manière fiable.

La discussion entre mainteneurs a soulevé l’absence de fichier AGENTS.md ou CLAUDE.md que les outils courants inspectent par défaut. Elle a également averti que l’ajout d’un tel fichier ne résoudrait pas nécessairement tout.

C’est la pression qui sous-tend la nouvelle proposition. Les mainteneurs du noyau reçoivent des correctifs assistés par l’IA, que le dépôt optimise ou non sa documentation pour les agents. Refuser d’ajouter un point d’entrée n’empêche pas les contributeurs d’utiliser ces outils.

Le choix pratique est plus restreint. Les mainteneurs peuvent laisser les agents découvrir de manière incohérente une documentation conçue pour les humains, ou placer un repère familier à la racine du dépôt.

La convention plus large AGENTS.md décrit le fichier comme un README pour les agents. Sa documentation de format ouvert indique que plus de 60 000 projets open source utilisent cette convention, bien que ce chiffre reflète des exemples indexés plutôt qu’une mesure auditée de l’usage actif des agents.

Le format n’impose aucun schéma obligatoire. Un projet peut répertorier des commandes de configuration, des règles de style de code, des tests, des préoccupations de sécurité ou des liens vers une documentation plus approfondie. Des fichiers imbriqués peuvent fournir des instructions plus spécifiques pour les sous-répertoires.

Cette flexibilité aide à expliquer la diffusion du format. Un dépôt peut utiliser un seul fichier Markdown simple avec plusieurs outils sans s’engager dans un système de configuration propriétaire.

La proposition du noyau emploie une version inhabituellement prudente de ce modèle. Elle ne créerait pas un vaste manuel pour agents et ne répéterait pas des informations déjà maintenues ailleurs. Elle exposerait le README existant sous un nom que les agents sont susceptibles de demander.

Cette approche préserve également la cohérence entre les consignes destinées aux humains et celles destinées aux machines. Kees Cook a déclaré que le README avait été délibérément conçu pour fonctionner avec des agents. Créer un lien vers celui-ci renforce ce parcours commun plutôt que de créer un ensemble privé de règles que les contributeurs humains pourraient ne jamais voir.

Une source partagée réduit la dérive des politiques. Si les mainteneurs mettent à jour le README ou son renvoi vers le guide sur l’IA, les agents reçoivent la modification via le lien symbolique. Un AGENTS.md copié pourrait devenir obsolète sans que personne ne s’en aperçoive.

L’utilisation d’un lien symbolique introduit toutefois une question de compatibilité. Les systèmes de type Unix gèrent naturellement les liens symboliques de dépôt, mais certaines configurations Windows les extraient sous forme de fichiers ordinaires. Un agent pourrait alors voir le mot README plutôt que le contenu référencé.

Cela n’invalide pas la proposition, en particulier pour un projet développé principalement au moyen de flux de travail Linux établis. Cela montre en revanche pourquoi le patch doit être évalué comme une infrastructure, et non comme des métadonnées magiques.

Le comportement des outils varie également. Certains agents chargent automatiquement AGENTS.md, tandis que d’autres privilégient des noms de fichiers propres à l’outil ou exigent une configuration explicite. Un nom de fichier à vocation universelle ne garantit pas une ingestion universelle.

Le patch améliore donc le parcours probable pour de nombreux agents sans éliminer les différences entre outils. Son utilité dépend du fait que le client suive le lien, respecte les instructions et les conserve tout au long de la tâche.

Ces conditions sont plus exigeantes que le simple fait de disposer d’une bonne documentation. Elles sont moins fortes qu’un contrôle technique applicable de manière contraignante.

De Meilleures Instructions Ne Rendent Pas les Patches Générés Sûrs

AGENTS.md peut améliorer la conformité, mais ne peut pas établir la justesse, la provenance ou une véritable revue humaine.

L’argument le plus solide en faveur de la proposition est opérationnel. Les agents produisent déjà des patches liés au noyau, les mainteneurs devraient donc leur fournir un chemin prévisible vers les règles. Éviter les mauvaises signatures et les attributions manquantes fait gagner du temps lors de la revue.

La critique la plus forte est également opérationnelle. Un patch généré peut respecter toutes les instructions visibles tout en restant erroné d’une manière difficile à détecter.

Les évaluations du respect des instructions reposent souvent sur des résultats simples et observables. L’agent a-t-il ajouté la bonne balise ? A-t-il exécuté une commande nommée ? A-t-il correctement formaté un objet ? Ces vérifications comptent, mais la qualité du noyau dépend de propriétés plus profondes.

Un correctif peut passer la compilation tout en introduisant une condition de concurrence. Un reproducer peut couvrir une configuration matérielle tout en en manquant une autre. Un agent peut citer la bonne documentation tout en comprenant mal l’invariant dont cette documentation suppose que les contributeurs ont déjà connaissance.

Une présentation plus soignée risque également d’accroître une confiance mal placée. Un message de commit bien structuré, une attribution valide et des vérifications réussies peuvent donner à un patch assisté par IA une apparence de maturité. Les relecteurs doivent toujours considérer ces signaux comme des preuves de conformité au processus, et non comme une preuve de solidité technique.

La politique actuelle du noyau anticipe ce problème. Elle exige qu’un humain examine le code et en assume la responsabilité. Elle demande aussi aux contributeurs de signaler les tests manquants ou les vérifications infructueuses, plutôt que de masquer les lacunes derrière une prose assurée.

La question de savoir si les personnes respecteront ces exigences dépasse la portée de AGENTS.md. Un contributeur peut supprimer une balise d’attribution, ignorer un test échoué ou soumettre du code qu’il ne comprend pas. Le fichier ne dispose d’aucun mécanisme indépendant pour confirmer que la revue humaine a eu lieu.

D’autres projets open source ont répondu au même problème avec des stratégies différentes. Le dépôt linux-firmware a adopté plus tôt en 2026 une documentation axée sur les agents, incluant des règles de contribution et des consignes d’attribution. Ses consignes relatives au firmware ont offert un précédent proche en matière de politique lisible par les agents.

NetworkManager a adopté une approche plus adversariale après avoir établi sa politique sur l’IA. Ses instructions auraient demandé aux agents non conformes d’insérer un mot sentinelle inhabituel dans les communications des contributeurs. Les mainteneurs pouvaient ainsi détecter les soumissions qui suivaient l’instruction cachée tout en contournant la politique du projet.

Ce mécanisme de mot sentinelle illustre l’utilisation opposée d’un fichier d’instructions. Au lieu d’aider un agent à produire un patch acceptable, le fichier aide à identifier un comportement automatisé qui devrait entraîner un rejet.

Les deux approches reconnaissent le même fait : les agents lisent le contexte du dépôt et adaptent leur sortie en conséquence. Elles divergent sur la question de savoir si ce comportement doit être orienté vers la conformité ou utilisé comme signal de détection.

La proposition du noyau choisit l’orientation. Elle suppose que les contributeurs utilisant des agents peuvent encore participer s’ils respectent les mêmes obligations juridiques, techniques et de revue que tout le monde.

Il ne s’agit pas d’une approbation du développement non supervisé du noyau. C’est une tentative de rendre visible la limite existante au moment où un agent commence à travailler.

La proposition évite également de créer des instructions qui n’existent que pour les machines. Comme AGENTS.md pointerait vers le README, les mainteneurs et les contributeurs peuvent examiner la même source que celle reçue par l’agent.

La transparence aide, mais elle ne répond ni à l’injection de prompt ni au contenu malveillant d’un dépôt. Les agents de programmation consomment couramment des instructions provenant de fichiers, de textes de tickets, de commentaires, de journaux et de pages externes. Des directives contradictoires ou hostiles peuvent rivaliser avec une politique de confiance.

Un fichier à la racine peut établir des priorités pour les outils coopératifs. Il ne peut pas garantir que chaque outil applique correctement ces priorités, surtout lorsque l’agent lit des fichiers plus profonds contenant un langage contradictoire.

Il existe un risque de maintenance connexe. Toute consigne de dépôt peut devenir obsolète à mesure que les flux de travail évoluent. Le lien symbolique proposé limite la duplication, mais les documents liés nécessitent toujours une revue active.

L’échelle du noyau rend cette maintenance particulièrement importante. Des instructions globalement correctes peuvent néanmoins être incomplètes pour un sous-système donné. Les agents et les contributeurs doivent continuer à consulter la documentation locale, les mainteneurs, les systèmes de build et l’infrastructure de test.

Le point de vue mesuré n’est donc ni « AGENTS.md corrige le code d’IA » ni « le fichier ne signifie rien ». Il peut réduire une catégorie précise d’erreurs prévisibles tout en laissant intact le travail de vérification le plus difficile.

Cette affirmation modeste est étayée par l’exemple de Levin. Toute conclusion plus large attend des preuves issues de contributions réelles dans des sous-systèmes et des outils variés.

Ce Qui Se Passera Ensuite Comptera Davantage Que le Lien Symbolique

La proposition devrait être jugée à l’aune des résultats de revue, du comportement des agents et de la charge de travail des mainteneurs après son adoption.

Le premier signal est le sort réservé au patch. Un accusé de réception soutient la conception, mais la modification doit encore suivre le processus de documentation du noyau et atteindre le dépôt principal avant de devenir une infrastructure standard du projet.

Les relecteurs pourraient accepter le lien symbolique sans modification, demander un fichier ordinaire, exiger des ajustements de compatibilité ou conclure que la voie du README est insuffisante. Chaque résultat préciserait la manière dont le noyau souhaite exposer les règles aux outils automatisés.

Le deuxième signal concerne la capacité des principaux agents de programmation à suivre le lien de manière cohérente. La comparaison de Levin entre deux agents est utile, mais limitée. Des tests plus larges devraient couvrir différents outils, prompts, répertoires de travail et types de contribution.

Une implémentation réussie produirait moins de signatures générées, des balises Assisted-by plus cohérentes, de meilleurs objets de commit et une divulgation plus claire du travail non testé. Il s’agit d’améliorations observables du processus.

L’échec aurait une autre apparence. Les agents pourraient ignorer le lien symbolique, ne lire qu’une partie du contenu lié ou suivre des règles génériques tout en manquant les exigences propres à un sous-système. Des fichiers d’instructions spécifiques aux outils pourraient rester nécessaires.

Le troisième signal, et le plus important, est la charge de travail des mainteneurs. Si le fichier réduit les corrections répétitives sans accroître le nombre de soumissions de faible qualité, il aura rempli un objectif pratique.

Si une sortie d’agent plus soignée encourage davantage de contributeurs à envoyer des patches qu’ils sont incapables d’expliquer, le lien pourrait améliorer la présentation tout en aggravant la charge de revue. Ce résultat affaiblirait le pari sous-jacent de la proposition.

Les mainteneurs devraient également surveiller si les contributeurs utilisent l’attribution de manière honnête. La convention Assisted-by n’a de valeur que si les personnes la préservent. La conformité automatisée lors de la génération ne peut empêcher quelqu’un de modifier le commit avant sa soumission.

Les projets au-delà de Linux étudieront le résultat. Le noyau est l’une des bases de code collaboratives les plus visibles et les plus exigeantes ; son traitement des instructions destinées aux agents a donc un poids symbolique, même lorsque le patch est techniquement minuscule.

Cette influence ne doit pas être confondue avec une politique universelle. Les dépôts plus petits, les équipes commerciales et les projets présentant des profils de risque différents peuvent choisir des fichiers d’instructions plus complets, des configurations propres aux outils, des contrôles automatisés ou des interdictions concernant certaines contributions générées.

L’approche du noyau est remarquable parce qu’elle ne construit pas un processus de développement parallèle. Elle renvoie les agents vers le processus qui régit déjà les personnes.

Pour les équipes d’ingénierie, la leçon immédiate est de séparer la découvrabilité de l’autorité. Un contexte lisible par les agents peut identifier les bonnes commandes et les contraintes pertinentes. Les tests, les revues, la responsabilité et les systèmes d’approbation doivent toujours garantir le travail.

Les équipes qui documentent ces limites peuvent également maintenir le contexte technique consultable grâce à une base de connaissances d’ingénierie. L’essentiel est d’exposer une source maintenue unique plutôt que de copier les règles dans plusieurs fichiers d’agents.

Au cours des prochains mois, surveillez l’historique du patch, les soumissions réelles assistées par IA et les réponses des mainteneurs. Ces signaux montreront si les consignes AGENTS.md du noyau Linux éliminent du bruit évitable ou ne font que normaliser la manière dont ce bruit arrive.

Les mainteneurs de dépôts devraient poser une question tout aussi concrète : quelle erreur répétée d’un agent provient d’un contexte manquant, et laquelle exige un contrôle applicable de manière contraignante ? Placez les consignes stables là où les outils les trouveront, puis mesurez si le comportement change. Maintenez la revue humaine responsable de tout ce qu’un fichier Markdown ne peut pas prouver.