MCP pour l'IA locale : donnez des mains à votre modèle, pas seulement une mémoire
Si vous avez lu notre guide sur le RAG respectueux de la vie privée, vous savez déjà rendre un modèle local conscient de vos documents : on retrouve le texte pertinent et on l'injecte dans le prompt. Cela résout un problème : la connaissance.
Mais cette connaissance-là est passive. Un modèle doté de RAG répond à partir des passages que vous avez récupérés pour lui. Il ne peut pas décider de lui-même d'ouvrir un autre fichier à l'instant, de lancer une requête fraîche sur une base de données vivante, puis d'agir sur la réponse.
C'est le vide que comble le Model Context Protocol (MCP). Là où le RAG donne une mémoire à votre modèle, MCP lui donne des mains — une manière standard de tendre le bras pour utiliser des outils, lire des données en direct et effectuer des actions. Et bien qu'il soit né dans le monde de l'IA cloud, MCP tourne à merveille avec un modèle entièrement local. Pas de cloud, pas de clés d'API, rien qui ne quitte votre machine.
Ce qu'est réellement MCP
La métaphore officielle est la meilleure : MCP est un port USB-C pour les applications d'IA.
Avant l'USB-C, chaque appareil réclamait son propre câble spécial. Avant MCP, chaque application d'IA voulant dialoguer avec vos fichiers, votre base de données ou une API devait écrire à la main sa propre intégration sur mesure — et aucune n'était réutilisable. MCP est la prise standard. Construisez un connecteur une fois et n'importe quelle IA compatible MCP peut l'utiliser.
C'est un protocole ouvert (qui n'appartient à aucune entreprise unique) pris en charge par un large éventail d'outils — Claude, ChatGPT, VS Code, Cursor et, ce qui nous intéresse ici, les configurations à LLM local. C'est tout l'intérêt : construire un outil une fois et il fonctionne partout.
MCP vs RAG : savoir contre agir
C'est la distinction qui fait tout comprendre, surtout si vous arrivez du guide RAG. Ce ne sont pas des concurrents — ils répondent à des questions différentes.
| RAG | MCP | |
|---|---|---|
| Répond à la question | « Que sait mon modèle ? » | « Que peut faire mon modèle ? » |
| Fonctionnement | Vous injectez le texte pertinent dans le prompt | Le modèle appelle des outils et lit des données à la demande |
| Les données | Passages récupérés dans les documents que vous avez indexés | En direct — une requête base de données, une lecture de fichier, un appel d'API, à l'instant |
| Peut-il agir ? | Non. Contexte en lecture seule. | Oui. Il peut écrire un fichier, lancer une requête, déclencher un workflow. |
Une image simple pour garder les deux en tête : le RAG est une carte de bibliothèque ; MCP est un trousseau de clés de voiture. L'un laisse le modèle consulter des choses. L'autre le laisse aller quelque part et faire quelque chose. Les configurations locales les plus capables utilisent les deux — le RAG pour une connaissance approfondie de vos documents, MCP pour les actions en direct.
Comment MCP est construit : hôte, client, serveur
MCP repose sur une architecture client–serveur propre, avec trois rôles. Une fois qu'on les voit, chaque montage MCP devient limpide.
- Hôte MCP (Host) — l'application d'IA que vous utilisez réellement. Elle exécute (ou dialogue avec) le modèle et coordonne l'ensemble. Voyez-la comme le poste de pilotage.
- Client MCP — un connecteur à l'intérieur de l'hôte. L'hôte lance un client par serveur auquel il se connecte et chaque client maintient une ligne dédiée vers son serveur.
- Serveur MCP — un petit programme qui expose une capacité : votre système de fichiers, une base de données, une recherche web, un agenda. Il peut tourner localement sur votre machine ou à distance.
Ainsi un même hôte peut faire tourner trois clients à la fois — un dialoguant avec un serveur de système de fichiers, un avec un serveur de base de données, un avec un serveur de recherche — chacun sur sa propre connexion.
Ce qu'expose un serveur : les trois primitives
Un serveur MCP peut proposer trois sortes de choses et il vaut la peine d'en connaître les noms car vous les verrez partout :
- Tools (outils) — des fonctions exécutables que le modèle peut invoquer pour agir : lire un fichier, lancer une requête, appeler une API. C'est celle qui donne des mains à votre modèle.
- Resources (ressources) — des sources de données qui fournissent du contexte : le contenu d'un fichier, un enregistrement de base de données, une réponse d'API. Information en lecture seule.
- Prompts — des modèles réutilisables qui structurent une interaction, comme un prompt système pré-construit ou un jeu d'exemples few-shot.
Sous le capot, tout repose sur JSON-RPC 2.0 — un format de messages simple et bien établi. Vous n'y touchez presque jamais directement (les outils s'en chargent pour vous), mais c'est ce qui rend MCP si portable : les mêmes messages fonctionnent que le serveur soit un script local ou un service distant.
- stdio — le serveur tourne comme un processus local sur votre machine et communique via l'entrée/sortie standard. Rapide, privé, sans réseau. C'est ce que vous utiliserez pour les outils locaux comme un serveur de système de fichiers.
- Streamable HTTP — le serveur tourne à distance et communique via HTTP. Utilisé pour les services hébergés, comme le connecteur de base de données partagé d'une entreprise.
Pour une configuration 100% locale et hors ligne, stdio est votre ami — le serveur vit sur votre machine et n'ouvre jamais de port réseau.
Le piège dont personne ne parle : Ollama n'est pas un client MCP
Voici la chose la plus importante à comprendre avant de vous lancer — et le détail que la plupart des tutoriels ratent.
Ollama ne parle pas MCP. Ollama est un serveur d'inférence : il exécute le modèle et expose une API de chat avec prise en charge du tool calling (appel d'outils). C'est tout. Il n'a aucune idée de ce qu'est un serveur MCP.
Vous ne pouvez donc pas « brancher MCP dans Ollama » directement. Il vous faut une pièce au milieu — un hôte/client MCP qui :
- parle MCP à vos serveurs (système de fichiers, base de données, etc.) et
- parle l'API de tool calling d'Ollama à votre modèle local.
Vos outils Le pont Votre modèle local
┌─────────────┐ ┌──────────────┐ ┌────────────────┐
│ serveurs MCP│◄───►│ hôte / │◄──────►│ Ollama │
│ (fichiers, │ MCP │ client MCP │ tool- │ (exécute le LLM)│
│ base) │ │ │ calling│ │
└─────────────┘ └──────────────┘ └────────────────┘
Le pont traduit entre les deux mondes. Une fois cela intégré, tout le paysage des projets « Ollama + MCP » prend soudain du sens — ce sont tous des ponts.
Le modèle que vous exécutez doit prendre en charge le tool calling. Ce n'est pas le cas de tous les modèles locaux. Des modèles comme Llama 3.1+, Qwen 2.5 et les variantes de Mistral compatibles avec les outils fonctionnent ; un modèle de base qui n'a jamais été entraîné à appeler des outils les ignorera tout simplement. Dans le doute, vérifiez la page du modèle avant de bâtir toute votre configuration autour de lui.
Un exemple local concret
Donnons à un modèle local la capacité de lire vos fichiers — en direct, à la demande, entièrement hors ligne.
Il vous faut trois choses :
Ollama, exécutant un modèle compatible avec les outils :
ollama pull qwen2.5Un pont — un client MCP conçu pour Ollama. L'option la plus dédiée est
mcp-client-for-ollama(dont la commande estollmcp), une application en terminal qui connecte les modèles Ollama locaux à un ou plusieurs serveurs MCP et prend en charge les trois primitives — tools, resources et prompts — ainsi qu'un mode agent.Un serveur MCP — pour cet exemple, le serveur de système de fichiers officiel, qui expose le dossier de votre choix sous forme d'outils que le modèle peut utiliser (lister les fichiers, lire les contenus, etc.).
Vous pointez le pont vers les deux : indiquez-lui quel modèle Ollama utiliser et à quel(s) serveur(s) MCP se connecter. À partir de cet instant, quand vous demandez « résume les notes dans mon dossier de projet », le modèle n'hallucine pas — il appelle l'outil de système de fichiers, lit les vrais fichiers et répond à partir de ce qu'il y a trouvé. Chaque octet reste sur votre machine.
Vous n'aimez pas le terminal ?
Le pont n'a pas à être un outil en ligne de commande. Deux options plus accueillantes :
- Open WebUI — une interface web auto-hébergée pour modèles locaux, avec prise en charge native de MCP. Un choix propre si vous voulez une fenêtre façon ChatGPT plutôt qu'un terminal.
- LM Studio — l'interface graphique de bureau populaire pour modèles locaux parle aussi MCP, vous pouvez donc câbler des serveurs depuis une application graphique.
Quel que soit votre choix, l'architecture de la section précédente est identique — seul le poste de pilotage change.
Pourquoi c'est important pour l'IA souveraine
Prenons du recul. MCP a été conçu pour les assistants cloud, mais c'est en local qu'il devient intéressant pour la confidentialité :
- Un assistant cloud avec un accès MCP à vos fichiers signifie que vos fichiers sont atteignables depuis les serveurs de quelqu'un d'autre.
- Un modèle local avec un accès MCP à vos fichiers signifie un agent capable qui lit vos documents, interroge vos bases de données et automatise vos tâches — et rien de tout cela ne quitte jamais votre machine.
C'est le rêve de l'IA locale poussé un cran plus loin. Le RAG a rendu votre modèle informé. MCP le rend utile. Ensemble, sur du matériel qui vous appartient, ils transforment un chatbot en assistant privé capable de vraiment faire avancer les choses.
Connaissance plus action, le tout tournant entièrement sur votre propre machine. Pas d'abonnement, pas de cloud, personne qui regarde par-dessus votre épaule. C'est toute l'idée.