À quoi sert le fichier llms.txt pour les IA ?

Le fichier llms.txt fait beaucoup parler de lui depuis 2024, au point que certains le présentent comme le nouveau robots.txt de l’ère des intelligences artificielles. La réalité est plus nuancée. Il s’agit d’une proposition de format, simple et intelligente, destinée à aider les Large Language Models à comprendre un site en leur fournissant un résumé et une sélection de liens en Markdown. Mais son adoption par les grands acteurs reste limitée et son effet sur la visibilité dans les réponses des IA n’est pas démontré. Chez Netamorphoz, nous préférons vous expliquer ce qu’il est vraiment, comment il se construit, en quoi il diffère de robots.txt et du sitemap, et dans quels cas il mérite une heure de votre temps.

Qu’est-ce que le fichier llms.txt, concrètement ?

Le fichier llms.txt est un simple fichier texte placé à la racine d’un site (à l’adresse /llms.txt), rédigé en Markdown, qui présente le site en quelques lignes et liste les pages les plus utiles pour un modèle de langage, avec une courte note pour chacune. Il s’inscrit dans la réflexion plus large sur le référencement sur les IA génératives, qui consiste à rendre ses contenus faciles à trouver, à comprendre et à citer par ChatGPT, Perplexity, Gemini ou Copilot. Son principe n’a rien de magique : offrir aux machines une porte d’entrée lisible plutôt que de les laisser déduire seules la structure d’un site à partir de pages HTML chargées de menus, de scripts et de bandeaux.

Une proposition née en 2024

Le format a été proposé en septembre 2024 par Jeremy Howard, cofondateur d’Answer.AI et connu dans la communauté de l’apprentissage automatique, sur le site llmstxt.org qui en décrit la spécification. Il ne s’agit ni d’une norme du W3C, ni d’un protocole adopté par un organisme de standardisation, ni d’un engagement pris par un éditeur de moteur ou d’assistant : c’est une proposition communautaire ouverte, documentée publiquement et que chacun peut adopter librement. Plusieurs plateformes de documentation technique et outils pour développeurs l’ont rapidement intégrée, ce qui explique sa visibilité dans les milieux tech. Cette origine compte pour évaluer son intérêt : un fichier que personne n’est obligé de lire peut être utile à certains outils, mais il ne crée pas d’obligation ou de garantie de prise en compte du côté des grands assistants. C’est cette prudence de lecture que nous recommandons avant tout investissement.

Le problème qu’il cherche à résoudre

Un modèle de langage qui consulte un site au moment de répondre à une question fait face à deux difficultés. D’abord, sa fenêtre de contexte est limitée : il ne peut pas ingérer un site entier, et doit choisir quelles pages lire. Ensuite, le HTML d’une page moderne contient beaucoup de bruit (navigation, pieds de page, scripts, fenêtres de consentement, éléments répétés) qui consomme de la place sans apporter d’information. La spécification de llms.txt part de ce constat et propose de fournir une sélection éditoriale condensée : un résumé de ce qu’est le site, puis les liens vers les contenus qui comptent, idéalement disponibles en version Markdown propre. Elle précise que l’usage visé est surtout celui de l’inférence, c’est-à-dire le moment où un utilisateur demande à un assistant de l’aider à partir d’un site, plutôt que l’entraînement des modèles. La nuance est importante pour comprendre son périmètre réel d’action.

Un fichier à la racine, lisible par les humains

L’un des atouts du format est d’être lisible aussi bien par une machine que par une personne. Markdown est une syntaxe légère que les modèles de langage manipulent couramment : un dièse pour un titre, un chevron pour une citation, un tiret pour un élément de liste, des crochets et des parenthèses pour un lien. Le fichier se rédige donc avec un simple éditeur de texte, sans compétence de développement particulière, puis se dépose à la racine du site comme on le ferait pour robots.txt. Voici à quoi pourrait ressembler celui d’une menuiserie fictive de l’Arrageois. On y retrouve le nom en titre, une phrase de résumé, une précision libre, puis des sections de liens commentés et une section facultative. Cette lisibilité a un autre mérite : elle oblige l’entreprise à formuler clairement ce qu’elle fait et quelles sont ses pages réellement essentielles, un exercice salutaire même sans IA.

# Menuiserie Exemple
> Menuiserie artisanale à Arras : fenêtres, portes, escaliers sur mesure, pose dans l’Arrageois.

Nous intervenons chez les particuliers et les professionnels, sur devis.

## Services
- [Fenêtres bois et mixtes](https://www.exemple.fr/fenetres.md): gammes, pose, délais
- [Escaliers sur mesure](https://www.exemple.fr/escaliers.md): conception et fabrication

## Informations pratiques
- [Zone d’intervention](https://www.exemple.fr/zone.md): communes desservies
- [Contact et devis](https://www.exemple.fr/contact.md): coordonnées, horaires

## Optional
- [Historique de l’atelier](https://www.exemple.fr/histoire.md)

Comment est structuré un fichier llms.txt ?

La spécification publiée sur llmstxt.org décrit un ordre précis, volontairement court. Seul le titre est obligatoire ; tout le reste est facultatif mais recommandé pour que le fichier soit réellement utile. L’idée est de permettre à des outils de traiter le fichier de façon prévisible, avec des analyseurs simples, tout en restant agréable à lire pour un humain qui l’ouvrirait dans son navigateur. Respecter cet ordre est la meilleure garantie de compatibilité avec les outils qui exploitent déjà le format.

Le titre et le résumé

Le fichier commence par un titre de niveau 1 (une ligne précédée d’un dièse) qui donne le nom du site ou du projet. C’est le seul élément exigé. Vient ensuite, de préférence, une citation en bloc (une ligne précédée d’un chevron) qui résume en une ou deux phrases ce que fait l’entreprise et ce que l’on trouvera dans le fichier. Ce résumé est la partie la plus stratégique : il doit être factuel et précis, sans slogan, avec l’activité, le public, la zone géographique et la spécialité. Après ce résumé, la spécification autorise des paragraphes ou des listes libres, sans titre, pour apporter un contexte utile : conditions d’intervention, langues, informations importantes pour bien interpréter le reste. Évitez d’y recopier votre page de présentation : un modèle a besoin d’informations utilisables, pas d’un texte promotionnel. Ce travail de formulation de l’essentiel sert d’ailleurs aussi vos pages et vos fiches.

Les sections de liens commentés

Le cœur du fichier est composé de sections introduites par des titres de niveau 2 (deux dièses), par exemple « Services », « Documentation » ou « Informations pratiques ». Chaque section contient une liste de liens au format Markdown, suivis éventuellement de deux-points et d’une courte note qui explique ce que contient la page. Ces notes font la différence : elles permettent au modèle de choisir la bonne ressource sans l’ouvrir. Sélectionnez les pages qui répondent aux questions les plus fréquentes de vos clients, plutôt que de recopier l’intégralité de votre plan de site. Un fichier de dix à trente liens bien choisis a plus de sens qu’un inventaire de plusieurs centaines d’adresses. Les liens peuvent pointer vers des pages HTML classiques, mais la proposition encourage à les faire pointer vers des versions Markdown propres lorsque le site en propose.

La section Optional et les versions Markdown des pages

Une section intitulée « Optional » a un sens particulier dans la spécification : elle regroupe des liens secondaires qu’un outil peut ignorer s’il a besoin d’un contexte plus court. C’est l’endroit idéal pour l’historique de l’entreprise, des articles de fond ou des pages annexes. La proposition suggère aussi que les pages utiles soient disponibles en Markdown à la même adresse suivie de l’extension .md, afin qu’un modèle puisse lire un contenu débarrassé du superflu. Par ailleurs, certains outils de documentation génèrent un fichier llms-full.txt qui rassemble le texte intégral des pages en un seul document ; cette variante est répandue dans l’univers des développeurs, mais elle ne fait pas partie du cœur de la proposition initiale. Pour un site vitrine, nous déconseillons de multiplier ces fichiers : mieux vaut un llms.txt court, tenu à jour, qu’une arborescence parallèle que personne ne maintient.

llms.txt, robots.txt, sitemap : quelles différences ?

La confusion est fréquente, car ces trois fichiers vivent à la racine du site et s’adressent tous à des robots. Ils n’ont pourtant ni le même rôle, ni le même statut. Le robots.txt donne des consignes d’accès, le sitemap fournit un inventaire, le llms.txt propose une lecture guidée. Les deux premiers sont des standards établis et lus par les moteurs de recherche depuis longtemps ; le troisième est une proposition encore jeune, sans engagement de lecture de la part des grands acteurs.

robots.txt : autoriser ou interdire l’exploration

Le robots.txt est le fichier historique du protocole d’exclusion des robots, formalisé par l’IETF dans la RFC 9309 en 2022 après des décennies d’usage. Il indique, robot par robot, les répertoires ou les pages que l’on ne souhaite pas voir explorés. C’est aussi l’outil qui permet aujourd’hui de gérer l’accès des robots liés à l’IA : OpenAI documente par exemple son robot GPTBot, et Google propose le jeton Google-Extended pour contrôler l’utilisation des contenus pour ses modèles Gemini, distinctement de l’indexation dans la recherche. Le robots.txt est une consigne d’accès, respectée par les robots qui jouent le jeu, et non une protection technique. Surtout, il fonctionne en sens inverse du llms.txt : il dit où ne pas aller, quand le llms.txt dit quoi lire en priorité. Si votre robots.txt bloque un robot d’IA, votre llms.txt ne lui servira à rien : la cohérence entre les deux fichiers est indispensable.

Le sitemap : inventaire exhaustif pour les moteurs

Le sitemap XML, défini par le protocole décrit sur sitemaps.org et soutenu par les principaux moteurs, liste les adresses que vous souhaitez voir explorées et indexées, avec éventuellement leur date de dernière modification. Un fichier peut contenir jusqu’à 50 000 adresses, et un index de sitemaps permet d’en regrouper plusieurs pour les grands sites. Son rôle est l’exhaustivité au service de l’indexation : aider les moteurs à découvrir toutes les pages, y compris celles qui sont peu liées. Il ne dit rien de l’importance relative des contenus ni de leur sens, et il est conçu pour être lu par des machines, pas par des humains. Le llms.txt prend le contre-pied : quelques liens choisis, un résumé, des notes en langage naturel. Les deux ne sont donc pas concurrents. Un site bien tenu dispose d’un sitemap à jour, déclaré dans la Search Console, et peut y ajouter un llms.txt comme couche éditoriale complémentaire.

llms.txt : une sélection éditoriale commentée

Là où le sitemap répond à la question « quelles pages existent ? » et le robots.txt à « où ai-je le droit d’aller ? », le llms.txt répond à « que faut-il lire pour comprendre ce site ? ». C’est un travail de curation, presque de rédaction en chef : choisir, hiérarchiser, résumer. Cette différence de nature explique pourquoi il ne peut pas être généré mécaniquement à partir du sitemap sans perdre l’essentiel de son intérêt. Un fichier produit automatiquement par une extension qui liste toutes les pages du site n’apporte guère plus qu’un sitemap au format texte. La valeur réside dans les choix éditoriaux assumés et dans la qualité des notes. Le tableau comparatif ci-dessous résume les principales différences entre robots.txt et llms.txt, les deux fichiers les plus souvent confondus, pour vous aider à bien répartir les rôles.

Faut-il créer un fichier llms.txt sur votre site ?

La question mérite une réponse honnête plutôt qu’un enthousiasme de circonstance. Créer un llms.txt prend peu de temps et ne présente pas de risque pour votre référencement classique. Mais il serait trompeur de le présenter comme un levier décisif de visibilité dans les réponses des IA : aucune donnée publique solide ne montre aujourd’hui qu’il augmente les citations d’un site. Notre position est donc pragmatique : le faire si cela a du sens pour votre activité, sans en attendre de miracle, et sans négliger les fondamentaux qui comptent davantage.

Une adoption encore limitée et incertaine

Du côté des sites, l’adoption progresse surtout dans les univers techniques : documentation de logiciels, bibliothèques de code, plateformes pour développeurs, où les assistants de programmation peuvent effectivement s’en servir pour accéder à une documentation propre. Du côté des grands assistants grand public et des moteurs, la situation est beaucoup moins claire. Les éditeurs ne documentent pas de manière détaillée la façon dont leurs robots exploitent ou non ce fichier, et des représentants de Google ont publiquement relativisé son intérêt pour la recherche. Les observations remontées par des professionnels, à partir des journaux de serveur, vont dans le sens d’une consultation encore rare par les robots des grands acteurs. La prudence s’impose donc, d’autant que le paysage de l’IA évolue vite : ce qui est vrai aujourd’hui peut changer, dans un sens comme dans l’autre, et mérite une veille régulière plutôt que des certitudes.

Un llms.txt bien fait ne compense jamais un site confus : il ne fait que résumer ce qui existe déjà.

Les cas où il présente un intérêt réel

Le fichier a du sens dans plusieurs situations. Si vous éditez un logiciel, une API ou une documentation technique, il facilite le travail des développeurs qui utilisent des assistants de code, et c’est son terrain d’origine. Si votre site est riche (centre de ressources, catalogue complexe, base de connaissances), il offre une carte de lecture claire à tout outil qui voudrait s’en servir. Pour un site vitrine de TPE, l’intérêt est plus modeste, mais le coût l’est aussi : une heure de réflexion pour formuler votre résumé et choisir vos pages clés, un fichier texte à déposer, une mise à jour quand vos offres changent. L’exercice a même un bénéfice indirect, car il vous oblige à clarifier votre positionnement et à repérer les pages qui manquent. La démarche ci-dessous permet de le produire proprement, sans y passer des journées ni sous-traiter à l’aveugle.

1. Vérifier robots.txtLes robots d’IA que vous voulez accueillir ne doivent pas être bloqués.
2. Rédiger le résuméActivité, public, zone, spécialité, en deux phrases factuelles.
3. Choisir les pagesDix à trente liens qui répondent aux vraies questions des clients.
4. Commenter chaque lienUne note courte qui dit ce que contient la page.
5. Planifier la mise à jourÀ chaque nouvelle offre, page supprimée ou changement d’adresse.

Ce qui compte davantage pour être cité par les IA

Les assistants qui citent leurs sources s’appuient avant tout sur des contenus accessibles, bien structurés et fiables, et sur la cohérence des informations disponibles à votre sujet sur le web. C’est là que se joue l’essentiel. Des pages qui répondent clairement aux questions, avec des titres explicites et des informations vérifiables, un site rapide et explorable sans difficulté, des données structurées schema.org cohérentes, des mentions de votre entreprise sur des sites tiers reconnus : ces leviers servent à la fois le référencement classique et la visibilité dans les réponses générées. Les travaux de recherche sur le GEO, comme l’article « GEO: Generative Engine Optimization » publié par une équipe de Princeton et présenté à KDD 2024, explorent d’ailleurs surtout la façon de rédiger et d’étayer les contenus. Pour une entreprise locale, la cohérence de vos coordonnées et de votre fiche Google Business Profile pèse aussi bien plus lourd qu’un fichier texte à la racine.