Remplacer MCP Tools Plus avec ps-proxy : une architecture analytique plus fiable
Dans mon précédent article, je racontais comment j’avais connecté Claude à PrestaShop via MCP pour automatiser mes rapports de ventes, et notamment comment le module MCP Tools Plus avait fini par être correctement activé sur mon installation multi-boutique. Depuis, ce module a tout simplement disparu. Plutôt que de lui chercher un remplaçant équivalent, j’ai préféré repenser l’ensemble : sa disparition a surtout mis en évidence un problème plus profond, à savoir qu’un connecteur générique ne suffit pas dès qu’on veut produire des analyses fiables, multi-boutiques et réellement exploitables.
La solution que j’ai mise en place avec ps-proxy n’est donc pas un simple remplacement fonctionnel, mais une architecture plus robuste, articulée entre un proxy sécurisé, un skill Python partagé et le MCP PrestaShop natif. Je tiens à le préciser tout de suite : je ne cherche pas à remplacer le MCP PrestaShop. Je continue de m’appuyer sur lui pour certaines récupérations standards, en particulier pour mieux cadrer la séparation de mes boutiques, et je complète ses limites avec des ressources supplémentaires et une couche d’intelligence métier centralisée dans une compétence (« skill ») pour Claude.
Pourquoi un simple connecteur ne suffisait plus
L’API WebService de PrestaShop est riche, mais elle reste brute, hétérogène et peu confortable à exposer directement à des outils métiers. Dans mon contexte (une boutique FR et une boutique DE sur la même installation), cette rugosité technique devient vite un risque pour la fiabilité de mes analyses dès qu’il faut manipuler des prix d’achat, des avoirs, des lignes de commande ou des consolidations par marque.
Le retrait de MCP Tools Plus a joué le rôle de révélateur. De nouveaux défis pratiques s’étaient aussi accumulés : maintenir à jour des fichiers Excel de suivi des prix était devenu laborieux et source d’erreurs, faute d’un accès direct et fiable aux données tarifaires. Je ne voulais donc pas seulement retrouver des appels équivalents, mais je devais reconstruire une chaîne de travail capable de sécuriser l’accès aux données, d’éviter les dérives entre mes projets et de transformer des ressources brutes en fonctions analytiques directement réutilisables.
Le rôle réel de ps-proxy
ps-proxy est un worker hébergé sur Cloudflare que j’ai développé comme couche d’accès sécurisée, en lecture seule, entre mes outils et l’API WebService de PrestaShop. En pratique, il me donne accès aux ressources que le MCP PrestaShop natif ne fournit pas : avoirs, prix catalogue et remisés déjà calculés (HT et TTC), lignes de commande détaillées, données de stock et grilles de frais de port. Son rôle est volontairement limité : il n’expose que des ressources autorisées via une liste blanche (produits et déclinaisons, prix spécifiques, commandes et avoirs, données de stock, transporteurs et grilles de frais de port, règles de TVA), filtre les données sensibles, impose une authentification par token nominatif et ne répond qu’à des requêtes en lecture. Aucune écriture n’est possible par ce biais.
Cette sobriété n’est pas une faiblesse, c’est un choix d’architecture. Le proxy ne produit aucun rapport métier pré-agrégé : ni calcul de marge, ni synthèse business, ni interprétation. En restant simple, il demeure plus sûr, plus stable et plus facile à faire évoluer sans risquer de casser la logique métier.
La compétence Claude (Skill) comme cœur du système
La vraie brique produit, c’est ce skill partagé. Ce module Python centralise toute l’intelligence métier et me sert de source unique de vérité pour mes analyses PrestaShop, avec une règle que je m’impose : ne jamais en garder de copies locales dans les projets, pour éviter tout décalage entre versions. Le skill est stocké directement dans Claude, au niveau de mon organisation, et tous mes projets y accèdent automatiquement. Concrètement, si j’ajoute une fonctionnalité ou corrige un comportement, je n’interviens qu’à un seul endroit et tous les projets en bénéficient immédiatement, sans aucune mise à jour à propager. Sans cette discipline, j’aurais autant de copies divergentes que de projets actifs : chaque évolution demanderait autant de mises à jour manuelles, et l’ensemble deviendrait rapidement ingérable.
C’est ce skill qui transforme le proxy brut en boîte à outils analytique. Il expose des fonctions prêtes à l’emploi pour les avoirs, la performance produit, la rentabilité par commande, les prix catalogue et remisés (déjà calculés en HT, TVA et TTC), les noms de transporteurs, les fiches produit complètes, la grille de frais de port et l’agrégation locale de certains frais. Autrement dit, le proxy ouvre l’accès aux données, mais c’est le skill qui les rend réellement utiles.
Une architecture complémentaire au MCP PrestaShop
Toute mon approche tient dans cette complémentarité. Le MCP PrestaShop natif reste pertinent pour les accès standards et pour certaines récupérations mieux cadrées côté boutique, notamment les commandes récentes que j’utilise ensuite comme base de scoping. Le couple ps-proxy + skill intervient là où il manque des ressources, des calculs, des normalisations ou des fonctions d’analyse prêtes à l’emploi.
Cette répartition des rôles m’évite deux erreurs classiques. La première serait de vouloir tout faire dans le proxy, au prix d’une couche serveur fragile et trop chargée. La seconde serait d’abandonner les outils natifs alors qu’ils restent utiles pour certaines opérations de cadrage, en particulier sur le périmètre multi-boutiques.
| Brique | Rôle principal | Ce qu’elle apporte |
| MCP PrestaShop | Accès standard à certaines données et récupération cadrée des commandes | Un socle utile pour les cas simples et le scoping initial par boutique. |
| ps-proxy | Exposition sécurisée de ressources brutes en lecture seule | Allowlist, filtrage PII, tokens nominatifs, rate limiting. |
| Skill | Intelligence métier et fonctions analytiques réutilisables | Calculs, agrégations, enrichissements et source unique de vérité partagée. |
Les apprentissages qui donnent de la valeur
La valeur de ce projet ne vient pas seulement de la technique, mais des contraintes réelles que j’ai dû absorber dans le skill. L’exemple le plus parlant concerne la séparation des boutiques : certaines ressources, comme les avoirs ou les lignes de commande, ne sont pas réellement cloisonnées par boutique au niveau attendu. Si je m’appuie sur une simple plage d’identifiants au lieu de la liste exacte des commandes du bon périmètre, les données FR et DE se mélangent, et l’écart n’a rien d’anecdotique : lors de mes tests, un indicateur consolidé par marque pouvait ressortir près de dix-huit fois trop élevé. La parade que j’applique systématiquement est de repartir des identifiants de commandes du bon périmètre, puis d’effectuer le découpage côté Python.
J’ai aussi appris à valider empiriquement la logique de filtrage plutôt que de la supposer. Et c’est sans doute là que réside le vrai savoir-faire : pas seulement dans le code, mais dans la compréhension des limites réelles de l’API et dans les garde-fous que j’ajoute pour produire des chiffres fiables.
Trois usages qui rendent l'architecture concrète
Le premier, c’est le reporting analytique. Le skill agrège les données pour me produire des lectures directement actionnables : chiffre d’affaires et marge par marque, performance par fabricant, rentabilité par commande ou comparaisons entre la boutique FR et la boutique DE. Cette couche analytique unifiée m’évite de recoder la même logique à chaque nouveau rapport.
Le deuxième, c’est Excel. Comme Claude dans Excel ne peut pas faire d’appels réseau directs, j’ai mis en place une macro VBA qui relaie les appels vers le proxy pour enrichir mes feuilles avec des informations comme les prix HT, TTC et les prix d’achat. J’exploite ainsi les données PrestaShop dans un environnement bureautique sans exposer directement l’API e-commerce.
Le troisième, c’est la migration depuis l’ancien module. J’ai documenté une table de correspondance : les anciennes fonctionnalités de MCP Tools Plus ont été redistribuées vers le skill, le proxy et le MCP natif selon les cas, avec des équivalences claires pour les avoirs, la performance produit, la rentabilité, les transporteurs et les prix. Ce n’est pas qu’une mise à jour technique : c’est un changement de modèle vers une architecture plus maintenable.
Pourquoi cette approche est plus durable
Une architecture de ce type est plus durable parce qu’elle sépare nettement trois responsabilités : accéder, sécuriser et interpréter. Le MCP reste utile là où il est déjà bon, le proxy reste sobre pour limiter les risques, et le skill concentre l’intelligence métier dans un composant versionné et partagé.
Pour un environnement PrestaShop qui évolue, je trouve cette organisation bien plus saine qu’un module monolithique (aujourd’hui disparu) ou qu’une accumulation de scripts dispersés. Elle me donne un point d’entrée analytique cohérent, tout en gardant la possibilité d’ajouter de nouveaux cas d’usage sans reconstruire tout le socle.