Serveur MCP pour PrestaShop : exposer le catalogue aux assistants IA, en lecture contrôlée

Au 14 octobre 2026, PrestaShop publie un module officiel, « PrestaShop MCP Server », qui laisse un assistant IA interroger la boutique. La lecture seule se règle par le rôle « Viewer » d’un membre ; la documentation indique aussi que les outils par défaut couvrent produits, images, commandes et clients. Le périmètre de départ dépasse le catalogue : il se réduit par des commutateurs, avant toute connexion.

• Le Model Context Protocol est un protocole ouvert dont la révision de référence date du 28 juillet 2026
• Une boutique PrestaShop se connecte par un transport HTTP
• PrestaShop publie un module officiel de serveur MCP, protégé par le compte PrestaShop
• La lecture seule tient au rôle de lecture du module
• Le module expose par défaut produits, images, commandes et clients, réductibles par commutateur
• Le module documente des journaux de débogage, sans limite de débit ni journal d’audit
• Quatre points d’hébergement peuvent bloquer la connexion
• Un serveur MCP maison déplace l’authentification chez le marchand
• Attendre ou renoncer reste raisonnable tant que le besoin n’est pas écrit
• Sources consultées
• Foire aux questions

Le Model Context Protocol est un protocole ouvert dont la révision de référence date du 28 juillet 2026

Le Model Context Protocol (MCP) est un protocole ouvert ; le site du protocole désigne par « latest » la révision 2026-07-28. Il standardise la connexion entre une application d’IA et des données ou des outils externes. Trois acteurs échangent des messages JSON-RPC (appels de procédure à distance codés en JSON) : l’hôte (l’application d’IA), le client (le connecteur intégré à l’hôte) et le serveur (ici, la boutique). Le serveur peut offrir des ressources (données lisibles), des prompts (modèles de messages) et des outils (fonctions que le modèle exécute).

Le tableau situe les révisions qui comptent pour une boutique.

Un client qui ne parle que l’ancien protocole échoue face à un serveur limité à la révision 2026-07-28 ; un serveur peut, s’il le choisit, servir les deux ères.

Une boutique PrestaShop se connecte par un transport HTTP

Le module PrestaShop utilise Streamable HTTP, l’un des deux transports standards de la spécification. Chaque message du client y est une requête POST vers une adresse unique du serveur. L’autre, stdio, échange des messages sur les flux standard d’un sous-processus que le client lance. Selon la page de connexion de PrestaShop, la plupart des dix applications qu’elle liste acceptent Streamable HTTP avec OAuth (norme d’autorisation par jeton), méthode du module.

L’autorisation est facultative dans la spécification. Quand un serveur HTTP la prend en charge, elle suit OAuth 2.1 : le serveur publie des métadonnées de ressource protégée, vérifie que le jeton lui est destiné, et n’accepte aucun jeton dans l’adresse de la requête. Pour Streamable HTTP, la spécification impose de valider l’en-tête « Origin » (l’origine déclarée de la requête) de chaque connexion et de refuser (HTTP 403) une origine invalide, contre le détournement de DNS. Elle recommande aussi d’authentifier toutes les connexions.

PrestaShop publie un module officiel de serveur MCP, protégé par le compte PrestaShop

Le module est développé par PrestaShop ; son seul fournisseur OAuth est le compte PrestaShop (PrestaShop Account). D’après un article d’E-commerce Nation du 19 novembre 2025, le module est gratuit, téléchargeable sur la Marketplace de PrestaShop et compatible avec la version 8 et les suivantes.

Le module dépend de PrestaShop Account (authentification), de PrestaShop EventBus (synchronisation de données) et de PrestaShop MCP Tools (les outils). La page « Installation » exige PrestaShop MBO (Marketplace in your Back Office), qui gère ces dépendances. L’API webservice de la boutique (accès programmatique) doit être activée : le module crée son propre jeton de webservice. L’adresse du serveur s’affiche dans la page de configuration, et l’application d’IA s’y connecte par OAuth.

Un jeton statique reste possible pour les applications sans OAuth ; la page « Security » le décrit comme moins sûr, car il n’expire pas seul.

Décrire mon besoin →

La lecture seule tient au rôle de lecture du module

Le module distingue deux rôles de membre. « Viewer » donne un accès en lecture seule : produits, commandes et clients s’interrogent sans rien modifier. « Editor » donne la lecture et l’écriture : la page « Introduction » liste la création et la mise à jour de produits, d’images et de clients, et la mise à jour de commandes. Par défaut, seuls les utilisateurs listés dans l’écran « Membres » (« Members ») peuvent se connecter. L’adresse de messagerie du jeton OAuth est comparée à cette liste ; les portées (permissions) demandées sont mcp.discover, mcp.read et mcp.write.

D’après la page « Security », le serveur applique les permissions de rôle à chaque requête. Cette garantie vient du module : la spécification, elle, traite les annotations d’outil, comme readOnlyHint, de simples indications que les clients doivent considérer comme non fiables sauf serveur de confiance. La documentation de développement de PrestaShop présente aussi ces indicateurs comme des repères pour le client.

Scénario : le dirigeant crée un membre « Viewer » avec une adresse dédiée, connecte un assistant, puis demande les commandes du jour. Si la liste revient, le rôle protège les écritures, pas la confidentialité.

Le module expose par défaut produits, images, commandes et clients, réductibles par commutateur

La page « Setup » écrit que PrestaShop MCP Tools fournit par défaut des outils pour les produits, les images, les commandes et les clients. La page « Introduction » détaille pour les clients la recherche, la liste des abonnés à la newsletter et les filtres par groupe ; pour les commandes, le détail des lignes, l’historique des statuts, le transporteur et les factures. Ce sont des données personnelles, ce qu’une lecture seule ne change pas.

Le périmètre se réduit avant la connexion. Dans l’écran « Modules & Fonctionnalités » (« Modules & Features »), décrit à la page « Setup », chaque module est une carte que l’on active ou désactive, et chaque fonction d’un module a son propre commutateur. Un module tiers compatible MCP ajoute ses outils à cette liste : chaque ajout se relit.

Le module documente des journaux de débogage, sans limite de débit ni journal d’audit

Le module écrit des journaux de débogage dans le dossier « .mcp/logs ». L’option « Journaux de Débogage » (« Debug Logs ») de l’écran « Options Développeur » (« Developer Options ») les active. La documentation « How to create my own MCP elements ? » nomme « Enable logs » le paramètre des fichiers de journaux du dossier .mcp. La spécification impose au serveur de contrôler les accès et de limiter le débit des appels d’outils. La documentation du module ne décrit ni limite de débit, ni journal d’audit des accès. La spécification recommande de journaliser l’usage des outils côté client : cette trace est celle de l’application d’IA, pas celle de la boutique.

Quatre points d’hébergement peuvent bloquer la connexion

La page de dépannage de PrestaShop liste quatre points d’hébergement. Le fichier .htaccess (réglages Apache du dossier du site) doit transmettre l’en-tête d’autorisation. Cloudflare (service intermédiaire) doit laisser passer les adresses « .well-known » (découverte OAuth). Le mode maintenance bloque l’accès externe. Le pare-feu doit admettre les agents utilisateurs des assistants, que la page énumère. Le durcissement du serveur lui-même se traite dans la mission durcissement du serveur.

Un serveur MCP maison déplace l’authentification chez le marchand

Une boutique peut aussi publier son propre serveur MCP. Le module officiel porte l’authentification, les rôles et la liste des membres ; un serveur maison les remplace par du code à écrire et à maintenir. La spécification n’impose pas l’autorisation : un serveur sans authentification reste conforme au protocole et ouvert à toute personne qui connaît son adresse.

Le périmètre « catalogue seul » s’écrit alors dans le code du serveur : les outils offerts, les champs renvoyés, les quotas.

Décrire mon besoin →

Attendre ou renoncer reste raisonnable tant que le besoin n’est pas écrit

Une boutique qui ne sait pas quelle question un assistant poserait à son catalogue n’a rien à connecter. Le catalogue lisible par un humain et par les robots publics se travaille sans MCP : voir la mission lisibilité du catalogue. Par défaut, seuls les membres listés se connectent ; l’option verrouillée « Désactiver l’Authentification » (« Disable Authentication »), réservée aux tests locaux, supprime cette barrière.

La connexion se justifie pour un usage interne : un responsable e-commerce qui interroge le back-office en langage naturel. Elle suppose un compte « Viewer » et un périmètre écrit. Le paiement par un agent relève d’un autre protocole : voir la mission Agentic Commerce Protocol.

Une dernière raison d’attendre : la révision 2026-07-28 retire les sessions et la poignée de main initiale, et la documentation du module ne dit pas quelle révision il vise.

Les relevés se notent dans le message du formulaire de cette page ; la connexion elle-même reste à faire dans votre back-office.

Sources consultées

• Model Context Protocol, spécification révision 2026-07-28, pages « Specification », « Transports », « Streamable HTTP » et « Authorization », consultée le 14 octobre 2026.
• Model Context Protocol, spécification révision 2026-07-28, pages « Tools », « Resources », « Key Changes » et « Versioning and Compatibility », consultée le 14 octobre 2026.
• PrestaShop, documentation « MCP Server » : pages « Introduction », « Installation », « Setup », « Security », « Connect your AI application » et « Troubleshooting », consultée les 14 et 15 octobre 2026.
• PrestaShop, documentation « MCP Server », section « MCP Overview », page de création d’éléments MCP, consultée les 14 et 15 octobre 2026.
• E-commerce Nation, « PrestaShop dévoile son serveur MCP : une révolution vers le commerce piloté par l’IA », 19 novembre 2025, consulté le 14 octobre 2026.

Foire aux questions

Le serveur MCP remplace-t-il l’API de PrestaShop ?

Non. La documentation du module écrit que ses outils reposent sur le système de webservices de PrestaShop, qui doit être activé, et que le module crée son propre jeton de webservice. D’après cette description, le serveur MCP est une couche d’accès pour assistants, posée sur l’interface existante.

Un assistant peut-il passer commande avec ce module ?

La page « Introduction » décrit, pour les commandes, la liste, la recherche et la mise à jour, sans création de commande ni paiement. Le paiement par un agent relève de protocoles de commerce, dont le protocole ACP d’OpenAI et de Stripe.

Quels assistants la documentation cite-t-elle ?

La page de connexion nomme ChatGPT, Claude Desktop, Le Chat, Dust, Claude Code, Gemini CLI, GitHub Copilot CLI, Cursor, Windsurf et VS Code. Claude Code et Gemini CLI, par exemple, demandent de fixer les portées mcp.discover, mcp.read, mcp.write et email.

Un module tiers peut-il ajouter ses outils ?

Oui. Un module se déclare compatible par une méthode « isMcpCompliant » dans sa classe principale, et ses outils, ressources et prompts se déclarent par des attributs PHP dans son dossier « src ». Ils apparaissent ensuite dans la liste des outils exposés.

Un serveur MCP rend-il la boutique visible dans les réponses publiques des assistants ?

Non. Par défaut, seuls les membres listés se connectent, et l’option qui désactive l’authentification est verrouillée et réservée aux tests locaux : le module ne sert pas de canal public. La visibilité dans les réponses des assistants dépend des robots d’exploration et de l’indexation, un autre sujet.