Un client, éditeur d’un configurateur de matériel professionnel vendu via WooCommerce, voulait qu’un assistant conversationnel interne puisse répondre à des questions comme « combien de références sont en rupture cette semaine » ou « quel est le délai moyen de traitement des commandes du mois ». Plutôt que de développer une intégration sur mesure entre un modèle de langage et l’API REST WooCommerce — ce qui suppose de réinventer, projet après projet, la même couche de traduction entre requêtes en langage naturel et appels API — nous avons choisi de construire un serveur MCP dédié.
Le Model Context Protocol, popularisé fin 2024 et largement adopté par l’écosystème des outils d’IA depuis 2025, standardise justement ce pont entre un agent et un système externe. Ce tutoriel montre la mise en place d’un premier serveur MCP en lecture au-dessus d’un catalogue WooCommerce ; la sécurisation approfondie de cet accès fait l’objet d’un article séparé.
Ce qu’un serveur MCP expose réellement
Un serveur MCP ne se contente pas de retransmettre l’API REST WooCommerce telle quelle à un modèle de langage. Il expose des outils (tools) précisément définis, chacun avec un nom, une description en langage naturel et un schéma d’entrée et de sortie typé. C’est cette description qui permet à l’agent de comprendre quand et comment appeler l’outil, sans avoir à deviner la structure d’une API REST générique.
{
"name": "rechercher_produits_rupture",
"description": "Retourne la liste des produits WooCommerce dont le stock est à zéro, avec leur référence et leur catégorie.",
"inputSchema": {
"type": "object",
"properties": {
"categorie": { "type": "string", "description": "Filtrer par catégorie (optionnel)" }
}
}
}Construire le serveur, étape par étape
- Choisir la bibliothèque MCP adaptée au langage du serveur : la plupart des implémentations WordPress s’appuient sur un serveur Node.js ou Python distinct, qui communique avec WooCommerce via l’API REST authentifiée par clé, plutôt que d’exécuter le protocole MCP directement en PHP à l’intérieur de WordPress.
- Définir un premier outil en lecture seule, volontairement limité, plutôt que d’exposer d’emblée l’ensemble du catalogue de points de terminaison disponibles.
- Créer une clé API WooCommerce dédiée, en lecture uniquement, réservée à ce serveur MCP — jamais la clé d’administration utilisée par ailleurs.
- Implémenter la fonction de résolution de l’outil, qui traduit l’appel MCP en requête vers l’API REST WooCommerce (
GET /wp-json/wc/v3/productsavec le paramètrestock_status=outofstock, par exemple). - Tester l’outil isolément avant de le connecter à un agent, en simulant des appels directs pour vérifier que le schéma de sortie est exploitable tel quel par un modèle de langage.
async function rechercherProduitsRupture({ categorie }) {
const params = new URLSearchParams({ stock_status: 'outofstock' });
if (categorie) params.set('category', categorie);
const reponse = await fetch(
`${process.env.WC_URL}/wp-json/wc/v3/products?${params}`,
{ headers: { Authorization: `Basic ${process.env.WC_AUTH_LECTURE}` } }
);
const produits = await reponse.json();
return produits.map((p) => ({
reference: p.sku,
nom: p.name,
categorie: p.categories?.[0]?.name ?? null,
}));
}Pourquoi granulariser chaque outil
La tentation la plus fréquente consiste à exposer un unique outil générique du type « exécuter une requête sur l’API WooCommerce », en laissant l’agent construire lui-même le point de terminaison et les paramètres. C’est une mauvaise idée : cela revient à donner à un modèle de langage un accès aussi large qu’une clé API complète, sans aucun garde-fou métier. Un outil granulaire, nommé et documenté précisément (« rechercher les produits en rupture », « lister les commandes en attente d’expédition depuis plus de 48 heures ») limite mécaniquement ce que l’agent peut faire, et rend chaque action auditable indépendamment des autres.
Le protocole standardise le dialogue, pas la sécurité
Adopter MCP standardise la façon dont l’agent découvre et appelle les outils disponibles, ce qui évite de réinventer un format propriétaire à chaque nouvel assistant connecté. Cela ne dispense en rien de vérifier, à chaque appel d’outil côté serveur, que l’action demandée reste dans le périmètre autorisé — le protocole transporte l’intention, il ne la valide pas à la place du développeur qui implémente le serveur.
Un serveur MCP bien conçu ressemble moins à une passerelle API qu’à une interface utilisateur pensée pour un utilisateur particulier : un agent qui ne sait ni deviner ni négocier, seulement suivre ce qui lui est explicitement décrit.
En résumé
Construire un serveur MCP au-dessus d’un catalogue WooCommerce n’est pas fondamentalement différent d’exposer une API métier bien pensée : la nouveauté tient dans le format standardisé de description des outils, qui permet à un agent de langage de les découvrir et de les utiliser sans intégration sur mesure à chaque fois. Commencer par des outils en lecture seule, granulaires et bien documentés, pose des bases solides avant d’envisager, avec toute la prudence nécessaire, des outils capables d’écrire dans la boutique.
