llms.txt : décider quelles données rendre publiques
Avant de générer llms.txt, dressez la liste des ressources que vous autorisez à rendre publiques. Une documentation produit et une conversation de support peuvent parler du même sujet sans avoir vocation à être diffusées ensemble.
La proposition llms.txt organise l'accès à des ressources ; elle ne protège pas un espace privé. Le choix des pages doit précéder leur extraction.
Public sur le Web ne signifie pas utile dans un index documentaire
Un fichier peut être accessible sans authentification tout en étant une mauvaise ressource à mettre en avant : export oublié, page de test, document ancien ou contenu contenant des données de personnes. La première question n'est donc pas « l'URL répond-elle ? », mais « cette ressource est-elle destinée à cette diffusion ? ».
Exemple fictif : une boutique dispose d'un guide public de tailles et d'un tableau de commandes exporté dans le même espace. Le guide aide à comprendre les produits. Le tableau ne devient pas une ressource éditoriale légitime parce qu'une URL fonctionne. L'inventaire doit conserver cette distinction avant la génération de llms.txt.
| Ressource envisagée | Question de sélection |
|---|---|
| Guide public maintenu | Apporte-t-il une réponse utile et actuelle ? |
| Politique commerciale | Son marché et sa période sont-ils explicites ? |
| Ancienne documentation | Son statut d'archive est-il clair ? |
| Export opérationnel | Est-il réellement destiné à une publication publique ? |
| Page de test | Contient-elle des valeurs ou promesses fictives ? |
Le fichier de découverte ne remplace pas les contrôles d'accès du serveur. Retirer un lien de llms.txt ne rend pas privée la ressource vers laquelle il pointait. La proposition llms.txt concerne la présentation de ressources documentaires ; elle ne fournit pas un mécanisme d'authentification.
Constituer une liste positive plutôt qu'exporter tout le site
Une liste positive décrit les catégories autorisées et leurs propriétaires. Elle peut retenir, par exemple, les pages d'aide publiques maintenues et les politiques effectivement applicables. Les autres catégories attendent une décision au lieu d'être incluses par défaut.
Pour chaque ressource, relevez son rôle, son public, sa langue, sa version et la personne qui peut trancher un doute. Ce travail peut être simple : l'objectif n'est pas de créer un deuxième catalogue, mais de rendre les décisions explicables lorsque le contenu change.
La liste doit aussi préciser les exclusions. Évitez les règles fondées uniquement sur le nom d'un dossier : une page peut être déplacée sans perdre son caractère sensible ou obsolète. Le contrôle final doit examiner les URL produites et leur contenu, pas seulement la configuration du générateur.
Prévoir ce qui se passe quand une ressource change de statut
Un guide peut devenir obsolète, une page publique peut devoir être retirée ou une archive peut recevoir un avertissement. La procédure doit faire remonter cette modification jusqu'au fichier de découverte et aux représentations alternatives éventuelles.
Après retrait, vérifiez ce que sert votre propre site. Cette observation ne démontre pas l'effacement des copies déjà récupérées ailleurs. Si des données personnelles ont été diffusées, le traitement de la situation dépasse la simple régénération du fichier ; utilisez les procédures adaptées au service et à la donnée concernés.
Pour le suivi courant, commencez par les changements : nouvelles ressources, redirections et pages sorties du périmètre public. Une politique de sélection fonctionne lorsqu'elle accompagne ces événements, plutôt que lorsqu'elle produit une approbation unique jamais réexaminée.
Séparer information produit et information personnelle
La fiche d'un produit décrit une référence. Une question posée par un acheteur peut révéler sa situation, son adresse ou son historique. Même si cette question aide à améliorer une documentation, son contenu ne doit pas être recopié automatiquement.
La CNIL recommande d'examiner les données confiées aux systèmes d'IA et les conditions de leur réutilisation. Pour un index public, le choix prudent consiste à publier une réponse générale validée, débarrassée des informations individuelles, plutôt qu'un extrait de conversation.
Cette reformulation ne doit pas créer de nouveau fait produit. Si le service client ne peut pas confirmer une caractéristique, son absence reste une information manquante.
Contrôler les fichiers générés, pas seulement la configuration
Une règle d'exclusion peut être correcte tandis qu'un ancien fichier reste servi. Contrôlez le résultat final : ressources liées, extraits intégrés et éventuel fichier de contenu complet.
Le contrôle doit aussi porter sur les destinations. Un lien qui contenait seulement une documentation publique peut changer de cible après une réorganisation. Conservez donc un inventaire des URL et un responsable pour chaque famille de contenu.
Les bonnes pratiques llms.txt couvrent la structure du fichier. Ajoutez, dans votre registre interne, le motif d'inclusion et le responsable de chaque famille de ressources.
Pour le cas Shopify, la ressource Verity Score consacrée à llms.txt aide à replacer ce fichier parmi les autres données publiques de la boutique. Elle ne vaut pas audit de confidentialité.
