Exposer les templates d’un starter theme d’agence à un assistant IA via MCP

$ ls templates/ | wc -l
12

Douze templates de page, et pourtant un développeur junior fraîchement arrivé dans l’agence pose presque chaque semaine la même question : lequel utiliser pour une page d’étude de cas ? Fin 2024, le Model Context Protocol venait tout juste d’être publié ; début 2025, une expérimentation a consisté à exposer la liste des templates de ce starter theme via un petit serveur MCP, interrogeable directement par l’assistant IA utilisé au quotidien pour coder.

Ce billet raconte ce premier essai, ses résultats concrets et ses limites. Il ne traite ni de l’Abilities API native de WordPress — encore à venir à cette date — ni de la génération de code par l’IA elle-même : uniquement de l’exposition d’une information structurelle du thème.

Le problème d’onboarding derrière l’idée

Le starter theme de l’agence compte une douzaine de templates de page personnalisés, chacun avec ses champs ACF, ses zones de contenu spécifiques et ses conventions de nommage. Un développeur expérimenté navigue dans cette structure sans effort ; un nouvel arrivant, ou un développeur en mission ponctuelle sur un projet, perd un temps réel à identifier le bon fichier avant de commencer à coder.

L’assistant IA utilisé en local pouvait déjà lire le code source du thème, mais devait à chaque fois parcourir l’arborescence complète pour en déduire la liste des templates disponibles et leur rôle. Un serveur MCP dédié permettait de lui fournir directement cette information, structurée et à jour, plutôt que de la lui faire redécouvrir à chaque session.

Construire un serveur MCP minimal

Le protocole MCP définit une manière standard d’exposer des ressources et des outils à un modèle de langage. Pour ce premier essai, un seul outil a suffi : lister_templates, qui lit les en-têtes de commentaire des fichiers de template du thème et retourne leur nom, leur description, et les champs ACF associés.

{
  "name": "starter-theme-mcp",
  "version": "0.1.0",
  "tools": [
    {
      "name": "lister_templates",
      "description": "Liste les templates de page disponibles dans le starter theme, avec leur usage prévu",
      "inputSchema": {
        "type": "object",
        "properties": {}
      }
    }
  ]
}

Le serveur, écrit en Node.js avec le SDK officiel MCP, parcourt le dossier templates/ du thème au démarrage, extrait le commentaire d’en-tête Template Name: de chaque fichier PHP, et construit la réponse structurée. Rien de plus complexe qu’un script de build classique — la nouveauté tient entièrement dans le protocole d’exposition, pas dans la logique métier.

Un exemple de réponse retournée

[
  {
    "fichier": "template-etude-de-cas.php",
    "nom": "Étude de cas",
    "champsACF": ["client", "secteur", "resultats_chiffres", "temoignage"],
    "usage": "Page de présentation détaillée d'un projet client livré"
  },
  {
    "fichier": "template-page-carriere.php",
    "nom": "Recrutement",
    "champsACF": ["postes_ouverts", "avantages"],
    "usage": "Page listant les offres d'emploi de l'agence"
  }
]

Connecté à l’assistant IA de développement, ce serveur transforme une question comme « quel template pour une nouvelle étude de cas client ? » en une réponse directe, sourcée sur le code réel du thème plutôt que sur une supposition du modèle basée sur des conventions génériques WordPress.

Ce que ce premier essai a réellement changé

Le gain ne se mesure pas sur la vitesse de codage des développeurs expérimentés de l’agence — eux connaissaient déjà la structure. Il se mesure sur deux populations précises : les nouveaux arrivants, dont le temps de rampe d’accès a visiblement raccourci sur les premières semaines, et les développeurs freelances intervenant ponctuellement sur un projet existant, qui n’ont plus besoin d’un brief oral complet sur l’organisation du thème.

• Réduction du temps passé à chercher le bon template avant de commencer une tâche
• Moins d’erreurs de choix de template en début de mission pour un intervenant externe
• Documentation du thème qui reste à jour « gratuitement », puisqu’elle est lue depuis le code source lui-même

Les limites observées

Ce serveur MCP reste un outil de lecture seule, volontairement. Il n’écrit rien, ne génère aucun code, et ne remplace en rien la compréhension du développeur sur ce que fait réellement chaque template une fois ouvert. Un autre point de vigilance : la maintenance de ce petit serveur repose sur la même personne qui maintient le starter theme, ce qui crée une dépendance à surveiller si cette personne quitte l’agence.

Enfin, à ce stade de l’expérimentation, seule la liste des templates est exposée. Étendre le serveur à d’autres informations — blocs personnalisés disponibles, conventions de nommage des classes CSS du thème — est envisagé, mais chaque ajout demande de réfléchir à la granularité utile plutôt que d’exposer indistinctement tout le code source du thème.

Pour aller plus loin

Ce cas d’usage reste volontairement modeste : un seul outil, une seule ressource exposée. Il illustre néanmoins ce que MCP change concrètement pour une agence WordPress dès le début de son adoption : transformer une connaissance tacite, portée par quelques développeurs seniors, en une information structurée et interrogeable par n’importe quel assistant IA connecté au projet.