Un serveur MCP peut donner à un assistant IA des outils pour interroger une boutique PrestaShop. Ce n’est pas un raccourci pour brancher une clé API d’administration dans Claude ou dans un agent autonome : c’est une couche de contrôle à concevoir. Une erreur de permission peut exposer des clients, modifier un stock ou déclencher des actions irréversibles.
Ce guide explique une approche prudente : commencer en lecture seule, limiter les données retournées, journaliser chaque appel et n’autoriser une écriture qu’après validation humaine.
MCP et API PrestaShop : deux rôles différents
Le Model Context Protocol définit la manière dont un client IA découvre et appelle des outils. Il ne remplace ni l’API ni les règles métiers de PrestaShop. Dans cette architecture :
- l’API Webservice de PrestaShop reste la source d’accès aux données de la boutique ;
- le serveur MCP expose seulement des outils précis, par exemple
rechercher_produitoulister_ruptures; - l’agent IA formule une intention, mais le serveur MCP contrôle les paramètres, permissions et validations ;
- le marchand conserve la décision finale pour toute opération sensible.
L’API Webservice de PrestaShop est une API CRUD. Une clé peut recevoir des droits distincts par ressource et par méthode. La documentation officielle insiste sur le principe de moindre privilège : ne donnez jamais tous les droits à une clé destinée à un outil tiers. Créer une clé Webservice avec permissions.
Cas d’usage qui ont du sens
Un premier serveur MCP doit résoudre une tâche concrète, sans automatiser toute l’administration de la boutique.
Lecture catalogue et contrôle qualité
Des outils en lecture seule peuvent répondre à des questions comme :
- quels produits actifs n’ont pas de description courte ;
- quels produits sont en rupture avec des commandes récentes ;
- quelles fiches ont une image principale sans légende ;
- quelles catégories comportent des produits désactivés.
Le bénéfice vient de la synthèse et de la priorisation. L’IA ne doit pas être utilisée comme source de vérité : elle reçoit les données filtrées par l’API et sa réponse doit rester vérifiable dans le back-office.
Préparer, puis faire valider une action
Pour modifier un titre, une description ou un stock, le bon flux est :
- l’agent prépare une proposition structurée ;
- un humain la relit dans le back-office ou une interface de validation ;
- une action explicite exécute la modification ;
- le serveur journalise l’identité, les données avant/après et le résultat.
N’accordez pas de droit PUT, PATCH ou DELETE à un assistant simplement parce qu’il sait enchaîner plusieurs étapes.
Architecture minimale et sûre
Un déploiement raisonnable sépare la boutique, le serveur MCP et les secrets :
Client IA
│ OAuth / jeton de session
▼
Serveur MCP ── journal d'audit ── validation humaine
│ clé Webservice limitée
▼
API PrestaShop /api/ ── boutiquePour un serveur HTTP exposé à des clients externes, la spécification MCP s’appuie sur OAuth 2.1 et sur la découverte des métadonnées de ressource protégée. Ce n’est pas un détail d’implémentation : c’est ce qui évite qu’un jeton destiné à un service soit réutilisé ailleurs. Spécification d’autorisation MCP.
Permissions à accorder au départ
Créez une clé distincte, nommée par exemple mcp-audit-catalogue, puis limitez-la :
| Besoin | Permission conseillée | À éviter au départ |
|---|---|---|
| Audit des produits | GET sur produits et catégories nécessaires | modification de produit |
| Contrôle de stock | GET sur les ressources strictement requises | mise à jour automatique du stock |
| Analyse de commandes | données agrégées ou anonymisées | exposition de données clients à l’agent |
| Rédaction assistée | aucune écriture API, export contrôlé | PUT direct sur les fiches |
N’intégrez jamais une clé dans un fichier versionné, une capture ou une configuration de poste partagée. Utilisez des variables d’environnement ou un gestionnaire de secrets.
Le même principe vaut sur les autres CMS. WooCommerce 11.3 en donne un exemple : son ancien point d’accès MCP, protégé par une clé d’API, disparaît au profit de l’adaptateur MCP de WordPress, avec un mot de passe d’application rattaché à un utilisateur aux droits limités. Dans nos essais sur la préversion, un compte qui peut modifier des produits mais pas les publier est bien refusé à la publication : voir notre test de WooCommerce 11.3.
Exemple d’outils à exposer
Le serveur MCP doit proposer des outils étroits, avec un schéma de paramètres et des limites. Cette granularité est plus sûre qu’un outil générique du type « exécute une requête API ».
rechercher_produits_sans_legende(langue, limite=50)
lister_produits_en_rupture(categorie_id, limite=50)
preparer_mise_a_jour_description(produit_id, brouillon)Le troisième outil ne doit pas modifier PrestaShop. Il renvoie un brouillon et une comparaison avant/après à valider. Une opération d’écriture distincte pourra exiger une approbation explicite et une permission dédiée.
Mise en œuvre par étapes
1. Créer une clé de test en lecture seule
Dans Paramètres avancés → Webservice, activez le Webservice, créez une clé dédiée et sélectionnez uniquement les ressources nécessaires. Testez-la d’abord contre un environnement de préproduction. La documentation PrestaShop indique que le Webservice est désactivé par défaut et que les permissions doivent être réglées ressource par ressource. Guide de démarrage Webservice.
2. Tester des requêtes simples sans données personnelles
Validez que le serveur MCP peut seulement lire les champs prévus. Pour un inventaire catalogue, ne demandez pas les clients, adresses, mots de passe ou détails de paiement. Conservez une limite de résultats et un délai d’expiration court pour les jetons.
3. Ajouter le journal d’audit
Pour chaque appel, conservez au minimum : l’outil utilisé, la date, l’identité ayant autorisé l’action, les identifiants de ressources concernés et le résultat. Évitez de mettre des données personnelles ou des secrets dans les logs.
4. Ouvrir les écritures une par une
Une écriture doit être justifiée par un cas d’usage, protégée par une approbation humaine et réversible. Commencez par une préproduction. Une synchronisation automatique de catalogue ou de stock sans garde-fou n’est pas un bon premier projet MCP.
Checklist avant mise en production
- Une clé API séparée existe pour le serveur MCP.
- Les permissions sont limitées aux ressources et méthodes nécessaires.
- La première version ne fait que de la lecture.
- Les données clients ne sont pas envoyées inutilement à un modèle externe.
- Les écritures requièrent une validation humaine et sont journalisées.
- Les secrets sont stockés hors du dépôt et peuvent être révoqués.
- Le serveur est testé sur une boutique de préproduction.
Questions fréquentes
MCP remplace-t-il l’API Webservice de PrestaShop ?
Non. MCP normalise l’appel d’outils par un client IA ; l’API Webservice reste l’interface qui accède aux données de la boutique. Le serveur MCP doit réduire et contrôler cette surface d’accès.
Peut-on connecter directement une clé Webservice à un assistant IA ?
Ce n’est pas recommandé. Une clé Webservice peut donner accès à des ressources sensibles. Un serveur intermédiaire permet de filtrer les outils, de limiter les droits et de demander une validation avant une écriture.
Quelle est la première automatisation utile ?
Un audit catalogue en lecture seule: images sans légende, attributs manquants, produits en rupture ou descriptions incomplètes. Il produit une liste vérifiable sans prendre de décision à la place du marchand.
Pour poursuivre
- Optimiser les balises ALT des images PrestaShop
- Activer le mode debug PrestaShop sans exposer sa boutique
- Optimiser le SEO de votre boutique PrestaShop
