MCP a Transformé Mon IA de Chatbot en Véritable Agent
J'ai fixé mon écran pendant une bonne trentaine de secondes, sincèrement confus.
Claude venait de créer une note dans mon coffre-fort Obsidian — pas parce que j'avais copié-collé du texte, pas parce que j'avais utilisé une intégration Zapier — mais parce que je le lui avais demandé. En français courant. « Crée une note sur le café à la presse française. » Et la voilà, dans mon coffre-fort comme si je l'avais écrite moi-même.
C'était il y a trois semaines. Depuis, j'ai connecté Claude à mon gestionnaire de tâches, mon calendrier, un web scraper, des transcriptions YouTube et — je n'invente rien — Kali Linux. Mon IA peut maintenant hacker pour moi. Enfin, plus ou moins. Mais le constat est là : quelque chose de fondamental a changé, et la plupart des développeurs à qui j'en parle ne s'en sont pas encore rendu compte.
Ce changement a un nom. Il s'appelle MCP — le Model Context Protocol. Et une fois que vous comprenez ce qu'il fait, vous réalisez que l'écart entre « chatbot IA » et « agent IA » n'est pas un problème de recherche lointain. C'est un fichier de configuration.
Voici ce que je n'attendais pas : le plus difficile n'a pas été la technologie. Le plus difficile a été de désapprendre ma façon de penser l'IA.
Le Problème Dont Personne Ne Parle
J'ai récemment regardé l'analyse de NetworkChuck sur MCP — une plongée approfondie de 38 minutes qui a déjà dépassé les 1,2 million de vues — et quelque chose qu'il a dit au début a fait tilt dans mon esprit d'une manière que des mois de lecture de documentation n'avaient pas réussi.
Il a comparé les LLMs à des personnes. Restez avec moi.
Quand vous ou moi voulons utiliser un outil — disons, ClickUp pour la gestion de tâches — nous interagissons via une interface graphique. Boutons, menus, glisser-déposer. L'interface abstrait toute la complexité sous-jacente. Nous n'avons pas besoin de connaître le schéma de la base de données ni les endpoints de l'API. Nous cliquons, tout simplement.
Les LLMs détestent les interfaces graphiques. Ils peuvent techniquement interagir avec elles (des agents basés sur des captures d'écran existent), mais c'est lent, peu fiable, et c'est comme apprendre à quelqu'un à conduire en lui montrant des photos de volants.
D'accord, alors donnez-leur des APIs ? C'est à ça que servent les APIs — permettre à un programme de communiquer avec un autre de manière programmatique. Et oui, ça fonctionne. Mais voici le problème que Chuck a parfaitement identifié : chaque API possède des centaines d'endpoints avec des schémas d'authentification uniques, des formats de paramètres et des structures de réponse. Rien que l'API de ClickUp est massive. Celle d'Obsidian aussi. Celle de GitHub aussi. Et celle de n'importe quel autre outil que vous voudriez que votre IA utilise.
Pour connecter un LLM à seulement cinq outils via des APIs brutes, il faudrait écrire du code d'intégration personnalisé pour chacun, gérer l'authentification pour chacun, parser les réponses de chacun, puis d'une manière ou d'une autre apprendre au LLM quels endpoints appeler et quand.
Je l'ai fait. Pour un projet client l'année dernière, j'ai passé deux semaines à construire une couche personnalisée d'appel d'outils pour GPT-4 qui se connectait à trois APIs internes. Deux semaines. Trois outils.
MCP change complètement cette équation.
Ce Qu'est Réellement MCP (Sans le Battage Médiatique)
Le Model Context Protocol est, en son cœur, une interface standardisée entre les LLMs et les outils externes. Anthropic l'a créé, mais c'est devenu un standard industriel adopté par OpenAI, Google et pratiquement toutes les entreprises d'outillage IA.
Pensez-y comme l'USB-C pour les outils d'IA. Avant l'USB-C, chaque appareil avait son propre connecteur propriétaire. Vous aviez besoin d'un tiroir plein de câbles. L'USB-C a dit : « Voici un standard. Tout le monde l'utilise. » MCP fait la même chose pour la communication entre LLMs et outils.
Voici l'architecture en termes simples :
LLM (Claude, GPT, Llama)
↕ parle le protocole MCP
MCP Server (s'exécute localement ou à distance)
↕ gère toute la partie compliquée de l'API
Outil Externe (Obsidian, ClickUp, GitHub, etc.)
Le serveur MCP se place entre votre IA et les outils dont elle a besoin. Il gère l'authentification, les appels API, le parsing des réponses — tout. Le LLM n'a pas besoin de savoir quoi que ce soit sur les endpoints REST ou les tokens OAuth. Il voit simplement une liste d'« outils » disponibles décrits en langage clair :
create_note— Créer une nouvelle note dans le coffre-fortsearch_vault— Rechercher du contenu dans toutes les notesappend_content— Ajouter du contenu à une note existante
Le LLM choisit le bon outil, passe les paramètres et reçoit des résultats structurés. C'est tout. Pas de code personnalisé. Pas de lutte avec les APIs.
Mais voici la partie qui m'a fait dresser l'oreille — et cela rejoint quelque chose de bien plus grand.
De Chatbot à Agent : Les Trois Niveaux
Pendant que je configurais des serveurs MCP, je suis tombé sur l'explication de Jeff Su sur les agents IA — une vidéo qui a atteint près de 4 millions de vues — et elle a cristallisé quelque chose que je ressentais mais ne pouvais pas articuler.
Jeff divise l'IA en trois niveaux, et une fois que vous les voyez, vous ne pouvez plus les ignorer :
Niveau 1 : LLM Basique. Vous donnez une entrée, vous obtenez une sortie. Demander à ChatGPT de rédiger un email ? Super. Lui demander quand est votre prochaine réunion ? Échec. Il ne sait pas. Il n'a pas accès. Il génère simplement du texte basé sur des données d'entraînement.
Niveau 2 : Workflow IA. Vous ajoutez des chemins prédéfinis. « Quand l'utilisateur pose une question sur les événements du calendrier, d'abord consulter Google Calendar, puis répondre. » Ça fonctionne — jusqu'à ce que l'utilisateur demande quelque chose que vous n'aviez pas anticipé. « Quel temps fera-t-il le jour de ma réunion ? » Votre workflow ne connaît que Google Calendar, pas les APIs météo. Chaque nouvelle capacité nécessite qu'un humain ajoute manuellement un autre chemin.
Voici l'insight clé de l'analyse de Jeff : peu importe combien d'étapes vous ajoutez — des centaines, des milliers — si un humain est le décideur de quel chemin suivre, c'est toujours juste un workflow. Pas un agent.
Niveau 3 : Agent IA. Le LLM lui-même décide quoi faire. Il raisonne (« J'ai besoin de données de calendrier ET de données météo »), sélectionne les outils (« Je vais utiliser l'API Google Calendar d'abord, puis un service météo »), exécute, évalue le résultat et itère si nécessaire.
Le framework derrière cela s'appelle ReAct — Reason and Act (Raisonner et Agir). L'agent réfléchit à ce dont il a besoin, agit en utilisant des outils, observe le résultat et décide s'il continue ou retourne une réponse finale.
Et c'est là que MCP devient la pièce manquante. Parce qu'un agent IA a besoin d'outils pour agir. Sans outils, il ne fait que penser à voix haute. MCP lui donne des mains.
Configurer MCP avec Docker (La Partie Pratique)
Je l'ai appris à mes dépens : n'essayez pas d'installer des serveurs MCP manuellement lors de votre premier essai. Utilisez Docker. Il gère l'isolement, les dépendances et le nettoyage automatiquement.
Voici mon processus exact de configuration :
Étape 1 : Installer Docker Desktop
Téléchargez-le depuis le site officiel pour votre système d'exploitation. Sur Mac :
# Téléchargez et installez Docker Desktop depuis docker.com/desktop
# Ou via Homebrew :
brew install --cask docker
# Vérifier l'installation
docker --version
# Docker version 28.x.x
# Activer MCP Toolkit dans Docker Desktop :
# Settings → Beta Features → Docker MCP Toolkit → Enable
Sur Windows, vous aurez besoin de WSL 2 ou Hyper-V comme backend d'abord. Linux est simple — installez simplement Docker Engine et Desktop.
Étape 2 : Parcourir le Catalogue MCP
Docker Desktop est maintenant livré avec un catalogue MCP — une liste organisée de serveurs MCP officiels. Ouvrez Docker Desktop, allez dans la section MCP Toolkit et parcourez le catalogue. J'ai été sincèrement surpris par ce qui est disponible :
- Obsidian — Accès complet au coffre-fort (lire, écrire, chercher)
- Brave Search — Recherche web avec confidentialité
- Fetch — Récupérer le contenu de n'importe quelle URL
- YouTube Transcripts — Extraire la transcription de n'importe quelle vidéo
- DuckDuckGo — Rechercher sans clés API
- Airbnb — Chercher des logements (oui, vraiment)
Ajouter un serveur se fait en un clic. Certains nécessitent des clés API (Brave, par exemple), mais beaucoup fonctionnent directement.
Étape 3 : Connecter Votre Client LLM
Docker MCP Toolkit prend en charge plusieurs clients :
- Claude Desktop (le niveau gratuit fonctionne)
- Cursor (pour le travail centré sur le code)
- LM Studio (pour les modèles locaux comme Llama)
Cliquez sur « Connect » à côté de votre client. Docker met automatiquement à jour le fichier de configuration MCP que votre client lit. Pour Claude Desktop, ce fichier se trouve à ~/Library/Application Support/Claude/claude_desktop_config.json sur Mac.
Voici à quoi ressemble la configuration en coulisses :
{
"mcpServers": {
"obsidian": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "OBSIDIAN_API_KEY=your-key-here",
"mcp/obsidian"
]
},
"fetch": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/fetch"]
},
"youtube-transcript": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/youtube-transcript"]
}
}
}
Chaque serveur s'exécute comme un conteneur Docker isolé. Quand Claude a besoin d'utiliser un outil, il lance le conteneur, fait l'appel, et le conteneur s'arrête. Propre. Isolé. Aucun conflit de dépendances.
Étape 4 : Tester
Redémarrez Claude Desktop. Cliquez sur l'icône de paramètres — vous devriez voir « MCP Docker » listé. Cliquez dessus pour vérifier que vos outils sont chargés.
Puis demandez simplement : « Cherche dans mon coffre-fort Obsidian les notes sur la planification de projets. »
Claude reconnaîtra qu'il dispose de l'outil search_vault, demandera la permission de l'utiliser (uniquement la première fois si vous le choisissez) et retournera des résultats de votre coffre-fort réel.
La première fois que j'ai vu ça fonctionner, j'ai littéralement dit « C'est une blague ? » à voix haute. Dans une pièce vide. À 2 heures du matin.
Construire un Serveur MCP Personnalisé
Le catalogue est excellent pour les outils courants. Mais la vraie puissance se déverrouille quand vous construisez des serveurs personnalisés pour vos besoins spécifiques.
La vidéo de NetworkChuck a montré quelque chose de dingue : il a construit un serveur MCP qui encapsule les outils de Kali Linux. Son IA pouvait lancer des scans nmap, utiliser Metasploit et énumérer des cibles — le tout en langage naturel.
J'ai construit quelque chose de moins spectaculaire mais plus pratique pour mon travail quotidien : un serveur MCP qui encapsule l'API du CMS de mon blog. Voici le squelette :
#!/usr/bin/env python3
"""Serveur MCP personnalisé pour le CMS du blog mejba.me."""
import json
import httpx
from mcp.server import Server
from mcp.types import Tool, TextContent
app = Server("blog-cms")
BASE_URL = "https://mejba.me/api"
API_TOKEN = "your-api-token"
@app.list_tools()
async def list_tools():
return [
Tool(
name="create_draft",
description="Create a new blog post draft with title, content, and tags",
inputSchema={
"type": "object",
"properties": {
"title": {"type": "string", "description": "Post title"},
"content": {"type": "string", "description": "Markdown content"},
"tags": {"type": "array", "items": {"type": "string"}}
},
"required": ["title", "content"]
}
),
Tool(
name="list_recent_posts",
description="List the most recent blog posts with their status",
inputSchema={
"type": "object",
"properties": {
"limit": {"type": "integer", "default": 10}
}
}
),
Tool(
name="get_post_analytics",
description="Get view count and engagement metrics for a post",
inputSchema={
"type": "object",
"properties": {
"slug": {"type": "string", "description": "Post slug"}
},
"required": ["slug"]
}
)
]
@app.call_tool()
async def call_tool(name: str, arguments: dict):
headers = {"Authorization": f"Bearer {API_TOKEN}"}
if name == "create_draft":
response = httpx.post(
f"{BASE_URL}/posts",
headers=headers,
json={
"title": arguments["title"],
"content": arguments["content"],
"tags": arguments.get("tags", []),
"status": "draft"
}
)
data = response.json()
return [TextContent(
type="text",
text=f"Draft created: {data['slug']} (ID: {data['id']})"
)]
elif name == "list_recent_posts":
limit = arguments.get("limit", 10)
response = httpx.get(
f"{BASE_URL}/posts?limit={limit}", headers=headers
)
posts = response.json()
result = "\n".join(
f"- [{p['title']}] ({p['status']}) - {p['views']} views"
for p in posts
)
return [TextContent(type="text", text=result)]
elif name == "get_post_analytics":
response = httpx.get(
f"{BASE_URL}/posts/{arguments['slug']}/analytics",
headers=headers
)
data = response.json()
return [TextContent(
type="text",
text=json.dumps(data, indent=2)
)]
if __name__ == "__main__":
import asyncio
from mcp.server.stdio import stdio_server
asyncio.run(stdio_server(app))
Encapsulez cela dans un Dockerfile, et n'importe quel client compatible MCP peut utiliser le CMS de votre blog en langage naturel. « Hé Claude, crée un brouillon d'article sur MCP avec ces tags. » Terminé.
Le modèle fonctionne pour tout ce qui a une API : tableaux de bord internes, bases de données, appareils IoT, pipelines CI/CD. Si ça a une API, vous pouvez l'encapsuler dans un serveur MCP en moins d'une heure.
Les Erreurs Honnêtes que J'ai Commises
Je veux être transparent sur ce qui m'a fait trébucher, parce que je pense que ce sont des erreurs que la plupart des gens commettront.
Erreur 1 : Traiter les agents MCP comme de l'automatisation traditionnelle. Mon premier instinct a été de construire des workflows rigides — « Quand je dis X, fais Y. » Mais tout l'intérêt du paradigme d'agent est que le LLM décide quels outils utiliser et quand. Je continuais à trop le contraindre. Les meilleurs résultats sont venus quand j'ai donné un objectif à Claude et l'ai laissé déterminer la séquence d'outils.
Erreur 2 : Ignorer le modèle de permissions. Les serveurs MCP peuvent accéder à vos fichiers, vos APIs, votre réseau. Claude Desktop demande la permission avant chaque utilisation d'outil (sauf si vous l'autorisez définitivement). J'ai désactivé les demandes de confirmation par commodité, puis j'ai oublié que j'avais un serveur MCP connecté à mon email. Claude a gentiment « organisé » ma boîte de réception sur la base d'un commentaire désinvolte que j'avais fait. Leçon retenue : gardez les permissions strictes jusqu'à ce que vous fassiez confiance au workflow.
Erreur 3 : Attendre la perfection des modèles locaux. J'ai essayé de faire tourner des agents connectés à MCP via LM Studio avec Llama 3.1. La sélection d'outils était nettement moins bonne qu'avec Claude. Les modèles locaux fonctionnent, mais ils ont besoin de prompts plus explicites sur quand et comment utiliser les outils. Claude et GPT-4 sont nettement meilleurs pour la sélection autonome d'outils — pour l'instant.
Voici une opinion controversée : je pense que la plupart des produits d'« agents IA » vendus actuellement sont en réalité des workflows de Niveau 2 déguisés en agents. Ils suivent des chemins prédéfinis avec un peu de prise de décision LLM saupoudrée. Les vrais agents de Niveau 3 — où le LLM raisonne véritablement sur la sélection d'outils, l'ordre d'exécution et itère de manière autonome — sont rares en dehors des démos de recherche et d'une poignée d'implémentations réelles.
Cela dit, MCP est la couche d'infrastructure qui rend les vrais agents possibles. Le protocole existe. Les outils existent. Ce qui rattrape son retard, c'est la capacité de raisonnement des modèles eux-mêmes.
À Quoi Cela Ressemble en Pratique
Après trois semaines à construire des workflows basés sur MCP, voici mon avant/après concret :
Recherche pour le blog — Avant : 2-3 heures à regarder manuellement des vidéos YouTube, prendre des notes, croiser les références avec la documentation. Après : 25 minutes. Claude extrait les transcriptions YouTube via MCP, cherche dans mon coffre-fort de recherche Obsidian les notes connexes et rédige un plan structuré. J'édite à partir de là.
Mise en place de projets clients — Avant : 45 minutes à créer des repos, configurer le CI/CD, ajouter au suivi de projets. Après : 8 minutes. Claude crée le repo GitHub, initialise la structure du projet, l'ajoute à ClickUp avec des jalons et envoie une notification Slack à l'équipe. Le tout via des outils connectés par MCP.
Préparation du standup quotidien — Avant : 15 minutes à vérifier ClickUp, les PRs GitHub et les canaux Slack. Après : 2 minutes. « Sur quoi ai-je travaillé hier et qu'est-ce qui est en attente pour aujourd'hui ? » Claude vérifie les trois et me donne un résumé.
Les gains de temps sont réels. Pas théoriques. Pas « jusqu'à X % ». Ce sont mes chiffres réels des trois dernières semaines.
Mais — et c'est important — la configuration initiale m'a pris un week-end entier. Installer Docker, configurer les serveurs, tester les connexions, débuguer quand les choses ne marchaient pas. Une fois que ça tourne, c'est magique. Y arriver demande de la patience.
Où Tout Cela Mène
NetworkChuck a mentionné quelque chose à la fin de sa vidéo que je pense que la plupart des spectateurs ont ignoré : le Docker MCP Gateway. Cela rend vos serveurs MCP locaux accessibles à distance — ce qui signifie que des outils comme n8n, Make.com ou n'importe quelle plateforme d'automatisation externe peuvent se connecter à vos serveurs MCP via le réseau.
Réfléchissez à ce que cela signifie. Votre agent IA n'est plus limité à votre machine locale. Vous pourriez avoir un workflow n8n qui déclenche un agent Claude utilisant vos serveurs MCP personnalisés tournant sur un VPS. L'agent raisonne sur ce qu'il faut faire, utilise des outils via MCP et retourne des résultats — le tout sans intervention humaine.
Nous n'en sommes pas encore là pour la plupart des cas d'utilisation en production. Mais l'écart entre « démo » et « production » se réduit plus vite que je ne l'aurais cru.
Si vous ne retenez qu'une chose de cet article : n'attendez pas que les agents IA soient « prêts ». L'infrastructure — MCP, conteneurs Docker, LLMs avec appel d'outils — est là maintenant. Les développeurs qui apprennent cette stack aujourd'hui auront un avantage considérable quand les capacités de raisonnement rattraperont leur retard.
Je parie mon workflow dessus. Et honnêtement ? Trois semaines plus tard, ça rapporte déjà.
Travaillons Ensemble
Vous cherchez à construire des systèmes d'IA, automatiser des workflows ou faire évoluer votre infrastructure technologique ? J'adorerais vous aider.
- Fiverr (builds et intégrations sur mesure) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design et branding) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
