---
type: "product"
id: 344
url: "https://prestadev.pl/fr/markdown4agents-pro-dla-prestashop-tresc-sklepu-w-markdown-dla-agentow-ai.html"
markdown_url: "https://prestadev.pl/fr/markdown/product/344.md"
title: "Markdown4Agents Pro pour PrestaShop — contenu de la boutique en Markdown pour les agents IA"
image: "https://prestadev.pl/2357/markdown4agents-pro-pour-prestashop-contenu-de-la-boutique-en-markdown-pour-les-agents-ia.jpg"
sku: "PDMD4APRO"
brand: "PrestaDev.pl"
price: 278.00
price_tax_excluded: 226.02
currency: "PLN"
tax_included: true
availability: "in_stock"
is_pack: false
customization_required: false
condition: "new"
categories: ["Import et export de données", "SEO et rapidité de la boutique"]
language: "fr"
updated: "2026-09-11"
---

# Markdown4Agents Pro pour PrestaShop — contenu de la boutique en Markdown pour les agents IA

PD Markdown4Agents Pro est un module PrestaShop qui met le contenu de la boutique à disposition des assistants et agents IA au format Markdown, au lieu de les obliger à traiter une page HTML complète. Le module fonctionne via deux canaux indépendants : la négociation de contenu sur l’adresse canonique du produit (une requête avec l’en-tête **Accept: text/markdown** reçoit du Markdown, tandis que le navigateur continue de recevoir du HTML) ainsi que des adresses parallèles en **.md** pour les agents qui n’envoient pas cet en-tête. Le document est généré directement à partir des données PrestaShop — produit, catégorie, page CMS et fabricant — et non par nettoyage d’un HTML rendu, ce qui lui permet de contenir les prix, variantes, caractéristiques et disponibilités sous forme de données, et non comme un texte à deviner. Le module génère également les fichiers **llms.txt** et **llms-full.txt**, c’est-à-dire une table des matières machine de la boutique conforme à la convention en cours de diffusion pour les modèles de langage. Le diagnostic intégré sert de garde-fou : la négociation de contenu s’installe désactivée et il est impossible de l’activer tant qu’un test n’a pas confirmé, au moyen de véritables requêtes HTTP, que la pile de cette boutique — CDN, reverse proxy, cache — ne servira pas de Markdown au navigateur ni de HTML à l’agent. Le Markdown généré est mis en cache dans la base de données et invalidé par des hooks lors d’un changement de produit, de combinaison, de promotion, d’état de stock, de catégorie, de page CMS et de fabricant, il n’est donc pas régénéré à chaque requête. Le module veille systématiquement au respect du principe selon lequel **l’agent ne voit jamais plus qu’un visiteur non connecté** : il respecte le masquage des quantités, les produits indisponibles à la commande, le mode catalogue, le masquage des prix pour les visiteurs, la visibilité du produit, le mode maintenance et la géolocalisation. Le compteur de visites intégré montre enfin ce qu’il est impossible de déterminer sans lui — si un agent interroge réellement votre boutique, par quel canal et à quelle fréquence.

## Description

### Caractéristiques et avantages du module

 - Markdown construit à partir des objets PrestaShop, et non par conversion d’une page rendue — le document ne contient ni menu, ni pied de page, ni formulaires, ni code d’autres modules.
- Coût en tokens radicalement plus faible côté agent : l’en-tête **X-Markdown-Tokens-Estimate** dans chaque réponse indique la taille estimée du document, et le panneau affiche une comparaison Markdown versus HTML pour l’entité indiquée.
- Deux canaux de diffusion indépendants — négociation de contenu à l’adresse canonique et adresses **.md** distinctes — ainsi l’agent accède au contenu qu’il envoie ou non l’en-tête **Accept**.
- Garde-fou de diagnostic avant l’activation de la négociation : le module ne permet pas d’activer la fonction tant qu’il n’a pas mesuré, au moyen de véritables requêtes HTTP, qu’un intermédiaire de cache n’empoisonnera pas le cache partagé.
- Principe « l’agent ne voit jamais plus qu’un visiteur » implémenté comme règle, et non comme une série d’exceptions — les paramètres de visibilité de la boutique s’appliquent aux agents exactement comme à un visiteur anonyme.
- Prix calculés dans le contexte d’un visiteur, avec résolution explicite de la devise et du pays, afin que le cache n’enregistre pas le prix d’un client pour le servir ensuite à tous les autres.
- Prise en charge complète du multiboutique et du multilingue : paramètres, fichiers **llms**, cache et compteur sont gérés séparément pour chaque boutique et chaque langue.
- Zéro dépendance externe — sans Composer, sans bibliothèques externes, sans appels à des services tiers ; le module n’envoie les données de votre boutique nulle part ailleurs que dans la réponse à la requête.
- Ne collecte pas de données personnelles : le compteur de visites enregistre uniquement le jour, la boutique, le canal et la famille de client, sans adresses IP, sessions, URL complètes ni **User-Agent** complet.
- Compatibilité de PrestaShop 1.7.1.0 à 9.x et de PHP 7.0 à 8.5, vérifiée sur de véritables arborescences de sources, et non de manière déclarative.

 ### Fonctionnalités principales du module

 - Négociation de contenu sur les adresses canoniques de la boutique : une requête avec **Accept: text/markdown** reçoit un document Markdown, une requête de navigateur reçoit le HTML inchangé.
- En-tête **Vary: Accept** et balise **Link: rel="alternate"** sur les pages HTML prises en charge par le module, afin que les intermédiaires et les agents sachent qu’une version alternative existe.
- Adresses parallèles **markdown/{typ}/{id}.md** pour les produits, catégories, pages CMS et fabricants, sous leur propre préfixe, afin d’éviter les conflits avec d’autres modules qui réécrivent les adresses.
- Fichier **llms.txt** — liste organisée des sections les plus importantes de la boutique : catégories de premier niveau, pages d’information et lien vers l’index complet.
- Fichier **llms-full.txt** — index compact des entités : titre, adresse canonique, adresse **.md**, prix, disponibilité, SKU et résumé ; automatiquement découpé en plusieurs parties après dépassement de la taille configurée.
- Génération de **llms-full.txt** exclusivement via un endpoint cron protégé par jeton, jamais pendant une requête de visiteur, avec budget de temps et reprise d’une reconstruction interrompue.
- Jeton cron distinct pour chaque boutique, comparé en temps constant, avec une commande **curl** prête à être copiée dans le panneau.
- Cache du Markdown généré dans la base de données avec durée de vie configurable et invalidation par hooks lors d’un changement de produit, combinaison, prix promotionnel, règle de prix, état du stock, catégorie, page CMS et fabricant.
- Onglet Diagnostic : sept vérifications effectuées au moyen de véritables requêtes HTTP contre le propre point de sondage du module, avec distinction séparée entre les pannes « HTML servi à l’agent » et « Markdown servi au navigateur ».
- Vérification informative de l’adresse réelle du catalogue après activation de la négociation, présentée séparément et sans bloquer la fonctionnalité.
- Aperçu du document dans le panneau pour le type et l’identifiant d’entité indiqués, avec compteur de tokens Markdown versus HTML et verdict explicite sur la visibilité de l’entité.
- Onglet Fichiers : état des fichiers **llms** pour chaque langue (présence, taille, date, nombre d’entités, nombre de parties), bouton de reconstruction manuelle avec budget de temps et commande cron.
- Compteur de visites des agents : agrégat jour × boutique × canal × famille de client, avec répartition par canaux **négociation**, **route .md** et **llms** ainsi que par familles **openai**, **anthropic**, **perplexity**, **google**, **bing**, **script**, **browser** et **other**.
- En-têtes de réponse conformes à l’usage du contenu : **X-Robots-Tag: noindex, nofollow** sur les documents Markdown, **X-Content-Type-Options: nosniff**, **ETag** avec prise en charge de **304** ainsi qu’une politique **Cache-Control** différenciée pour l’adresse canonique et l’adresse **.md**.
- Données produit dans l’en-tête du document : type, identifiant, adresse canonique, adresse Markdown, titre, SKU, marque, prix TTC et HT, devise, information fiscale, disponibilité, indication de lot, exigence de personnalisation, état du produit, catégories, langue et date de mise à jour.
- Prix standard ainsi que montant et pourcentage de remise lorsque le produit est en promotion — l’agent ne verra pas le prix promotionnel comme un prix ordinaire.
- Tableau des variantes avec prix, quantité, disponibilité et identifiant de combinaison, afin que l’agent puisse indiquer une variante précise, et non seulement la décrire.
- Contenu des lots de produits avec quantités et liens vers les documents Markdown de chaque élément.
- Information sur les champs de personnalisation obligatoires, en excluant les champs appartenant à d’autres modules que PrestaShop n’affiche pas sur le front-office.
- Sélection des types d’entités mis à disposition des agents, appliquée uniformément sur tous les canaux : sur les routes **.md**, dans les fichiers **llms** et dans la balise de version alternative.
- Répertoire de travail du module protégé contre la lecture directe depuis le réseau, et fichiers **llms** servis exclusivement par les contrôleurs du module.
- Respect du mode maintenance de la boutique et de la géolocalisation — une boutique fermée aux visiteurs l’est aussi pour les agents.
- Panneau dans la convention PD avec en-tête du module et barre d’onglets, avec indications sur les paramètres aux conséquences coûteuses, telles que la fragmentation du cache CDN.

 ### Usage métier

 - Pour les boutiques PrestaShop qui veulent être correctement lues par les assistants d’achat et les agents IA, au lieu de compter sur le fait que le modèle nettoie lui-même la page HTML.
- Pour les vendeurs qui veulent contrôler exactement ce qui parvient aux agents — périmètre des types d’entités, visibilité des prix et des quantités, ainsi que mode de publication.
- Pour les boutiques avec un catalogue étendu, où la différence entre une page HTML complète et un document Markdown se traduit par une différence réelle de coût côté requérant.
- Pour les déploiements multiboutiques, où chaque boutique exige ses propres paramètres, ses propres fichiers **llms** et son propre jeton cron.
- Pour les entreprises qui veulent fonder la décision de poursuivre les investissements dans ce canal sur des données — le compteur de visites montre si les agents interrogent réellement la boutique, et par quel chemin.
- Pour les boutiques fonctionnant derrière un CDN ou un reverse proxy, où l’activation autonome de la négociation de contenu sans vérification risquerait de servir une mauvaise version de la page aux clients ordinaires.

 ### Ce que le module ne fait pas

 - Ce n’est pas un module SEO et il n’améliore pas la position de la boutique dans les résultats de recherche Google — les documents Markdown sont explicitement marqués comme non indexables.
- Il ne modifie ni l’apparence, ni le contenu, ni les performances de la page HTML vue par les clients ; la page prise en charge par le module reçoit uniquement des en-têtes supplémentaires informant de l’existence d’une version alternative.
- Il n’envoie les données de la boutique à aucun service externe et ne nécessite ni compte ni clé API.
- Il ne traduit pas les libellés structurels du document — les noms de champs restent fixes et en anglais, car ils sont destinés à la machine, tandis que le contenu des entités est toujours dans la langue de la boutique.

 ### Compatibilité

 - PrestaShop : **1.7.1.0 - 9.x**
- PHP : **7.0 - 8.5**
- Sans Composer et sans bibliothèques externes
- Multiboutique : **oui**, paramètres et fichiers gérés séparément pour chaque boutique
- Multilingue : **oui**, documents et fichiers **llms** pour chaque langue active

## Features

| Feature | Value |
| --- | --- |
| Support pour Prestashop 9.x | Oui |
| Prise en charge de Prestashop 8.x | Oui |
| Prise en charge de Prestashop 1.7.x | Oui |
| Module de traduction | PL, ANG |
| Support gratuit | Alors |
| Mises à jour gratuites (1 an) | Alors |
| Facilité d'installation | Alors |

## Categories

- Import et export de données
- SEO et rapidité de la boutique

## Questions and answers

### Que fait exactement le module PD Markdown4Agents Pro ?

Language: fr

Le module met à disposition le contenu de la boutique PrestaShop au format Markdown, destiné aux assistants et agents IA. Il fonctionne via deux canaux : à l’adresse canonique du produit, il répond en Markdown lorsque la requête contient l’en-tête Accept: text/markdown, et pour les clients qui n’envoient pas cet en-tête, il fournit des adresses parallèles se terminant par l’extension .md. En outre, il génère les fichiers llms.txt et llms-full.txt, c’est-à-dire la table des matières machine de la boutique. Les types de contenu pris en charge sont les produits, les catégories, les pages CMS et les fabricants.

### Est-ce un module SEO ? Améliorera-t-il le positionnement de ma boutique sur Google ?

Language: fr

Non. Il ne s’agit pas d’un module SEO et il n’influence pas le positionnement dans les résultats de recherche. Les documents Markdown sont explicitement marqués par l’en-tête X-Robots-Tag: noindex, nofollow, c’est-à-dire qu’ils demandent directement aux moteurs de recherche de ne pas les indexer. Le module répond à une autre question que le SEO : comment faire en sorte qu’un assistant IA lise correctement et à moindre coût l’offre de la boutique, au lieu de traiter toute la page HTML avec le menu, le pied de page et le code des autres modules.

### En quoi cela diffère-t-il d’une conversion ordinaire d’une page HTML en Markdown ?

Language: fr

Le module ne convertit pas la page rendue, mais construit le document directement à partir des données de PrestaShop. Grâce à cela, le prix, le prix habituel en cas de promotion, la devise, l’information sur la taxe, la disponibilité, le SKU, les caractéristiques, les variantes avec les quantités et les identifiants ainsi que le contenu des ensembles sont intégrés au document sous forme de données structurées, et non comme un texte à deviner. La conversion du HTML, en revanche, restitue ce qui se trouve justement dans la couche de présentation, avec les éléments de l’interface et le contenu des autres modules.

### Les clients de ma boutique verront-ils un quelconque changement ?

Language: fr

Non. Le navigateur du client reçoit toujours une page HTML classique, sans changement d’apparence ni de contenu. Les pages prises en charge par le module reçoivent uniquement des en-têtes supplémentaires informant les intermédiaires et les agents qu’il existe une version alternative : Vary: Accept et Link rel="alternate". Le module ne modifie pas le thème, n’ajoute pas de scripts sur le front et ne change pas la manière dont la page est rendue.

### Que sont les fichiers llms.txt et llms-full.txt ?

Language: fr

Il s’agit de deux fichiers texte selon la convention adoptée par les outils basés sur des modèles de langage. llms.txt est une liste courte et soigneusement sélectionnée des sections les plus importantes de la boutique : catégories de premier niveau, pages d’information et lien vers l’index complet. llms-full.txt est un index compact des entités, où chaque entrée contient le titre, l’adresse canonique, l’adresse de la version Markdown, le prix, la disponibilité, le SKU et un bref résumé, l’agent ne récupérant le contenu complet qu’à partir du document qui l’intéresse. Le fichier est automatiquement divisé en parties après dépassement de la taille configurée.

### Pourquoi ne puis-je pas activer immédiatement la négociation de contenu après l’installation ?

Language: fr

Il s’agit d’une protection intentionnelle. La négociation de contenu consiste à ce que, sous une même adresse, la réponse dépende de l’en-tête de la requête, et cela est dangereux si un quelconque cache sur le chemin — CDN, proxy inverse, cache de l’hébergement — mémorise une version et la sert à tout le monde. Dans ce cas, un client ordinaire pourrait voir le texte brut au lieu de la page de la boutique. C’est pourquoi le commutateur est bloqué tant que le diagnostic intégré n’a pas vérifié, au moyen de véritables requêtes HTTP, que la pile de votre boutique se comporte correctement dans les deux sens. Le diagnostic lui-même ne modifie aucun paramètre.

### Le module nécessite-t-il la configuration d’un cron ?

Language: fr

Pour un fonctionnement complet, oui, mais pas pour le lancement. Le fichier llms-full.txt est généré exclusivement par un endpoint protégé par un jeton et n’est jamais créé pendant la requête d’un visiteur, afin qu’un grand catalogue ne bloque pas la page. Dans le panneau, il y a un bouton de reconstruction manuelle ainsi qu’une commande prête à être copiée dans le planificateur de tâches. Sans cron, le module fonctionne, et les fichiers llms-full.txt ne sont actualisés que lorsque vous cliquez sur la reconstruction manuelle. Chaque boutique a son propre jeton distinct.

### L’agent IA verra-t-il les prix ou les états des stocks que je masque aux utilisateurs non connectés ?

Language: fr

Non. Le module applique systématiquement le principe selon lequel l’agent ne voit jamais plus qu’un visiteur non connecté sur la boutique. Sont respectés : le masquage des quantités en stock, les produits marqués comme indisponibles à la commande, le mode catalogue, le masquage des prix pour le groupe Visiteur, les paramètres de visibilité du produit, ainsi que le mode maintenance de la boutique et la géolocalisation. Les prix sont calculés dans le contexte d’un visiteur anonyme, de sorte que le cache n’enregistrera pas le prix d’un client pour le servir aux autres.

### Le module collecte-t-il des données personnelles ou envoie-t-il quelque chose vers l’extérieur ?

Language: fr

Non. Le module n’appelle aucun service externe, ne nécessite ni compte ni clé API et n’envoie aucune donnée de la boutique en dehors de la réponse à la requête entrante. Le compteur de visites intégré enregistre uniquement des données agrégées : le jour, l’identifiant de la boutique, le canal ainsi que la famille du client ramenée à quelques catégories. Il n’enregistre ni adresses IP, ni identifiants de session, ni URL complètes, ni le contenu intégral de l’en-tête User-Agent.

### Comment saurai-je si un agent utilise réellement ces contenus ?

Language: fr

Le compteur de visites intégré sert à cela. Il affiche le nombre de requêtes ventilé par jour, boutique, canal et famille de l’émetteur de la requête. Les canaux comprennent la négociation de contenu, les adresses .md ainsi que les fichiers llms, et les familles incluent notamment openai, anthropic, perplexity, google et bing, ainsi que les requêtes provenant de bibliothèques de scripts et de navigateurs. Ainsi, la décision de poursuivre le développement de ce canal repose sur les données de votre boutique, et non sur des suppositions.

### Le module prend-il en charge le multiboutique et plusieurs langues ?

Language: fr

Oui, dans les deux cas, entièrement. Les paramètres, les fichiers llms, la mémoire cache, le jeton cron et le compteur de visites sont gérés séparément pour chaque boutique. Les documents Markdown ainsi que les fichiers llms sont générés pour chaque langue active de la boutique. L’enregistrement des paramètres nécessite de sélectionner une boutique précise dans le sélecteur, afin qu’un seul clic n’écrase pas la configuration des autres boutiques.

### Quelles sont les exigences techniques et le module alourdit-il la boutique ?

Language: fr

Le module fonctionne sur PrestaShop de 1.7.1.0 à 9.x ainsi que sur PHP de 7.0 à 8.5, sans Composer et sans bibliothèques externes. Le Markdown généré est enregistré en cache dans la base de données et invalidé automatiquement lors d’une modification du produit, de la déclinaison, de la promotion, du stock, de la catégorie, de la page CMS ou du fabricant, de sorte qu’il n’est pas régénéré à chaque requête. La page HTML vue par les clients n’est ni reconstruite ni ralentie — elle reçoit uniquement des en-têtes supplémentaires.