# llms.txt pour un catalogue Algolia : que faut-il exposer à un agent > Le fichier llms.txt promet de guider les agents IA vers l'essentiel d'un site. Quand le catalogue réel vit dans un index Algolia, que doit-il décrire, et que doit-il taire ? - Auteur : Clément Hadrot - Publié le : 2025-09-15 - Mis à jour le : 2025-09-15 - Catégorie : IA & MCP - URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/llms-txt-catalogue-algolia-exposer-agent/ ## L’essentiel - llms.txt décrit la structure, jamais le contenu complet de l'index - Un lien vers un point d'entrée MCP vaut mieux qu'un dump de produits - Le fichier doit rester lisible en quelques secondes par un agent Que doit contenir un fichier `llms.txt` quand le vrai catalogue d'une boutique ne vit pas dans les pages HTML, mais dans un index Algolia interrogé en direct par le moteur de recherche du site ? C'est la question qui s'est posée en travaillant sur un site e-commerce de pièces détachées automobiles, avec plus de 40 000 références et un catalogue qui change plusieurs fois par jour. Le standard `llms.txt`, apparu en septembre 2024, propose un fichier Markdown placé à la racine du site, destiné à orienter les modèles de langage et les agents vers les ressources importantes, sans qu'ils aient à explorer l'intégralité des pages. Son adoption reste facultative et aucun moteur ne garantit qu'il sera lu, mais il devient un point de repère utile pour les agents d'achat qui commencent à naviguer le web de façon autonome. ## Ce que llms.txt n'est pas censé faire La première erreur, tentante avec un catalogue Algolia, est de vouloir y lister des exemples de produits ou des extraits de schéma d'index. Le fichier `llms.txt` n'est pas une exportation de données : c'est une carte, pas le territoire. Un agent qui a besoin du détail d'un produit doit passer par un canal structuré — une page produit, une API, ou idéalement un serveur MCP — pas lire un résumé approximatif glissé dans un fichier texte à la racine. ## Ce qu'il doit décrire concrètement > L'essentiel à retenir : llms.txt décrit la structure, jamais le contenu complet de l'index ; Un lien vers un point d'entrée MCP vaut mieux qu'un dump de produits ; Le fichier doit rester lisible en quelques secondes par un agent Pour ce catalogue, le fichier retenu se limite à décrire la structure générale et les points d'entrée disponibles : ``` # Pièces Détachées Express > Catalogue de pièces détachées automobiles, recherche par référence > constructeur, modèle et année. Plus de 40 000 références indexées. ## Points d'entrée - [Recherche produits](https://exemple.fr/api/recherche) : API de recherche en langage naturel, filtrable par marque et modèle - [Fiche produit](https://exemple.fr/produit/{sku}) : détail structuré d'une référence via son SKU - [Documentation API](https://exemple.fr/docs/api) : format des réponses ## À ne pas faire - Ne pas déduire la disponibilité d'un produit à partir du contenu indexé par un moteur de recherche tiers, toujours vérifier via l'API ``` Ce fichier tient en une quinzaine de lignes et suffit à orienter un agent vers les bons points d'entrée, sans jamais prétendre représenter l'état exact du stock ou des prix, qui changent trop souvent pour être figés dans un fichier statique. ## Fonctionnement interne : un guide, pas un index Contrairement à un plan de site XML, `llms.txt` n'a pas de format rigide imposé par une spécification stricte : c'est un Markdown libre, avec des conventions de structuration (titre, citation de résumé, listes de liens par section) plutôt que des balises obligatoires. Cette souplesse est à la fois sa force — n'importe qui peut en écrire un en quelques minutes — et sa limite, puisque rien ne garantit qu'un agent donné saura l'interpréter de la même façon qu'un autre. ## Cas d'usage : orienter vers un serveur MCP plutôt que vers du HTML Le cas le plus intéressant pour un catalogue Algolia consiste à faire pointer `llms.txt` vers un serveur MCP dédié à la recherche produit, plutôt que vers des pages HTML classiques. Un agent d'achat capable de parler MCP peut alors interroger directement l'index avec des filtres structurés (marque, modèle, année, prix), au lieu de tenter de parser une page de résultats pensée pour un navigateur humain. ## Les pièges à éviter - Vouloir tout dire : un fichier trop long perd l'agent autant qu'il informerait un humain pressé - Oublier de le maintenir à jour quand l'architecture du site change - Croire que sa seule présence améliore le référencement classique, ce qui n'a aucun rapport > Un llms.txt qui décrit fidèlement trois points d'entrée vaut mieux qu'un llms.txt qui tente de résumer quarante mille produits. ## Pour aller plus loin Le fichier `llms.txt` reste un complément, pas un remplacement des mécanismes structurés existants : données structurées Schema.org, flux produits, et surtout serveurs MCP quand l'objectif est de permettre à un agent d'agir, pas seulement de lire. Sur un catalogue Algolia de cette taille, la combinaison qui a le mieux fonctionné associe un llms.txt minimaliste et un point d'entrée MCP correctement documenté, laissant le gros du travail de recherche à l'index lui-même.