Jusqu’à récemment, connecter un assistant IA à un outil métier — un CRM, un système de ticketing, une base documentaire — demandait d’écrire un connecteur sur mesure pour chaque couple (agent, service). C’était long, fragile et difficilement réutilisable.

Le Model Context Protocol (MCP) change la donne. Introduit par Anthropic fin 2024 et confié à la Linux Foundation en décembre 2025 (avec OpenAI et Google parmi les cofondateurs), MCP est aujourd’hui supporté nativement par l’ensemble des grands fournisseurs d’IA.

L’analogie USB

Le modèle mental est simple : MCP est à l’IA ce que l’USB est au matériel informatique. On n’écrit plus un pilote par couple (ordinateur, périphérique). On écrit un serveur MCP par service, et tout agent compatible peut s’y brancher.

Avant MCP, intégrer un outil SaaS à un agent demandait environ dix-huit heures de développement sur mesure. Avec MCP, c’est l’affaire de quelques heures.

Comment ça fonctionne

L’architecture est client-serveur. Un client MCP (intégré dans l’agent) parle à un ou plusieurs serveurs MCP, en JSON-RPC. Chaque serveur expose trois types de ressources :

Tools (outils) : des fonctions que l’agent peut appeler — “rechercher un client”, “créer un ticket”, “envoyer une notification”
Resources (données) : des informations que l’agent peut consulter — fichiers, enregistrements, configuration
Prompts (gabarits) : des modèles de prompts réutilisables pour des tâches récurrentes

Les transports disponibles : stdio pour un serveur local lancé en sous-processus (le cas le plus courant), HTTP/SSE pour un serveur distant.

Ce que ça permet concrètement

Pour une TPE ou une PME, MCP ouvre des possibilités qui étaient réservées aux grandes entreprises il y a un an :

Brancher un assistant sur votre messagerie pour qu’il lise les e-mails, prépare des réponses et classe les conversations
Connecter un outil de facturation pour que l’agent retrouve une facture, vérifie un paiement ou prépare un avoir
Exposer un outil de supervision pour qu’un agent d’astreinte consulte l’état des services et les journaux
Relier un système de gestion documentaire pour que l’assistant réponde aux questions en citant les bons documents

Et tout cela avec un seul standard, pas un connecteur par outil.

Un serveur MCP en 20 lignes

Pour les profils techniques, voici à quoi ressemble un serveur MCP minimal en Python :

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("mon-outil")

@mcp.tool()
def rechercher_client(nom: str) -> str:
    """Recherche un client par nom dans la base.

    nom : nom ou partie du nom du client.
    Renvoie les informations du client ou un message d'erreur explicite.
    """
    # ... requête vers votre base de données
    return resultat

if __name__ == "__main__":
    mcp.run()

L’agent voit le nom de l’outil, sa description et le schéma de paramètres. La qualité de la description conditionne directement la qualité de l’usage — c’est un point souvent sous-estimé.

L’écosystème : des milliers de serveurs disponibles

La communauté a produit des serveurs MCP pour à peu près tout : Google Drive, Slack, GitHub, bases de données SQL, Notion, Jira, systèmes de supervision… Le registre officiel en recense des milliers.

Mais cet écosystème ouvert est aussi une source de risques.

Les risques de sécurité à connaître

Des analyses publiées en 2026 ont recensé plus de douze mille serveurs MCP exposés sur Internet, dont environ 40 % sans aucune authentification. MCP a été conçu pour un usage local en réseau de confiance ; son exposition publique demande une couche de sécurité que le protocole seul ne fournit pas.

Cinq points de vigilance

Accès sans authentification. Beaucoup de serveurs MCP tournent sans contrôle d’identité. Un serveur exposé sans authentification donne accès à toutes ses fonctions à quiconque le trouve.
Injection via les résultats d’outils. Le contenu renvoyé par un outil peut contenir des instructions que l’agent traitera comme légitimes. Un serveur MCP tiers compromis peut détourner l’agent.
Permissions excessives. L’agent reçoit souvent l’accès à tous les outils d’un serveur pour toute la session, alors qu’il n’en a besoin que de quelques-uns.
Empoisonnement de description. Des instructions malveillantes cachées dans le champ “description” d’un outil — que l’agent lit avec confiance — peuvent modifier son comportement.
Absence de piste d’audit. Sans journal structuré des appels, un incident est impossible à reconstituer.

Les bonnes pratiques

Ne jamais exposer un serveur MCP sur Internet sans authentification
Relire le code de tout serveur MCP tiers avant activation — c’est un composant de votre chaîne de confiance
Un compte de service par serveur MCP, avec les droits minimaux
Les garde-fous dans le code, pas dans le prompt — une règle dans le prompt est une suggestion, une règle dans le code est une garantie
Journaliser tous les appels, hors de portée de l’agent lui-même

MCP et A2A : deux protocoles complémentaires

Là où MCP répond à “comment un agent accède à un outil”, le protocole A2A (Agent-to-Agent, initié par Google) répond à “comment deux agents se découvrent et se délèguent du travail”. Les deux ne sont pas en concurrence — ils se complètent.

En pratique, pour la très grande majorité des projets, MCP suffit largement. A2A devient pertinent quand des agents appartenant à des organisations différentes doivent coopérer.

Ce qu’aucun protocole ne fournit

Point souvent oublié : ni MCP ni A2A ne fournissent nativement la traçabilité, la journalisation d’audit, l’application de politiques ou la gestion du cycle de vie. Ils décrivent des échanges, pas une gouvernance. Ces couches sont à votre charge.

MCP démocratise l’intégration de l’IA dans les systèmes d’information, mais cette ouverture vient avec des responsabilités de sécurité. Pour évaluer comment connecter vos outils métier de façon sécurisée, demandez un diagnostic.