97 % des fichiers llms.txt ne sont jamais lus — j'en ai quand même mis un sur mon site

Le paradoxe qui résume toute l'histoire

Entre juin 2025 et mai 2026, le nombre de sites publiant un fichier llms.txt est passé de 4 088 à 36 120, selon le suivi d'Originality.ai sur plus de 3 millions de domaines. Une multiplication par 8,8 en douze mois. Pendant la même période, Ahrefs a analysé les logs serveur de 137 000 domaines et a trouvé que 97 % de ces fichiers n'ont reçu aucune requête en mai 2026. Pas une seule. Et parmi le maigre 3 % qui a reçu du trafic, les premiers demandeurs ne sont même pas des IA : ce sont des outils SEO (21,7 % des requêtes), venus vérifier si le fichier existe pour cocher une case dans un rapport d'audit. GPTBot représente 4,51 % des requêtes, ClaudeBot 0,80 %.

Autrement dit : des dizaines de milliers de sites écrivent une lettre que presque personne n'ouvre. Et pourtant, j'en ai mis une sur mon site. Pas par naïveté — par calcul. Pour comprendre le calcul, il faut d'abord comprendre ce que ce fichier est réellement, qui l'utilise vraiment, et pourquoi les deux camps du débat ont chacun à moitié raison.

llms.txt en deux minutes : un sommaire markdown pour les machines

La proposition vient de Jeremy Howard, cofondateur d'Answer.AI (et le gars derrière fast.ai), publiée le 3 septembre 2024 sur llmstxt.org. Le constat de départ est solide : quand un modèle de langage visite ta page, il reçoit ton HTML complet — la navigation, les scripts, les bannières de cookies, le footer. Du bruit qui gaspille sa fenêtre de contexte. L'idée : offrir à la racine du site (/llms.txt) une version condensée et structurée, en markdown, que les systèmes d'IA peuvent consommer directement.

Le format est volontairement simple. Un titre H1, une citation en blockquote qui résume le site, puis des sections H2 contenant des listes de liens au format [nom](url) : note descriptive. Une section « Optional » peut regrouper ce qui est sacrifiable quand le contexte est serré. La spec prévoit aussi un cousin plus costaud, llms-full.txt, qui inline le contenu complet des pages plutôt que des liens — Anthropic publie les deux pour sa documentation développeur, et ce fichier-là connaît une croissance encore plus folle : ×107 sur la même période, de 23 à 2 463 sites.

C'est tout. Pas de balisage exotique, pas de schéma JSON, pas de validation. Un fichier texte qu'un humain peut lire et qu'une machine préfère.

Qui le publie — et qui le lit vraiment

La liste des adopteurs ressemble à un annuaire du tooling développeur : Anthropic, Stripe, Cloudflare, Zapier, Vercel, Supabase, Cursor. Cloudflare pousse le concept jusqu'à publier des paires de fichiers séparées pour chacune de ses gammes de produits. Et Mintlify, la plateforme de documentation, a activé la génération automatique pour tous ses sites clients en novembre 2024 — des milliers de llms.txt sont apparus du jour au lendemain, ce qui gonfle d'ailleurs les statistiques d'adoption plus que n'importe quelle décision individuelle.

Mais regarde qui manque à l'appel : les entreprises ordinaires. En mars 2026, seulement 7,4 % des Fortune 500 avaient un llms.txt — contre 92,8 % pour robots.txt. Et surtout, regarde qui ne le lit pas : les crawlers des grands fournisseurs d'IA. Aucun — ni OpenAI, ni Anthropic, ni Google, ni Perplexity — n'a annoncé officiellement utiliser ce fichier. John Mueller, de Google, l'a dit sans détour sur Reddit au printemps 2025 : à sa connaissance aucun service d'IA n'utilise llms.txt, les logs serveur le confirment, et le fichier lui rappelle le meta tag keywords — une auto-déclaration de ce que le site prétend être, invérifiée. « Pourquoi ne pas simplement vérifier le site directement ? »

Sur ce point précis, Mueller a raison, et les chiffres d'Ahrefs le prouvent. Si tu ajoutes un llms.txt en espérant que ChatGPT se mette soudainement à citer ton site dans ses réponses, tu vas être déçu. Ce n'est pas comme ça que les moteurs de réponse construisent leurs citations — j'ai détaillé ce qui compte vraiment dans mon article sur la citabilité IA, et llms.txt n'y figure pas en haut de liste.

Le vrai lecteur n'est pas le crawler que tu crois

Alors pourquoi Stripe et Anthropic s'en donnent la peine ? Parce que le débat est mal cadré. Tout le monde évalue llms.txt comme un outil de crawl — un signal pour les robots d'indexation qui passent en masse. Son vrai usage en 2026 est ailleurs : la consultation à la demande, en pleine session de travail.

Quand un développeur tape @docs dans Cursor, quand Claude Code va chercher la documentation d'une librairie, quand un serveur MCP expose une doc à un agent — ces outils-là consomment du llms.txt. Pas en crawl périodique qui laisserait des traces massives dans les logs, mais en fetch ponctuel, au moment précis où un humain pose une question. C'est exactement pour ça que la liste des adopteurs est dominée par des produits développeur : leur documentation est interrogée par des agents de code des milliers de fois par jour, et un index markdown propre améliore concrètement la qualité des réponses que ces agents donnent sur leur produit.

La conclusion pratique que j'en tire : la valeur de llms.txt dépend entièrement de qui interroge ton contenu par agent interposé. Une documentation d'API ou de produit SaaS ? Le fichier travaille réellement. Un site vitrine de PME à Sherbrooke ? Personne ne demandera ton llms.txt cette semaine. Mais — et c'est là que mon calcul diverge du cynisme ambiant — le coût de production est tellement bas que le pari reste asymétrique.

Comment je le sers sur mon site (et l'erreur que j'ai faite)

Mon site tourne sur Next.js avec Supabase. Plutôt qu'un fichier statique, je sers /llms.txt par un route handler qui interroge la base à chaque requête — les articles de blogue publiés s'y ajoutent donc tout seuls :

// app/llms.txt/route.js
export async function GET() {
  const { data: articles } = await supabase
    .from("blog_articles")
    .select("title, slug")
    .eq("published", true)
    .order("id", { ascending: false });

  const liste = articles
    .map((a, i) => `${i + 1}. ${a.title} — /blog/${a.slug}`)
    .join("\n");

  return new Response(
    `# Pascal Potvin — Designer & Créateur Numérique\n\n## Blogue\n\n${liste}`,
    { headers: { "Content-Type": "text/plain; charset=utf-8" } }
  );
}

Vingt lignes, zéro dépendance, et le fichier ne peut pas mentir sur l'état du site puisqu'il est généré depuis la même base que les pages.

Le contenu du fichier suit la logique de la spec : qui je suis, mes services avec leurs URLs, mes outils, et la liste des articles. Pas de superlatifs, pas de texte marketing — des faits et des liens. Un agent qui lit ce fichier doit pouvoir répondre correctement à « qu'est-ce que Pascal Potvin offre comme services ? » sans charger une seule autre page.

Le piège : en faire un meta keywords 2.0

La comparaison de Mueller avec le meta tag keywords est plus qu'une pique — c'est une prophétie sur la façon dont ce fichier peut mourir. Le meta keywords n'est pas mort parce que l'idée était mauvaise ; il est mort parce que les sites ont menti dedans, massivement, jusqu'à ce que les moteurs cessent de le lire. Le même destin guette llms.txt si les gens le traitent comme un levier de manipulation.

Et l'industrie s'y emploie déjà. Depuis que « GEO » est devenu le buzzword de 2026, je vois passer des offres d'agences qui facturent l'« optimisation llms.txt » comme un service premium, avec la promesse implicite de meilleures citations dans ChatGPT. Sois lucide : il n'existe aucune donnée — zéro — montrant qu'un llms.txt améliore la fréquence de citation par les moteurs de réponse. L'étude Ahrefs de juin 2026 montre littéralement le contraire : les systèmes visés ne demandent pas le fichier. Payer pour « optimiser » un document que personne ne lit, c'est le sommet de l'art de vendre du vent.

Trois règles simples pour rester du bon côté : n'écris dans ton llms.txt que ce qui est vérifiable sur le site lui-même ; ne bourre pas de mots-clés — les modèles lisent le langage naturel, pas la densité lexicale ; et ne dépense ni argent ni plus d'une heure dessus. C'est un fichier d'hygiène technique, pas une stratégie.

Mon verdict : un pari à 20 minutes

Voici le calcul complet. Coût : une vingtaine de minutes si ton contenu est déjà structuré, zéro dollar, zéro maintenance si tu le génères dynamiquement. Gain actuel : marginal pour un site comme le mien — quelques agents IDE et assistants qui consultent à la demande. Gain potentiel : si un des grands fournisseurs décide demain de consommer officiellement le format (la demande existe : « llms.txt » se cherche 17 000 fois par mois dans le monde selon Ahrefs en juillet 2026), les sites déjà équipés partent avec une longueur d'avance. Risque : aucun, tant que le fichier dit la vérité.

Un pari asymétrique à coût quasi nul, ça se prend. Mais ça ne remplace pas le vrai travail : un site rapide, un contenu factuel et daté, des données structurées propres, une autorité qui se construit lien par lien. Le llms.txt est la poignée de porte ; encore faut-il que la maison derrière vaille la visite.