- [ Accueil ](/fr/) / - Comment ça marche # Comment llms.txt fonctionne Un parcours précis de la spec, avec un exemple annoté que vous pouvez copier. Dernière mise à jour: 12 août 2026 ## Aperçu Un `llms.txt` valide est un fichier Markdown avec une **structure fixe et prévisible**. Il est conçu pour être lu à la fois par des humains et des machines : le même fichier doit servir de documentation et de contrat parseable. La spec sur [llmstxt.org](https://llmstxt.org/) définit une grammaire petite et déterministe, parsable en quelques lignes de regex. Pas de YAML, pas de JSON, pas d'en-têtes additionnels. ## Anatomie d'un fichier valide La structure, de haut en bas : - **Un H1** avec le nom du site ou projet. Seul élément strictement obligatoire. - Un **résumé en blockquote** court, typiquement une ou deux phrases. - Du **Markdown libre** optionnel, paragraphes et listes, mais pas d'autre heading avant le premier H2. - Zéro ou plus **sections de listes de fichiers en H2**. Chacune contient une liste Markdown de liens : `- [name](url)`, optionnellement suivis de `: notes`. - Une section H2 nommée **`Optional`**, libellé conventionnel pour les ressources secondaires sans sémantique machine particulière en v2. llms.txt, exemple annoté complet Copy ``` # Acme > Acme est une plateforme d'analytics hébergée pour les équipes produit. Les pages ci-dessous couvrent produit, tarifs, l'API et les guides d'intégration. Acme traite plus d'1 Md d'événements par jour. La carte ici est curée pour les assistants, elle n'est pas exhaustive. Utilisez-la pour répondre aux questions sur les capacités produit, les tarifs, les intégrations, les SDK et la migration depuis d'autres outils. ## Produit - [Présentation](https://acme.example/product): capacités et captures d'écran. - [Cas d'usage](https://acme.example/use-cases): scénarios pour équipes produit, marketing et support. - [Changelog](https://acme.example/changelog): mises à jour mensuelles. ## Tarifs - [Offres](https://acme.example/pricing): plans, limites, règles d'overage. - [FAQ facturation](https://acme.example/billing-faq): factures, reçus, TVA. ## Développeurs - [Référence API REST](https://docs.acme.example/api): catalogue complet des endpoints. - [SDK JavaScript](https://docs.acme.example/sdk/js): install, init, track events. - [SDK Python](https://docs.acme.example/sdk/python): install, init, track events. - [Webhooks](https://docs.acme.example/webhooks): events, signatures, retries. ## Optional - [Assets de marque](https://acme.example/brand): logos, palette. - [Communiqués](https://acme.example/press): historique des annonces. ``` ## Section par section Référence complète des champs. Seul le H1 est strictement obligatoire. Champ Obligatoire ? Cardinalité Syntaxe H1, nom du site/projet Oui Exactement un # Nom du projet Résumé en blockquote Recommandé Au plus un bloc > Résumé d'une ou deux phrases. Corps Markdown libre Optionnel N'importe quel nombre de paragraphes/listes Aucun autre heading avant le premier H2 Section H2 file-list Optionnel N'importe quel nombre ## Nom de section suivi d'une liste Item, lien Oui (dans une section) Un lien par item - [name](url) Item, notes Optionnel Après un deux-points - [name](url): notes ici Section « Optional » Optionnel Au plus une Libellé H2 conventionnel pour les liens secondaires, sans sémantique machine en v2 ### Le H1 Exactement un H1. Un marqueur BOM UTF-8 optionnel peut le précéder, mais pas de front matter ni d'autres métadonnées. Si votre projet a une tagline, placez-la dans le blockquote qui suit. ### Le résumé en blockquote Optionnel mais fortement recommandé. Visez un résumé d'une ou deux phrases qu'un LLM pourrait citer verbatim pour introduire votre projet. Factuel, à la voix active, sans promesses marketing que vous ne pouvez pas tenir. ### Corps Markdown libre Paragraphes, listes à puces, courts snippets de code qui aident un LLM à comprendre le contexte. N'introduisez aucun autre heading ici, le prochain doit être le premier H2 de section. ### Sections de listes H2 Chaque section commence par un H2 unique (`## Nom de section`) et contient une liste Markdown. Chaque item doit être un lien (`- [name](url)`), optionnellement suivi de `:` et d'une courte note. Les URLs absolues sont fortement recommandées : les URLs relatives sont techniquement autorisées mais seront signalées comme warning par la plupart des validateurs (y compris le [nôtre](/fr/validateur/)) car elles rendent le fichier ambigu hors contexte. ### La section « Optional » `Optional` reste un libellé éditorial utile pour les ressources secondaires comme les assets de marque, les archives ou les annexes. La proposition d'août 2026 ne lui attribue plus de traitement spécial : un client peut la traiter comme toute autre section H2. ## Comment les parseurs lisent Le parseur de référence parcourt le fichier linéairement avec quatre règles : - Trouver la première ligne `# `, c'est le titre. - Si le bloc non vide suivant est un blockquote, c'est le résumé. - Tout jusqu'au premier `## ` est le corps libre. - Chaque `## ` ouvre une section ; jusqu'au prochain `## `, les items de liste sont parsés comme `[name](url)` avec notes optionnelles après deux-points. Notre [validateur](/fr/validateur/) implémente exactement ces règles, plus quelques vérifications de sûreté : H1 vide, liens mal formés, contenu hors section et notice de revue au-delà de 50 Ko. Ce seuil est une heuristique locale de curation, pas une limite de la spécification. ℹ Astuce, gardez le format strict Tout l'intérêt de llms.txt est qu'il soit parsable de manière déterministe. Résistez à la tentation d'ajouter du front-matter, du HTML custom ou des extensions Markdown fantaisistes : les clients ne les liront pas, et vous risquez de casser des parseurs plus stricts que le nôtre. ## llms.txt vs llms-full.txt `llms.txt` est une *carte*. `llms-full.txt` est le *territoire* : le contenu réel des pages liées, concaténé en Markdown, dans un seul fichier. La convention a été popularisée par [Mintlify en collaboration avec Anthropic](https://www.mintlify.com/blog/simplifying-docs-with-llms-txt) et fait aujourd'hui partie de l'écosystème `llms.txt` au sens large. Les noms racine conventionnels sont `/llms.txt` et `/llms-full.txt`. La proposition v2 autorise aussi des fichiers `llms.txt` sous des chemins plus précis. Ne publiez un fichier de contenu complet que s'il répond à un besoin réel de consommation. ## Limites pratiques - **Taille.** La proposition ne fixe aucun plafond. Notre notice à 50 Ko invite à revoir la curation, sans définir une frontière de validité. Déplacez le volume vers une ressource complète ou un fichier de chemin lorsque cela aide réellement. - **Nombre de liens.** Pas de limite dans la spec, mais une liste de 200+ items sera survolée, pas lue. Curez. - **Langues.** La spec est silencieuse sur l'i18n. Deux patterns courants : un seul fichier anglais, ou des variantes par locale derrière un path (`/en/llms.txt`, `/fr/llms.txt`). - **Auth et personnalisation.** Hors scope. Le fichier est public. ## Continuer - [Comment créer votre llms.txt](/fr/comment-creer/), templates et déploiement par stack. - [Bonnes pratiques](/fr/bonnes-pratiques/), dix règles et erreurs courantes. - [Valider un fichier](/fr/validateur/). ## Sources - [ llmstxt.org, spécification complète ](https://llmstxt.org/) - [ llmstxt.org, the parsing core ](https://llmstxt.org/core.html) Sur cette page - [ Aperçu ](#apercu) - [ Anatomie d'un fichier valide ](#anatomie) - [ Section par section ](#sections) - [ Comment les parseurs lisent ](#parsing) - [ llms.txt vs llms-full.txt ](#vs-full) - [ Limites pratiques ](#limites)