559 CLAUDE.md : 63 % ne sont pas des règles

Ce qui se passe

L'auteur de RuleReceipt, un outil qui vérifie si un agent a suivi les règles de votre fichier de configuration, s'est aperçu qu'il testait son parseur sur un seul fichier : le sien. Il est donc allé en chercher 559 — CLAUDE.md, AGENTS.md, .cursorrules, instructions Copilot, Windsurf, Gemini — dans PyTorch, Kubernetes, Elasticsearch et quelques centaines de dépôts plus petits. 23 704 éléments analysés, aucun plantage.

Deux résultats en sortent.

62,9 % du fichier n'est pas une règle

Arborescences de répertoires, tables de référence, exemples d'import, notes d'architecture, aide-mémoire de syntaxe glob. C'est de la documentation utile, mais elle ne demande rien à l'agent — et elle occupe le même fichier que les vraies consignes, en concurrence pour la même attention.

La conséquence reformule un problème courant : un CLAUDE.md de 400 lignes, ce n'est généralement pas 400 lignes de règles. C'est plutôt 150 lignes de règles et 250 lignes de README agrafées derrière. Le fichier n'est pas trop long : les règles y sont enfouies.

43,5 % seulement des vraies règles sont vérifiables

Le second résultat est le plus surprenant pour qui outille des agents. Parmi ce qui est bien une directive, moins de la moitié peut être contrôlée mécaniquement.

Vérifiable, parce qu'il en reste une trace : « ne jamais commiter directement sur main », « pas de console.log dans le code commité », « lancer la suite de tests avant de pousser ». La commande a tourné, ou non.

Non vérifiable, par aucun outil : « annonce d'abord les mauvaises nouvelles », « explique le compromis avant de choisir une approche », « garde les changements relisables ». Ce n'est pas une limite du parseur — l'information n'est pas dans la transcription. Or 56,5 % des règles que les gens écrivent tombent là.

Pourquoi le chiffre tient

À 40 fichiers, la proportion de non-directives était de 65,4 %. À 559, elle est de 62,9 % — 2,5 points d'écart, alors que l'auteur avait entre-temps ajouté des formats pour lesquels le parseur n'avait jamais été réglé.

Il en tire une hypothèse défendable : « est-ce une directive ? » est une propriété du langage, pas du format de fichier. Ce qui compte, parce que l'approche alternative — reconnaître chaque manière de mettre en forme une règle — est une liste infinie.

Ce qu'il ne prétend pas

L'auteur le dit : il n'a aucune expérience contrôlée montrant qu'un fichier long dégrade les performances d'un modèle. Il publie aussi le cas où son outil a rapporté 10 violations sur une session réelle, toutes fausses.

À retenir

1. Séparer les directives de la documentation : deux fichiers, deux rôles.
2. Distinguer ensuite les règles qu'un outil peut contrôler de celles qui demandent une relecture humaine — cela change ce qu'on peut automatiser.
3. L'outil est npx rulereceipt check, local et sans compte ; le classifieur est dans le dépôt.

Source : DEV Community