J'ai récemment intégré une API REST complète sur knowledge.arnaudallouche.fr pour gérer les articles, catégories, tags et médias de mon site. La question logique s'est alors posée : comment permettre à une IA comme Claude de gérer ce site directement, sans rédiger des requêtes cURL à la main ou ouvrir une interface d'administration à chaque fois ? La réponse tient en trois lettres : MCP.
Le Model Context Protocol est un standard ouvert développé par Anthropic qui change fondamentalement la façon dont les modèles de langage interagissent avec les applications extérieures. Plutôt que de se limiter à générer du texte, un LLM équipé d'un serveur MCP peut lire des données réelles, écrire dans des bases de données, appeler des APIs, déclencher des workflows — et piloter des applications entières via des instructions en langage naturel. J'ai implémenté ce pattern sur mon propre site, et je vous explique comment ça fonctionne concrètement, avec le code, les pièges, et un retour d'expérience honnête.
Qu'est-ce que MCP et pourquoi c'est différent
Avant MCP, quand vous vouliez qu'un LLM accède à des données externes, vous aviez deux options peu satisfaisantes. Soit vous colliez les données directement dans le prompt — ce qui ne scale pas au-delà de quelques pages de contexte — soit vous implémentiez du function calling propriétaire avec une interface différente pour chaque provider et chaque application. Résultat : des intégrations fragiles, non standardisées, impossibles à réutiliser d'un projet à l'autre.
MCP résout ce problème avec un protocole standardisé client-serveur. L'idée est simple mais puissante : les applications — appelées serveurs MCP — exposent des outils que les modèles d'IA — les clients MCP — peuvent découvrir et utiliser dynamiquement. Un peu comme des plugins, mais avec un protocole commun qui fonctionne quel que soit le LLM ou l'application ciblée.
La différence fondamentale avec les approches précédentes : le modèle ne sait pas à l'avance quels outils sont disponibles. Il les découvre au démarrage de la session, comme un développeur qui lirait une documentation d'API pour la première fois. Cela rend le système extensible — ajoutez un outil à votre serveur, et le modèle peut l'utiliser immédiatement sans re-déploiement ni modification côté IA.
L'anatomie d'un serveur MCP
Un serveur MCP est, dans sa forme la plus simple, un script qui tourne en local sur votre machine et expose des outils via un protocole de communication standardisé. Le transport par défaut est stdio : le client (Claude Code) démarre votre script en subprocess et communique via stdin/stdout avec des messages JSON. C'est volontairement simple pour favoriser la portabilité.
Concrètement, voici ce que contient un serveur MCP minimal en Python avec la librairie mcp d'Anthropic :
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("mon-serveur")
@mcp.tool()
async def lire_article(article_id: int) -> str:
"""Récupère le contenu complet d'un article par son ID"""
# votre logique ici
return "contenu de l'article"
@mcp.tool()
async def creer_article(titre: str, contenu: str) -> str:
"""Crée un nouvel article en brouillon"""
# votre logique ici
return "Article créé avec l'ID 42"
if __name__ == "__main__":
mcp.run()
Chaque fonction décorée avec @mcp.tool() devient un outil que le modèle peut appeler. La docstring est cruciale : c'est elle que Claude lit pour comprendre quand et comment utiliser l'outil. Une mauvaise description produit des outils mal utilisés ou ignorés. J'ai personnellement passé plus de temps à rédiger des descriptions claires qu'à écrire le code des outils eux-mêmes — et c'est un investissement qui paie immédiatement.
Le protocole définit trois types de primitives :
- Tools : des fonctions que le modèle peut appeler (lire, écrire, calculer, appeler une API...)
- Resources : des données que le modèle peut lire (fichiers, URLs, résultats de requêtes)
- Prompts : des templates de prompts réutilisables pour des workflows récurrents
Pour la grande majorité des cas d'usage pratiques — piloter une API, gérer du contenu, automatiser des tâches — les Tools suffisent largement. Les Resources et Prompts deviennent utiles pour des architectures plus complexes avec de la gestion d'état persistant ou des workflows multi-étapes élaborés.
Mettre un serveur MCP devant une API REST existante
Le cas d'usage le plus immédiat : vous avez déjà une API REST et vous voulez la rendre pilotable par un LLM. C'est exactement ce que j'ai fait pour ce site. L'API Django existante expose des endpoints pour créer, modifier, supprimer des articles — le serveur MCP fait le travail de translation entre les appels du modèle et les requêtes HTTP. C'est une couche fine, sans logique métier :
import os, json
import httpx
from mcp.server.fastmcp import FastMCP
API_URL = os.environ.get("API_URL", "https://knowledge.arnaudallouche.fr")
API_TOKEN = os.environ.get("API_TOKEN", "")
mcp = FastMCP("knowledge-api")
def _headers():
return {"Authorization": f"Token {API_TOKEN}", "Content-Type": "application/json"}
@mcp.tool()
async def creer_article(
titre: str,
contenu: str,
statut: str = "draft",
categorie_id: int = None,
tag_ids: list[int] = None
) -> str:
"""
Crée un nouvel article sur le site.
statut : 'draft' (brouillon) ou 'published' (publié immédiatement).
Toujours récupérer les IDs via list_categories() et list_tags() avant d'appeler cet outil.
"""
payload = {"title": titre, "content": contenu, "status": statut}
if categorie_id:
payload["category"] = categorie_id
if tag_ids:
payload["tags"] = tag_ids
async with httpx.AsyncClient() as c:
r = await c.post(f"{API_URL}/api/articles/", json=payload, headers=_headers())
return json.dumps(r.json(), indent=2, ensure_ascii=False)
L'architecture est limpide : le serveur MCP ne contient aucune logique métier. Il traduit les appels d'outils en requêtes HTTP, gère l'authentification, et retourne les réponses au modèle. Toute la logique reste dans votre API. Cette séparation des responsabilités est fondamentale — votre API reste utilisable indépendamment du MCP, et le serveur MCP peut évoluer sans toucher au backend.
Un point critique souvent négligé : le token d'authentification ne doit jamais être en dur dans le code. Passez-le via une variable d'environnement. Si vous versionnez votre serveur MCP sur GitHub, vous n'exposez pas accidentellement vos credentials. Même principe que les fichiers .env pour les configurations sensibles.
Comment Claude utilise concrètement les outils MCP
Quand Claude Code démarre avec un serveur MCP configuré, le modèle commence par demander la liste des outils disponibles. Votre serveur répond avec les noms, descriptions et schémas de paramètres de chaque outil. À partir de là, Claude intègre ces capacités comme s'il les avait toujours eues — il n'y a pas de prompt spécial à rédiger, pas de syntaxe particulière à connaître.
Ce qui se passe ensuite est fascinant. Si je lui dis « crée-moi un article sur les bonnes pratiques Docker, catégorie Développement, avec les tags Python et DevOps », Claude va de lui-même :
- Appeler
list_categories()pour récupérer l'ID de la catégorie "Développement" - Appeler
list_tags()pour récupérer les IDs de "Python" et "DevOps" - Rédiger le contenu de l'article en HTML
- Appeler
create_article()avec le contenu rédigé et les IDs corrects - Confirmer en retournant le lien vers l'article créé
Tout ça sans une seule ligne de code supplémentaire de ma part, sans ouvrir l'interface d'administration, sans copier-coller quoi que ce soit. Une instruction en langage naturel déclenche une cascade d'appels API coordonnés. C'est là que le pattern MCP révèle toute sa puissance : le LLM gère le raisonnement, l'orchestration et la décision — le serveur MCP gère l'exécution.
J'ai testé des scénarios plus complexes, comme « analyse les 5 derniers articles publiés et crée un article récapitulatif avec des liens vers chacun ». Claude a récupéré les articles un par un, analysé leur contenu, rédigé le récapitulatif avec les bons liens, et créé le brouillon — le tout en un seul prompt, sans intervention de ma part.
La configuration côté Claude Code
Côté client, la configuration est triviale. Claude Code supporte MCP nativement. Vous déclarez vos serveurs dans un fichier mcp.json à la racine de votre projet :
{
"mcpServers": {
"knowledge-api": {
"command": "python",
"args": ["mcp_server.py"],
"env": {
"API_URL": "https://knowledge.arnaudallouche.fr",
"API_TOKEN": "votre_token_ici"
}
}
}
}
Ou via la commande CLI, une seule fois :
claude mcp add knowledge-api \
--command python \
--args "mcp_server.py" \
--env API_URL=https://knowledge.arnaudallouche.fr \
--env API_TOKEN=votre_token_ici
Au démarrage de la session, Claude Code lance automatiquement tous les serveurs MCP déclarés, découvre leurs outils, et les intègre. Aucun redémarrage, aucune configuration supplémentaire. La friction d'adoption est quasi nulle.
Cas d'usage concrets : ce que vous pouvez vraiment faire
Après avoir utilisé MCP au quotidien sur mes projets, voici les scénarios où j'ai constaté des gains de productivité réels et mesurables.
Gestion de contenu sans interface. Plutôt que d'ouvrir un CMS, naviguer dans les menus et remplir les formulaires, je dicte mes instructions à Claude. « Crée un article sur X dans la catégorie Y, mets-le en brouillon, ajoute les tags Z » — 30 secondes contre 5 minutes sur l'interface. Sur un site avec beaucoup de contenu, le gain s'accumule vite.
Audits et corrections en masse. « Liste tous les articles qui n'ont pas de meta description et génère-en une pour chacun. » Ce type de tâche répétitive qui prendrait des heures manuellement devient triviale. Claude parcourt les données via les outils de lecture, prend les décisions de rédaction, et exécute les modifications via les outils d'écriture.
Automatisation de workflows complexes. « Pour chaque article publié cette semaine, vérifie qu'il a une image à la une, un excerpt et une meta description. Pour ceux qui en manquent, génère les éléments manquants. » Un seul prompt orchestre plusieurs lectures et écritures enchaînées.
Monitoring via langage naturel. Connecter un serveur MCP à vos logs applicatifs ou métriques permet de demander « quelles sont les URLs qui génèrent le plus d'erreurs 404 ce mois-ci ? » et d'obtenir une analyse structurée, plutôt qu'une liste brute de logs à parser à la main.
Les limites qu'il faut anticiper
MCP n'est pas magique, et plusieurs écueils méritent d'être adressés avant de déployer ça en production.
La sécurité avant tout. Donner à un LLM la capacité de modifier vos données en production, c'est s'exposer à des erreurs de raisonnement du modèle. J'ai vu Claude interpréter « supprime les vieux articles » en ciblant des articles que je ne souhaitais pas supprimer, parce qu'il avait mal interprété le critère "vieux". La solution : implémentez des outils de suppression qui nécessitent une confirmation explicite, limitez les permissions par défaut à la lecture seule, et utilisez des tokens avec des droits minimaux.
La fenêtre de contexte se sature vite. Si votre API retourne des objets massifs — articles avec contenu HTML long, réponses avec des centaines de résultats — vous saturez rapidement le contexte du modèle. Concevez vos outils pour retourner des réponses concises. Un outil list_articles qui retourne titre + ID + statut, et un get_article séparé pour le détail à la demande : c'est bien plus efficace qu'un seul outil qui retourne tout.
La latence s'accumule. Chaque appel d'outil implique un aller-retour réseau. Un workflow avec dix étapes séquentielles peut prendre 30 à 60 secondes. Ce n'est pas un problème pour les tâches de fond ou les workflows non-interactifs, mais c'est rédhibitoire pour des interactions temps réel avec des utilisateurs finaux.
Les hallucinations sur les IDs. Les LLMs ont tendance à inventer des identifiants numériques quand ils ne les ont pas récupérés explicitement. J'ai vu Claude passer un category_id inexistant parce qu'il le devinait plutôt que de l'avoir récupéré via list_categories. La solution : précisez dans les docstrings que les IDs doivent être récupérés via les outils de liste, et retournez des messages d'erreur explicites côté API.
MCP vs function calling classique : quand choisir quoi ?
La question revient souvent : en quoi MCP est-il différent du function calling que Claude et GPT-4 supportent nativement ? La distinction est importante.
Le function calling classique est défini dans le prompt, côté application. Vous passez la liste des fonctions disponibles à chaque appel API du LLM, et le modèle retourne des JSON avec les appels à exécuter. C'est votre application qui orchestre l'exécution. C'est adapté pour des intégrations simples et monolithiques où tout tourne dans le même process.
MCP résout un problème différent : la découvrabilité et la réutilisabilité à travers des clients différents. Votre serveur MCP peut être utilisé par Claude Code, par Claude Desktop, par n'importe quelle application compatible MCP — sans modifier une ligne de code. C'est un protocole standardisé, comme REST pour les APIs web ou OAuth pour l'authentification.
Autre différence pratique : MCP isole la logique d'intégration dans un processus séparé. Votre serveur MCP peut s'authentifier, mettre en cache des résultats, retry sur erreur — tout ça indépendamment du modèle qui l'utilise. C'est une architecture plus propre et plus maintenable que d'inclure cette logique dans chaque prompt ou chaque appel API.
L'avenir : des agents qui pilotent des applications entières
Ce qui m'enthousiasme dans MCP, ce n'est pas uniquement la gestion de contenu. C'est ce que ça rend possible comme nouveau paradigme de développement. Imaginez : vous développez une application e-commerce. Plutôt que de construire une interface d'administration complète avec des dizaines d'écrans, vous exposez vos opérations via un serveur MCP. Le back-office devient un agent IA auquel vous décrivez ce que vous voulez faire en langage naturel.
« Applique une remise de 20% sur tous les produits de la catégorie Hiver dont le stock est supérieur à 50 unités, mais uniquement pour les clients avec un historique d'achat de plus de 12 mois. » Une règle métier complexe qui nécessiterait normalement du code sur mesure ou plusieurs écrans d'interface devient une instruction humaine que l'agent décompose, planifie et exécute étape par étape.
Ce n'est pas de la science-fiction. Les primitives existent aujourd'hui. Ce qu'il manque encore, c'est la fiabilité et la prévisibilité suffisantes pour déléguer des actions critiques sans supervision humaine. Les modèles font encore des erreurs de raisonnement sur des workflows complexes — les garde-fous (confirmations, dry-run modes, rollback automatique) sont encore à construire domaine par domaine. Mais la trajectoire est claire, et MCP est l'infrastructure sur laquelle ces agents seront construits.
Conclusion : MCP comme pont entre l'IA et vos applications
J'ai commencé par vouloir gérer mon blog plus facilement. J'ai fini par implémenter un protocole qui change ma façon de penser l'automatisation. MCP n'est pas une révolution technologique en soi — c'est un standard de communication, comme REST pour les APIs web ou OAuth pour l'authentification. Sa valeur vient de la standardisation et de l'adoption croissante par l'écosystème.
Si vous avez une API REST existante, la mettre derrière un serveur MCP est une affaire de quelques heures. Les librairies Python et TypeScript sont bien documentées, le pattern est simple, et les gains de productivité sont immédiatement perceptibles. Mon conseil : commencez petit — un serveur avec 3 ou 4 outils de lecture, testez le workflow avec Claude Code, puis étendez progressivement avec les opérations d'écriture au fur et à mesure que vous gagnez confiance dans le comportement du modèle.
Le vrai conseil pratique : traitez vos outils MCP comme une API publique bien conçue, pas comme des scripts internes. Des noms clairs, des descriptions précises, des retours d'erreur explicites. Le modèle est votre utilisateur — il interprète les descriptions, déduit le comportement attendu, réagit aux messages d'erreur. Soignez ces interfaces comme vous soigneriez une documentation pour des développeurs humains. C'est exactement le même effort, pour exactement le même résultat.
MCP est disponible dès aujourd'hui dans Claude Code et Claude Desktop. L'écosystème grandit rapidement — des serveurs MCP pour GitHub, Postgres, Slack, Figma existent déjà. Votre application mérite peut-être d'en avoir un aussi.