llms.txt v2 : ce qui a changé
Publié:
La proposition llms.txt a été révisée en août 2026, près de deux ans après l'originale. Le format du fichier lui-même n'a pas changé — un fichier v1 reste un fichier v2 valide. Ce qui a changé, c'est tout ce qui entoure le fichier : la façon dont les agents le trouvent, et l'outillage que la spécification attend.
Le format est inchangé
La structure requise est exactement la même qu'avant : un BOM optionnel, un H1 avec le nom du projet (toujours le seul élément obligatoire), un résumé en blockquote, du texte libre sans titres en option, puis zéro ou plusieurs sections H2 contenant des listes de liens Markdown. Si votre fichier obtenait 100 selon la v1, il obtient toujours 100.
1. Des relations de lien, pour que les agents cessent de deviner
C'est l'ajout substantiel, et il répond à la demande la plus fréquente après deux ans d'adoption : étant donné une page, comment un agent trouve-t-il sa version Markdown, ou le llms.txt qui la couvre, sans deviner les URL ?
La v2 répond avec deux relations de lien standard :
rel="describedby"— pointe vers le llms.txt qui couvre cette page.rel="alternate" type="text/markdown"— pointe vers la version Markdown de cette page.
L'une comme l'autre peut être un élément HTML <link> :
<link rel="describedby" href="/llms.txt"> <link rel="alternate" type="text/markdown" href="/docs/page.html.md">
… ou un en-tête de réponse HTTP, seule option pour les ressources non HTML comme les fichiers Markdown eux-mêmes, et qui peut se configurer dans votre serveur web ou votre CDN sans toucher à une seule page :
Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"
Si vous avez suivi le conseil d'annoncer le fichier avec rel="alternate" type="text/plain" — y compris dans nos propres guides plus anciens — remplacez-le par rel="describedby". C'était une convention raisonnable avant que la spécification n'en ait une ; désormais elle en a une.
2. Les deux formes d'URL .md sont désormais autorisées
La v1 imposait une seule forme d'URL pour le jumeau Markdown d'une page : .md ajouté à l'URL complète, si bien que page.html devenait page.html.md. En pratique, plusieurs outils de publication remplaçaient plutôt l'extension, produisant page.md. La v2 valide les deux. Pour les URL sans nom de fichier, ajoutez index.html.md ou index.md.
Rien à migrer ici — la forme que vous produisez déjà est maintenant correcte.
3. Les fichiers en sous-chemin sont enfin définis
La v1 autorisait un llms.txt hors de la racine sans jamais dire ce que cela signifiait. La v2 le définit : un fichier couvre les pages sous son chemin, et lorsque plusieurs s'appliquent, les agents utilisent le plus spécifique. Ainsi /docs/llms.txt couvre tout ce qui se trouve sous /docs/, et un agent qui lit une page de documentation le préfère au fichier racine.
Cela compte pour quiconque contrôle un chemin mais pas un hôte — un site de projet GitHub Pages, une section documentation sur un domaine partagé — et c'est la raison pour laquelle la spécification s'en tient à un nom de fichier conventionnel plutôt qu'à /.well-known/, qui n'existe qu'à la racine de l'origine.
Conséquence pratique : si votre documentation est la partie qui intéresse les agents, un /docs/llms.txt dédié est désormais un choix de premier ordre, et non une zone grise.
4. L'outillage d'expansion de contexte disparaît (et « Optional » perd sa mécanique)
La v1 décrivait llms_txt2ctx, un outil qui développait un llms.txt en un contexte LLM unique. La v2 l'abandonne et énonce l'attente directement : les agents consultent ou recherchent le llms.txt, puis suivent les liens dont ils ont besoin — les liens doivent donc pointer vers du contenu adapté aux LLM, et le fichier lui-même reste assez petit pour tenir dans le contexte.
Avec cet outillage disparaît la signification mécanique de la section ## Optional, qui existait pour indiquer à ces outils ce qu'ils devaient omettre. Les sections Optional restent autorisées et restent une convention utile pour les liens secondaires qu'un agent peut ignorer — elles ne pilotent simplement plus rien d'automatique.
Notez que llms-full.txt n'a jamais fait partie de la spécification, dans aucune des deux versions. C'est une pratique du secteur largement adoptée, et une bonne pour les grands ensembles de documentation — ne la considérez simplement pas comme une exigence.
Ce qu'il faut faire concrètement cette semaine
- Ajoutez
rel="describedby"pointant vers votre llms.txt — une ligne dans votre gabarit, ou une règle d'en-tête CDN. - Si vous publiez des jumeaux Markdown, annoncez-les avec
rel="alternate" type="text/markdown". - Remplacez toute indication
rel="alternate" type="text/plain"parrel="describedby". - Si votre documentation est la partie de valeur, envisagez un
/docs/llms.txtdédié. - Relancez le validateur — il indique maintenant si vos pages annoncent les relations v2, et il suit les fichiers en sous-chemin comme la v2 le prévoit pour les agents.
Pourquoi cette révision
Parce que la prémisse a cessé d'être spéculative. Quand llms.txt a été proposé en septembre 2024, « les agents liront votre site web » était une prédiction. Aujourd'hui les plateformes de documentation génèrent le fichier automatiquement, Lighthouse de Chrome audite les sites pour en vérifier la présence dans ses contrôles de navigation agentique, et les laboratoires d'IA publient des llms.txt pour leur propre documentation développeur. La v2, c'est à quoi ressemble une proposition après que ses hypothèses ont été mises à l'épreuve par une adoption réelle.