llms.txt : ce que c'est et comment le rédiger

Ce que dit réellement la proposition

Le problème que llms.txt cherche à résoudre est celui du contexte, pas du crawl. Quand un modèle ou un agent doit répondre à une question en s'appuyant sur votre site, il dispose d'une fenêtre de contexte limitée et d'une entrée hostile : des pages HTML saturées de navigation, de bandeaux cookies, de colonnes latérales, de publicités et de contenus rendus en JavaScript. Convertir un site volumineux en quelque chose sur quoi un modèle peut raisonner est à la fois coûteux et source de perte d'information.

La spécification llms.txt propose deux réponses complémentaires. D'abord, un unique fichier Markdown à /llms.txt qui fait office d'index curé : voici ce qu'est ce projet, voici les pages qui comptent, par ordre de priorité. Ensuite, la publication de versions Markdown propres de chaque page à des URL prévisibles (une page /docs/setup également disponible en /docs/setup.md), afin qu'une fois un lien choisi dans votre index, l'agent récupère du texte plutôt qu'un gabarit.

Notez bien ce que ce n'est pas. Le fichier ne contient aucune directive, aucune règle d'autorisation ou d'interdiction, aucune permission. C'est une liste de lecture que vous proposez, et tout consommateur reste libre de l'ignorer. La spécification retient délibérément le Markdown plutôt que JSON ou XML, précisément parce que le consommateur visé est un modèle de langage, et parce qu'un humain doit pouvoir maintenir le fichier à la main.

• Où en est réellement l'adoption
• paragraphes
• puces

Où en est réellement l'adoption

Méfiez-vous de quiconque affirme que llms.txt est désormais un facteur de classement. John Mueller, de Google, l'a publiquement comparé à l'ancienne balise meta keywords et a indiqué que Google ne l'utilise pas pour Search ; vous en trouverez la couverture sur Search Engine Roundtable. La documentation de Google sur l'exploration et l'indexation ne mentionne nulle part ce fichier ; celui qu'elle documente pour le contrôle des robots, c'est robots.txt.

Du côté des consommateurs, la position honnête est la suivante : aucun éditeur majeur d'assistant n'a publié de documentation indiquant que son crawler ou sa couche de récupération s'appuie sur /llms.txt pour décider quoi récupérer ou citer. Là où le fichier est manifestement utilisé, c'est dans l'autre sens : des développeurs collent une URL llms.txt dans une conversation ou l'indiquent à un agent de codage, et l'agent suit les liens. C'est un usage réel, et c'est précisément celui pour lequel la spécification a été écrite.

Côté éditeurs, l'adoption se voit surtout dans la documentation technique, en partie parce que des plateformes de documentation comme Mintlify génèrent le fichier automatiquement pour les sites qu'elles hébergent. C'est une bonne raison d'en avoir un si vous publiez de la doc — et une mauvaise raison de supposer que l'écosystème s'est standardisé. Une convention dont l'adoption ne coûte presque rien ne dit pas grand-chose sur le fait que quoi que ce soit la consomme.

Comment rédiger llms.txt : le format exact

La spécification définit un ordre de document précis, et c'est tout l'intérêt : un consommateur doit pouvoir l'analyser avec un simple parseur Markdown plutôt qu'avec des heuristiques.

Le seul élément obligatoire est un H1 contenant le nom du site ou du projet. Tout ce qui suit est facultatif mais contraint par sa position : une citation (blockquote) facultative, immédiatement après le H1, contenant un résumé court avec les informations clés nécessaires pour comprendre le reste ; puis zéro ou plusieurs blocs Markdown de texte ou de listes apportant des détails supplémentaires, sans aucun titre ; puis zéro ou plusieurs sections H2, chacune contenant une liste de liens.

Les lignes de lien prennent la forme d'un élément de liste Markdown avec un lien et une description facultative après deux points : le nom, l'URL, puis une phrase expliquant quand lire cette page. Ces descriptions ont un vrai rôle fonctionnel : c'est ainsi qu'un modèle décide auxquels de vos quinze liens consacrer son contexte. Rédigez-les comme des instructions d'orientation, pas comme du discours marketing.

Un H2 a une signification particulière : une section intitulée Optional. Les liens qui y figurent peuvent être ignorés lorsqu'un contexte plus court est nécessaire. Réservez-la aux changelogs, aux références approfondies et à tout ce dont un lecteur peut raisonnablement se passer. Une autre convention, llms-full.txt, qui contient le texte complet concaténé de votre documentation, est populaire auprès des plateformes de doc mais ne fait pas partie de la spécification de base : traitez-la comme un extra, et ne la publiez que si votre contenu tient réellement dans une fenêtre de contexte moderne.

• Servez-le à la racine du domaine, en /llms.txt, en text/plain ou text/markdown, via HTTPS.
• Restez court. Dix à trente liens curés valent mieux qu'un vidage de sitemap ; si vous avez besoin de toutes vos URL, vous avez déjà un sitemap XML.
• Rédigez des descriptions qui lèvent l'ambiguïté : « paliers tarifaires et limites », pas « en savoir plus sur Growli ».
• Ne liez que des pages publiquement accessibles et stables. Des liens morts dans un index curé sont pires que pas d'index du tout.
• Générez-le à la compilation, pas à la main, si votre documentation change chaque semaine.

Un exemple concret : le fichier de Growli

Le nôtre est volontairement minimal. Growli mesure la façon dont les assistants IA mentionnent et recommandent les entreprises ; les pages dont un agent a besoin sont donc : ce que fait le produit, comment fonctionne la mesure, les tarifs, et les articles de recherche qui définissent notre vocabulaire. Rien d'autre ne mérite sa place.

Lu comme un fichier, cela donne un H1, un résumé en une citation, puis deux sections H2 — la seconde étant Optional. Chaque ligne ci-dessous est une ligne de ce fichier :

• # Growli
• > Growli suit la façon dont les assistants IA — ChatGPT, Gemini, Claude, Perplexity, Copilot et Grok — mentionnent, comparent et recommandent les entreprises, et transforme les écarts constatés en actions priorisées.
• ## Core
• Comment ça marche : la méthode de mesure — jeux de prompts, fréquence des exécutions, et notation des mentions et des recommandations.
• Visibilité IA : définition de la métrique, ce qui la fait bouger, et ce qui ne la fait pas bouger.
• ## Optional
• Blog : articles de recherche sur le comportement des assistants, les schémas de citation et la méthodologie de mesure.

Sa place à côté de robots.txt et des données structurées

Ces trois fichiers répondent à trois questions différentes, et les confondre est l'erreur la plus fréquente que nous rencontrons en audit.

robots.txt répond à « avez-vous le droit de récupérer ceci ? » : c'est un fichier de contrôle d'accès pour les robots, au comportement de parsing documenté et éprouvé, et c'est là que vous autorisez ou interdisez des crawlers IA nommés. Si vous voulez restreindre l'entraînement ou le crawl, cela se passe là et dans vos conditions d'utilisation, jamais dans llms.txt. Les données structurées répondent à « qu'est-ce que c'est ? » : le vocabulaire Schema.org en JSON-LD vous permet d'affirmer sans ambiguïté que vous êtes une Organization portant ce nom, avec ces produits, ce prix et ces avis — le type de fait lisible par machine qui survit à un résumé. llms.txt ne répond qu'à « que dois-je lire en premier ? », pour un consommateur qui a déjà décidé de vous lire.

En termes de retour sur effort, l'ordre est peu glamour mais constant : corrigez d'abord la crawlabilité et le rendu côté serveur, puis les données structurées au niveau des entités, puis llms.txt. Un fichier qui liste des liens vers des pages s'affichant vides sans JavaScript n'aide personne.

Alors, faut-il en publier un ?

Oui, si vous avez de la documentation, une API, un produit destiné aux développeurs ou une base de connaissances : le coût se compte en minutes, le fichier reste lisible par un humain, et le scénario où quelqu'un transmet votre URL llms.txt à un agent est déjà courant. Publiez-le, tenez-le à jour, et passez à autre chose.

Probablement pas une priorité si vous êtes une entreprise de services locale, un catalogue e-commerce ou un site vitrine de douze pages. Rien ne prouve que cela change la probabilité qu'un assistant vous recommande, et l'effort est mieux investi dans ce que les assistants lisent démontrablement : des pages qui s'affichent sans JavaScript, du contenu explicite de comparaison et de tarifs, des faits d'entité cohérents sur votre site et dans les annuaires tiers, et une présence dans les sites d'avis et les comparatifs sur lesquels les modèles s'appuient quand ils répondent à « meilleur X pour Y ».

Le vrai test, c'est la mesure. Suivez la fréquence à laquelle les assistants vous nomment, sur quels prompts, et quelles sources ils citent quand ils le font — c'est précisément l'objet de notre suivi de visibilité IA, et comment ça marche détaille la méthode. Si publier llms.txt fait bouger ces chiffres pour votre site, vous le verrez. Sinon, vous y aurez passé vingt minutes et appris quelque chose de vrai.

FAQ