Le protocole MCP ouvre la porte à une nouvelle génération d’assistants capables d’interagir avec vos fichiers, vos outils et vos applications. Mais avant d’exploiter tout son potentiel, encore faut-il savoir installer et configurer un serveur MCP local. Bonne nouvelle : c’est beaucoup plus accessible qu’il n’y paraît.
Dans ce tutoriel, vous allez apprendre à créer votre premier serveur MCP, à le connecter à Claude, à comprendre son fonctionnement avec ChatGPT et à réaliser vos premiers tests pas à pas. Même si vous débutez avec MCP, vous découvrirez rapidement comment transformer une simple intelligence artificielle en un assistant capable d’utiliser vos propres outils.
- Transformer Claude en assistant capable d’utiliser vos propres outils et données grâce à un serveur local.
- Comprendre comment relier une intelligence artificielle à des fonctions personnalisées sans dépendre uniquement de ses connaissances intégrées.
- Adopter les bonnes pratiques de configuration et de sécurité pour construire des intégrations MCP fiables et évolutives.
Installer un serveur MCP local peut sembler impressionnant au premier abord. Nous allons avancer tranquillement, étape par étape. L’objectif n’est pas seulement de copier des commandes, mais de comprendre ce que vous faites. À la fin, vous saurez installer un serveur MCP local, le connecter à Claude Desktop, comprendre ce qui change avec ChatGPT, et créer un petit serveur de démonstration capable de répondre à une demande simple.
Mais, avant tout chose :
👉 MCP : comprendre le Model Context Protocol
- Un serveur MCP local : à quoi ça sert ?
- Les prérequis avant de commencer
- Initialiser le projet Node.js
- Créer notre premier serveur MCP local
- Connecter le serveur MCP local à Claude Desktop
- Tester le serveur depuis Claude
- Ajouter un outil plus concret
- Comprendre la différence entre un outil et une réponse classique
- Et pour ChatGPT, comment faire ?
- Sécuriser votre serveur MCP local
- Lire un fichier local avec un serveur MCP
- Organiser proprement vos outils MCP
- Et CODEX CLI dans tout ça ?
- Rien de grandiose jusqu'à présent, comment aller plus loin ?
- 1. Un serveur MCP pour votre blog
- 2. Un serveur MCP connecté à votre base WordPress
- 3. Un serveur MCP relié à GA4
- 4. Un serveur MCP pour votre boutique en ligne
- 5. Analyse automatique de votre sitemap
- 6. Création automatique de maillage interne
- 7. Recherche dans toute votre bibliothèque de contenus
- 8. Générateur de formations
- 9. Surveillance SEO automatique
- 10. Assistant WordPress personnel
- 11. Le plus impressionnant : plusieurs MCP ensemble
- Les erreurs fréquentes à connaître
- Bonnes pratiques pour débuter
Avant de toucher au terminal, prenons une minute pour poser le décor.
Un serveur MCP est un petit programme qui expose des outils à une application d’intelligence artificielle.
Par exemple, il peut permettre à Claude de lire un dossier local, d’interroger une base de données, de lancer une recherche dans des fichiers, ou encore d’appeler une fonction que vous avez vous-même codée.
Ici, nous allons créer un serveur MCP local très simple. Il ne fera pas quelque chose de spectaculaire mais il permettra de comprendre la logique complète : installation, configuration, lancement, connexion et test.
Nous allons utiliser Node.js, car c’est une solution accessible pour un développeur web. Et si vous connaissez déjà un peu JavaScript, vous serez en terrain familier.
Un serveur MCP local : à quoi ça sert ?
Un serveur MCP local tourne directement sur votre ordinateur. Cela signifie qu’il peut accéder à des ressources locales, selon les permissions que vous lui donnez.
Concrètement, cela peut servir à connecter une IA à vos propres outils. Vous pouvez imaginer un serveur MCP capable de lire un dossier de projet, d’analyser des fichiers Markdown, de récupérer des données depuis une API privée, ou encore d’exécuter des tâches répétitives.
La grande idée est simple : au lieu de demander à l’IA de deviner, vous lui donnez un accès contrôlé à des outils précis.

C’est un peu comme si vous disiez à un assistant : « Tu peux m’aider, mais voici uniquement les tiroirs que tu as le droit d’ouvrir. » C’est beaucoup plus propre, plus sécurisé et plus prévisible.
Claude, ChatGPT et MCP : petite précision importante
Pour éviter toute confusion, il faut distinguer deux cas.
Claude Desktop est aujourd’hui l’un des environnements les plus simples pour tester un serveur MCP local. Vous pouvez déclarer un serveur dans un fichier de configuration, relancer Claude, puis utiliser les outils exposés par ce serveur.
Pour ChatGPT, la situation est différente. L’écosystème OpenAI prend bien en charge MCP, notamment pour créer des intégrations, des connecteurs ou des usages via API.
En revanche, l’application ChatGPT classique ne fonctionne pas exactement comme Claude Desktop avec un simple fichier local à modifier. Dans la pratique, un serveur MCP destiné à ChatGPT est souvent pensé comme un serveur distant accessible par Internet, ou comme une intégration utilisée via l’API OpenAI.
Autrement dit, dans ce tutoriel, nous allons installer un serveur MCP local utilisable facilement avec Claude Desktop, puis expliquer comment adapter la logique pour ChatGPT et OpenAI sans vendre du rêve ni inventer un bouton magique qui n’existe pas.
Claude desktop est-il gratuit ?
Claude Desktop est gratuit à télécharger et à utiliser avec un compte gratuit Anthropic.
Cependant, il faut distinguer deux choses :
- Claude Desktop (l’application) : gratuit.
- Les modèles Claude utilisés dans l’application : soumis à des limites d’utilisation sur l’offre gratuite.
Avec l’offre gratuite, vous pouvez :
- Installer Claude Desktop.
- Utiliser MCP (Model Context Protocol).
- Connecter des serveurs MCP locaux.
- Tester vos propres outils MCP.
- Discuter avec Claude.
Les limitations concernent surtout :
- Le nombre de messages sur une période donnée.
- L’accès aux modèles les plus puissants.
- Certaines fonctionnalités avancées selon les évolutions de l’offre Anthropic.
Pour apprendre MCP et développer un serveur MCP local, la version gratuite est généralement suffisante. Beaucoup de développeurs utilisent d’ailleurs Claude Desktop gratuit pour leurs premiers tests de serveurs MCP avant de passer éventuellement à une offre payante.
Si votre objectif est simplement de suivre ce tutoriel du Créa-Blog et d’expérimenter avec un serveur MCP local, vous pouvez commencer sans dépenser un centime.
Les prérequis avant de commencer
Pour suivre ce tutoriel, vous aurez besoin d’un ordinateur sous macOS, Windows ou Linux. Les commandes peuvent légèrement changer selon votre système, mais la logique reste la même.
Vous aurez également besoin de Node.js. C’est l’environnement qui permet d’exécuter du JavaScript en dehors du navigateur. Si vous développez déjà en web, vous l’avez peut-être installé sur votre machine.
Pour vérifier si Node.js est disponible, ouvrez votre terminal et tapez :
node -v
Cette commande demande simplement à Node.js d’afficher sa version. Si vous voyez une réponse comme ceci, tout va bien :

Peu importe que le numéro soit différent. L’important est d’avoir une version récente.
Vérifiez ensuite npm, le gestionnaire de paquets livré avec Node.js :
npm -v
npm permet d’installer des bibliothèques JavaScript. Dans notre cas, il va nous servir à ajouter les outils nécessaires pour créer notre serveur MCP.
Créer le dossier du projet
Nous allons maintenant créer un dossier propre pour notre serveur MCP local.
Dans votre terminal, placez-vous à l’endroit où vous rangez vos projets. Par exemple :
cd ~/Documents
👉 Pour ceux qui débutent avec le terminal : Naviguer et se situer
Puis créez un nouveau dossier :
mkdir serveur-mcp-local
👉 Toujours pour les débutants : Fichier et dossier depuis le terminal
Entrez dans ce dossier :
cd serveur-mcp-local
À ce stade, vous avez préparé l’emplacement de travail. Rien de sorcier. C’est comme poser une nappe propre avant de commencer à cuisiner. Ce n’est pas obligatoire pour survivre, mais ça évite d’en mettre partout.
Initialiser le projet Node.js
Nous allons maintenant initialiser un projet Node.js.
Tapez la commande suivante :
npm init -y
Le -y permet d’accepter automatiquement les options par défaut. Cela crée un fichier package.json.
Ce fichier est important, car il décrit votre projet : son nom, sa version, ses scripts et les dépendances nécessaires. Vous pouvez le voir comme la petite fiche d’identité de votre serveur MCP.
Vous devriez obtenir un fichier ressemblant à ceci :
{
"name": "serveur-mcp-local",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC",
"type": "commonjs"
}
Pour le moment, ce fichier est très simple. Nous allons l’améliorer dans quelques instants.
Installer le SDK MCP
Pour créer notre serveur, nous allons utiliser le SDK officiel MCP pour JavaScript.
Dans le terminal, tapez :
npm install @modelcontextprotocol/sdk
Cette commande ajoute la bibliothèque MCP à votre projet. Elle crée aussi un dossier node_modules, qui contient les fichiers nécessaires au fonctionnement du paquet.
Vous verrez également apparaître ou se mettre à jour un fichier package-lock.json. Ce fichier garde une trace précise des versions installées. Vous n’avez pas besoin de le modifier à la main.
Passer le projet en module JavaScript moderne
Nous allons utiliser la syntaxe moderne de JavaScript avec import. Pour cela, ouvrez le fichier package.json et ajoutez la ligne suivante :
"type": "module"
Votre fichier peut maintenant ressembler à ceci :
{
"name": "serveur-mcp-local",
"version": "1.0.0",
"type": "module",
"main": "server.js",
"scripts": {
"start": "node server.js"
},
"dependencies": {
"@modelcontextprotocol/sdk": "^1.0.0"
}
}
La partie importante ici est le script :
"start": "node server.js"
Grâce à lui, vous pourrez lancer votre serveur avec :
npm start
C’est plus propre que de retaper la commande complète à chaque fois.
Créer notre premier serveur MCP local
Créez maintenant un fichier nommé server.js à la racine du projet.
Dans ce fichier, nous allons écrire un petit serveur MCP. Son rôle sera volontairement simple : exposer un outil appelé dire_bonjour.
Cet outil prendra un prénom en entrée et retournera un message personnalisé. Ce n’est pas encore l’outil du siècle, mais il permet de comprendre le mécanisme sans se noyer dans la complexité.
Voici le code complet :
// On importe les éléments nécessaires depuis le SDK MCP
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
// On crée un nouveau serveur MCP
const server = new McpServer({
name: "serveur-mcp-local",
version: "1.0.0"
});
// On déclare un outil disponible pour l'IA
server.tool(
"dire_bonjour",
{
prenom: z.string().describe("Le prénom de la personne à saluer")
},
async ({ prenom }) => {
return {
content: [
{
type: "text",
text: `Bonjour ${prenom}, votre serveur MCP local fonctionne parfaitement !`
}
]
};
}
);
// On prépare le transport en entrée/sortie standard
const transport = new StdioServerTransport();
// On connecte le serveur au transport
await server.connect(transport);
Prenons le temps de comprendre.
La ligne suivante crée le serveur :
const server = new McpServer({
name: "serveur-mcp-local",
version: "1.0.0"
});
Le nom permet d’identifier votre serveur. La version est utile pour suivre son évolution. Dans un vrai projet, vous pourriez passer de 1.0.0 à 1.1.0 après avoir ajouté de nouveaux outils.
Ensuite, nous déclarons un outil :
server.tool("dire_bonjour", ...)
Un outil MCP est une action que l’IA peut demander au serveur d’exécuter. Ici, l’action consiste simplement à générer une phrase avec un prénom.
La partie suivante décrit les paramètres attendus :
{
prenom: z.string().describe("Le prénom de la personne à saluer")
}
Nous indiquons que l’outil attend une valeur appelée prenom, et que cette valeur doit être une chaîne de caractères. La bibliothèque zod sert ici à valider les données. C’est une bonne habitude, car il ne faut jamais supposer qu’une entrée est correcte.
Enfin, cette partie retourne la réponse :
return {
content: [
{
type: "text",
text: `Bonjour ${prenom}, votre serveur MCP local fonctionne parfaitement !`
}
]
};
Le serveur renvoie un contenu de type texte. L’application cliente, comme Claude Desktop, pourra ensuite afficher ce résultat dans la conversation.
Installer Zod si nécessaire
Dans notre exemple, nous utilisons zod. Si votre installation du SDK ne l’ajoute pas automatiquement, installez-le avec :
npm install zod
Zod permet de décrire et vérifier les données attendues. Pour un débutant, retenez simplement ceci : c’est un garde-fou. Il évite que votre outil reçoive n’importe quoi et parte en promenade dans un champ de bugs.
Tester le serveur dans le terminal
Avant de connecter le serveur à Claude, nous allons vérifier qu’il démarre correctement.
Dans le terminal, tapez :
npm start
Normalement, vous ne verrez pas forcément un grand message spectaculaire. Avec le transport stdio, le serveur attend de communiquer avec un client MCP. C’est normal.

Si aucune erreur ne s’affiche, c’est déjà une bonne nouvelle. Pour arrêter le serveur, utilisez :
CTRL + C
Si vous voyez une erreur, lisez-la calmement. Les problèmes les plus courants sont une faute dans le nom d’un import, une dépendance manquante ou une virgule oubliée. JavaScript est parfois sympathique, mais pas toujours très patient avec la ponctuation.
Connecter le serveur MCP local à Claude Desktop
Nous allons maintenant indiquer à Claude Desktop où se trouve notre serveur MCP.
Ouvrez Claude Desktop, puis allez dans les paramètres développeur. Selon votre système, Claude peut proposer un bouton pour modifier le fichier de configuration.
Le fichier s’appelle généralement :
claude_desktop_config.json
Sur macOS, il se trouve souvent dans un chemin ressemblant à ceci :
~/Library/Application Support/Claude/claude_desktop_config.json
Sur Windows, il peut se trouver dans un chemin de ce type :
%APPDATA%\Claude\claude_desktop_config.json
Dans ce fichier, ajoutez une configuration comme celle-ci :
{
"mcpServers": {
"serveur-mcp-local": {
"command": "node",
"args": [
"/chemin/complet/vers/serveur-mcp-local/server.js"
]
}
}
}
Attention : vous devez remplacer le chemin par le vrai chemin de votre fichier server.js.
Par exemple, sur macOS, cela pourrait donner :
{
"mcpServers": {
"serveur-mcp-local": {
"command": "node",
"args": [
"/Users/alban/Documents/serveur-mcp-local/server.js"
]
}
}
}
Sur Windows, le chemin pourrait ressembler à ceci :
{
"mcpServers": {
"serveur-mcp-local": {
"command": "node",
"args": [
"C:\\Users\\Alban\\Documents\\serveur-mcp-local\\server.js"
]
}
}
}
Remarquez les doubles antislashs \\ dans le chemin Windows. Dans un fichier JSON, l’antislash seul a une signification spéciale. Il faut donc l’échapper.
Une fois le fichier modifié, enregistrez-le, puis redémarrez complètement Claude Desktop.
Tester le serveur depuis Claude
Dans Claude, vous pouvez maintenant poser une question du genre :
Utilise l'outil dire_bonjour avec le prénom Alban.
Si tout est correctement configuré, Claude devrait détecter l’outil disponible et l’utiliser. Vous devriez obtenir une réponse proche de :
Bonjour Alban, votre serveur MCP local fonctionne parfaitement !
À ce moment-là, vous venez de franchir une étape importante. Votre assistant IA ne s’est pas contenté de répondre avec ses connaissances internes. Il a utilisé un outil fourni par votre propre serveur local.
C’est exactement l’intérêt d’un serveur MCP.
Ajouter un outil plus concret
Notre premier outil est pratique pour tester, mais il reste très simple. Ajoutons maintenant un exemple un peu plus réaliste.
Imaginons un outil qui calcule le prix TTC à partir d’un prix HT et d’un taux de TVA. C’est simple, concret et facile à vérifier.
Ajoutez ce code dans votre fichier server.js, avant la ligne de connexion finale :
server.tool(
"calculer_ttc",
{
prix_ht: z.number().describe("Le prix hors taxes"),
taux_tva: z.number().describe("Le taux de TVA en pourcentage")
},
async ({ prix_ht, taux_tva }) => {
const montant_tva = prix_ht * (taux_tva / 100);
const prix_ttc = prix_ht + montant_tva;
return {
content: [
{
type: "text",
text: `Prix HT : ${prix_ht} €\nTVA : ${montant_tva.toFixed(2)} €\nPrix TTC : ${prix_ttc.toFixed(2)} €`
}
]
};
}
);
Ici, l’outil attend deux nombres : le prix hors taxes et le taux de TVA.
La ligne suivante calcule le montant de la TVA :
const montant_tva = prix_ht * (taux_tva / 100);
Si le prix HT est de 100 € et le taux de TVA de 20 %, le calcul donne 20 €.
Ensuite, nous ajoutons la TVA au prix initial :
const prix_ttc = prix_ht + montant_tva;
Puis nous retournons une réponse lisible.
Après modification, redémarrez Claude Desktop pour que la configuration et le serveur soient rechargés proprement.
Vous pouvez ensuite demander :
Calcule le prix TTC pour un produit à 150 € HT avec une TVA de 20 %.
Claude pourra utiliser l’outil calculer_ttc et vous donner le résultat.
Comprendre la différence entre un outil et une réponse classique
- C’est une notion essentielle.
Quand Claude ou ChatGPT répond normalement, il génère du texte à partir de son modèle. Il peut expliquer, reformuler, comparer, résumer ou proposer du code.
Quand il utilise un outil MCP, il demande à un serveur externe d’effectuer une action précise.
La différence est importante. Si vous demandez simplement « combien font 150 + 20 % ? », l’IA peut calculer elle-même. Mais si vous avez un outil métier qui récupère un tarif dans votre base de données, l’IA ne peut pas l’inventer. Elle doit appeler l’outil.
Un serveur MCP sert donc à relier l’intelligence du modèle à des actions ou données réelles.
Et pour ChatGPT, comment faire ?
Côté ChatGPT, il faut être prudent dans la formulation.
Claude Desktop permet une configuration locale directe très pratique. Vous déclarez votre serveur dans un fichier JSON, vous redémarrez Claude, et vous pouvez tester.
Pour ChatGPT, l’approche officielle est davantage orientée vers des serveurs MCP accessibles à distance, des connecteurs, des intégrations ou des usages via l’API OpenAI. Cela signifie que votre serveur local devra souvent être adapté si vous voulez le rendre utilisable dans un contexte OpenAI.
Dans un environnement de développement, vous pouvez créer un serveur local, le tester, puis le rendre temporairement accessible avec un tunnel sécurisé comme ngrok ou Cloudflare Tunnel. Cela transforme votre serveur local en adresse accessible depuis Internet.
Le principe est le suivant :
Votre ordinateur
↓
Serveur MCP local
↓
Tunnel sécurisé
↓
OpenAI / ChatGPT / API

Ce n’est plus un serveur purement local du point de vue de ChatGPT, car OpenAI doit pouvoir le joindre. Mais pour vous, le code continue bien à tourner sur votre machine.
Exemple de logique avec un serveur distant
Pour un usage avec l’écosystème OpenAI, vous devrez généralement réfléchir à plusieurs points supplémentaires.
Votre serveur doit être accessible via une URL publique. Il doit aussi respecter les attentes de sécurité, notamment pour éviter que n’importe qui puisse appeler vos outils. Vous devrez souvent prévoir une authentification, une gestion des permissions et une description claire des outils disponibles.
- En local, vous pouvez vous permettre d’expérimenter.
- En distant, vous devez être plus rigoureux.
C’est un peu comme cuisiner chez vous ou ouvrir un restaurant. Dans votre cuisine, vous pouvez goûter la sauce avec la cuillère. Dans un restaurant, il vaut mieux mettre en place deux ou trois règles d’hygiène supplémentaires.
Sécuriser votre serveur MCP local
Même en local, il faut adopter les bons réflexes.
Un serveur MCP peut donner accès à des fichiers, des commandes, des API ou des données sensibles. Il ne faut jamais exposer plus que nécessaire.
Par exemple, si vous créez un outil qui lit des fichiers, évitez de lui donner accès à tout votre disque dur. Préférez un dossier précis :
const DOSSIER_AUTORISE = "/Users/alban/Documents/projets-demo";
Cette approche limite les dégâts en cas d’erreur. Votre outil ne peut travailler que dans un périmètre défini.
Évitez aussi de créer un outil qui exécute directement des commandes système envoyées par l’IA. C’est très risqué. Si vous avez besoin d’automatiser certaines commandes, créez des actions très encadrées.
Mauvaise idée :
// Dangereux : ne faites pas ça
// L'utilisateur pourrait demander n'importe quelle commande
exec(commande_envoyee_par_ia);
Meilleure idée :
Des formations informatique pour tous !
Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…
Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.
Découvrez mes formations Qui suis-je ?// Plus sûr : on contrôle précisément l'action autorisée
server.tool(
"afficher_version_node",
{},
async () => {
return {
content: [
{
type: "text",
text: `Cet outil pourrait afficher une information contrôlée, sans exécuter n'importe quelle commande.`
}
]
};
}
);
Le principe est simple : l’IA peut demander une action, mais vous décidez ce que le serveur a réellement le droit de faire.
Lire un fichier local avec un serveur MCP
Ajoutons maintenant un exemple plus parlant : lire un fichier texte précis.
Créez un fichier nommé notes.txt dans votre dossier de projet :
Bienvenue dans mon premier serveur MCP local.
Ce fichier sert de test pour vérifier que l'IA peut lire une ressource locale autorisée.
Nous allons ajouter un outil qui lit ce fichier.
Ajoutez d’abord ces imports en haut de server.js :
import fs from "node:fs/promises";
import path from "node:path";
Puis ajoutez cet outil :
server.tool(
"lire_notes",
{},
async () => {
const cheminFichier = path.join(process.cwd(), "notes.txt");
const contenu = await fs.readFile(cheminFichier, "utf-8");
return {
content: [
{
type: "text",
text: contenu
}
]
};
}
);
Ici, nous utilisons :
process.cwd()
Cette instruction désigne le dossier courant du projet. Ensuite, nous construisons le chemin vers notes.txt.
La lecture du fichier se fait avec :
await fs.readFile(cheminFichier, "utf-8");
Le "utf-8" indique que nous voulons lire le fichier comme du texte.
Après avoir redémarré Claude Desktop, vous pouvez demander :
Lis mes notes locales avec l'outil disponible.
Claude pourra appeler l’outil lire_notes et afficher le contenu du fichier.
Organiser proprement vos outils MCP
Au début, mettre tous les outils dans un seul fichier est acceptable. Mais dès que votre serveur MCP local grossit, il devient préférable de mieux organiser le code.
Vous pourriez imaginer cette structure :
serveur-mcp-local/
├── server.js
├── tools/
│ ├── direBonjour.js
│ ├── calculerTtc.js
│ └── lireNotes.js
├── notes.txt
├── package.json
Chaque fichier dans le dossier tools contient un outil précis. Votre fichier server.js sert alors à les charger.
Cette organisation rend le projet plus lisible. Elle évite aussi le fameux fichier géant de 2 000 lignes que plus personne n’ose ouvrir, un peu comme ce tiroir où l’on range « provisoirement » les câbles depuis 2014.
Et CODEX CLI dans tout ça ?
Codex CLI peut déjà utiliser des serveurs MCP, donc il sait se connecter à des outils, des bases de données, des systèmes de fichiers, Playwright, GitHub, etc. Il peut être configuré pour consommer des serveurs MCP via son fichier de configuration.
Mais Codex CLI n’est pas un remplaçant d’un serveur MCP.
Il faut distinguer deux rôles :
- Codex CLI = le client MCP
- Serveur MCP = l’outil auquel le client se connecte
Par exemple :
Codex CLI
│
▼
Serveur MCP GitHub
Serveur MCP Filesystem
Serveur MCP Playwright
Serveur MCP MySQL
Dans ce cas, Codex agit comme Claude Desktop : il utilise les outils exposés par les serveurs MCP.
Pour le cas d’un développeur web, si vous utilisez déjà Codex CLI avec votre compte ChatGPT Plus, vous pouvez éviter d’installer Claude Desktop et travailler directement dans le terminal :
Projet WordPress
│
▼
Codex CLI
│
▼
Serveur MCP Filesystem
│
▼
Lecture et modification des fichiers
Par contre, si vous créez un serveur MCP personnalisé, par exemple un serveur qui :
- analyse le SEO de votre site
- relier codex à GA4
- génère des liens internes
- interroge un site
- analyse des articles
Alors Codex CLI ne remplace pas ce serveur. Il va simplement s’y connecter pour l’utiliser.
Une autre subtilité intéressante : Codex peut même servir de composant MCP dans certaines architectures, et il existe des projets permettant à Claude d’utiliser Codex comme outil.
Pour résumer simplement :

Dans certain contexte, si votre objectif est d’améliorer le workflow de votre site web, WordPress, le SEO ou vos projets PHP = Codex CLI + quelques serveurs MCP spécialisés plutôt que Claude Desktop.
Rien de grandiose jusqu’à présent, comment aller plus loin ?
C’est normal que d’avoir cette impression car ce tutoriel montre surtout comment installer un serveur MCP, pas pourquoi c’est révolutionnaire.
Pour quelqu’un qui utilise déjà Codex CLI, Claude Desktop, Git, le terminal, PHP et WordPress, le petit exemple « Bonjour Alban » est franchement peu impressionnant.
Le vrai intérêt arrive quand vous allez créer des serveurs MCP qui donnent à l’IA accès à vos données, vos outils métier ou vos processus personnalisés.
Voici quelques exemples beaucoup plus parlants.
1. Un serveur MCP pour votre blog
Aujourd’hui, Codex peut lire des fichiers.
Mais imaginez un serveur MCP qui expose des fonctions comme :
chercher_article()
lister_tutoriels_seo()
articles_sans_image()
articles_sans_meta_description()
liens_internes_manquants()
Vous pourriez alors demander :
Analyse les 50 derniers articles du blog et trouve ceux qui n’ont pas assez de liens internes.
L’IA n’aurait plus besoin de scanner le site manuellement.
2. Un serveur MCP connecté à votre base WordPress
Vous pourriez exposer :
get_articles()
get_categories()
get_tags()
get_commentaires()
Puis demander :
Quels sont les 20 articles les plus consultés qui n’ont pas été mis à jour depuis plus de 2 ans ?
Ou :
Trouve tous les tutoriels PHP qui n’ont aucun lien vers la catégorie Sécurité.
Codex seul ne connaît pas votre base.
3. Un serveur MCP relié à GA4
Imaginez :
top_pages()
top_keywords()
pages_en_baisse()
Puis :
Quelles pages ont perdu plus de 20 % de trafic ce mois-ci ?
Ou :
Donne-moi 10 idées d’articles basées sur les pages qui progressent le plus.
Là, l’IA travaille sur vos vraies données.
4. Un serveur MCP pour votre boutique en ligne
Celui-là serait énorme.
Fonctions :
get_devis()
get_clients()
get_commandes()
get_factures()
Vous pourriez demander :
Quels clients ont commandé des agrafes 70 cm au cours des 12 derniers mois ?
Ou :
Faites-moi la liste des clients qui n’ont rien commandé depuis plus d’un an.
5. Analyse automatique de votre sitemap
Vous utilisez souvent :
https://blog.crea-troyes.fr/post-sitemap.xml
Imaginez :
analyser_sitemap()
trouver_contenu_duplique()
articles_non_mailles()
Vous demandez :
Trouve les 50 articles qui devraient pointer vers mon pilier SEO.
Réponse en quelques secondes.
6. Création automatique de maillage interne
Là, on touche quelque chose de très puissant.
Votre serveur MCP pourrait :
lire_article()
rechercher_articles_associes()
proposer_liens()
Vous pourriez dire :
Analyse cet article et propose 15 liens internes vers mon contenu existant.
L’IA aurait accès à vos plusieurs centaines de tutoriels.
👉 Découvrez ILP, notre plugin Wordpress gratuit pour votre maillage interne.
7. Recherche dans toute votre bibliothèque de contenus
Aujourd’hui :
800 tutoriels
Demain :
rechercher_contenu("wordpress")
Puis :
Quels tutoriels parlent déjà des hooks WordPress ?
Ou :
Ai-je déjà écrit quelque chose sur MCP ?
8. Générateur de formations
Vous avez un site de formations web, un MCP pourrait exposer :
formations()
calendrier()
supports()
Vous pourriez demander :
Crée une formation de 4 heures sur les Custom Post Types à partir des articles existants du blog.
9. Surveillance SEO automatique
Un MCP peut tourner en permanence.
Exemple :
verifier_erreurs_404()
verifier_meta()
verifier_images()
Puis :
Donne-moi le rapport SEO du jour.
Codex seul ne surveille rien lorsqu’il est fermé.
10. Assistant WordPress personnel
Le plus intéressant à mon avis.
Vous pourriez avoir :
plugins_installes()
themes_installes()
logs_php()
logs_wordpress()
Puis demander :
Pourquoi mon site affiche une erreur 500 ?
L’IA pourrait lire directement :
debug.log
apache.log
nginx.log
et vous répondre.
11. Le plus impressionnant : plusieurs MCP ensemble
Imaginez :
MCP WordPress
MCP GA4
MCP Sitemap
MCP Affnox
MCP GitHub
Vous demandez :
Analyse les pages qui génèrent le plus de trafic SEO, vérifie leur maillage interne, trouve celles qui ont un taux de rebond élevé et propose des améliorations.
L’IA va :
GA4
↓
WordPress
↓
Sitemap
↓
Base SQL
↓
Rapport final
- C’est là que MCP devient vraiment intéressant.
Construisez directement un MCP capable de :
- lire le sitemap ;
- interroger WordPress
- analyser le maillage interne
- accéder à GA4
- retrouver des articles par thème
- générer des rapports SEO
- proposer des liens internes
- identifier les contenus à mettre à jour
- détecter les opportunités de nouveaux articles
Là, vous auriez un assistant qui connaît réellement votre écosystème et qui peut faire des choses qu’aucun Codex CLI ou Claude Desktop utilisé seul ne peut accomplir.
Les erreurs fréquentes à connaître
Lorsque vous installez un serveur MCP local, quelques erreurs reviennent souvent.
La première concerne le chemin du fichier dans la configuration Claude. Si le chemin vers server.js est incorrect, Claude ne pourra pas lancer le serveur.
La deuxième concerne Node.js. Si Claude ne trouve pas la commande node, vous devrez parfois indiquer le chemin complet vers Node.js.
Sur macOS ou Linux, vous pouvez le trouver avec :
which node
La commande peut retourner quelque chose comme :
/usr/local/bin/node
Dans ce cas, vous pouvez adapter la configuration :
{
"mcpServers": {
"serveur-mcp-local": {
"command": "/usr/local/bin/node",
"args": [
"/Users/alban/Documents/serveur-mcp-local/server.js"
]
}
}
}
La troisième erreur classique vient d’un JSON mal formé. Une virgule oubliée ou ajoutée au mauvais endroit peut casser toute la configuration. Si Claude ne détecte pas votre serveur, commencez par vérifier ce fichier.
Bonnes pratiques pour débuter
Quand vous créez votre premier serveur MCP, commencez petit. C’est tentant de vouloir créer immédiatement un assistant capable de gérer tous vos fichiers, vos factures, votre calendrier, vos projets web et peut-être même votre cafetière. Mais ce n’est pas la meilleure approche.
Créez d’abord un outil très simple. Testez-le. Ajoutez ensuite un deuxième outil. Puis un troisième.
À chaque étape, vérifiez que tout fonctionne. Cette méthode progressive vous évitera de chercher une erreur pendant deux heures dans un projet devenu trop complexe trop rapidement.
Pensez aussi à nommer clairement vos outils. Un nom comme lire_notes est beaucoup plus parlant que tool1. L’IA utilise ces descriptions pour comprendre quand appeler tel ou tel outil. Plus vos noms et descriptions sont clairs, plus le résultat sera fiable.
Une fois la base comprise, vous l’aurez compris, les possibilités deviennent très intéressantes.
Vous pouvez créer un serveur MCP qui lit des fichiers de documentation dans un projet web. Vous pouvez aussi connecter l’IA à un dossier contenant des notes de formation. Vous pouvez imaginer un outil qui analyse des fichiers JSON, prépare des brouillons d’articles, vérifie des données locales ou récupère des informations depuis une API.
Pour un développeur web, un serveur MCP local peut devenir une passerelle entre l’assistant IA et l’environnement de travail. Il ne remplace pas votre jugement, mais il peut accélérer certaines tâches répétitives.
L’important est de garder le contrôle. MCP n’est pas une invitation à tout ouvrir sans réfléchir. C’est plutôt une manière propre de définir des portes d’entrée précises.
Ce code lit le dossier public, filtre les fichiers qui se terminent par .css, puis retourne la liste.
Là encore, l’idée est d’autoriser une action précise. L’IA ne fouille pas partout. Elle utilise un outil limité, conçu par vous.
Faut-il installer plusieurs serveurs MCP ?
Vous pouvez avoir plusieurs serveurs MCP selon vos besoins.
Par exemple, vous pourriez avoir un serveur pour les fichiers locaux, un serveur pour une API métier, un serveur pour des outils de développement, et un serveur pour des tâches de rédaction ou de documentation.
Cependant, au début, je vous conseille de rester sur un seul serveur simple. Ajoutez plusieurs outils dedans, puis séparez plus tard si le projet devient plus sérieux.
Cette approche permet d’apprendre sans multiplier les sources de confusion.
Peut-on utiliser un serveur MCP sans être développeur ?
Oui. Quelques bases en informatique et l’utilisation du terminal suffisent pour suivre les premières étapes. De nombreux serveurs MCP prêts à l’emploi existent déjà et permettent de découvrir le protocole sans écrire beaucoup de code.
Un serveur MCP local est-il sécurisé ?
Il peut l’être à condition de limiter les accès aux seules ressources nécessaires. Il est recommandé de n’autoriser que certains fichiers, dossiers ou actions spécifiques plutôt que de donner un accès complet à votre ordinateur.
Quelle est la différence entre un serveur MCP local et distant ?
Un serveur MCP local fonctionne directement sur votre machine et peut accéder à vos ressources locales. Un serveur distant est hébergé sur un serveur accessible via Internet, ce qui facilite son utilisation depuis plusieurs appareils ou services en ligne.
Installer un serveur MCP local, ce n’est pas seulement ajouter une nouvelle technologie à votre boîte à outils. C’est changer légèrement votre manière de travailler avec une intelligence artificielle.
Au lieu de voir Claude ou ChatGPT comme de simples fenêtres de discussion, vous commencez à les relier à des outils concrets, à des données maîtrisées et à des actions précises. C’est là que MCP devient vraiment intéressant.
Et surtout, gardez une règle en tête : un bon serveur MCP n’est pas celui qui peut tout faire. C’est celui qui fait clairement ce que vous lui demandez, dans un cadre sécurisé, compréhensible et maîtrisé.
C’est souvent comme cela que naissent les meilleurs outils : une petite expérimentation locale, un besoin concret, puis une amélioration après l’autre.

Fondateur de l’agence Créa-troyes, affiliée France Num
Intervenant en Freelance.
Contactez-moi
