llms.txt : ce qu'est vraiment ce fichier, et ce qu'il n'est pas

Tous les quelques mois, un nouveau fichier apparaît à la racine des sites et tout le monde pose les deux mêmes questions : est-il obligatoire, et fait-il monter mon classement. Pour llms.txt, les réponses sont non et non. Il vaut quand même la peine de l'écrire, et la spécification explique pourquoi en deux paragraphes environ, soit à peu près deux paragraphes de plus que ce que la plupart des articles à son sujet en citent.

Les deux problèmes qu'il traite

Le premier est une limite dure. Comme le dit la spécification, les grands modèles de langage s'appuient de plus en plus sur l'information des sites web, mais se heurtent à une limite critique : les fenêtres de contexte sont trop petites pour traiter la plupart des sites dans leur intégralité. Un modèle qui répond à une question sur votre produit ne peut pas lire votre site. Il peut en lire une tranche, et quelque chose doit décider laquelle.

Le second est une question de qualité. Convertir des pages HTML complexes, avec navigation, publicités et JavaScript, en texte brut exploitable par un modèle est à la fois difficile et imprécis. Même la partie qui est lue arrive dégradée, mêlée aux menus, aux bandeaux de cookies et à tout ce que votre framework a injecté.

llms.txt répond aux deux d'un coup, en vous rendant la décision. Plutôt qu'un modèle devine quelles vingt pages de votre site comptent et les analyse mal, vous lui tendez une liste courte, propre et choisie. C'est toute l'idée.

Où il vit, et pourquoi l'emplacement compte

Le fichier se place à la racine du site, au chemin /llms.txt, ou éventuellement dans un sous-chemin. Une adresse prévisible est tout l'intérêt : ce qui le cherche le trouve sans qu'on ait à le lui dire.

On est tenté de le ranger mentalement à côté de robots.txt, et la comparaison aide tant qu'on garde la différence en vue. robots.txt est une restriction : il dit ce qu'un robot n'a pas le droit de récupérer. llms.txt est une recommandation : il dit ce qui mérite d'être lu en premier. L'un est une clôture, l'autre un panneau indicateur. Poser un panneau ne retire pas votre clôture, et n'en construit pas non plus.

La structure est plus légère qu'on ne le croit

L'essentiel de l'inquiétude autour de ce fichier vient de l'idée qu'il imposerait un schéma exigeant. Ce n'est pas le cas.

Un H1 portant le nom du projet ou du site. La spécification précise que c'est la seule section obligatoire. Tout le reste est facultatif au sens strict.

Une citation contenant un résumé court du projet, avec l'information clé nécessaire pour comprendre le reste du fichier. C'est la phrase qui dit au modèle ce qu'il a sous les yeux avant qu'il ne lise le moindre lien, et c'est la partie qui mérite le plus d'être réécrite deux fois.

Zéro ou plusieurs sections markdown délimitées par des titres H2, contenant des listes de liens. Regroupez selon ce qu'un lecteur chercherait à faire : documentation, guides, référence, tarifs. Le regroupement porte du sens, donc des intitulés vagues le gaspillent.

La section Optional est une vraie instruction, pas une étiquette

Un nom de section a un comportement défini, et c'est celui que l'on comprend à l'envers. La spécification énonce que la section « Optional » a une signification particulière : si elle est présente, les URLs qui s'y trouvent peuvent être ignorées lorsqu'un contexte plus court est nécessaire.

Lisez-la pour ce qu'elle est : une instruction de tri que vous écrivez vous-même. Vous indiquez au modèle lesquels de vos liens abandonner en premier quand la place vient à manquer. Y placer vos meilleures pages explicatives parce que l'intitulé sonne modeste est la seule erreur qui vous nuise activement : vous avez désigné votre contenu le plus utile comme le premier à jeter.

C'est un fichier d'inférence, pas d'entraînement

Cette distinction règle la plupart des objections faites à llms.txt, et les auteurs l'énoncent sans détour : leur attente est que llms.txt serve principalement à l'inférence, c'est-à-dire au moment où un utilisateur cherche de l'aide, par opposition à l'entraînement.

Le scénario qu'il sert est donc étroit et concret. Quelqu'un pose une question à un assistant. L'assistant part chercher. Votre fichier est ce qu'il trouve en premier, et il décide de ce qui sera lu dans les secondes qui suivent. Si votre inquiétude porte plutôt sur l'entraînement des modèles sur votre contenu, ce fichier est le mauvais instrument, et ce sont les directives de robots.txt qu'il faut discuter.

Ce qu'il ne fait pas

C'est une convention proposée. Rien n'oblige un fournisseur à la lire, et aucun moteur de recherche n'a rien promis en échange de sa publication. Qui vous présente ce fichier comme un facteur de classement décrit un espoir, pas un mécanisme.

L'argument honnête pour l'écrire est différent, et selon nous plus solide : le coût est proche de zéro, l'inconvénient est nul, et l'exercice consistant à décider quelles vingt pages représentent réellement votre activité vaut d'être fait même si rien ne lit jamais le résultat. La plupart des équipes découvrent à mi-parcours qu'elles ne sont pas d'accord sur la liste. C'est cette partie-là qui est utile.

Questions fréquentes

Quel problème llms.txt résout-il réellement ?

Deux, et la spécification les énonce tous les deux. Le premier est une question de taille : les grands modèles de langage s'appuient de plus en plus sur l'information des sites web, mais se heurtent à une limite critique, à savoir que les fenêtres de contexte sont trop petites pour traiter la plupart des sites dans leur intégralité. Le second est une question de bruit : convertir des pages HTML complexes, avec navigation, publicités et JavaScript, en texte brut exploitable par un modèle est à la fois difficile et imprécis. llms.txt n'est donc ni un fichier de classement ni un fichier de permissions. C'est une carte choisie, et déjà propre, de ce qui compte sur votre site.

Où doit se trouver le fichier ?

À la racine du site, au chemin /llms.txt, ou éventuellement dans un sous-chemin. C'est toute la règle d'emplacement. Il voisine robots.txt par l'esprit, à une adresse prévisible, mais il fait le travail inverse : robots.txt dit ce qu'un robot n'a pas le droit de récupérer, llms.txt dit ce qui mérite d'être lu en premier.

Quelle structure est exigée ?

Moins que ce que l'on croit. La spécification demande un H1 portant le nom du projet ou du site, et précise que c'est la seule section obligatoire. Vient ensuite une citation contenant un résumé court du projet, avec l'information clé nécessaire pour comprendre le reste du fichier, puis zéro ou plusieurs sections markdown délimitées par des titres H2, contenant des listes de liens. Tout ce qui suit le H1 est donc facultatif au sens strict, et c'est pourquoi un llms.txt utile s'écrit en vingt minutes.

Que signifie la section Optional ?

C'est un nom de section au comportement défini, pas une étiquette que l'on invente. La spécification est explicite : si elle est présente, les URLs qui s'y trouvent peuvent être ignorées lorsqu'un contexte plus court est nécessaire. C'est votre propre déclaration de priorité, qui indique au modèle quels liens abandonner en premier quand la place manque. Y placer vos pages les plus importantes revient exactement à l'inverse de ce que vous vouliez.

llms.txt sert-il à entraîner des modèles sur mon contenu ?

Non, et les auteurs le disent directement : leur attente est que llms.txt serve principalement à l'inférence, c'est-à-dire au moment où un utilisateur cherche de l'aide, par opposition à l'entraînement. C'est un fichier pour l'instant où quelqu'un pose une question et où un modèle part chercher une réponse. Si votre préoccupation porte sur l'entraînement, llms.txt est le mauvais levier et ce sont les directives de robots.txt qu'il faut discuter.

Google utilise-t-il llms.txt ?

Aucun fournisseur n'a l'obligation de le lire, et le traiter comme un facteur de classement, c'est se méprendre sur sa nature. C'est une convention proposée, adoptée par ceux qui le veulent bien. Cela dit, le coût de publication est proche de zéro et l'inconvénient est nul, ce qui est une combinaison rare. Écrivez-le parce qu'il rend votre contenu lisible par ce qui le lira, pas parce qu'un moteur aurait promis quoi que ce soit.

L'énoncé de la limite des fenêtres de contexte, la description de la conversion HTML vers texte comme difficile et imprécise, la règle d'emplacement à la racine, le H1 obligatoire et son statut de seule section requise, le résumé en citation, les sections H2 de listes de liens, la signification particulière de la section « Optional », et l'attente que le format serve l'inférence plutôt que l'entraînement, proviennent tous de la spécification llms.txt, consultée au moment de la rédaction. C'est une convention proposée, susceptible d'évoluer.

L'accompagnement ZAX sur la visibilité IA

Nous aidons les équipes à rendre leur contenu lisible par les applications d'IA : données structurées, llms.txt, serveurs MCP exposant les systèmes internes, et la mesure qui dit si tout cela fonctionne.

Audit et cadrage. Un audit IA gratuit de 30 minutes examine ce qu'un assistant trouve aujourd'hui à votre sujet, et ce qu'il se trompe à dire.

Contactez-nous pour parler de votre visibilité auprès des IA.