Réponse en bref
robots.txt est un mécanisme d'instruction normalisé pour les robots coopérants ; llms.txt est une proposition volontaire de découverte. Aucun des deux n'est une frontière de sécurité, et seuls les journaux prouvent les requêtes observées.
Trois problèmes que l'on confond
Les propriétaires de sites mettent souvent `robots.txt`, `llms.txt` et le « contrôle des robots IA » dans le même panier, alors que ces éléments résolvent des problèmes différents. Le protocole d'exclusion des robots normalisé par la RFC 9309 est une convention permettant à un robot d'exploration de découvrir les règles indiquant quels chemins il est prié de parcourir. La documentation de Google décrit le même usage pratique pour ses propres robots. Le protocole est largement implémenté, mais la RFC est explicite sur une limite importante : ces règles ne constituent pas une autorisation d'accès. Une URL interdite peut rester joignable par toute personne ou tout système qui en connaît l'adresse, sauf si le serveur lui-même exige une authentification ou refuse la requête d'une autre manière.
`llms.txt` diffère à la fois par sa finalité et par sa maturité. Le site du projet le décrit comme une proposition de fichier Markdown, généralement placé à `/llms.txt`, qui présente des liens utiles et du contexte à destination des systèmes fondés sur des modèles de langage. Il est pensé comme une aide à la découverte et à l'orientation, non comme un protocole établi de contrôle d'accès. La comparaison pertinente n'est donc pas « quel fichier bloque le mieux l'IA ? ». Les questions utiles sont : quel robot respecte `robots.txt` ; un outil donné choisit-il de lire `llms.txt` ; et le site dispose-t-il de contrôles côté serveur pour les contenus qui doivent réellement rester privés ?
Ce que robots.txt normalise
La RFC 9309 définit la manière dont les robots coopérants peuvent récupérer et interpréter `/robots.txt`, y compris les groupes d'agents utilisateurs, les règles `Allow` et `Disallow` et le comportement de correspondance. Le fichier se place à la racine d'une origine, et les règles s'appliquent dans ce périmètre. Cette normalisation compte, car une analyse syntaxique incohérente peut sinon produire des comportements de robots surprenants. Une entreprise qui utilise ce fichier doit générer des règles simples, éviter les conflits de syntaxe accidentels et tester exactement les chemins qui l'intéressent. Les fournisseurs de recherche peuvent publier leurs propres outils et une documentation supplémentaire, mais le protocole lui-même est un mécanisme d'instruction pour robots, pas un pare-feu général.
Cette distinction compte particulièrement pour les documents sensibles. Une règle robots ne rend confidentiels ni une facture, ni un site de préproduction, ni un export client, ni un PDF privé. La RFC avertit qu'utiliser le protocole comme mesure de sécurité peut exposer des chemins, puisque le fichier est public et les énumère. Si un contenu doit être protégé, employez une véritable autorisation : accès authentifié, contrôles réseau, URL signées à durée de vie adaptée, ou réponses serveur qui refusent les requêtes non autorisées. `robots.txt` peut réduire l'exploration par les robots conformes ; il ne doit jamais porter la charge de garder un secret. De même, bloquer l'exploration n'est pas la même opération que demander le retrait d'un index ou la suppression de matériaux déjà collectés.
Ce que Google dit que son fichier robots peut et ne peut pas faire
La documentation de Google Search explique que `robots.txt` sert principalement à gérer le trafic des robots et à éviter que certains fichiers ne soient demandés par les robots de Google. Elle avertit aussi que ce mécanisme ne doit pas servir à tenir une page à l'écart de Google Search. Une URL bloquée peut rester connue par des liens ou d'autres signaux, même lorsque son contenu n'est pas exploré. Pour les éditeurs, c'est un modèle utile bien au-delà de Google : permission d'exploration, comportement d'indexation, comportement d'affichage et contrôle d'accès sont des couches distinctes, qui ne doivent pas être traitées comme des interrupteurs interchangeables.
Une implémentation fiable part donc du résultat visé. S'il s'agit de réduire l'exploration d'URL à facettes dupliquées, une règle robots peut convenir. S'il s'agit d'empêcher l'accès public, l'autorisation relève du serveur. S'il s'agit de contrôler la présentation dans la recherche, employez les mécanismes documentés par le service de recherche concerné plutôt que de supposer qu'un blocage d'exploration produit le même effet. Les services d'IA ajoutent une couche supplémentaire, car une même entreprise peut exploiter des agents utilisateurs différents pour l'entraînement des modèles, la récupération de recherche ou une requête déclenchée par l'utilisateur. Le propriétaire du site doit consulter la documentation à jour de ce fournisseur, plutôt que d'inférer une finalité à partir du mot « IA ».
Ce que llms.txt propose réellement
La proposition `llms.txt` tient davantage de la carte commentée que du portail. Sa spécification s'appuie sur Markdown, afin qu'un éditeur puisse décrire un projet et orienter les outils fondés sur des modèles de langage vers la documentation ou d'autres ressources importantes. Cela peut être utile sur des sites où le matériau critique est éclaté dans la navigation, généré côté client, ou entouré d'éléments d'interface peu efficaces pour une consommation machine. Un fichier concis peut énoncer ce que contient le site et identifier les ressources canoniques. Rien de tout cela n'oblige un produit d'IA à récupérer, croire ou citer ces ressources, et la proposition ne remplace pas une architecture web normale.
Le projet a été publié pour la première fois en 2024 et n'a cessé d'évoluer ; son propre journal des modifications doit donc être considéré comme la référence faisant autorité pour connaître le format actuel de la proposition. L'adoption est volontaire et inégale. Un éditeur ne doit pas présenter ce fichier à ses parties prenantes comme une directive standard de l'industrie, ni comme une garantie de visibilité dans les moteurs de réponse. Sa valeur s'évalue au mieux empiriquement : ajoutez un fichier bien formé si son coût de maintenance est faible, gardez les pages sous-jacentes exploitables par elles-mêmes, et observez si les services qui vous intéressent demandent effectivement le fichier ou les ressources qu'il référence.
Ne faites pas de llms.txt un second système de contenu
Une erreur d'implémentation courante consiste à rédiger à la main un résumé `llms.txt` soigné qui s'éloigne peu à peu du site. La disponibilité d'un produit change, une version d'API est retirée, une politique est mise à jour, mais le fichier destiné aux machines reste figé. Si le fichier est adopté, générez-le ou révisez-le à partir du même inventaire canonique de sources que celui qui alimente la navigation et la documentation. Évitez d'y placer des affirmations qui n'existent sur aucune page source accessible. Le fichier doit réduire la friction de découverte, pas devenir une base de connaissances parallèle qui porte des faits uniques sans la gouvernance appliquée au contenu ordinaire.
La même règle vaut pour les variantes dites `llms-full.txt` décrites par la proposition. De grands exports adaptés aux machines peuvent être commodes, mais la taille n'est pas automatiquement synonyme de qualité. Du matériau dupliqué, périmé ou inapproprié au regard des droits d'accès peut dégrader la récupération et créer un risque de maintenance. Conservez la provenance, les dates de mise à jour et des URL stables quand c'est pertinent. Si certains documents ne doivent pas être largement récupérés, ne les incluez pas au seul motif qu'un paquet lisible par machine est techniquement facile à produire. Les indices de découverte doivent refléter l'architecture d'information et le modèle d'autorisation du site, non les contourner.
Servez-vous des journaux serveur pour observer, pas pour supposer
La façon la plus concrète de savoir ce qui sollicite un site public est d'examiner les journaux d'accès HTTP, ou la télémétrie équivalente de CDN et de périphérie. Consignez au minimum l'horodatage, le chemin demandé, le statut de la réponse, l'agent utilisateur, le volume d'octets, le référent lorsqu'il est disponible, l'hôte et un identifiant de requête ; ne conservez les informations d'adresse IP que dans le cadre d'une politique de confidentialité et de sécurité appropriée. Créez des vues pour les requêtes vers `/robots.txt`, `/llms.txt`, les principaux chemins de contenu et les agents utilisateurs de robots connus. Mesurez la fréquence, les codes de statut et les pages référencées effectivement récupérées après le fichier de découverte. Cela vous dit ce que votre serveur a observé, ce qui est plus solide que de supposer qu'un service a utilisé un fichier parce que ce fichier existe.
Les journaux demandent malgré tout une interprétation. Une chaîne d'agent utilisateur peut être recopiée par un autre client : ce n'est pas une preuve cryptographique d'identité. Certains grands fournisseurs publient des méthodes de vérification des adresses IP de robots ou de DNS inverse ; employez ces méthodes à jour, propres à chaque fournisseur, lorsque l'identité compte. Les proxys et les récupérations déclenchées par un utilisateur peuvent aussi se comporter autrement que des robots autonomes. N'assimilez pas une requête vers `llms.txt` à une ingestion, un entraînement, un classement ou une citation. Une récupération prouve seulement qu'une requête a atteint le serveur. L'usage ultérieur du contenu dépend du comportement et des politiques documentés du service demandeur.
Construisez une matrice de vérification par service
Pour chaque service de recherche ou d'IA qui vous importe, tenez une petite matrice : noms de robots documentés, finalités annoncées, comportement vis-à-vis du fichier robots, méthode de vérification, contrôles pertinents, date de la dernière revue documentaire et ce que vos journaux montrent réellement. Séparez les robots orientés entraînement, les robots de recherche ou de récupération et les récupérateurs déclenchés par un utilisateur lorsque le fournisseur le fait lui-même. La matrice empêche qu'une règle recopiée d'un vieux billet de blog ne devienne une infrastructure permanente. Elle rend aussi les contradictions visibles : un fournisseur peut documenter un robot alors que les journaux montrent un autre agent utilisateur frappant les mêmes chemins, ce qui appelle une investigation plutôt qu'une conclusion hâtive sur la politique en vigueur.
Testez les changements délibérément. Sauvegardez le fichier robots précédent, déployez une règle claire, notez l'horodatage et observez les requêtes suivantes. Utilisez un chemin de test non sensible plutôt que de vous appuyer sur des données protégées. Pour `llms.txt`, journalisez les requêtes vers le fichier et vers des ressources liées bien identifiables. Tenez compte de la mise en cache et des intervalles d'exploration ; l'absence de requête immédiate ne prouve pas qu'un contrôle est ignoré. Si l'entreprise a des raisons juridiques ou contractuelles de restreindre l'usage automatisé, associez vos conseils juridiques et la sécurité technique plutôt que de vous en remettre aux seules conventions volontaires. La configuration d'un site n'est qu'une partie des droits et obligations opposables.
Une politique praticable pour 2026
Utilisez `robots.txt` pour donner des instructions normalisées aux robots coopérants, et gardez ses règles volontairement simples. Utilisez l'authentification et l'autorisation côté serveur pour tout ce qui ne doit pas être public. Envisagez `llms.txt` comme une couche de découverte optionnelle lorsque le site dispose de ressources canoniques bien gouvernées que des systèmes machine auraient intérêt à trouver. N'y dupliquez pas de contenu confidentiel et ne promettez pas que sa publication produira des citations. Consultez séparément la documentation propre à chaque fournisseur au sujet de ses robots, car un fichier normalisé ne peut pas vous dire pourquoi chaque service d'IA émet une requête.
Bouclez ensuite la boucle avec des preuves. Versionnez les deux fichiers, conservez les dates de déploiement, examinez les journaux serveur, vérifiez l'identité des robots quand c'est praticable, et consignez le comportement observé sans surestimer ce qui se passe après une récupération. Le cœur du sujet « llms.txt contre robots.txt » n'est donc pas un choix entre deux systèmes d'exclusion concurrents. L'un est un protocole normalisé d'instruction pour robots ; l'autre est une proposition volontaire de découverte de contenu. Aucun des deux n'est une frontière de sécurité. Une fois ces rôles séparés, l'implémentation devient beaucoup moins mystérieuse — et beaucoup plus facile à tester.
Checklist pratique
- Déterminez si le vrai objectif est le contrôle de l'exploration, de l'indexation, de la découverte ou de l'accès.
- Gardez des règles robots.txt simples et ne les utilisez jamais pour protéger des chemins confidentiels.
- Traitez llms.txt comme des métadonnées de découverte optionnelles, issues du contenu canonique.
- Journalisez les requêtes vers les deux fichiers et vers des pages liées représentatives.
- Vérifiez l'identité des robots avec les méthodes actuelles du fournisseur lorsque l'identité compte.
- Versionnez les changements de configuration et consignez les fenêtres d'observation.
Questions et réponses
robots.txt peut-il empêcher une entreprise d'IA d'accéder à une page ?
Il peut demander à un robot coopérant de ne pas récupérer un chemin, mais la RFC 9309 ne fait pas de cette demande un mécanisme d'autorisation. Le serveur peut toujours délivrer l'URL à n'importe quel client qui a par ailleurs le droit d'y accéder. Différents fournisseurs exploitent en outre des robots différents et publient leurs propres politiques : l'agent utilisateur concerné doit donc être vérifié dans la documentation à jour. Si la page doit rester privée, appliquez une authentification ou un autre contrôle côté serveur plutôt que de vous reposer sur robots.txt.
Publier llms.txt rend-il un site plus susceptible d'être cité par les moteurs de réponse ?
Il n'existe aucune garantie générale. Le projet llms.txt propose une carte Markdown commode des ressources importantes, mais l'adoption et le comportement en aval dépendent de chaque service. Une requête vers le fichier ne prouve pas que ses liens ont été indexés, utilisés pour une réponse ou cités. Les éditeurs peuvent y voir une expérience de découverte peu coûteuse tant qu'ils peuvent la tenir à jour, puis observer le comportement à l'aide des journaux d'accès et d'audits de requêtes contrôlés. La qualité des pages canoniques et les preuves factuelles doivent malgré tout tenir debout seules.
Comment savoir si un robot IA a respecté un changement ?
Notez l'heure exacte du déploiement, examinez les journaux du serveur ou du CDN pour l'agent utilisateur et les chemins concernés, et tenez compte des calendriers d'exploration et de la mise en cache. Si le fournisseur publie une procédure de vérification par adresse IP ou par DNS, employez-la lorsque l'identité du robot compte, car les chaînes d'agent utilisateur peuvent être usurpées. Testez sur un chemin non sensible et comparez les requêtes avant et après le changement. Le journal peut établir qu'une requête a atteint le serveur ; il ne peut pas établir à lui seul ce que le service a fait d'un contenu récupéré auparavant.