Sommaire
« Quels sont les produits en rupture et auprès de quels fournisseurs puis-on les commander ? »
RSS
Le RSS envoie les nouveaux articles dans le lecteur de votre choix, sans algorithme ni newsletter.
La question semble simple. Pourtant, pour y répondre correctement, l'assistant doit connaître les stocks, les déclinaisons et les fournisseurs associés aux produits. Il doit aussi comprendre ce que le marchand attend : une liste exploitable pour préparer son réapprovisionnement.
Depuis l'arrivée d'Ask AI dans PrestaShop, on vois des réactions partagées. Certains y voient une aide pour gérer leur boutique, d'autres restent sur leur faim face aux résultats obtenus. Avant de conclure que l'outil est inutile, il y a une possibilité à regarder : lui donner accès à des outils adaptés à nos propres usages.
Dans cet article, on te propose de poser les bases d'un module « Super Pouvoirs » capable d'identifier les produits en rupture et leurs fournisseurs. Nous verrons ensuite comment prolonger l'idée avec un rapport PDF de réapprovisionnement.
À retenir : un outil MCP expose une fonction à un assistant IA. Il ne garantit pas que celui-ci l'utilisera correctement à chaque demande. La qualité du résultat dépend aussi du code, des données et du client utilisé.
Ask AI, MCP et les modules : qui fait quoi ?
Ask AI est l'interface avec laquelle le marchand échange. Le serveur MCP PrestaShop sert de passerelle vers les fonctionnalités exposées à une application IA. Les modules compatibles peuvent, quant à eux, déclarer leurs propres outils.
Concrètement, un outil est une fonction à laquelle on donne un nom, une description et, si nécessaire, des paramètres. L'assistant peut la sélectionner pour répondre à une demande. La fonction exécute ensuite son code PHP et renvoie un résultat.
Le parcours ressemble à ceci :
- Le marchand demande les produits en rupture.
- L'assistant identifie un outil disponible qui correspond à cette demande.
- Le serveur MCP appelle le code du module.
- Le module récupère les informations et les renvoie.
- L'assistant présente le résultat au marchand.
La documentation officielle permet aux modules de se déclarer compatibles MCP et d'exposer leurs propres outils. Attention toutefois : un outil découvert par le serveur ne sera pas nécessairement visible ou utilisé par tous les clients IA dans toutes les configurations. La visibilité et l'appel effectif depuis Ask AI doivent être vérifiés sur l'installation utilisée.
Les outils standards savent déjà consulter certaines données de stock et de catalogue. Notre intérêt ici est de créer une fonction métier ciblée qui rassemble les ruptures et les informations fournisseurs dans un résultat adapté au réapprovisionnement. La liste des capacités standard permet de voir ce qui est déjà disponible.
Avant de coder : les prérequis
Le centre d'aide indique que PrestaShop MCP Server nécessite PrestaShop 8.2 ou supérieur, ou PrestaShop 9. De son côté, PrestaShop 9 exige PHP 8.1 au minimum.
Pour cet exemple, on me place donc dans le cadre suivant :
- Une boutique de développement ou de préproduction sous PrestaShop 9, avec une version de PHP prise en charge par la version exacte de PrestaShop installée.
- Les modules PrestaShop MCP Server et ses dépendances installés et configurés, conformément à la documentation d'installation.
- Des produits, des stocks et des fournisseurs renseignés pour pouvoir vérifier les résultats.
- Un client MCP connecté pour tester l'outil, puis Ask AI si son accès aux outils personnalisés est disponible dans la configuration retenue.
Important : les extraits qui suivent expliquent le mécanisme. Ils ne constituent pas un module complet testé sur une combinaison précise de versions et ne doivent pas être copiés en production sans adaptation et validation. La version minimale d'Ask AI et la version exacte du SDK embarqué dans MCP Server doivent être vérifiées pour la version installée.
Le serveur MCP est en PHP ?
Oui : dans cette architecture, le serveur MCP de PrestaShop est fourni par un module et les outils personnalisés sont déclarés en PHP. La documentation référence le SDK PHP officiel du Model Context Protocol parmi ses dépendances.
Le SDK aide à gérer les aspects du protocole. De ton côté, tu écris la fonctionnalité métier : quelles données récupérer, quels paramètres accepter et quel résultat renvoyer. Tu n'as pas besoin de créer un serveur MCP distinct pour chaque module compatible.
Pour bénéficier de l'autocomplétion et de l'analyse statique, PrestaShop propose également des stubs à installer en dépendance de développement :
composer require --dev prestashop/ps-mcp-server-stubs
Ces stubs décrivent les classes pour les outils de développement. Ils ne remplacent pas le module MCP Server, qui fournit les véritables classes sur la boutique. Voir la documentation technique.
Notre module : un outil pour les ruptures
Le module « Super Pouvoirs » pourrait, à terme, regrouper plusieurs outils. Commençons avec un seul : list_out_of_stock_products.
Son rôle serait de renvoyer les produits et déclinaisons dont la quantité disponible est inférieure ou égale à zéro, avec leurs fournisseurs lorsqu'ils sont renseignés. On pourrait ensuite lui demander de limiter la recherche à un fournisseur donné.
Le résultat attendu ressemblerait à ceci :
| Produit | Déclinaison | Stock disponible | Fournisseur |
|---|---|---|---|
| T-shirt | Bleu / M | 0 | Fournisseur A |
| T-shirt | Noir / L | -2 | Fournisseur A |
| Sac | — | 0 | Non renseigné |
Ces données sont fictives. Une quantité négative doit rester visible : elle peut avoir une signification métier différente d'un stock simplement égal à zéro.
1. Déclarer le module compatible MCP
Dans la classe principale du module, la documentation demande d'ajouter cette méthode :
public function isMcpCompliant()
{
return true;
}
Cette déclaration indique au serveur que le module contient des éléments MCP à découvrir. Elle ne suffit pas à elle seule : il faut ensuite déclarer les outils dans le répertoire src/ du module ou dans l'un de ses sous-dossiers.
2. Déclarer l'outil
Voici la forme que pourrait prendre la déclaration, en reprenant les attributs documentés par PrestaShop :
<?php
use PrestaShop\Module\PsMcpServer\Server\Attributes\PsMcpSchema;
use PrestaShop\Module\PsMcpServer\Server\Attributes\PsMcpTool;
use PrestaShop\Module\PsMcpServer\Server\Attributes\PsMcpToolAnnotations;
class StockTools
{
#[PsMcpTool(
name: 'list_out_of_stock_products',
title: 'Lister les produits en rupture',
description: 'Liste les produits et déclinaisons en rupture avec leurs fournisseurs.',
annotations: new PsMcpToolAnnotations(
title: 'Lister les produits en rupture',
readOnlyHint: true,
destructiveHint: false,
idempotentHint: true,
openWorldHint: false,
),
)]
#[PsMcpSchema(
properties: [
'supplier_id' => [
'type' => 'integer',
'description' => 'Identifiant du fournisseur à filtrer.',
],
],
required: ['supplier_id'],
)]
public function listOutOfStockProducts(int $supplier_id): string
{
// À implémenter : récupérer les ruptures du fournisseur choisi,
// puis renvoyer un résultat structuré, par exemple en JSON.
throw new \LogicException('Recherche de stock non implémentée.');
}
}
Cet extrait illustre la déclaration ; il ne renvoie pas encore de produits. Dans cette première forme, l'identifiant du fournisseur est obligatoire. Pour lister tous les fournisseurs, il faudra adapter le schéma et la signature, ou proposer un outil distinct, puis vérifier le comportement avec le serveur installé.
La description est importante : elle aide le client IA à comprendre à quoi sert la fonction. Les annotations indiquent notamment que l'outil est censé être en lecture seule. Elles ne remplacent pas les contrôles d'accès ni une revue du code.
3. Récupérer les stocks et les fournisseurs
C'est ici que se trouve la partie métier. Le SQL permet de croiser les données, mais il faut définir précisément ce que l'on cherche avant d'écrire la requête.
La documentation PrestaShop sur le stock indique que StockAvailable est la source de référence pour les quantités disponibles, au niveau du produit ou de la déclinaison. Elle précise aussi que le stock peut dépendre de la boutique ou du groupe de boutiques.
La ressource fournisseurs de produits documente notamment les associations et références fournisseurs. Pour notre recherche, il faudra tenir compte des points suivants :
- Un produit peut avoir des déclinaisons : une taille peut être en rupture alors que les autres sont disponibles. Il faut éviter de compter deux fois une ligne de synthèse et ses déclinaisons.
- Un produit peut avoir plusieurs fournisseurs ou aucun. Filtrer par fournisseur et lister les produits sans fournisseur sont donc deux besoins distincts.
- En multiboutique, la sélection des lignes de stock doit respecter le contexte et le partage de stock configuré.
- Une grande boutique peut avoir beaucoup de résultats : une limite et une pagination évitent de tronquer silencieusement la réponse.
- Les noms et références dépendent des données renseignées ; une référence fournisseur absente doit être présentée comme telle.
Une requête SQL directe donne de la maîtrise, mais elle doit rester paramétrée, adaptée aux versions ciblées et testée sur des cas représentatifs. Elle ne doit pas accepter du SQL libre généré par l'assistant. Attention aussi aux personnalisations : PrestaShop prévoit notamment un hook permettant à des modules de modifier la quantité retournée. Selon la boutique, une lecture directe peut donc différer de la quantité exposée par une API PrestaShop.
Pour une implémentation complète, on partirais du boilerplate officiel, puis j'ajouterais un service dédié à la recherche de stock. La méthode MCP resterait courte : valider les paramètres, appeler le service et renvoyer un résultat structuré.
Et le rapport PDF ?
Une fois la recherche fiable, le prolongement naturel serait de demander :
« Prépare-moi un rapport des produits en rupture pour le fournisseur A. »
Le PDF pourrait reprendre la date du rapport, le fournisseur, les produits et déclinaisons concernés, leurs références fournisseur lorsqu'elles existent et le stock disponible. Ce document aiderait le marchand à préparer son réapprovisionnement.
En revanche, une rupture ne dit pas combien d'unités commander. Pour produire une proposition de commande pertinente, il faudrait que le marchand fournisse les quantités ou que le module applique une règle définie : objectif de stock, historique des ventes, délais fournisseur ou conditionnement, par exemple. Il faudrait aussi vérifier les prix et les données manquantes avant validation.
On distingue donc deux étapes : le rapport PDF, qui restitue les ruptures, puis une éventuelle proposition de bon de commande, avec des quantités et des prix à valider. Cela ne signifie pas qu'une commande fournisseur native a été créée dans PrestaShop ni qu'elle a été envoyée.
La génération du PDF, son stockage, son contrôle d'accès et sa remise au marchand restent à implémenter. Il faut aussi tester ce que le client IA sait réellement afficher : la présence d'un outil MCP ne garantit pas qu'Ask AI proposera directement un fichier téléchargeable. Un accès protégé depuis le back-office pourrait être une piste à étudier.
Comment vérifier que cela fonctionne ?
Avant d'évaluer la réponse de l'IA, il faut tester chaque maillon séparément :
- Installer et activer le module de développement, puis vérifier que MCP Server découvre son outil. Si nécessaire, consulter la configuration et la documentation de découverte du serveur.
- Appeler l'outil avec un client de test, par exemple MCP Inspector, et comparer les résultats avec le back-office.
- Tester un produit simple, plusieurs déclinaisons, un stock négatif, un produit sans fournisseur et un produit avec plusieurs fournisseurs. Ajouter les cas multiboutiques si la boutique les utilise.
- Vérifier que l'assistant voit l'outil, puis lui poser une question précise. Contrôler l'appel et les résultats plutôt que de se fier uniquement à la réponse formulée.
- Pour le PDF, vérifier le contenu, les droits d'accès et le parcours de téléchargement avec le client réellement utilisé.
Si l'outil répond correctement dans Inspector mais pas dans Ask AI, cela permet déjà d'isoler une partie du problème : il reste à examiner la visibilité de l'outil, le client ou sa configuration. Si les données renvoyées sont fausses, il faut d'abord corriger la logique métier.
Ce que cet exemple change
La valeur de ce module ne serait pas simplement de demander à une IA de lire du stock. Elle serait de transformer une opération que le marchand répète en un outil défini : identifier les ruptures, retrouver les fournisseurs et préparer un document exploitable.
Ask AI et le serveur MCP ouvrent une porte aux développeurs de modules. À nous de choisir ce que nous exposons, de définir les règles métier et de vérifier les résultats. C'est à cette condition qu'un « super-pouvoir » devient une fonctionnalité utile au quotidien.
