MCP expliqué : l'USB-C des outils d'IA

Avant l'USB-C, chaque appareil avait son propre chargeur, et relier deux objets supposait de partir à la chasse au bon adaptateur. Le Model Context ProtocolModel Context ProtocolUn standard ouvert qui permet aux assistants IA de se connecter aux outils et données de l'entreprise de façon cohérente et gouvernée, sans intégration sur mesure à chaque fois.Voir la définition complète → (MCP) fait pour les outils d'IA ce que l'USB-C a fait pour les câbles : il définit un standard ouvert unique pour que n'importe quelle application d'IA puisse dialoguer avec n'importe quel outil via une seule interface prévisible.

C'est important parce que vous avez déjà vu l'alternative. Chaque fois que vous raccordez Claude à une nouvelle source de données avec du code sur mesure, vous construisez une intégration unique que vous êtes seul à maintenir. MCP remplace cet éparpillement par un contrat partagé. Construisez un connecteur une fois, et toute application compatible MCP peut l'utiliser.

Anthropic a introduit MCP comme un standard ouvert, et la spécification complète est disponible sur modelcontextprotocol.io. Ce n'est pas réservé à Claude. Mais Claude a été le premier assistant majeur à l'adopter massivement, ce qui explique sa présence dans les applications Claude, dans Claude Code et dans la marketplace de connecteurs.

Les trois pièces : host, client, serveur

MCP compte exactement trois rôles. Dès que vous savez les nommer, chaque intégration dont vous entendez parler se met en place.

Le host

Le host est l'application d'IA avec laquelle l'utilisateur interagit réellement. Claude Desktop est un host. Claude Code aussi. L'application Claude web et mobile aussi, dès que vous ajoutez un connecteur. Le host détient la conversation, fait tourner le modèle et décide quels outils le modèle est autorisé à atteindre.

Voyez le host comme l'ordinateur portable. C'est lui qui a le port USB-C.

Le client

Le client est un petit connecteur qui vit à l'intérieur du host et gère une connexion vers un serveur. Le host lance un client distinct pour chaque serveur avec lequel il dialogue. Si Claude Desktop se connecte à votre wiki et à votre agenda, cela fait deux clients, chacun maintenant un canal propre et isolé.

Vous touchez rarement le client directement. C'est de la plomberie que le host gère pour vous. Voyez-le comme la puce contrôleur USB-C : invisible, mais elle applique le protocole côté host.

Le serveur

Le serveur est là où se passe le travail intéressant. Un serveur MCP est un programme autonome qui expose des capacités au host : des outils qu'il peut appeler, des ressources qu'il peut lire et des prompts qu'il peut utiliser. Vous écrivez des serveurs (ou installez ceux écrits par d'autres) pour connecter Claude à vos systèmes réels.

Le serveur, c'est l'appareil à l'autre bout du câble : un wiki, une base de données, un repo GitHub, un système de tickets.

Le déroulé est toujours le même. Le host lance un client. Le client se connecte à un serveur. Le serveur annonce ce qu'il sait faire. Le modèle, qui tourne dans le host, décide quand appeler ces capacités, et le client relaie la requête.

Ce qu'un serveur expose réellement

Un serveur MCP s'exprime avec trois noms. Apprenez-les et vous pourrez lire le code source de n'importe quel serveur.

• Tools : des actions que le modèle peut invoquer, comme search_wiki ou create_ticket. Ce sont des fonctions avec des entrées typées. C'est le modèle qui choisit de les appeler.
• Resources : des données que le host peut lire, comme une page de wiki précise ou un fichier. Voyez-les comme du contexte en lecture seule que l'utilisateur ou le modèle fait entrer.
• Prompts : des modèles de prompt réutilisables offerts par le serveur, comme un workflow « résume cet incident » que l'utilisateur peut déclencher.

La plupart des serveurs que vous construirez s'appuieront surtout sur les tools. C'est là que se trouve le gain.

Un exemple concret : exposer le wiki de votre équipe à Claude

Disons que votre équipe fait tourner un wiki interne. Les ingénieurs oublient sans cesse où se trouve le runbook d'astreinte, et vous voulez que Claude réponde à « quelle est notre procédure de rollback de déploiement ? » en cherchant réellement dans le wiki, pas en devinant.

Vous construisez un serveur MCP qui expose un seul tool : `search_wiki`. Le voici, avec le SDK Python officiel et le style moderne FastMCP.

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("team-wiki")

WIKI_API = "https://wiki.internal.acme.com/api/search"

@mcp.tool()
async def search_wiki(query: str, limit: int = 5) -> str:
    """Search the internal team wiki and return matching page snippets."""
    async with httpx.AsyncClient() as client:
        resp = await client.get(WIKI_API, params={"q": query, "limit": limit})
        resp.raise_for_status()
        hits = resp.json()["results"]

    if not hits:
        return f"No wiki pages found for: {query}"

    return "\n\n".join(
        f"# {h['title']}\n{h['url']}\n{h['snippet']}" for h in hits
    )

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

C'est un serveur complet et fonctionnel. Le décorateur @mcp.tool() transforme une simple fonction Python en une capacité que Claude peut appeler. La docstring n'est pas décorative : le host l'envoie au modèle pour que Claude sache *quand* recourir à cet outil. Les annotations de type (query: str, limit: int) deviennent le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → d'entrée que le client utilise pour valider.

Remarquez ce que vous n'avez pas fait. Vous n'avez rien écrit de spécifique à Claude. Vous n'avez pas parsé la sortie du modèle ni formaté à la main le JSON d'appel d'outil. Le protocole gère tout cela. Si votre collègue utilise un autre host MCP l'an prochain, ce serveur exact fonctionnera toujours.

Le connecter à Claude Desktop

Pour que Claude Desktop (un host) charge votre serveur, vous l'enregistrez dans le fichier de configuration MCP du host. Sur une machine de développement, cela ressemble à ceci :

{
  "mcpServers": {
    "team-wiki": {
      "command": "python",
      "args": ["/Users/you/servers/wiki_server.py"]
    }
  }
}

Redémarrez le host, et Claude voit désormais search_wiki dans sa boîte à outils. Demandez « quelle est notre procédure de rollback ? » et Claude décide d'appeler l'outil, le client relaie la requête à votre serveur, votre serveur interroge le wiki, et les extraits reviennent dans la conversation comme contexte factuel.

C'est le même schéma derrière les Connectors que vous voyez dans les applications Claude et dans la marketplace de connecteurs : des serveurs MCP prêts à l'emploi pour les outils courants (Google Drive, GitHub, et d'autres) que vous activez d'un clic au lieu d'éditer un fichier de configuration. Sous le capot, un connecteur de la marketplace et votre serveur wiki artisanal sont la même chose.

Transports : local vs distant

Comment le client parle-t-il concrètement au serveur ? MCP définit deux transports principaux, le canal par lequel voyagent les messages.

• stdio : le host lance le serveur comme un sous-processus local et lui parle via l'entrée/sortie standard. C'est ce qu'utilise la configuration ci-dessus. Parfait pour les outils locaux et le développement.
• Streamable HTTP : le serveur tourne comme un service web distant et le host s'y connecte en HTTP. C'est ainsi que fonctionnent les connecteurs hébergés et les serveurs à l'échelle d'une équipe, quand vous ne voulez pas que chaque employé fasse tourner un processus Python sur son portable.

Pour votre serveur wiki, stdio est parfait pendant la construction. Quand vous êtes prêt à le partager avec l'équipe, vous redéployez la même logique derrière un endpoint HTTP et vous pointez le host de chacun vers l'URL.

La place de MCP dans l'écosystème Claude élargi

MCP est le tissu conjonctif, mais il est utile de voir comment il se rapporte aux autres briques que vous utiliserez.

Le Claude Agent SDK sert à construire des agents autonomes en code. Quand cet agent doit toucher des systèmes externes, il utilise des serveurs MCP comme outils. MCP n'est donc pas un concurrent de l'Agent SDK ; c'est le standard que le SDK utilise pour se brancher sur le monde. Même chose pour Claude Code : vous pouvez ajouter des serveurs MCP à Claude Code pour qu'il cherche dans votre outil de suivi de tickets ou interroge une base de données pendant qu'il travaille.

Les Skills sont une autre couche. Une Skill empaquette des instructions, des scripts et des ressources qui apprennent à Claude *comment* bien exécuter une procédure. MCP concerne la *connectivité* (atteindre un système) ; les Skills concernent la *capacité* (savoir faire une tâche). Une configuration bien pensée utilise souvent les deux : une Skill qui décrit votre processus de réponse aux incidents, appelant des outils MCP qui lisent vos dashboards de monitoring.

La Messages API est la surface bas niveau. Si vous construisez votre propre host de zéro, c'est là que vous gérez les appels au modèle et que vous câblez MCP dans votre propre logique de client. La plupart des équipes n'ont pas besoin d'aller aussi loin, mais il est bon de connaître l'empilement. La documentation officielle sur docs.claude.com couvre l'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète →, l'Agent SDK et les connecteurs en détail, et github.com/anthropics héberge les SDK et les serveurs de référence.

Le modèle mental : MCP standardise le *port*, l'Agent SDK et les Skills décident *ce que vous faites une fois connecté*, et la Messages API est le *moteur* en dessous.

Sécurité : la partie que les gens sautent

Un port USB-C peut charger votre téléphone ou effacer votre disque selon ce qu'on y branche. MCP, c'est pareil. Un serveur que vous installez tourne avec les accès que vous lui donnez, et le modèle peut décider d'appeler ses outils.

Trois habitudes vous protègent :

1. N'installez que des serveurs de confiance. Un serveur malveillant peut exfiltrer des données ou mener des actions destructrices. Traitez un serveur MCP tiers comme n'importe quelle autre dépendance que vous auditeriez.
2. Restreignez strictement les permissions du serveur. Votre serveur wiki doit avoir un tokentokenUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → d'API en lecture seule, pas des identifiants admin. Si un outil n'a besoin que de chercher, ne lui donnez pas la capacité de supprimer.
3. Gardez des humains dans la boucle pour les outils destructeurs. Des hosts comme Claude Desktop demandent une approbation avant d'exécuter des outils. Ne désactivez pas cela pour tout ce qui écrit ou supprime.

Le protocole vous donne la portée. Le rayon d'explosion, c'est votre responsabilité.

Pourquoi c'est important

Le gain discret de MCP, c'est la composabilité. Dès que votre wiki, votre système de tickets et votre monitoring parlent tous MCP, vous pouvez les combiner à volonté entre les hosts sans rien réécrire. Une nouvelle application d'IA sort avec le support MCP, et vos serveurs existants s'y allument dès le premier jour.

C'est la promesse de l'USB-C rendue réelle pour l'IA : construisez le connecteur une fois, branchez-le partout.

Points clés

• Mémorisez les trois rôles. Host (l'application d'IA que l'utilisateur manipule), client (le gestionnaire par connexion à l'intérieur du host), serveur (le programme qui expose tools, resources et prompts). Toute configuration MCP est un agencement de ces trois-là.
• Commencez avec un seul outil, en local. Écrivez un petit serveur avec FastMCP, exposez un seul outil bien documenté, enregistrez-le dans la configuration de votre host via stdio, et vérifiez que Claude l'appelle avant d'en ajouter d'autres.
• Écrivez les docstrings pour le modèle, pas pour les humains. La description de l'outil est ce que Claude lit pour décider quand l'appeler. Des docstrings vagues provoquent des appels d'outils manqués ou erronés.
• Limitez les identifiants au moindre privilège et gardez les approbations actives. Un token en lecture seule et une confirmation humaine dans la boucle sont vos défenses principales, puisque c'est le modèle, et non vous, qui décide quand les outils se déclenchent.
• Souvenez-vous de l'empilement. MCP est le port standard ; l'Agent SDK et les Skills décident ce que vous faites une fois connecté. Utilisez la bonne couche plutôt que de reconstruire la connectivité vous-même. Commencez par modelcontextprotocol.io.