llms.txt, 90 jours plus tard : une rétrospective honnête

En juin, nous avons déployé un llms.txt sur l'ensemble d'aat.ee — un seul fichier de route, une carte markdown du contenu clé du site, servi à aat.ee/llms.txt. Cela a coûté environ une heure. Quatre-vingt-dix jours plus tard, voici un compte rendu honnête de ce que cela a fait et n'a pas fait, car la plupart de ce que vous lirez sur llms.txt est soit une reformulation de la spécification, soit un argumentaire de vente, et le juste milieu — des résultats mesurés sur un vrai site en production — est rare.

Ce qu'est llms.txt, en un paragraphe

llms.txt est une convention proposée (pas un standard — nous y reviendrons) : un fichier markdown à la racine de votre domaine qui donne aux modèles de langage une carte organisée de votre site. Là où sitemap.xml est une liste exhaustive d'URL pour les crawlers, llms.txt est une courte liste de lecture hiérarchisée pour les assistants — ce qui compte, comment cela s'appelle, et où cela se trouve. Le pari est que les agents préfèrent un résumé organisé plutôt qu'un crawl à l'aveugle.

Ce que nous avons déployé

L'implémentation est délibérément ennuyeuse : une seule route dynamique qui compose trois choses — un préambule statique de politique de crawl, les 15 lancements les plus récents, les 10 derniers articles publiés, et la liste des catégories — en markdown, avec une fonction d'échappement englobant tout contenu contrôlé par l'utilisateur.

// User text (project names, article titles) must not break out of the
// markdown link or inject headings into an agent-facing file.
function mdSafe(text: string): string {
  return text
    .replace(/[\r\n]+/g, " ")
    .replace(/[[\]()]/g, "")
    .trim()
}

const projectLinks = recentProjects
  .map((p) => `- [${mdSafe(p.name)}](${baseUrl}/projects/${p.slug})`)
  .join("\n")

// User text (project names, article titles) must not break out of the
// markdown link or inject headings into an agent-facing file.
function mdSafe(text: string): string {
  return text
    .replace(/[\r\n]+/g, " ")
    .replace(/[[\]()]/g, "")
    .trim()
}

const projectLinks = recentProjects
  .map((p) => `- [${mdSafe(p.name)}](${baseUrl}/projects/${p.slug})`)
  .join("\n")

Cette étape d'assainissement est la seule partie subtile. Les noms de projets et les titres proviennent des utilisateurs et des pipelines de LLM ; des retours à la ligne ou des crochets intégrés permettraient à une fiche d'injecter un titre ou un faux lien dans un fichier que les assistants sont invités à considérer comme une carte fiable.

Ce que les logs ont montré

Trois observations issues de quatre-vingt-dix jours de logs serveur et de données de référents.

Les agents le récupèrent bel et bien. Nous observons des requêtes périodiques de /llms.txt de la part de user-agents de crawlers d'assistants connus, à une fréquence bien moindre que robots.txt mais de manière constante. Quel que soit le statut de la spécification, le comportement de récupération est réel.

Aucun miracle mesurable en matière de référents. Les référents provenant d'assistants IA vers aat.ee ont augmenté au cours du trimestre — mais cette croissance suit notre rythme de publication, pas le déploiement de llms.txt. Nous ne pouvons attribuer une seule session à un agent ayant lu le fichier, et nous nous méfions de quiconque revendique une attribution précise ici : les assistants récupèrent, puis répondent à partir d'un mélange de sources, et la citation porte rarement un référent en forme de llms.txt.

Cela a forcé un inventaire utile. Le bénéfice inattendu : rédiger une carte organisée signifie décider ce qui constitue réellement le sommet de votre site. Notre route génère des données en direct, donc le fichier reste à jour — mais la discipline du « qu'est-ce qui appartient à la liste de lecture » a davantage amélioré la structure des catégories que le fichier lui-même.

La partie inconfortable : ce n'est toujours qu'une proposition

llms.txt n'a aucun standard ratifié derrière lui. Le type MIME est débattu (text/markdown vs text/plain), les assistants ne sont pas documentés comme le lisant, et rien ne casse si vous n'en avez pas. Tout article vous affirmant que c'est « essentiel pour le SEO IA » en 2026 devance les preuves.

Notre position après quatre-vingt-dix jours : le coût est si faible que la valeur attendue reste positive, comme un hall bien organisé est positif pour un immeuble de bureaux. Cela ne produira pas le résultat à lui seul, mais quand un agent cherche effectivement à s'orienter, vous préférez qu'il trouve une carte organisée plutôt qu'un mur.

Devriez-vous en créer un ?

Un tableau de décision, honnêtement :

• Si votre site fait moins de ~50 pages avec des titres clairs — marginal. Votre sitemap et votre navigation racontent déjà l'histoire.
• Si vous avez un site piloté par les données (lancements, annonces, articles, docs — du contenu qui change chaque semaine) — oui. Un llms.txt généré est un seul fichier de route, reste à jour automatiquement, et donne aux assistants un résumé sans spam que votre sitemap ne peut pas fournir.
• Si l'on vous a dit que cela améliorera vos classements IA — non. C'est une carte, pas une balise meta.

Le modèle d'implémentation ci-dessus — composer, assainir, servir — convient à tout framework disposant d'une couche de routage. Gardez-le généré plutôt qu'écrit à la main, gardez le texte utilisateur assaini, et gardez vos attentes calibrées.