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

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

Module version: 1.2.0

PrestaShop compatibility: 1.7.x 8.x 9.x

Fichier du module mis à jour : 2026-09-11 17:52:14

Données du produit mises à jour : 2026-09-11 17:54:49


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.

278,00 zł
226,02 złnetto
Price history:

La 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

détails du produit

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
PDMD4APRO

Changelog

Newest entries first. Click to expand details.

  • dodano obsługę Content Signals
  • dodano obsługę ph_simpleblog
  • dodano obsługę pdfaqpro
  • dodano obsługę productcomments
  • dodano obsługę iqitrewievs

FAQ

Find answers to the most common questions about this product.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Commentaires (0)

Aucun avis