llms.txt : ce que ce fichier fait réellement, et ce qu'il ne fait pas

Le fichier llms.txt est arrivé dans les conversations sur la visibilité avec une analogie séduisante et trompeuse : ce serait le robots.txt des moteurs génératifs. L’analogie est fausse sur les trois points qui comptent. Ce fichier n’a pas de statut normatif établi, il n’a aucun caractère contraignant, et rien ne garantit qu’un système donné le consulte. Le publier en croyant contrôler quelque chose conduit à une déception, et parfois à négliger le mécanisme qui, lui, fonctionne réellement.

Je le recommande néanmoins, et je vais expliquer pourquoi — mais la raison n’est pas celle qu’on avance habituellement.

Ce qu’il est, et ce qu’il n’est pas

	robots.txt	llms.txt
Statut	Convention ancienne, largement respectée	Proposition récente, adoption partielle
Fonction	Autoriser ou interdire l’exploration	Orienter : voici ce qui compte, voici où
Contraignant	Respecté par les robots sérieux	Aucune garantie de lecture
Contrôle d’accès	Oui, en pratique	Non, en aucun cas

La conséquence pratique tient en une phrase : ce qui doit être bloqué se bloque ailleurs. Par robots.txt pour les robots qui le respectent, et par des règles au niveau du serveur — authentification, filtrage — pour ce dont on veut réellement empêcher l’accès. Un fichier d’orientation ne protège rien.

Cette clarification est nécessaire parce que je rencontre régulièrement des organisations qui ont publié un llms.txt en pensant avoir traité la question de l’accès de l’IA à leur contenu, et qui n’ont pas touché à leur robots.txt.

La raison de le publier quand même

Elle est double, et aucune des deux ne dépend du taux d’adoption du format.

Le coût est nul et le risque est nul. Quelques heures de rédaction, un fichier statique à la racine, aucune interaction avec le reste du site. Même si son adoption restait marginale, la mise n’est pas engageante.

L’exercice de rédaction a une valeur propre. Écrire en une page ce que le site propose, à qui il s’adresse, et où se trouve quoi, oblige à une clarté qu’aucun autre document n’impose. Dans les cas que j’ai traités, cet exercice a systématiquement révélé des incohérences : deux sections qui se recouvrent, un intitulé de menu qui ne dit pas ce que la page contient, une offre importante enterrée à trois clics.

Autrement dit : le bénéfice le plus fiable de ce fichier est ce qu’il vous apprend sur votre propre site en l’écrivant.

Le gain le plus certain de ce fichier n’est pas d’être lu par une machine. C’est ce que sa rédaction révèle sur l’organisation de votre propre site.

Ce qu’un fichier utile contient

La différence entre un fichier qui sert et un fichier qui décore tient à une seule qualité : la sélection.

Un bon fichier commence par situer l’entité en quelques lignes — ce qu’elle fait, pour qui, où, dans quelles langues. Puis il liste les ressources qui comptent, groupées par nature, chacune accompagnée d’une phrase disant ce qu’on y trouve. Cette phrase est l’élément qui fait la différence : une URL seule n’apporte rien qu’un plan de site ne donne déjà.

Un mauvais fichier reproduit le plan du site. Trois cents URL sans hiérarchie ni description signalent une génération automatique et n’aident personne — ni une machine, qui dispose déjà du plan de site, ni un humain qui l’ouvrirait.

La règle que j’applique : si le fichier fait plus de deux écrans, il liste probablement trop de choses. C’est une carte, pas un inventaire.

L’erreur qui vide le fichier de son sens

Il existe un défaut plus grave que la longueur, et il est fréquent sur les sites qui génèrent ce fichier automatiquement : la désynchronisation.

Un fichier qui référence des pages qui n’existent plus, qui décrit une offre retirée, ou qui omet les publications des six derniers mois est pire qu’absent. Il donne une image fausse de ce que le site propose, et cette image sera reprise telle quelle par tout système qui la lit.

La correction est structurelle : le fichier doit être généré à partir du contenu réel au moment de la construction du site, pas rédigé une fois à la main. Les sections stables — présentation, offres — peuvent être écrites ; les listes de publications doivent être produites depuis la source de contenu, avec la même règle de filtrage que le site lui-même.

C’est le même principe que celui qui gouverne l’exactitude du balisage produit¹ : ce qui est déclaré doit provenir de la même source que ce qui est affiché, au même instant.

Ce qui compte davantage

Il faut remettre ce fichier à sa place dans l’ordre des priorités, parce qu’il attire une attention disproportionnée.

Ce qui détermine réellement qu’un contenu soit repris par un moteur génératif tient à des propriétés du contenu lui-même : des affirmations autonomes et vérifiables, une structure extractible, des faits datés, une source identifiable². Un fichier d’orientation ne compense aucune de ces absences.

L’ordre que je recommande est donc celui-ci. D’abord vérifier que les robots concernés sont autorisés dans robots.txt — j’ai vu des marques en bloquer certains par héritage d’une configuration ancienne, sans l’avoir décidé. Ensuite travailler l’extractibilité du contenu. Enfin publier llms.txt, parce qu’il coûte peu et qu’il oblige à un exercice utile.

L’inverse — soigner le fichier d’orientation sur un contenu qui n’a rien d’extractible — revient à poser une signalisation impeccable devant une porte fermée.

---

Footnotes

1. Sur la synchronisation entre ce qui est déclaré et ce qui est affiché, voir Données structurées : ce que les moteurs lisent vraiment sur une fiche produit. ↩

2. Sur ce qui rend un passage citable par un moteur génératif, voir Se faire citer par les moteurs génératifs. ↩