MCP (Model Context Protocol) : connecter vos outils à l’IA, proprement

L'IA générative devient vraiment utile quand elle peut agir : lire vos données, appeler vos outils, déclencher des actions. Le MCP (Model Context Protocol) est le standard qui rend ça propre et contrôlé.

Le problème que MCP résout

Brancher un LLM sur vos systèmes, base de données, CRM, API interne, se faisait jusqu'ici au cas par cas, avec du code sur mesure pour chaque connexion. Résultat : fragile, difficile à sécuriser et à maintenir.

MCP standardise cette connexion. Un serveur MCP expose des outils et des données au modèle de façon déclarée et contrôlée. Le modèle sait quels outils existent, ce qu'ils font, et les appelle dans un cadre défini.

La spécification est publique et versionnée, ce qui change beaucoup de choses par rapport aux intégrations maison. Un serveur MCP expose trois types de primitives : des outils, que le modèle peut appeler; des ressources, qu’il peut lire; et des prompts, que l’application peut proposer à l’utilisateur. Le même serveur fonctionne avec n’importe quel client compatible, ce qui supprime la réécriture à chaque changement d’assistant. Deux transports coexistent : stdio pour un serveur local lancé par le client, et HTTP pour un serveur distant, le choix n’est pas anodin, puisqu’il détermine qui peut joindre le serveur.

Ce que ça change concrètement

• Accès contrôlé : vous décidez exactement quelles données et quelles actions le modèle peut atteindre. Pas de tuyau ouvert.
• Réutilisable : un serveur MCP bien fait sert plusieurs assistants ou agents, sans tout réécrire.
• Auditable : les appels passent par une interface explicite, traçable.

« Accès contrôlé » demande à être outillé, et la spécification y consacre une page entière. Les bonnes pratiques de sécurité MCP nomment plusieurs attaques et les contre-mesures obligatoires. Le « token passthrough » est explicitement interdit : un serveur MCP ne doit jamais accepter un jeton qui ne lui a pas été délivré à lui, sans quoi il devient un relais anonyme vers vos API internes. Les sessions ne doivent pas servir d’authentification, et les identifiants de session doivent être aléatoires et liés à l’utilisateur. Le problème du « député confus » impose un consentement par client, avant de rediriger vers un fournisseur tiers. S’y ajoute le principe de moindre privilège sur les portées : commencer par un jeu minimal en lecture, et n’élever qu’à la demande.

Des serveurs MCP sur mesure

Sur nos projets, on construit des serveurs MCP qui exposent vos données (une base Supabase, un ERP, une API métier) à un assistant IA, souvent propulsé par un modèle souverain comme Mistral. L'IA devient capable de répondre et d'agir sur votre périmètre, sans accès incontrôlé. C'est une brique centrale de nos assistants IA connectés à vos données.

Un risque reste entier quel que soit le protocole, et il vaut d’être posé avant d’ouvrir des outils à un modèle : l’injection de requête, classée première des risques du Top 10 OWASP pour les applications à modèles de langage. Un texte présent dans un document indexé, un ticket client ou une page web lue par l’agent peut contenir des instructions qui détournent son comportement. MCP standardise l’accès aux outils; il ne filtre pas ce que le modèle décide d’en faire. Trois règles s’imposent donc côté serveur : n’exposer que les outils strictement nécessaires, appliquer les droits de l’utilisateur réel plutôt qu’un compte de service tout-puissant : c’est le contrôle d’accès défaillant du Top 10 de l’OWASP, et exiger une validation humaine pour toute action irréversible.

En résumé

MCP n'est pas un gadget : c'est la façon propre de donner à l'IA accès à vos systèmes, avec le contrôle et la traçabilité qu'exige la production.

Un assistant ou un agent à connecter à vos outils ? On en parle.