MCP pour CMS

Définition

MCP et CMS : un accès unifié quel que soit le système

Un serveur MCP donne à l’assistant le même mode d’accès quel que soit le CMS : un catalogue d’outils décrits, appelés avec des paramètres typés. Ce qui change d’un système à l’autre n’est pas le protocole, c’est le point d’entrée technique par lequel on atteint réellement les contenus.

L’unification se joue donc côté assistant, pas côté CMS. Vous pilotez une boutique et un site institutionnel bâtis sur deux technologies différentes depuis la même conversation, à condition d’avoir construit deux serveurs. WordPress relève d’une logique propre, traitée sur la page MCP pour WordPress ; cette page couvre les autres systèmes.

Pourquoi chaque CMS nécessite son propre serveur MCP

Trois éléments diffèrent radicalement d’un CMS à l’autre. Le modèle de contenu, d’abord : article, nœud, entrée, produit ne recouvrent ni les mêmes champs ni les mêmes relations. Le mécanisme d’authentification ensuite, propre à chaque système. Enfin la façon d’écrire sans court-circuiter les caches, les événements internes et les extensions.

Aucun serveur générique n’absorbe ces écarts. Un outil « créer un contenu » n’a pas le même sens sur un site éditorial et sur une boutique, où la création implique déclinaisons, stock, prix et taxes. Un serveur MCP utile parle le vocabulaire du CMS qu’il pilote.

Ce qui se mutualise, en revanche, c’est la convention de nommage. Si vos outils s’appellent de la même façon d’un site à l’autre, l’assistant transpose ses habitudes et vos consignes restent valables. Décidez cette convention avant le premier serveur, pas au troisième.

CMS traditionnels et architectures headless : deux logiques d’accès

Un CMS traditionnel mêle stockage, administration et rendu des pages dans une même application. Pour l’atteindre, le serveur MCP doit soit vivre à l’intérieur, sous forme d’extension écrite dans le langage du CMS, soit dialoguer avec son interface de services web quand elle existe.

Un CMS headless ne rend aucune page : il publie déjà son contenu par API, en REST ou en GraphQL, avec des jetons et des périmètres d’accès. Le serveur MCP y devient une couche de traduction qui transforme des points d’accès existants en outils décrits pour un modèle.

La conséquence est pratique : l’effort change de nature. Sur un CMS traditionnel, il porte sur l’accès et la sécurité. Sur un headless, l’accès est acquis, et l’effort porte sur la sélection des points d’accès et la qualité de leur description.

Tableau comparatif

Comparatif des approches par CMS

Le tableau ci-dessous résume la voie d’intégration la plus directe pour chaque famille de systèmes, ce qu’elle permet sans développement lourd, et la limite qu’elle impose. Lisez la dernière colonne en premier : c’est elle qui décide, pas la deuxième.

Système	Voie d’accès la plus directe	Ce que l’on pilote sans développement lourd	Limite ou point de vigilance
Joomla	API REST d’administration, jetons par utilisateur	Articles, catégories, menus, modules	L’API doit être activée et les extensions tierces n’y publient pas toujours leurs données
Drupal	JSON:API sur les entités	Nœuds, termes, champs personnalisés, médias	Le modèle d’entités est très libre : sans description précise, le modèle se trompe de type de contenu
PrestaShop	Service web à activer ressource par ressource	Produits, déclinaisons, catégories, commandes	Les droits se règlent par ressource, un oubli ouvre l’écriture sur les commandes
Shopify	API d’administration via une application déclarée	Produits, collections, pages, métachamps	Aucun code hébergé dans la boutique, tout dépend des portées accordées à l’application
CMS headless	API REST ou GraphQL native du service	Collections, entrées, langues, états de publication	Le volume renvoyé explose vite si les requêtes ne filtrent pas les champs

Deux enseignements ressortent. Sur les systèmes auto-hébergés, la difficulté est d’obtenir un accès complet sans fragiliser le site. Sur les plateformes hébergées, l’accès est balisé mais vous ne dépassez jamais ce que la plateforme accepte d’exposer.

Applications

Cas d’usage

• Piloter le catalogue produits d’une boutique PrestaShop depuis un assistant IA
• Traduire et publier en série des articles Joomla multilingues
• Synchroniser les contenus d’un CMS headless avec une base de connaissances IA
• Migrer une arborescence Drupal en conservant les métadonnées SEO

Vos questions

Questions fréquentes

Faut-il un serveur MCP différent pour chaque CMS ?

Oui pour la partie exécution : le code qui parle à Drupal ne peut pas parler à Shopify. Un serveur par technologie est la règle, quel que soit le nombre de sites concernés.

En revanche, un même serveur peut desservir plusieurs sites bâtis sur le même CMS, en prenant l’identifiant du site en paramètre. C’est là que se gagne le temps quand vous gérez un parc : un serveur, plusieurs installations, une seule convention de nommage à retenir.

Quelle solution existe pour WordPress ?

WordPress se traite à part, parce qu’il combine une API REST native et un système d’extensions qui permet d’exposer des capacités depuis l’intérieur du site. Les deux voies décrites ici lui sont donc ouvertes simultanément.

Les choix concrets (abilities exposées, rôles utilisateur, périmètres à ne pas ouvrir) sont détaillés sur la page MCP pour WordPress. Si votre parc mélange WordPress et un autre CMS, commencez par celui que vous connaissez le mieux : les erreurs de conception y coûteront moins cher.

MCP fonctionne-t-il avec un CMS headless ?

Oui, et c’est même le cas le plus simple. Le contenu est déjà accessible par API avec une authentification par jeton : le serveur MCP se limite à décrire les opérations utiles et à contraindre leurs paramètres.

Le piège se situe ailleurs. Les CMS headless renvoient volontiers des collections entières, avec toutes les langues et tous les états de publication. Sans filtrage ni pagination imposés dans l’outil, la réponse sature le contexte du modèle et la qualité des réponses chute.

Comment gérer les droits d’écriture sur un site e-commerce ?

Laissez les prix, les stocks et les commandes en dehors du périmètre par défaut. Ouvrez l’écriture sur les descriptions, les catégories et les métadonnées, qui se corrigent sans conséquence financière, et gardez le reste en lecture.

Si un besoin d’écriture sur ces données apparaît, passez par un état intermédiaire : l’assistant prépare la modification, un humain la valide. Les usages de l’IA sur ce type de site sont développés sur IA et e-commerce.