# Sécuriser un connecteur MCP relié à un catalogue de pièces industrielles B2B

> Un fabricant industriel ouvre son catalogue de pièces à des agents partenaires via MCP. Voici comment encadrer ce serveur sans lui laisser plus d'accès que nécessaire.

- Auteur : Clément Hadrot
- Publié le : 2025-09-07
- Mis à jour le : 2025-09-07
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/securiser-connecteur-mcp-catalogue-pieces-industrielles-b2b/

## L’essentiel

- Le serveur MCP expose des outils précis plutôt que la base entière
- Chaque partenaire reçoit un jeton scindé par périmètre de pièces
- Toute action d'écriture reste désactivée par défaut

Comment un fabricant de pièces industrielles peut-il permettre à des agents conversationnels de ses partenaires de consulter son catalogue, sans leur donner un accès équivalent à celui d'un administrateur de la base de données ? La question s'est posée concrètement au moment de connecter un serveur MCP (Model Context Protocol) au catalogue WordPress du fabricant, pensé jusqu'ici uniquement pour des visiteurs humains naviguant sur le site. Ce tutoriel ne traite pas de la conception du serveur MCP lui-même, mais de la manière de l'encadrer une fois qu'il existe.

## Ce que le MCP change par rapport à une API classique

Un serveur MCP expose des « outils » que peut appeler un agent, souvent porté par un modèle de langage exécuté chez un partenaire. Contrairement à un formulaire de recherche classique, l'agent décide lui-même des requêtes à formuler, parfois de façon imprévisible : il peut chercher à combiner plusieurs outils, à réessayer une requête refusée sous une autre forme, ou à explorer des paramètres non documentés. L'encadrement doit donc partir du principe que l'agent testera les limites du système, sans intention malveillante nécessairement, mais par simple exploration.

## Étape 1 : définir des outils précis plutôt qu'un accès générique

> L'essentiel à retenir : Le serveur MCP expose des outils précis plutôt que la base entière ; Chaque partenaire reçoit un jeton scindé par périmètre de pièces ; Toute action d'écriture reste désactivée par défaut

Le premier réflexe, exposer une requête SQL libre ou un accès direct à `WP_Query` sans restriction, a été écarté. À la place, quatre outils précis ont été définis : `rechercher_piece`, `obtenir_fiche_piece`, `lister_categories` et `verifier_disponibilite`. Chacun correspond à une fonction métier claire, avec des paramètres validés individuellement, plutôt qu'un langage de requête ouvert.

```
function mcp_outil_rechercher_piece(array $parametres): array {
  $reference = sanitize_text_field($parametres['reference'] ?? '');
  if (strlen($reference) < 3) {
    return array('erreur' => 'Référence trop courte');
  }
  $pieces = get_posts(array(
    'post_type'   => 'piece_industrielle',
    's'           => $reference,
    'numberposts' => 20,
    'fields'      => 'ids',
  ));
  return array_map('mcp_formater_piece_publique', $pieces);
}
```

## Étape 2 : attribuer un jeton scindé par périmètre

Chaque partenaire connecté reçoit un jeton d'application distinct, associé à un compte de service dédié plutôt qu'à un compte administrateur partagé. Ce compte ne dispose que d'une capacité personnalisée, `consulter_catalogue_partenaire`, sans aucune capacité d'édition :

```
add_role('partenaire_mcp', 'Partenaire catalogue MCP', array(
  'read' => true,
  'consulter_catalogue_partenaire' => true,
));
```

Certains partenaires ne doivent voir qu'une partie du catalogue, par exemple une seule famille de pièces sous accord de distribution exclusif. Cette restriction est appliquée en filtrant systématiquement la requête sur la base de la catégorie autorisée, stockée en métadonnée du jeton, jamais laissée au choix de l'agent appelant.

## Étape 3 : désactiver l'écriture par défaut

Aucun des quatre outils exposés ne permet de modifier une donnée. Cette décision volontaire limite fortement la surface de risque : même si un agent partenaire était compromis ou détournait sa mission d'origine, il ne pourrait ni modifier une fiche produit, ni créer une commande, ni altérer un prix. Si une fonctionnalité d'écriture devait un jour être nécessaire, elle ferait l'objet d'un outil séparé, avec sa propre capacité dédiée et sa propre validation.

## Étape 4 : journaliser chaque appel

Chaque invocation d'outil est journalisée avec l'identifiant du jeton, l'outil appelé, les paramètres reçus et le nombre de résultats renvoyés. Ce journal permet de détecter un usage anormal — un partenaire qui interroge des références hors de son périmètre contractuel, ou un volume de requêtes incompatible avec un usage humain relayé par son agent.

## Étape 5 : tester les limites avant l'ouverture

Avant la mise à disposition aux partenaires, l'équipe a simulé des appels hors périmètre : demande de références appartenant à une autre catégorie, tentative de requête avec des paramètres malformés, appel répété à haute fréquence. Chaque cas devait renvoyer un refus propre plutôt qu'une erreur révélant des détails d'implémentation.

## En résumé

Ouvrir un catalogue à des agents partenaires via MCP demande la même discipline qu'une API classique, avec une vigilance supplémentaire sur l'imprévisibilité du comportement de l'agent appelant. Des outils précis, un compte de service par partenaire, l'absence d'écriture par défaut et une journalisation systématique forment un socle raisonnable avant toute ouverture.