Architecture d’exposition sécurisée du catalogue WooCommerce à un serveur MCP

Une agence qui gère plusieurs boutiques WooCommerce pour des clients de taille moyenne a été sollicitée par un partenaire souhaitant intégrer un agent d’achat basé sur l’IA à son propre service, capable d’interroger en temps réel le catalogue de plusieurs boutiques partenaires pour comparer prix et disponibilité. Le cahier des charges était clair sur un point : lecture seule stricte, l’écriture faisant l’objet d’un projet distinct traité séparément. Cette architecture décrit comment cette garantie de lecture seule a été construite, pas simplement affirmée dans la documentation de l’API.

Pourquoi une simple restriction de permission ne suffit pas

La première tentation, la plus rapide à mettre en œuvre, consiste à créer une clé API WooCommerce en lecture seule et à considérer le problème résolu. C’est un bon point de départ, mais insuffisant à lui seul pour un accès exposé à un tiers externe et à un volume de requêtes potentiellement élevé et imprévisible, généré par un agent automatisé plutôt que par un navigateur humain avec ses limites naturelles de rythme.

Couche 1 : l’isolation d’accès

La clé API dédiée au serveur MCP reste la première ligne de défense, avec un rôle WordPress spécifique créé pour l’occasion, dépourvu de toute capacité d’écriture même théorique — pas seulement une clé « en lecture » au sens de l’interface WooCommerce, mais un utilisateur dont les capacités WordPress sous-jacentes ne permettent tout simplement pas d’écrire, même si un bug venait à contourner la restriction de niveau applicatif de la clé elle-même.

Couche 2 : la base de données répliquée

Un agent externe génère un profil de requêtes imprévisible : un pic soudain de consultations simultanées, des requêtes répétées sur les mêmes produits en quelques secondes. Plutôt que de faire porter ce trafic directement sur la base de données de production de chaque boutique cliente, l’architecture retenue s’appuie sur une réplique en lecture seule de la base de données, alimentée par une réplication native de la base, interrogée exclusivement par le serveur MCP. Un incident de charge côté agent externe ne peut ainsi jamais dégrader les performances de la boutique en production elle-même.

┌────────────────────┐
│  Boutique WooCommerce   │
│   (base primaire)       │
└─────────┬───────────────┘
          │ réplication continue
          ▼
┌────────────────────┐        ┌───────────────────┐
│  Réplique lecture seule │◀──┤   Serveur MCP       │
└────────────────────┘        │ (outils catalogue)  │
                                └─────────┬──────────┘
                                          │
                                          ▼
                                 Agent externe partenaire

Couche 3 : le filtrage de champs avant la sortie

La troisième couche, souvent négligée, concerne les champs exposés par chaque outil MCP. Il ne suffit pas d’interdire l’écriture : il faut aussi s’assurer qu’aucune donnée sensible (marge, coût d’achat fournisseur, notes internes sur un produit) ne transite jamais, même par erreur, dans la réponse d’un outil de lecture. Le filtrage doit avoir lieu explicitement dans le code du résolveur de l’outil, sur une liste blanche de champs autorisés, jamais sur une liste noire de champs à exclure — une liste noire oublie toujours, tôt ou tard, un champ ajouté après coup par une extension tierce.

function resoudre_outil_fiche_produit( $produit_id ) {
    $produit = wc_get_product( $produit_id );

    // Liste blanche explicite, jamais une exclusion de champs sensibles a posteriori
    return array(
        'nom'         => $produit->get_name(),
        'prix'        => $produit->get_price(),
        'disponible'  => $produit->is_in_stock(),
        'categorie'   => wp_get_post_terms( $produit_id, 'product_cat', array( 'fields' => 'names' ) ),
    );
    // Volontairement absents : coût d'achat, marge, notes internes, historique fournisseur
}

Ce que ces trois couches garantissent ensemble

• L’isolation d’accès empêche toute écriture même en cas de faille dans le code de l’outil lui-même.
• La réplique en lecture seule empêche qu’un volume de requêtes imprévisible dégrade la boutique de production.
• Le filtrage par liste blanche empêche la fuite de données sensibles, indépendamment de ce que la base de données contient par ailleurs.

La lecture seule n’est pas une propriété qu’on affirme dans la documentation d’une API, c’est une garantie qu’on construit en plusieurs couches indépendantes, chacune capable de tenir seule si une autre venait à échouer.

En résumé

Exposer un catalogue WooCommerce en lecture seule à un serveur MCP destiné à un agent externe demande davantage qu’une simple clé API restreinte : l’isolation des capacités d’écriture au niveau du compte utilisateur, une réplique de base de données dédiée pour absorber une charge imprévisible, et un filtrage de champs par liste blanche avant toute sortie forment ensemble une architecture réellement étanche, plutôt qu’une promesse de lecture seule reposant sur un seul point de contrôle.