MCP (Model Context Protocol) est un standard pour connecter une IA à des outils et des sources de données de façon plus homogène. Ce n’est ni un modèle, ni une magie d’accès total. Voici ce que ça change pour brancher des capacités, avec les précautions de permissions indispensables avant tout usage sensible.
Définition
Le Model Context Protocol (MCP) décrit comment un client d’IA (éditeur, agent, interface) peut dialoguer avec des serveurs MCP. Un serveur expose typiquement des capacités : outils appelables, ressources lisibles, parfois des modèles de prompts. Le client découvre ces capacités et les met à disposition du modèle via la boucle d’appel d’outils ou d’injection de contexte. Le protocole vise l’interopérabilité entre écosystèmes.
Ce que le mot ne désigne pas : MCP n’est pas un LLM. Ce n’est pas non plus une garantie que vos données restent locales — cela dépend de où tourne le client, le serveur, et le modèle. Ce n’est pas un substitut au prompt système métier. MCP organise le branchement ; votre gouvernance décide ce qui est branché. Sans liste blanche, « standard ouvert » peut aussi vouloir dire « surface d’attaque standardisée ».
Dans la pratique, vous verrez des serveurs MCP pour fichiers, bases, navigateurs, tickets, etc. Le client compatible les lance ou s’y connecte. Le modèle, lui, ne « parle MCP » que via le runtime. Comprendre MCP, c’est surtout comprendre la chaîne : client → serveur → permissions → modèle. Chaque maillon mérite une question : qui contrôle, qui journalise, qui peut écrire.
Un exemple du quotidien
Analogie : une prise électrique normalisée. Avant, chaque appareil avait son adaptateur maison. Avec une norme, vous branchez plusieurs appareils sur le même type de prise. MCP vise ce genre de confort pour les connecteurs d’IA : moins de bricolage unique par éditeur, plus de serveurs réutilisables. La norme ne dit pas si l’appareil est sûr : elle dit comment le brancher.
Concrètement, vous activez un serveur « dossier projet » en lecture, un autre « calendrier » en écriture contrôlée. L’assistant peut alors répondre avec le contenu autorisé ou proposer une action. Si vous débranchez le serveur, les capacités disparaissent. MCP rend ce branchement explicite — à condition de ne pas activer vingt serveurs « pour voir » sans lire leurs droits.
Un exemple en Hauts-de-France
À Denain, une PME industrielle teste un assistant pour interroger un dossier de procédures qualité (PDF et notes internes). L’équipe branche un serveur MCP limité à ce dossier, en lecture seule, sur une machine locale. Les opérateurs obtiennent des reformulations et des rappels de étapes ; ils ne peuvent pas faire modifier le serveur de production. Le protocole sert le cadre, pas l’inverse.
À Fourmies, une association compare un connecteur propriétaire d’un logiciel cloud et un serveur MCP open source pour sa base adhérents anonymisée. Le débat porte sur la maintenance, les logs, et qui a la clé. IAHDF insiste sur la même leçon qu’avec Ollama : la techno n’absout pas la gouvernance. Documentez le serveur, la version, le périmètre, et le responsable.
On confond souvent
Première confusion : « j’ai MCP, donc mon IA est sécurisée ». Faux. MCP structure l’accès ; la sécurité dépend des permissions, de l’authentification, du réseau, et de ce que le serveur peut faire. Un serveur MCP trop large (tout le disque, tout le navigateur) est risqué. Traitez chaque serveur comme une application à auditer.
Deuxième confusion : confondre MCP et le modèle lui-même, ou croire que MCP remplace le RAG. MCP peut exposer des ressources utiles au RAG ou des outils de recherche ; ce n’est pas automatiquement une indexation vectorielle. Autre mélange : penser que tous les clients « MCP » sont équivalents. Lisez la doc de votre client : capacités, sandbox, confirmations utilisateur.
En pratique, que faire avec ce mot
Quand vous choisissez un outil, demandez : gère-t-il MCP ? quels serveurs sont recommandés ? peut-on limiter lecture/écriture ? y a-t-il confirmation avant action ? Commencez par un serveur unique, périmètre minimal, journal activé. Testez une tâche réelle courte. Désactivez ce qui n’est pas nécessaire.
Pour une collectivité ou une TPE, ajoutez MCP à votre cartographie des traitements si des données personnelles circulent. Croisez avec l’appel d’outils et l’inférence locale. Préférez les serveurs dont le code ou la politique est lisible. Et souvenez-vous : brancher un serveur, c’est élargir le pouvoir de l’assistant — donc le pouvoir de l’erreur.
Termes voisins
- Client MCP
- L’application d’IA qui se connecte aux serveurs et expose leurs capacités au modèle.
- Serveur MCP
- Programme qui expose outils, ressources ou prompts selon le protocole.
- Appel d’outils
- Mécanisme d’exécution souvent utilisé via MCP. Voir appel d’outils.
- Sandbox
- Isolation qui limite ce qu’un serveur ou un outil peut toucher sur la machine.
Pour aller plus loin
Pour le mécanisme d’action, lisez l’appel d’outils ; pour le cadre, le prompt système. Les rencontres IAHDF : l’agenda. Pour rejoindre la communauté : l’inscription.
Questions fréquentes
C’est quoi MCP ?
MCP (Model Context Protocol) est un standard de connexion entre une application d’IA et des serveurs qui exposent outils ou données. Il vise à réduire les connecteurs propriétaires uniques. En pratique, vous activez un client compatible et des serveurs choisis. Ce n’est ni un modèle, ni une plateforme cloud obligatoire. C’est une façon normalisée de brancher des capacités, avec les mêmes exigences de permissions qu’un plugin classique. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.
MCP remplace-t-il les API ?
Souvent, un serveur MCP s’appuie lui-même sur des API ou des fichiers locaux. MCP ne fait pas disparaître les API : il uniformise la façon dont l’assistant les découvre et les appelle. Pour une équipe, cela peut simplifier le branchement dans plusieurs clients. Pour la sécurité, vous devez toujours comprendre ce que le serveur appelle derrière, avec quelles identifiants et quels droits. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.
Puis-je utiliser MCP entièrement en local ?
Oui, dans beaucoup de configurations : client local, modèle en inférence locale, serveurs MCP sur la même machine ou le réseau interne. Cela n’est pas automatique : vérifiez chaque composant. Un client local qui appelle un serveur distant, ou un modèle cloud, change le parcours des données. Dessinez le flux avant de brancher des dossiers sensibles. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.
Quels risques principaux ?
Sur-permissionnement (accès trop large au disque ou au navigateur), serveurs non maintenus, absence de journalisation, confirmation utilisateur désactivée, fuite de secrets dans les prompts. Réduisez le périmètre, mettez à jour, exigez une validation humaine pour les écritures, et séparez les comptes. MCP rend l’intégration plus simple — donc potentiellement plus dangereuse si on active tout par défaut. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.
Par quoi commencer concrètement ?
Choisissez un client que vous utilisez déjà et qui documente MCP. Ajoutez un seul serveur utile et borné (par exemple un dossier de démo sans données personnelles). Vérifiez les permissions, testez une question, observez les logs d’appel. Si le gain est clair, élargissez prudemment. Sinon, restez sur du texte et un prompt système bien écrit : parfois suffisant. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.