Expertise PrestaShop

Conseils techniques e-commerce et PrestaShop

Une question ? Contactez Les Vikings

PrestaShop MCP Server : installer le module et activer les webservices

Tutoriel complet pour installer le module MCP Server, activer et cloisonner les webservices (/api), tester avec curl et sécuriser l’endpoint avant migration vers l’Admin API.

Kévin DECQ-CAILLET

|

|

Mis à jour le Lecture : 12 min

Graphique montrant une interface d'installation et de gestion d'un serveur MCP de PrestaShop.

Table des matières :

  1. PrestaShop MCP Server : rôle du module et dépendance aux webservices
  2. Pré-requis d’installation : versions, HTTPS, droits fichiers et environnement de test
  3. Installer le module PrestaShop MCP Server : déploiement, cache et validation
  4. Activer les webservices PrestaShop et créer une clé API utilisable par MCP
  5. Hardening de l’endpoint /api : contrôle d’accès, rate limiting, logs
  6. Tester et dépanner : curl, codes HTTP, pièges Apache/Nginx/OVH
  7. Quand basculer vers l’Admin API : scopes, secrets, coexistence avec le Webservice

PrestaShop MCP Server : rôle du module et dépendance aux webservices

Le module PrestaShop MCP Server sert de “façade” entre une boutique et un client MCP (typiquement un agent IA). Dans l’écosystème MCP, le serveur expose des tools (fonctions) et des schémas de données ; le client les appelle, et le serveur traduit ces appels en opérations concrètes côté boutique (lecture catalogue, recherche, création de panier, récupération de commandes, etc.). La doc officielle résume bien l’idée : « MCP is an open protocol that standardizes how applications provide context to LLMs. » (Model Context Protocol, documentation : https://modelcontextprotocol.io/).

Sur PrestaShop, ce module s’appuie généralement sur l’API HTTP existante la plus disponible “out of the box” : le Webservice (/api). C’est une API REST historique qui expose les ressources CRUD (products, categories, orders, customers…). Le module MCP Server évite d’ouvrir directement votre base ou vos objets métier ; il se contente de requêter le Webservice avec une clé API et de normaliser la réponse pour le client MCP.

Concrètement, le module joue souvent trois rôles “pratiques” côté intégration :

  • Traduction fonctionnelle : un tool “rechercher un produit” devient un appel GET /api/products + filtres + mapping des champs pertinents (nom, prix, stock, URL, image).
  • Normalisation des données : le Webservice renvoie du XML par défaut, parfois des structures verbeuses ; le MCP Server peut ressortir un JSON plus “LLM-friendly” (champs plats, libellés explicites).
  • Garde-fous et ergonomie : selon l’implémentation, le serveur peut limiter des champs, imposer des display restreints, ou refuser certains appels (par exemple empêcher une lecture de données clients si le tool n’est pas explicitement prévu).

Mini-scénario (très réaliste en support e-commerce) : un agent IA connecté via MCP reçoit une question “où en est ma commande ?”. Il appelle un tool “récupérer commande par référence” → le MCP Server interroge /api/orders (filtre sur reference) puis /api/order_details et renvoie un résumé : état, transporteur, derniers mouvements, et éventuellement un lien BO (si vous l’autorisez). Ce workflow est simple à démarrer… à condition que les webservices soient activés et correctement cloisonnés.

Le revers est connu : le Webservice PrestaShop est une brique legacy (authentification simple, permissions par ressource pas toujours fines, payloads parfois lourds, comportements hétérogènes selon les ressources). Si vous cherchez une vue d’ensemble du CRUD et des paramètres (display, filter, output_format), le plus utile à garder sous la main reste ce guide : API Webservice PrestaShop : guide CRUD et ressources développeur.

Pré-requis d’installation : versions, HTTPS, droits fichiers et environnement de test

Les étapes ci-dessous sont cohérentes pour PrestaShop 8.1/8.2/9.0–9.2 avec PHP 8.1 à 8.3 (en août 2026, PHP 8.3 est un choix réaliste pour PrestaShop 9). Avant de toucher à quoi que ce soit, vérifiez : accès Back Office, accès au filesystem (SFTP/SSH), et capacité à purger le cache (BO ou CLI). Si votre stack est floue (mutualisé, mod_rewrite, limites PHP), commencez par stabiliser l’infra : PrestaShop auto-hébergé : prérequis d’installation, maintenance et sécurité.

Pour éviter les installations “qui marchent sur mon poste”, gardez une checklist courte avant d’ajouter un module qui va s’appuyer sur une surface API :

  • Version & compatibilité : version exacte PrestaShop, version PHP, extensions activées (cURL, OpenSSL), mémoire et temps d’exécution.
  • Cache & compilation (surtout PrestaShop 9) : capacité à régénérer le cache Symfony sans erreur.
  • Droits fichiers : /modules, /var, /cache et /img accessibles en écriture selon les opérations du module.
  • Staging : un environnement de test fidèle, et idéalement des données anonymisées (important si vous avez des clients UE/France et que vos logs/exports peuvent contenir des données personnelles).

Exposez /api uniquement derrière HTTPS. PrestaShop Webservice utilise une variante de HTTP Basic Auth (clé API en “username”). Le RFC rappelle explicitement le risque : « This scheme is not considered to be a secure method of user authentication unless used in conjunction with some external secure system such as TLS (…) » (RFC 7617, “The ‘Basic’ HTTP Authentication Scheme” : https://www.rfc-editor.org/rfc/rfc7617). En clair : pas de TLS, pas de Webservice exposé.

Enfin, ne faites pas ça en prod “au feeling”. Installez/validez d’abord sur un environnement de staging fidèle (même PHP, même MariaDB, mêmes modules) : Staging PrestaShop : créer un environnement Docker fidèle à la production. Et prenez un snapshot (fichiers + DB) avant d’installer un module qui va encourager l’ouverture d’une surface API.

Installer le module PrestaShop MCP Server : déploiement, cache et validation

Installation “standard” : BO → Gestionnaire de modules → Ajouter un nouveau module (upload du ZIP), puis Installer. Sur PrestaShop 9.x (Symfony 6.4), surveillez les erreurs au moment de la compilation du container (cache). Si vous avez une erreur 500 immédiatement après installation, ne perdez pas 30 minutes : activez le debug et cherchez l’exception racine. En dépannage rapide, ce type de checklist fait gagner du temps : Erreur 500 PrestaShop : 10 causes fréquentes et solutions rapides.

Deux points “terrain” à contrôler juste après l’installation :

  • Le module est-il activé et configurable ? Certains modules MCP exposent une page de configuration (URL du Webservice, clé, format, logs). Vérifiez aussi que la boutique peut atteindre son propre /api (problèmes DNS internes, reverse proxy, règles sortantes).
  • Le cache a-t-il bien été purgé ? Sur PrestaShop 9, une install/désinstall de module peut laisser un cache incohérent. Si vous déployez via pipeline, prévoyez une étape explicite de clear cache (BO ou CLI) avant de conclure à un bug du module.

Installation “filesystem” (utile en CI/CD, ou si le BO est bridé) : déposer le module dans /modules/<nom_du_module>/, puis déclencher l’installation depuis le BO. Vérifiez les droits Unix : un grand classique est un vendor/ non lisible après déploiement. Exemple (à adapter à votre user PHP-FPM/Apache) :

cd /var/www/prestashop
chown -R www-data:www-data modules
find modules -type d -exec chmod 755 {} \;
find modules -type f -exec chmod 644 {} \;

Avant de considérer l’installation “propre”, validez le module comme n’importe quel livrable PrestaShop. Si vous avez une pipeline, vous pouvez intégrer le Validator en terminal : ps-validator : intégration CI/CD du Validator PrestaShop en terminal. Le Validator ne prouve pas l’absence de bugs, mais il détecte des erreurs basiques (métadonnées, structure, fichiers interdits) qui cassent souvent l’installation.

Astuce CI/CD (simple mais efficace) : traitez l’installation comme un déploiement applicatif. Autrement dit, prévoyez au minimum (1) backup, (2) déploiement des fichiers, (3) purge cache, (4) test de santé sur /api et sur une page front, (5) rollback si 5xx.

Activer les webservices PrestaShop et créer une clé API utilisable par MCP

Activation : Paramètres avancés → Webservice → Activer le Webservice. Création de la clé : dans la même page, Ajouter une clé. Traitez-la comme un secret : stockage dans un vault, rotation, et interdiction de la coller dans un ticket/support. Concrètement, votre client MCP et votre module MCP Server vont réutiliser cette clé pour signer les requêtes vers /api. Techniquement, c’est du Basic Auth : l’API key est le “login”, le password est vide dans la plupart des implémentations.

Bonnes pratiques simples (qui évitent les fuites “bêtes”) :

  • 1 clé = 1 usage = 1 environnement : une clé pour staging, une autre pour prod ; une clé pour lecture, une autre (si nécessaire) pour écriture.
  • Rotation : planifiez une rotation (par exemple trimestrielle) et testez la procédure sur staging avant.
  • Traçabilité : nommez la clé de façon explicite (ex. mcp-staging-readonly, mcp-prod-readonly) pour comprendre rapidement l’impact d’une révocation.

Permissions : c’est ici que vous évitez l’accident industriel. La grille PrestaShop permet d’autoriser (GET/POST/PUT/DELETE) par ressource. Pour une intégration MCP “lecture + assistance”, partez sur du read-only (GET) et ouvrez ensuite au cas par cas. Exemple minimaliste (à adapter au périmètre de vos tools MCP) :

Ressource GET POST PUT DELETE Pourquoi
products, categories, images ✅ ❌ ❌ ❌ lecture catalogue, enrichissement contexte
stock_availables ✅ ❌ ❌ ❌ disponibilité (attention multiboutique)
customers ✅ ❌ ❌ ❌ support/CRM limité (PII !)
orders, order_details ✅ ❌ ❌ ❌ suivi commandes

Deux précisions importantes, souvent sous-estimées :

  • Données personnelles (RGPD) : dès que vous autorisez customers ou orders, vous manipulez des données identifiantes (noms, emails, adresses, IP selon logs). Même si votre usage est “support”, gardez une logique de minimisation : n’exposez que ce dont vos tools MCP ont besoin.
  • Performance : certaines ressources (ex. produits avec associations, commandes détaillées) peuvent devenir coûteuses si le client MCP fait du scraping involontaire. Pensez dès le départ à limiter les display, à paginer, et à cadrer les volumes.

Si vous devez autoriser l’écriture (ex. création de panier/commande), faites-le avec une clé distincte, dédiée à un environnement et à un usage, et documentez précisément quelles routes MCP déclenchent des POST/PUT. La règle de base (toujours valide, même en 2026) est celle de Saltzer & Schroeder : « Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job. » (“The Protection of Information in Computer Systems”, 1975 : https://web.mit.edu/Saltzer/www/publications/protection/).

Hardening de l’endpoint /api : contrôle d’accès, rate limiting, logs

Activer les webservices PrestaShop sans hardening revient à publier une API d’administration simplifiée sur Internet. Ce n’est pas “dangereux par principe”, c’est dangereux par défaut : Basic Auth, bruteforce de clé, enumeration de ressources, scraping massif, et surtout exploitation d’un module vulnérable qui expose involontairement des données. Si vous construisez une posture globale (SBOM, WAF, CI), ce socle aide à cadrer : PrestaShop : sécuriser APIs et modules avec SBOM, WAF et CI/CD.

Côté reverse proxy (Nginx), appliquez au minimum : allowlist IP, rate limiting, et blocage explicite si la boutique n’en a pas besoin en continu. Exemple (schématique) :

# /etc/nginx/conf.d/prestashop.conf
limit_req_zone $binary_remote_addr zone=ps_api:10m rate=5r/s;

server {
  # ... TLS etc.

  location /api/ {
    # 1) limiter aux IP de votre MCP client / serveur d’orchestration
    allow 203.0.113.10;  # exemple
    deny all;

    # 2) limiter le débit
    limit_req zone=ps_api burst=20 nodelay;

    # 3) logs dédiés
    access_log /var/log/nginx/prestashop_api.access.log;
    error_log  /var/log/nginx/prestashop_api.error.log warn;

    try_files $uri /index.php$is_args$args;
  }
}

Pour rendre ces réglages actionnables, voici des ordres de grandeur “raisonnables” (à ajuster selon votre trafic et vos tools MCP) :

  • Lecture catalogue : 1–5 req/s par IP avec un burst limité (10–30).
  • Points de terminaison sensibles (commandes/clients) : encore plus strict, et idéalement restreints à une IP d’orchestrateur.
  • Fenêtres de maintenance : si votre MCP est utilisé uniquement en journée, vous pouvez aussi limiter l’accès par créneaux (via firewall/WAF), surtout en B2B.

Ajoutez de l’observabilité : taux de 401/403, latence, 5xx, volumétrie par IP, et alerting sur pics. Si vous n’avez pas déjà une stack de metrics, Netdata est un moyen rapide d’avoir de la visibilité (CPU, PHP-FPM, MySQL, Nginx) : Netdata : intégrer Prometheus, SNMP et StatsD pour tout surveiller. Et rappelez l’évidence : si TLS/redirect HTTPS est mal géré, vous cassez à la fois sécurité et intégration ; ce guide permet de cadrer les points SEO + infra : HTTPS SEO : bonnes pratiques, certificats SSL et audit technique.

Enfin, côté logs : séparer les logs /api est utile (diagnostic, traçabilité), mais attention à la rétention et à l’accès. Une IP, un identifiant de clé, ou un user-agent peuvent entrer dans un cadre “donnée personnelle” selon le contexte : définissez une durée de conservation et un périmètre d’accès (ops/sécu), surtout si vous opérez en France/UE.

Tester et dépanner : curl, codes HTTP, pièges Apache/Nginx/OVH

Test minimal (GET) : vous devez obtenir un 200 avec une payload (XML ou JSON selon config). PrestaShop Webservice répond en XML par défaut ; en pratique, JSON est plus simple à consommer côté MCP. Exemple curl (JSON) :

API_KEY="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
SHOP_URL="https://boutique.example.com"

curl -i \
  -u "$API_KEY:" \
  "$SHOP_URL/api/products?display=full&output_format=JSON&limit=0,1"

Avant même d’analyser la payload, validez ces signaux :

  • 200 OK : la clé + permissions + routage sont bons.
  • 401 Unauthorized : auth refusée (ou header perdu).
  • 403 Forbidden : accès bloqué (ACL/WAF/rate limit) ou ressource non autorisée.
  • 404 Not Found : routage /api cassé (rewrite/try_files).
  • 429 Too Many Requests : rate limiting (souvent voulu, mais à calibrer).
  • 500/502/503 : bug serveur (PHP-FPM, cache, module) ou timeout.

Si vous prenez 401 Unauthorized, c’est quasi toujours : clé invalide, Webservice désactivé, ou header Authorization supprimé par un proxy/CDN/WAF (ça arrive). Un symptôme typique : “ça marche en local, ça ne marche plus derrière le CDN”. Dans ce cas, testez sans CDN/WAF (en ciblant l’IP directe si possible) pour isoler la cause.

Un 403 Forbidden pointe plutôt vers une restriction serveur (allowlist, règle WAF, ACL) ou une ressource non autorisée dans la grille de permissions. Pour traiter un 403 proprement côté infra, cette check-list est applicable sans dépendre de PrestaShop : Erreur 403 Forbidden : causes et dépannage étape par étape.

Les erreurs les plus coûteuses en temps sont les 404/500 “silencieuses” liées au routage : .htaccess non généré, mod_rewrite off, règle Nginx incomplète (try_files), ou cache Symfony incohérent après déploiement. Sur OVH mutualisé, le combo mauvaise version PHP + mode d’exécution produit des symptômes trompeurs (API qui marche en BO mais pas via /api). Si la boutique devient lente après activation (scraping API, pics de GET), ne regardez pas uniquement PHP : un Webservice peut déclencher des requêtes lourdes (joins + objets), donc pensez à profiler côté base.

Point d’attention spécifique “perf” : des appels MCP mal cadrés peuvent demander display=full sur des listes larges (produits, commandes). Préférez des patterns du type :

  • limit=0,20 (pagination stricte)
  • display=[id,name,price] (champ ciblés)
  • filter[name]=%mot% ou filtres précis plutôt que du “full scan”

Pour une approche structurée des lenteurs et des requêtes, ce guide est un bon point de départ : Audit MySQL/MariaDB : optimiser les requêtes lentes e‑commerce.

Quand basculer vers l’Admin API : scopes, secrets, coexistence avec le Webservice

En 2026, sur PrestaShop 9.x, l’Admin API devient la voie “moderne” pour des intégrations plus industrialisées : modèle plus cohérent, meilleure structuration, et un cadre de sécurité généralement plus clair que le Webservice legacy (notamment sur la gestion des clients, des secrets et des périmètres d’accès). Si votre MCP Server doit faire de l’écriture (commandes, clients, stocks), c’est typiquement là que le Webservice commence à montrer ses limites (granularité, validation métier, compatibilité modules).

La coexistence est réaliste : gardez le Webservice pour ce qu’il fait bien (lecture simple et stable), et migrez les opérations sensibles vers l’Admin API (création/modification). Les points critiques à traiter sont le stockage du secret et la séparation par client/scopes : PrestaShop Admin API : sécuriser secret et scopes par client. Pour le dev, avoir un environnement Docker + Swagger vous évite de “deviner” les schémas : PrestaShop Admin API : environnement de développement Docker et Swagger.

Un bon critère de bascule (pragmatique) :

  • Webservice OK : catalogue, catégories, images, stocks en lecture, récupération “simple” d’informations de commande pour le support.
  • Admin API recommandée : opérations d’écriture, workflows qui doivent respecter les règles métier (statuts, retours, remboursements), ou besoin de sécurité fine par client (droits/scopes), surtout si plusieurs consommateurs (IA, ERP, PIM, helpdesk) coexistent.

Enfin, si votre besoin MCP touche au modèle de données (champs custom, enrichissement d’entités), l’Admin API va plus vite à industrialiser que des contournements via overrides ou tables annexes. PrestaShop 9.2 introduit des mécanismes natifs qui simplifient ce genre de cas : PrestaShop 9.2 : Extra Properties, champs personnalisés natifs via Admin API. En pratique, la trajectoire la plus saine est : MCP Server + Webservice en lecture, puis Admin API pour l’écriture, avec un hardening réseau strict dans les deux cas.

À lire aussi