La bascule : le manuel est écrit, il manque les mains
Volet Skills terminé : vous savez transmettre un savoir-faire au modèle, le tester, le gouverner. Mais relisez la skill du fil rouge : elle explique comment rédiger un compte-rendu… à partir de notes que le modèle n'a aucun moyen d'aller chercher. Le manuel est parfait, les mains manquent.
C'est tout l'objet des quatre prochaines étapes. Et on commence par comprendre le protocole lui-même — pas pour le plaisir de la théorie : parce que les décisions qui comptent (qu'est-ce qu'on branche, avec quels droits, où ça tourne) se prennent mal quand on ne sait pas ce qui circule dans les tuyaux.
Le problème d'avant : l'enfer du M × N
Remontons à 2023-2024. Chaque éditeur d'application IA voulait connecter son assistant aux mêmes services : messageries, dépôts de code, bases de données, CRM. Et chacun développait ses connecteurs, dans son format. Résultat :
À trois applications et trois services, l'écart semble anecdotique. À l'échelle réelle — des dizaines d'applications hôtes, des milliers de services — le M × N est un mur : chaque intégration spécifique est du code à développer, à sécuriser et à maintenir, chez chaque éditeur, pour chaque service. C'est ce mur que MCP fait tomber, et c'est le sens précis de l'analogie « USB-C de l'IA » : avant la prise standard, chaque appareil avait son chargeur propriétaire ; après, un câble pour tout. Le service implémente MCP une fois, et il devient accessible à toutes les applications compatibles — et réciproquement.
L'architecture : hôte, client, serveur
Trois rôles techniques, souvent confondus, faciles à démêler :
L'hôte — l'application que l'utilisateur voit et utilise : un assistant de bureau, un IDE, un agent métier. C'est lui qui embarque le modèle et qui décide quels serveurs sont branchés (avec, on l'espère, la gouvernance de l'étape 4 en tête).
Le client — le composant dans l'hôte qui gère la connexion avec un serveur donné : une connexion, un client. C'est de la plomberie interne ; en tant qu'utilisateur ou architecte, vous ne le manipulez pas directement, mais savoir qu'il existe clarifie les schémas de la documentation officielle.
Le serveur — le programme qui expose les capacités : celui qu'on a appelé « les mains » depuis l'étape 1. Il peut tourner en local sur la machine de l'hôte, ou en distant comme un service réseau — distinction anodine en apparence, lourde de conséquences en sécurité (on y consacre une partie de l'étape 8).
Retenez la chaîne : l'hôte héberge le modèle, le client tient la ligne, le serveur tend les mains. Et le principe de l'étape 1 reste intact à chaque maillon : rien ne se déclenche sans une décision du modèle.
Les trois primitives : tools, resources, prompts
Un serveur MCP n'expose pas « des fonctions » en vrac : le protocole distingue trois natures de choses, et la distinction est une aide à la conception, pas une subtilité d'implémenteur.
Le réflexe d'architecte à installer tout de suite : tout ce qui peut être une resource ne doit pas être un tool. Exposer la lecture d'un document via un tool read_document fonctionne — mais un tool peut avoir des effets de bord, et sera traité comme tel par toute analyse de sécurité. La resource dit par construction « ceci est de la lecture seule ». Moins de surface, moins de questions : la moitié du travail de l'étape 8 se joue dans ce choix de conception.
La séquence d'un tool call, pas à pas
Le cœur battant du protocole. Suivons notre fil rouge — « fais-moi le compte-rendu de la réunion de ce matin » — dans le circuit :
① La décision. Le modèle constate qu'il lui manque les notes. Dans son catalogue de tools (transmis par les serveurs branchés, avec pour chacun un nom, une description et un schéma d'arguments), il repère get_meeting_notes. La description du tool joue ici le même rôle que la description d'une skill : c'est elle qui permet le bon choix — vous connaissez la chanson depuis l'étape 2.
② L'appel. Le modèle produit un appel structuré : le nom du tool et des arguments (« la réunion de ce matin » devient une date). Le schéma d'entrée déclaré par le serveur permet de valider ces arguments avant exécution — première ligne de défense contre les appels malformés.
③ L'exécution. Le serveur fait son travail : il interroge l'outil de prise de notes. Point capital, à retenir pour l'étape 8 : il le fait avec ses propres droits — son compte de service, son token, son périmètre. Le modèle n'a jamais eu ces identifiants ; il a demandé, le serveur a agi. C'est exactement pour ça que les secrets n'ont rien à faire dans une skill.
④ Le retour. Le résultat — les notes brutes — remonte au client, qui l'injecte dans la fenêtre de contexte. À partir de cet instant, ces données sont du contexte comme un autre : le modèle les lit… et peut être influencé par ce qu'elles contiennent. Gardez cette phrase en mémoire : c'est la porte d'entrée de l'injection indirecte, le plat de résistance de l'étape 8.
⑤ La suite. Le modèle reprend son raisonnement, applique le format maison de la skill aux notes récupérées — et si la tâche le demande, enchaîne un second appel (send_summary). La boucle skill + MCP du fil rouge est complète : le manuel a dit comment, les mains ont fourni quoi.
Ce que le protocole standardise (et pourquoi ça vous concerne)
Trois mécanismes du standard méritent d'être connus même sans écrire une ligne de code, parce qu'ils fondent des propriétés que vous exploiterez :
La découverte. À la connexion, l'hôte demande au serveur la liste de ses capacités — tools, resources, prompts, avec descriptions et schémas. Aucun couplage en dur : brancher un serveur suffit à rendre ses tools visibles. C'est la propriété qui rend l'écosystème composable… et qui impose la question de gouvernance « que venons-nous exactement de rendre possible ? » à chaque branchement.
Les schémas d'entrée. Chaque tool déclare la forme exacte de ses arguments. Pour l'architecte, c'est un contrat lisible : la déclaration d'un tool dit précisément ce qu'on peut lui demander — auditable avant tout usage, comme la liste de permissions d'une application mobile.
Les transports. Le même protocole circule sur deux canaux : stdio pour un serveur local (un processus enfant sur la machine de l'hôte) et HTTP pour un serveur distant. Même grammaire, propriétés opérationnelles opposées — qui détient les secrets, où passent les données, qui peut se connecter. Le choix local/distant est le premier arbitrage de l'étape 6.
📚Pour aller plus loin
Pour les geeks : sous le capot, JSON-RPC 2.0. Les messages MCP sont du JSON-RPC : des requêtes nommées (tools/list pour la découverte, tools/call pour l'appel, leurs équivalents resources/* et prompts/*), des réponses corrélées par identifiant, des notifications sans réponse attendue. Conséquence pratique n°1 : tout s'observe — un proxy qui journalise les trames vous donne l'audit trail complet des échanges modèle↔serveur, brique de base de la supervision qu'on montera à l'étape 8. Conséquence n°2 : la session a un cycle de vie (initialisation avec négociation de version et de capacités, puis échanges) — un serveur peut notifier que sa liste de tools a changé en cours de session, ce qui est puissant pour la composabilité et intéressant à surveiller pour la sécurité : un serveur qui « fait apparaître » des tools après la phase d'audit initial est un pattern à détecter.
📚Pour aller plus loin
Pour les geeks : stdio vs HTTP, le tableau mental complet. stdio : l'hôte lance le serveur comme processus enfant et lui parle par entrée/sortie standard. Propriétés : pas d'exposition réseau, secrets dans l'environnement local du processus, cycle de vie lié à l'hôte, un utilisateur = une instance. Idéal pour les mains personnelles : fichiers locaux, outils de la machine. HTTP (streamable) : le serveur est un service réseau, potentiellement mutualisé, avec authentification à part entière (typiquement OAuth pour les serveurs distants) et la panoplie classique du service exposé — TLS, contrôle d'accès, journalisation centralisée, montée en charge. Idéal pour les mains d'équipe : le CRM, la base partagée. La règle de poche : stdio = les droits de votre session ; HTTP = les droits d'un service, avec tout ce que ça implique d'ingénierie de part et d'autre. Et dans les deux cas, le principe de l'étape 8 s'applique déjà : le serveur détient les secrets, le modèle n'en voit jamais la couleur.
📍 Parcours Skills & MCP — étape 5/9
- 🗺️ La carte avant le territoire
- 🔬 Anatomie d'une skill
- 🛠️ Créer sa première skill
- 🏛️ Skills en entreprise : gouvernance
- 🔌 MCP : le protocole expliqué ← vous êtes ici
- ⚡ Utiliser un serveur MCP existant
- ⚙️ Créer son serveur MCP minimal
- 🛡️ Sécuriser ses MCP
- 📡 L'écosystème : où trouver, où ça bouge
Prochaine étape → Utiliser un serveur MCP existant : brancher avant de construire — lire un manifest, comprendre ce qu'on autorise, et le premier arbitrage local vs distant.
Le catalogue d'outils vous démange déjà ? Notre fiche 40 outils Claude & MCP recense l'écosystème, stars GitHub en direct.