Lors d’une conférence récente, on m’a demandé si llms.txt avait de l’importance. Au départ, je n’étais pas convaincu, et je vais expliquer pourquoi plus loin. Une amie m’avait encouragé à creuser le sujet car elle estimait que je n’avais pas saisi toutes les nuances de la proposition — elle avait raison. Après une étude approfondie, ma compréhension s’est approfondie, mais paradoxalement cela n’a fait que renforcer mes réserves initiales. Plutôt que d’exprimer une opinion personnelle isolée, j’ai essayé d’adopter le point de vue d’une plateforme de recherche ou d’un fournisseur de modèles. Pourquoi ces acteurs adopteraient-ils — ou n’adopteraient-ils pas — ce protocole ? Ce changement de perspective m’a conduit à des observations que je considère utiles et pertinentes.

Il est désormais clair que la recherche traditionnelle n’est plus le seul canal de découverte de contenu. Les outils pilotés par des **LLM** (modèles de langage de grande taille) transforment la manière dont les pages web sont trouvées, interprétées et présentées. La proposition dite llms.txt vise à aider les sites à structurer et faciliter l’accès à leur contenu par ces outils. Pourtant, cette idée soulève les mêmes problématiques de confiance qui ont rendu inefficaces d’autres signaux destinés à « aider la machine ». Cet article détaille ce qu’est supposé faire llms.txt (selon ma lecture), pourquoi les plateformes hésitent, les vecteurs d’abus possibles et ce qu’il faudrait changer pour que ce format devienne réellement pertinent.

Image Credit: Duane Forrester

Ce que llms.txt cherchait à résoudre

Les sites modernes sont généralement conçus pour des navigateurs humains : beaucoup de JavaScript, des menus dynamiques, des pop-ups, des publicités et des templates complexes. En revanche, la plupart des **LLM** en phase d’inférence fonctionnent dans des environnements plus contraints : fenêtres de contexte limitées, lecture d’un document en une seule passe et mécanismes de récupération souvent plus simples que ceux des indexeurs traditionnels. La proposition originale d’Answer.AI recommande de placer à la racine d’un site un fichier Markdown nommé llms.txt, qui liste les pages jugées les plus pertinentes et, en option, inclut des versions aplaties (flat) du contenu afin que les systèmes d’IA n’aient pas à extraire l’information au milieu d’éléments parasites.

Ses partisans décrivent le fichier comme « une carte manuelle des pages pour les outils d’IA » plutôt qu’un fichier servant à bloquer l’exploration. L’idée centrale : fournir le contenu le plus important d’un site dans un format plus propre et plus directement exploitable, pour éviter que les outils n’ignorent ou ne mal interprètent des pages de valeur.

Dans les grands principes, il s’agit d’un manifeste éditorial : un index clairement structuré et orienté pour les agents automatiques, destiné à accélérer la récupération d’information et à préserver la représentation fidèle des pages essentielles. Mais, comme nous allons le voir, ce concept soulève des questions de confiance, de responsabilité et d’opérationnalité.

Le problème de confiance qui ne disparaît jamais

Si l’on prend du recul, on retrouve un schéma récurrent dans l’évolution du web. Au tout début, la balise meta keywords permettait aux sites de déclarer leur sujet — elle a été massivement manipulée et finalement ignorée par les moteurs. De même, des balises d’authorship (rel=author, etc.) ont tenté d’établir l’autorité d’un auteur, mais l’usage malveillant les a marginalisées. Le signal le plus durable, le succès de schema.org, n’a été possible qu’après des années de coordination et de gouvernance partagée entre acteurs majeurs.

llms.txt se situe dans cette lignée : il s’agit d’un signal auto-déclaratif qui promet de lever des ambiguïtés mais qui repose sur la bonne foi de l’éditeur. Sans mécanismes sérieux de vérification, tout format de fichier placé à la racine d’un site devient une surface d’attaque potentielle pour la manipulation.

Cela explique pourquoi certains responsables de plateformes et d’équipes de modération se montrent prudents : tout nouveau signal demandant un niveau de confiance accru impose simultanément des exigences de validation et des coûts d’application.

Le manuel d’abus (ce que voient en premier les équipes anti-spam)

Du point de vue des équipes de sécurité et de modération, les risques sont concrets et immédiatement identifiables : si un site publie un fichier nommé llms.txt avec des déclarations arbitraires, comment une plateforme peut-elle vérifier que les URL et les contenus listés correspondent réellement à ce que voient les utilisateurs standards ? Plusieurs scénarios d’exploitation se dégagent :

1. Cloaking via le manifeste. Un éditeur peut lister dans le fichier des pages qui sont invisibles aux visiteurs non authentifiés ou cachées derrière des paywalls, permettant ainsi à un **LLM** d’ingérer du contenu inaccessible au grand public.
2. Remplissage par mots-clés ou dumping de liens. Le manifeste peut devenir un répertoire bourré d’URL d’affiliation, de pages de faible valeur ou d’ancres optimisées pour manipuler la récupération.
3. Empoisonnement ou biaisage des réponses. Si des agents accordent plus de poids aux entrées du manifeste qu’à l’analyse complète du HTML, un acteur malveillant peut insérer des instructions ou des listes orientées qui biaisent les réponses en aval.
4. Chaînes de liens tiers. Le fichier pourrait pointer vers des domaines externes, des fermes de redirections ou des îlots de contenu de faible qualité, faisant du site un vecteur d’amplification pour du contenu douteux.
5. Blanchiment de confiance. La simple présence d’une structure manifeste pourrait pousser un modèle à surpondérer les pages listées, offrant un avantage injustifié à des pages minces ou spammy.

Ces risques expliquent pourquoi certains observateurs du secteur estiment que llms.txt « crée des opportunités d’abus, comme le cloaking ». Le faible taux d’adoption signalé par certains retours de communauté ajoute une dimension incertaine : si peu d’outils lisent ces fichiers en production, les scénarios d’abus réels sont peu documentés, mais cela signifie aussi que les mécanismes de défense n’ont pas été sérieusement éprouvés.

Pourquoi les plateformes hésitent

La logique d’une plateforme est pragmatique et orientée vers la réduction des risques : tout nouveau signal impose des coûts, des responsabilités et des impacts potentiels sur la qualité des réponses. Voici les principaux éléments du raisonnement.

Premièrement, la question de la qualité du signal. Si les entrées d’un llms.txt sont bruyantes, trompeuses ou incohérentes avec le site réel, les intégrer pourrait dégrader la pertinence des réponses plutôt que l’améliorer. Les opérateurs doivent donc se demander : ce fichier augmente-t-il réellement la précision des réponses de nos systèmes, ou ouvre-t-il la porte à la désinformation ?

Deuxièmement, le coût de vérification. Pour s’appuyer sur un manifeste, une plateforme devrait le recouper systématiquement avec le HTML public, les balises canoniques, les données structurées, les logs d’accès, etc. Cela exige des ressources de calcul, d’ingénierie et d’opérations — et toutes les plateformes n’ont pas intérêt à les engager sans preuve tangible d’un bénéfice net.

Troisièmement, la gestion de l’abus. Si un acteur malveillant publie un llms.txt listant des URL trompeuses qu’un **LLM** utilise ensuite pour générer des réponses erronées, qui prend la responsabilité ? Le propriétaire du site ? Le fournisseur du modèle ? Le service qui expose la réponse ? La question de la responsabilité juridique et réputationnelle est réelle et dissuasive.

Quatrièmement, le risque d’atteinte aux utilisateurs. Un modèle pouvant citer du contenu issu d’un manifeste sans contrôles stricts peut produire des réponses inexactes ou déséquilibrées, aggravant le problème actuel d’informations erronées que le public peut prendre pour argent comptant.

À l’appui de ces préoccupations, Google a déjà déclaré qu’il ne comptait pas s’appuyer sur llms.txt pour sa fonctionnalité d’« AI Overviews » et qu’il continue à suivre les bonnes pratiques traditionnelles de référencement. De façon similaire, certains responsables techniques ont indiqué qu’aucun système public majeur n’utilisait actuellement llms.txt en production. Autrement dit, les acteurs les plus susceptibles de consommer ce signal restent prudents tant que des garanties n’existent pas.

Pourquoi l’adoption sans gouvernance est vouée à l’échec

Les standards durables du web partagent des caractéristiques communes : une gouvernance claire, un vocabulaire accepté et des mécanismes d’application. Les formats qui s’imposent répondent tôt à la question : « Qui gouverne les règles ? »

Schema.org a réussi parce qu’il est né d’une coopération entre plusieurs moteurs importants (Bing, Google, Yahoo, Yandex), ce qui a défini un vocabulaire limité, une syntaxe acceptée et un cycle de rétroaction avec les éditeurs. Quand des abus sont apparus (avis bidons, données produits frauduleuses), ces acteurs ont coordonné des réponses et affiné la documentation. Le signal a perduré parce qu’il n’était pas laissé à l’auto-régulation complète des éditeurs.

À l’inverse, robots.txt a tenu grâce à sa simplicité : il n’essaie pas de qualifier la qualité ou le sens du contenu, il indique simplement ce qu’un crawler doit ignorer. Cette minimalité réduit considérablement la surface d’abus : mentir dans un robots.txt mène surtout à se priver soi-même d’indexation, il n’y a pas d’avantage à tricher.

llms.txt fonctionne sur un principe opposé : il invite l’éditeur à auto-déclarer ce qui compte, et, dans sa variante incluant du texte aplati, à définir « la vérité » du contenu. Aujourd’hui, il n’existe aucune entité de gouvernance clairement identifiée, pas de schéma normalisé et validé à grande échelle, ni d’organisme chargé de surveiller les abus. N’importe qui peut publier un manifeste ; n’importe qui peut ignorer celui d’autrui. Sans adoption publique par des fournisseurs majeurs, le standard reste marginal et sans force normative.

Ce qu’il faudrait changer pour instaurer la confiance

Pour qu’un concept comme llms.txt passe du statut d’idée intéressante à celui de signal exploitable, plusieurs conditions doivent être réunies. Chacune entraîne des coûts en ingénierie, en gouvernance et en surveillance.

• Premièrement, une vérification du manifeste. Un mécanisme de signature (par exemple via HTTPS, DNS ou signatures cryptographiques) doit prouver que le fichier appartient bien au domaine revendiqué, ce qui réduit le risque d’usurpation.
• Deuxièmement, des processus de recoupement automatisé. Les plateformes devraient comparer les URL listées avec les pages publiques, vérifier l’accessibilité, détecter le cloaking, et analyser la cohérence avec les balises canoniques et les données structurées.
• Troisièmement, de la transparence et des logs. Des registres publics de manifestes et un historique des modifications permettraient à la communauté et aux équipes de sécurité d’identifier des changements brusques ou suspects.
• Quatrièmement, une évaluation empirique des gains. Les moteurs et fournisseurs doivent démontrer par des études que l’ingestion d’un manifeste améliore la justesse des réponses, la qualité des citations ou la représentation de la marque, sinon l’effort reste spéculatif.
• Enfin, des mesures de dissuasion des abus. Des outils automatiques et des processus humains doivent détecter et sanctionner l’usage malveillant du fichier, sinon les équipes anti-spam considéreront le signal comme une nuisance.

Sans ces éléments, les plateformes continueront de considérer llms.txt comme optionnel ou sans intérêt stratégique. Pour un éditeur, cela signifiera un investissement potentiel en temps et en maintenance pour un bénéfice incertain.

La valeur réelle à court terme

Pour les propriétaires de sites, llms.txt peut encore avoir une utilité, mais pas comme un raccourci garanti vers du trafic ou une meilleure visibilité par les grands fournisseurs d’IA. Il peut servir d’outil interne d’alignement du contenu : une façon structurée de définir les URL prioritaires que vous souhaitez que des agents internes ou partenaires voient. Pour des sites très documentés, des intranets ou des agents spécifiques contrôlés par l’entreprise, publier un manifeste et l’utiliser dans un cadre restreint peut être pertinent.

Cependant, si l’objectif est d’influencer des résultats publics fournis par des acteurs tels que Google, OpenAI ou Perplexity, il convient d’être prudent. Il n’existe pas de preuve publique solide que ces systèmes respectent aujourd’hui les instructions d’un llms.txt. Autrement dit : considérez ce fichier comme un « miroir » de la stratégie de contenu plutôt que comme un « aimant » garantissant du trafic ou une meilleure représentation par les modèles externes. Rédiger et maintenir ces manifestes nécessite du travail : pesez le temps investi face au retour d’expérience attendu.

En pratique, les efforts les plus sûrs restent ceux visant à optimiser l’expérience humaine et la clarté du contenu : architecture propre, balises structurées, contenu textuel accessible sans dépendance excessive à l’exécution côté client et métadonnées correctes. Ces actions continuent d’être les plus robustes si vous souhaitez que vos pages soient correctement interprétées par des systèmes automatiques.

Pistes opérationnelles et bonnes pratiques si vous décidez d’expérimenter

Si vous envisagez malgré tout de publier un llms.txt pour usage interne ou expérimental, quelques pratiques peuvent limiter les risques :

• Signez ou validez le fichier via des méthodes de propriété de domaine (DNS TXT record, fichiers bien connus, ou signatures numériques) pour réduire l’usurpation.
• Ne publiez pas de copies complètes de contenu sensible ou exclusif ; préférez des résumés structurés et des métadonnées qui décrivent l’objectif et la portée des pages listées.
• Maintenez un historique des modifications et des raisons commerciales derrière chaque mise à jour importante, afin d’expliquer toute variation inhabituelle aux auditeurs.
• Testez d’abord l’usage dans des environnements fermés (agents internes, partenaires techniques) avant toute mise à disposition publique.
• Supervisez activement les logs d’accès et de récupération afin de détecter des usages anormaux du fichier par des bots ou des agents externes.

Ces démarches ne suffisent pas à transformer llms.txt en un signal de confiance universel, mais elles réduisent la surface d’abus pour les implémentations contrôlées.

Perspectives et implications pour les éditeurs et les plateformes

Le débat autour de llms.txt illustre une tension plus large du web actuel : comment permettre aux machines de mieux comprendre le contenu sans ouvrir de voies faciles à la manipulation ? Les réponses passent par un équilibre entre innovation, gouvernance et contrôle opérationnel. Les éditeurs cherchent des méthodes pour expliciter la valeur de leur contenu aux moteurs et aux assistants, tandis que les plateformes cherchent à minimiser les risques de désinformation et les coûts de modération.

Concrètement, plusieurs scénarios peuvent émerger :

• Approche coopérative : une coalition d’acteurs (fournisseurs de modèles, moteurs, éditeurs) définit un standard signé, avec règles d’usage, validation et sanctions. C’est le chemin le plus long mais le plus solide.
• Approche minimaliste : la communauté adopte une version très simple de llms.txt (liste d’URL sans texte aplati), répliquant la philosophie prudente de robots.txt.
• Approche fragmentée : certains acteurs intègrent des variantes internes du concept pour des usages contrôlés (agents de support, intranets, partenaires), tandis que les plateformes publiques continuent de l’ignorer.

Il est probable que l’avenir combine plusieurs de ces pistes : des usages restreints et vérifiés à court terme, plus une évolution vers des normes partagées si des preuves de bénéfice réel sont produites.

Conclusion — entre promesse et contraintes

Le web a constamment tenté de se présenter de manière plus compréhensible aux machines. À chaque génération d’outils correspond une nouvelle tentative pour déclarer « voici ce qui compte ». Le succès d’un tel signal dépend in fine d’une question simple et répétitive : « Peut-on faire confiance à ce signal ? »

Avec llms.txt, l’idée est attractive : simplifier l’accès des **LLM** au contenu pertinent et réduire le bruit. Mais les mécanismes de confiance, de vérification et de gouvernance nécessaires pour en faire un signal robuste ne sont pas encore en place. Tant que ces éléments manqueront, llms.txt restera dans une zone grise, entre promesse d’utilité et risques potentiels.

Pour les éditeurs, la recommandation pragmatique est de prioriser les bonnes pratiques classiques : contenu accessible, structure claire, balisage pertinent et documentation des changements. Si vous testez un llms.txt, faites-le dans un cadre contrôlé, documentez soigneusement vos objectifs et vos observations, et préparez-vous à ce que les bénéfices restent incertains tant que des normes partagées n’existent pas.

Ressources complémentaires :

Ce billet a été publié à l’origine sur Duane Forrester Decodes.

Image de couverture : Roman Samborskyi/Shutterstock