MCP, le Model Context Protocol

Un assistant conversationnel ne sait rien de votre entreprise. Il répond très bien aux questions générales et se trompe dès qu’il faut vos chiffres à vous. Pendant deux ans, la parade a consisté à coller des exports dans la fenêtre de discussion. Lourd, invérifiable, et périmé le lendemain.

Le Model Context Protocol répond à ce problème par une norme d’interconnexion. Anthropic l’a publié en open source fin 2024, et les principaux éditeurs d’assistants l’ont adopté depuis. L’idée tient en une phrase : permettre à une IA d’appeler vos systèmes de façon standardisée, au lieu d’écrire une intégration sur mesure pour chaque couple assistant-outil.

L’architecture est volontairement pauvre. D’un côté un client, c’est-à-dire l’application qui héberge l’assistant. De l’autre un serveur MCP, un programme qui expose un système donné. Ils échangent en JSON-RPC.

Un serveur expose trois catégories d’éléments. Les outils sont des actions que le modèle peut déclencher : lire une balance, chercher une facture, créer un enregistrement. Les ressources sont des contenus qu’il peut lire, un document ou un jeu de résultats. Les invites sont des modèles de requête préparés pour les usages fréquents.

Cette distinction n’est pas cosmétique. Seuls les outils peuvent écrire. Un serveur qui n’expose que des ressources et des outils de lecture ne peut rien modifier, quoi que demande l’utilisateur et quoi que décide le modèle. C’est le levier de sécurité le plus simple et le plus efficace, et il se règle à l’installation.

En local, le serveur tourne sur le poste de l’utilisateur, lancé par l’application cliente, et communique par entrée-sortie standard. C’est le mode le plus rapide à mettre en place et le plus étanche, puisque rien ne quitte la machine. C’est aussi le moins gouvernable : chaque poste a sa configuration, ses identifiants, et personne ne sait vraiment qui a accès à quoi.

À distance, le serveur est hébergé et plusieurs personnes s’y connectent en HTTP. C’est le mode qui convient à une organisation : une configuration unique, des droits par personne, un journal centralisé. Le transport de référence aujourd’hui est le HTTP dit streamable. La variante fondée sur SSE, utilisée dans les premières versions, est dépréciée, ce qui vaut la peine d’être vérifié si vous reprenez un serveur écrit en 2025.

L’authentification d’un serveur distant repose sur OAuth 2.1, avec PKCE et enregistrement dynamique du client. En pratique, chaque personne s’authentifie pour elle-même, et l’on sait qui a demandé quoi. C’est ce qui sépare un accès d’entreprise d’un jeton partagé recopié dans un fichier de configuration.

Brancher une IA sur des données réelles pose quatre questions, et aucune n’est vraiment technique.

Lecture seule ou écriture. Un serveur en lecture seule ne peut pas se tromper de façon coûteuse, et cela couvre l’immense majorité des usages d’analyse. C’est le réglage par défaut raisonnable.

Qui voit quoi. Un accès nominatif permet de restreindre par personne et par périmètre. Un jeton unique partagé donne à tout le monde les droits du plus privilégié, ce qui est rarement l’intention de départ.

Ce qui sort. Les données envoyées au modèle quittent votre système. Selon leur sensibilité, il peut être nécessaire de pseudonymiser les identités avant l’appel, noms, identifiants, coordonnées bancaires, puis de rétablir la correspondance à la réponse. On garde les montants et les dates, sans lesquels l’analyse n’a plus de sens.

Ce qui reste comme trace. Un journal des appels, qui, quand, quel outil, quels arguments, est la seule façon de répondre à une question de conformité six mois plus tard. Sans lui, la réponse est un haussement d’épaules.

Ces quatre décisions se prennent avant l’installation. Elles constituent le cadrage d’accès, et c’est souvent la partie la plus utile de l’exercice, avant même la technique.

Le cas le plus fréquent est celui d’une entreprise dont les équipes utilisent déjà un assistant sur des données internes, souvent sans que la direction le sache. Le protocole permet alors de remplacer un usage subi par un accès défini, ce qui est un progrès même si rien d’autre ne change.

L’autre bon cas est celui des questions imprévues. Un tableau de bord répond aux questions qu’on a anticipées. Un accès conversationnel répond aux autres. Les deux se complètent, ils ne se remplacent pas.

En revanche, si vous avez besoin d’un chiffre officiel et reproductible, un rapport calculé reste l’outil adapté : une réponse conversationnelle peut varier dans sa formulation et ne fait pas foi. Et si vos données sont sales, le protocole transportera fidèlement les incohérences. Sur un référentiel bancal, il produira des réponses fausses avec beaucoup d’assurance, ce qui est pire qu’une absence de réponse. Le socle de données passe avant.

Dernier cas où l’on déconseille : le suivi périodique. Reposer la même question tous les lundis en langage naturel coûte plus cher, en temps et en jetons, qu’un rapport qui s’actualise seul.

Nous commençons par le cadrage d’accès : quelles données, pour qui, en lecture seule ou non, et la note écrite qui documente la décision. Vient ensuite l’installation, avec les connecteurs existants quand ils suffisent, sur poste ou sur serveur selon le contexte.

Quand un connecteur officiel n’expose pas ce dont vous avez besoin, nous écrivons un serveur sur mesure : plusieurs sources dans le même accès, outils métier spécifiques, règles de calcul propres à la maison. Nous posons enfin la gouvernance, accès nominatif, journalisation, pseudonymisation des identités, et nous regardons le socle de données, parce qu’un accès IA ne vaut que ce que valent les données derrière.

Qu’est-ce que le Model Context Protocol (MCP) ?

Une norme ouverte publiée par Anthropic fin 2024, qui permet à un assistant IA d’appeler des systèmes externes de façon standardisée. Un serveur MCP expose des outils, des ressources et des invites ; le client, c’est-à-dire l’application qui héberge l’assistant, les consomme. L’objectif est d’éviter d’écrire une intégration sur mesure pour chaque couple assistant-outil.

Quelle différence entre un serveur MCP local et un serveur MCP distant ?

Un serveur local tourne sur le poste de l’utilisateur et communique par entrée-sortie standard : simple et étanche, mais chaque poste a sa configuration et ses identifiants. Un serveur distant est hébergé et communique en HTTP streamable, avec une authentification OAuth 2.1 : configuration unique, droits par personne, journal centralisé. C’est le mode adapté à une organisation.

Un serveur MCP peut-il modifier mes données ?

Seulement s’il expose des outils d’écriture. Un serveur limité aux ressources et aux outils de lecture ne peut rien modifier, quelle que soit la demande de l’utilisateur ou la décision du modèle. La lecture seule est le réglage par défaut recommandé et couvre la majorité des usages d’analyse.

Comment sécuriser un accès IA à des données sensibles via MCP ?

Quatre décisions se prennent avant l’installation : limiter à la lecture seule, authentifier chaque personne nominativement plutôt que par un jeton partagé, pseudonymiser les identités avant transmission au modèle quand la sensibilité l’exige tout en conservant montants et dates, et journaliser chaque appel avec son auteur, son horodatage et ses arguments.

• Un serveur MCP sur vos outils, quand le besoin dépasse un seul logiciel : comptabilité Pennylane et paie Silae ou OpenPaye dans le même serveur.
• Le connecteur MCP officiel Pennylane, installation pas à pas et paramétrage du client.
• MCP en cabinet d’expertise comptable, pour la question du secret professionnel.
• Le guide de l’API Pennylane, ce que l’API expose sous le protocole.
• ChatGPT, Copilot ou Claude en entreprise, quel assistant pour quel usage.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : spécification.