MCP expliqué aux DSI : le standard qui branche l'IA sur votre SI

MCP (Model Context Protocol) est un standard ouvert qui décrit comment un agent d'IA se connecte à des outils et des sources de données : lire un dossier, interroger un ERP, préparer un envoi. Publié fin 2024 par Anthropic, adopté en 2025 par l'ensemble de l'industrie puis confié à une gouvernance neutre, il est devenu la prise commune entre les modèles et le système d'information. Pour une DSI, il change deux choses très concrètes : le coût d'intégration, et la dépendance au fournisseur. Voici lesquelles, et les questions à poser avant de brancher quoi que ce soit.

Le problème qu'il règle : l'intégration N x M

Avant un standard, chaque assistant d'IA devait être intégré à chaque outil : N outils multipliés par M assistants, chaque couple demandant son développement sur mesure, sa maintenance, sa surface d'erreur. C'est l'économie qui a longtemps condamné les projets d'intégration IA au périmètre réduit.

MCP remplace cette matrice par une prise : un connecteur par outil (un "serveur MCP"), utilisable par n'importe quel agent qui parle le protocole. L'ERP expose une fois ce qu'il sait faire ; tous vos agents, présents et futurs, savent s'en servir. Un connecteur par outil, pas une intégration par couple outil-assistant.

Comment ça marche, sans jargon

Trois rôles. Le serveur MCP est un petit service qui décrit ce qu'un outil sait faire, sous forme de capacités nommées et typées : "lire les factures du mois", "chercher dans la GED", "préparer un courriel". L'agent découvre ces capacités et les appelle quand sa tâche le demande. Le protocole est le langage commun entre les deux, publié et documenté publiquement.

Deux propriétés de ce mécanisme intéressent directement une DSI. D'abord, les capacités sont énumérables : vous pouvez lister, exactement, ce qu'un agent peut faire sur chaque outil. C'est une surface d'audit, là où une intégration sur mesure est une boîte à ouvrir. Ensuite, chaque appel est individuellement journalisable : quel agent, quelle capacité, quels paramètres, quel résultat. La granularité de la trace est celle de l'action, pas celle de la session.

Ce que ça change pour la réversibilité

Le connecteur appartient au standard, pas à la plateforme. Si vous changez de couche d'IA, les serveurs MCP de vos outils restent valables ; si vous changez d'outil, vos agents apprennent le nouveau connecteur sans être réécrits. L'intégration cesse d'être ce qui vous attache à un fournisseur, et c'est une inversion notable : dans le SaaS classique, l'intégration est précisément là où la dépendance se construit.

C'est aussi un critère de sélection. Un fournisseur d'IA qui vous propose ses intégrations propriétaires là où un standard existe vous propose, en creux, de reconstruire la matrice N x M à son profit.

Les six questions de gouvernance à poser

1. Où tourne le serveur MCP ? Sur votre infrastructure, ou chez un tiers ? Un serveur distant voit passer vos données et vos requêtes : sa localisation et sa juridiction comptent autant que celles de votre hébergeur.
2. Qui détient les jetons d'accès ? Un serveur MCP s'authentifie auprès de vos outils. Comptes de service dédiés, moindre privilège, révocation possible : les règles classiques, appliquées sans exception. Jamais les identifiants personnels d'un salarié.
3. Quel périmètre par agent ? La lecture seule est un défaut sain. Un agent de rapprochement n'a pas besoin d'écrire dans l'ERP ; celui qui prépare des courriels n'a pas besoin de lire la comptabilité.
4. Qui a écrit le serveur ? Un serveur MCP communautaire est du code que vous exécutez avec vos accès. La revue de provenance est la même que pour toute dépendance logicielle, avec un enjeu supérieur : ce code-là tient vos clés.
5. Chaque appel est-il journalisé ? Le protocole rend la trace possible ; c'est votre plateforme qui la rend obligatoire, requêtable et exportable. Une intégration MCP sans journal reperd l'essentiel du bénéfice de gouvernance.
6. L'écriture passe-t-elle par une validation ? Toute action sortante (envoi, modification, publication) mérite une validation humaine, quel que soit le connecteur. Le standard n'impose pas ce garde-fou : votre architecture doit le faire.

Ce que MCP ne règle pas

MCP est une prise, pas une politique. Il ne décide pas où résident vos données, ne choisit pas vos modèles, ne fixe aucun périmètre et ne protège pas, à lui seul, contre le détournement d'un agent : un document piégé peut tenter de faire exécuter à un agent outillé des actions non prévues, et c'est précisément le périmètre restreint, la validation humaine et le journal qui limitent ce risque. Un standard d'intégration ne remplace ni l'architecture, ni la politique de sécurité. Il rend les deux plus simples à construire, et c'est déjà beaucoup.

La prise, côté root

root Workspace utilise MCP nativement : les connecteurs tournent sur votre instance, pas chez un relais tiers ; chaque agent a un périmètre déclaré ; chaque appel alimente le journal d'audit ; l'écriture attend une validation. Le détail des outils couverts est sur la page connecteurs, et ce qu'une DSI peut exiger de toute la couche est détaillé sur la page dédiée aux DSI et RSSI.

Questions fréquentes

MCP est-il lié à un fournisseur de modèles ?

Non. La spécification est publique, la gouvernance a été confiée à une fondation neutre fin 2025, et les implémentations existent chez tous les grands fournisseurs comme dans l'open source. C'est précisément son intérêt : la prise ne vous engage pas sur le modèle qui l'utilise.

Quelle différence entre MCP et une API ?

Votre API expose un outil aux développeurs ; un serveur MCP expose les mêmes capacités aux agents, sous une forme qu'ils peuvent découvrir et appeler seuls, avec des types et des descriptions. En pratique, un serveur MCP est souvent une couche fine au-dessus d'une API existante : si vos outils ont une API, ils sont à portée de connecteur.

Un serveur MCP est-il un risque de sécurité ?

Comme tout code exécuté avec des accès : le risque tient à la provenance, au périmètre et à la trace, pas au protocole. Les six questions ci-dessus en font le tour ; un serveur revu, exécuté chez vous, en moindre privilège et journalisé, est plus auditable qu'une intégration sur mesure équivalente.

Nos outils métier n'ont pas de serveur MCP officiel. C'est bloquant ?

Non, et c'est même le cas le plus courant : un serveur se construit au-dessus de l'API existante de l'outil, y compris pour un logiciel interne. C'est un travail d'intégration classique et borné, celui que nous menons en atelier sur votre configuration exacte.