# Un serveur MCP unique qui expose plusieurs sites d’un même multisite

> Architecture d'un serveur MCP capable de router ses outils vers le bon sous-site d'un réseau multisite selon le contexte de la requête de l'agent.

- Auteur : Clément Hadrot
- Publié le : 2026-02-19
- Mis à jour le : 2026-02-19
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/serveur-mcp-multisite-plusieurs-sites/

## L’essentiel

- Un seul serveur, un routage par identifiant de sous-site
- Chaque outil reçoit un contexte de site explicite, jamais implicite
- Le réseau évite la duplication d'un serveur par sous-site

Un réseau WordPress multisite de neuf sous-sites, un par filiale régionale d'une même enseigne, souhaitait ouvrir un accès agent pour la génération de rapports de contenu et la recherche d'articles. La question posée dès le départ : faut-il un serveur MCP par sous-site, ou un serveur unique capable de s'adresser au bon sous-site selon la demande ? Nous avons retenu la seconde option, pour des raisons de maintenance autant que de cohérence d'architecture.

Cet article détaille comment ce routage a été construit, et pourquoi la question de l'identifiant de site explicite dans chaque appel d'outil s'est révélée plus délicate qu'elle n'en avait l'air au départ.

## Pourquoi un serveur unique plutôt que neuf

Neuf serveurs MCP distincts auraient signifié neuf déploiements à surveiller, neuf schémas d'outils à maintenir en synchronisation, et un risque réel de divergence progressive entre eux au fil des mises à jour. Un serveur unique, connecté au réseau multisite via l'API de commutation de site propre à WordPress, permet de maintenir une seule base de code pour l'ensemble des outils exposés.

> L'essentiel à retenir : Un seul serveur, un routage par identifiant de sous-site ; Chaque outil reçoit un contexte de site explicite, jamais implicite ; Le réseau évite la duplication d'un serveur par sous-site

## Le routage par identifiant de sous-site

Chaque outil du serveur MCP reçoit systématiquement un paramètre `site_id` obligatoire, jamais déduit implicitement du contexte de connexion. C'est le point le plus important de cette architecture : un agent qui omettrait ce paramètre reçoit une erreur de validation, plutôt qu'une réponse portant par défaut sur le site principal du réseau.

```
{
  "name": "search_articles",
  "inputSchema": {
    "type": "object",
    "properties": {
      "site_id": { "type": "integer", "description": "Identifiant du sous-site cible dans le réseau" },
      "mot_cle": { "type": "string" }
    },
    "required": ["site_id", "mot_cle"]
  }
}
```

Côté PHP, chaque appel bascule explicitement de contexte avec `switch_to_blog()`, exécute la requête, puis revient systématiquement au contexte d'origine avec `restore_current_blog()`, même en cas d'erreur intermédiaire.

```
function agence_search_articles( $site_id, $mot_cle ) {
    if ( ! get_site( $site_id ) ) {
        return new WP_Error( 'site_invalide', 'Sous-site introuvable dans le réseau.' );
    }

    switch_to_blog( $site_id );

    $articles = get_posts( array(
        's'         => $mot_cle,
        'post_type' => 'post',
    ) );

    $resultat = array_map( function ( $p ) {
        return array( 'id' => $p->ID, 'titre' => get_the_title( $p ) );
    }, $articles );

    restore_current_blog();

    return $resultat;
}
```

## Le piège du contexte oublié

Lors des premiers tests, une erreur survenue en cours de requête (par exemple un dépassement de délai sur une recherche trop large) empêchait `restore_current_blog()` d'être appelé, laissant le contexte du serveur bloqué sur le mauvais sous-site pour les appels suivants. La correction a consisté à envelopper systématiquement chaque appel dans un bloc garantissant le retour au contexte d'origine, y compris en cas d'exception.

```
function agence_avec_contexte_site( $site_id, callable $action ) {
    switch_to_blog( $site_id );
    try {
        return $action();
    } finally {
        restore_current_blog();
    }
}
```

## Limiter l'accès d'un agent à un sous-ensemble de sites

Certains agents (par exemple un outil de reporting utilisé par le siège) ont besoin d'accéder à l'ensemble des neuf sous-sites. D'autres, utilisés par une équipe régionale, ne doivent voir que leur propre sous-site. Cette restriction est appliquée à l'authentification du serveur, avant même l'exécution de l'outil : le jeton d'accès de l'agent porte la liste des identifiants de sous-sites autorisés, vérifiée à chaque appel.

| Profil d'agent | Sous-sites accessibles |
| --- | --- |
| Reporting siège | Les neuf sous-sites |
| Équipe régionale | Un seul sous-site, le sien |

> Le paramètre `site_id` obligatoire dans chaque outil n'est pas qu'une question de routage technique : c'est aussi le point où l'on vérifie que l'agent a réellement le droit de consulter ce sous-site précis.

## En résumé

Un serveur MCP unique pour un réseau multisite évite la duplication de code et de configuration entre sous-sites, à condition d'imposer un identifiant de site explicite dans chaque outil plutôt que de le déduire du contexte de connexion, et de garantir que le contexte de sous-site est toujours restauré après chaque appel, même en cas d'erreur. Ce sujet ne traite pas la maintenance pilotée par agent en général, abordée séparément : il porte uniquement sur ce que le multisite change dans la conception du serveur lui-même.