SwarmForge
04 Action 17 min d'exploration Intermédiaire

MCP — Donner des mains à l'IA

La question

Comment une IA peut-elle atteindre des milliers de systèmes sans que chaque intégration soit un développement à part ?

04 / 05Action

Un branchement par système

Le chapitre précédent a laissé l’agent capable de savoir. Reste à lui donner accès aux systèmes qui font tourner votre organisation — et là, chaque intégration a longtemps été un développement à part : son authentification, son format, sa gestion d’erreurs, sa maintenance.

Avant, après

Application IA

MCP
  • Fichiers
  • Dépôt Git
  • Base de données
  • Agenda
  • ERP
  • Capteurs
  • CRM

Sept systèmes, sept intégrations sur mesure. Chaque nouveau système est un projet, et chaque nouvelle application IA recommence le même travail. Sept systèmes, une seule interface à implémenter de chaque côté. Un serveur écrit une fois sert toutes les applications qui parlent le protocole.

Actionnez l'interrupteur : les branchements ne disparaissent pas, ils cessent d'être tous différents.

Version textuelle

Avant : une application IA reliée à sept systèmes par sept intégrations différentes. Après : les mêmes sept systèmes exposés à travers une interface commune, MCP, que l’application n’implémente qu’une fois.

C’est l’idée entière du Model Context Protocol : une façon standard de brancher, pour que l’effort d’intégration se paie une fois par système au lieu d’une fois par couple système-application.

Trois rôles qu'il ne faut pas confondre

La confusion la plus fréquente consiste à dire que « le modèle a appelé l’API ». Il ne l’a pas fait, et la distinction n’est pas un détail de vocabulaire : elle indique où placer un contrôle.

Hôte, client, serveur

Hôte — l'application IA

Modèle

  • Client MCP
  • Client MCP
  • Client MCP

L'hôte est votre application. C'est elle qui décide quels serveurs sont branchés, ce qu'elle expose au modèle, et ce qu'elle fait d'une proposition d'appel.

Frontière de processus

  • Serveur agenda

    Agenda

  • Serveur ERP

    ERP

  • Serveur fichiers

    Fichiers

Un client MCP est un connecteur à l'intérieur de l'hôte : il parle à un serveur et un seul. Un serveur est un service qui expose du contexte et des capacités. Il peut vivre sur la même machine ou ailleurs, et il ignore tout de l'application qui l'appelle.

Le modèle propose. Le client émet. Le serveur exécute. Trois responsabilités, trois endroits différents où intervenir.

Version textuelle

L’hôte est l’application IA. Elle contient le modèle et un client MCP par serveur branché. Chaque client parle à un serveur, qui expose un système extérieur. La requête franchit une frontière de processus entre l’hôte et le serveur.

Retenez la ligne pointillée. Ce que le modèle produit reste, jusqu’à ce qu’elle soit franchie, une proposition de texte. Ce qui la transforme en appel, c’est l’hôte.

Ce qu'un serveur peut exposer

Un serveur n’offre pas seulement des fonctions. La spécification distingue trois choses, et la distinction porte sur qui les pilote.

Primitives serveur

Choisissez une primitive

Des fonctions que le modèle peut exécuter.

Piloté par Le modèle, à partir de sa compréhension du contexte et de la demande. C'est la primitive qui agit.

Exemples

  • creer_ticket(titre, description)
  • lire_capteur(id)
  • envoyer_message(destinataire, corps)

C'est ici que se joue tout le reste du chapitre : un outil est un chemin d'exécution de code, et le protocole ne dit rien de qui a le droit de l'emprunter.

Trois choses différentes, souvent confondues sous le mot « outil ».

Version textuelle

Trois primitives serveur. Outils : des fonctions que le modèle peut exécuter — la seule qui agisse. Ressources : du contexte et des données, à l’usage de l’utilisateur ou du modèle, pilotées par l’application. Prompts : des messages et enchaînements pré-écrits, déclenchés par l’utilisateur.

Un serveur peut n’exposer que des ressources et rester parfaitement inoffensif. La bascule se produit à la première fonction.

Une découverte, puis un appel

Suivons une demande de bout en bout. L’agent ne connaît pas d’avance les capacités disponibles : il les demande, puis choisit.

Découverte et appel

Demande Ouvre un ticket pour le défaut que je viens de décrire.

  1. Client → Serveur Le client demande la liste des capacités du serveur. { "jsonrpc": "2.0", "id": 1, "method": "tools/list" }
  2. Serveur → Client Le serveur répond avec les outils disponibles, chacun décrit par un nom, une description et un schéma d'entrée. { "result": { "resultType": "complete", "tools": [ { "name": "creer_ticket", "description": "Ouvre un ticket", "inputSchema": { … } } ], "ttlMs": 300000 } }
  3. Hôte → Modèle L'application place ces descriptions dans le contexte du modèle, avec la demande de l'utilisateur.
  4. Modèle → Hôte Le modèle propose un appel : l'outil creer_ticket, avec les arguments qu'il a rédigés.
  5. Hôte L'application reçoit une proposition. Elle peut l'exécuter, la refuser, ou la soumettre à quelqu'un. À cet instant précis, rien dans le protocole n'a encore décidé si cet appel est permis, ni par qui.
  6. Client → Serveur L'appel part. { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "creer_ticket", "arguments": { "titre": "Écran figé au démarrage", "priorite": "haute" } } }
  7. Serveur → Client Le serveur exécute et renvoie le résultat. { "result": { "resultType": "complete", "content": [ { "type": "text", "text": "Ticket OPS-4182 créé." } ], "isError": false } }
  8. Hôte → Modèle Le résultat rejoint le contexte, et la boucle du chapitre 02 recommence.

Messages relevés sur la révision 2026-07-28 de la spécification, vérifiée le 14 août 2026. Le protocole évolue : cette date est là pour que vous sachiez quand cesser de me croire.

Avancez pas à pas. L'interrupteur du haut révèle les messages réellement échangés, pour qui veut les voir.

Version textuelle

Le client demande tools/list ; le serveur répond avec les outils disponibles et leurs schémas ; l’application place ces descriptions dans le contexte ; le modèle propose un appel à creer_ticket ; l’application décide d’exécuter ; le client émet tools/call ; le serveur exécute et renvoie le résultat, qui rejoint le contexte.

Le cinquième pas est le seul qui compte pour la suite. Le protocole y arrive avec une proposition et en repart avec un appel, et rien dans le protocole ne dit ce qui doit se passer entre les deux.

Ce que la révision 2026-07-28 a changé

Le protocole est devenu sans état. La poignée de main initialize / notifications/initialized a été supprimée : chaque requête porte désormais sa version de protocole et les capacités du client dans son champ _meta. Les sessions de niveau protocole et l’en-tête Mcp-Session-Id ont disparu du transport Streamable HTTP, et les listes (tools/list, resources/list, prompts/list) ne varient plus d’une connexion à l’autre.

Une conséquence pratique, contre-intuitive et utile : un serveur qui a besoin de mémoire entre deux appels ne peut plus s’appuyer sur la connexion. Il émet un identifiant explicite et le reçoit en argument ordinaire de l’appel suivant. La spécification le dit sans détour : du point de vue du fil, un handle est une chaîne ordinaire dans un résultat d’outil et un argument ordinaire dans les appels suivants.

Trois fonctionnalités sont dépréciées dans cette révision : Roots, Sampling et Logging. Les requêtes initiées par le serveur — dont l’élicitation, qui demande une information à l’utilisateur — passent désormais par le motif MRTR : le serveur renvoie un résultat de type input_required, et le client rejoue la requête en y joignant les réponses.

Ces détails changeront encore. Ce qui ne changera pas, c’est la forme : découvrir, choisir, appeler, recevoir.

Trois appels que le protocole traite identiquement

Voici le point où la commodité devient un problème d’architecture.

Portée des effets

lire_facture(id) Retourne une facture. Ne modifie rien.

Portée

Pour que ce soit acceptable Que l'appelant ait le droit de voir cette facture — ce qui est déjà une question, mais une question connue.

rembourser_client(id, montant) Déplace de l'argent. Effet réversible en théorie, coûteux en pratique.

Portée

Pour que ce soit acceptable Un plafond, un motif enregistré, et une personne identifiable qui répond de la décision.

supprimer_base(nom) Détruit des données. Aucun retour en arrière sans sauvegarde.

Portée

Pour que ce soit acceptable Rien, dans un contexte agentique, ne rend cet appel acceptable sans une décision humaine explicite et tracée.

Le protocole ne distingue pas ces trois lignes. Votre organisation, elle, ne peut pas se le permettre.

Trois outils, trois conséquences sans commune mesure. Sur le fil, les trois appels se ressemblent.

Version textuelle

Trois outils de portée croissante : lire une facture ne modifie rien ; rembourser un client déplace de l’argent ; supprimer une base détruit des données. Les trois appels ont exactement la même forme sur le fil, et le protocole les traite de la même façon.

La spécification elle-même le reconnaît, et en termes nets. Elle demande que les descriptions de comportement d’un outil soient considérées comme non fiables à moins de venir d’un serveur de confiance, et qu’il y ait « toujours un humain dans la boucle, avec la capacité de refuser l’invocation d’un outil ». Puis elle ajoute la phrase qui décide de tout le chapitre suivant : MCP ne peut pas faire appliquer ces principes au niveau du protocole.

Ce n’est pas un manque. Un protocole d’accès n’a pas à contenir votre politique — il ne la connaît pas. Mais quelqu’un doit la porter.

Qui répond de quoi

Reprenons les zones traversées par un appel, et demandons à chacune ce qu’elle peut décider.

Frontières de confiance

  1. Modèle

    Peut décider
    Quel outil semble convenir à la demande, et avec quels arguments.
    Ne peut pas savoir
    Qui est l'utilisateur, ce que la politique autorise, et ce que l'appel va réellement produire.

  2. Hôte

    Peut décider
    Quels serveurs sont branchés, ce qui est exposé au modèle, et si une proposition devient un appel.
    Ne peut pas savoir
    Ce que l'outil fait vraiment côté serveur — il n'en connaît que la description, que la spécification dit de tenir pour non fiable.

  3. Serveur MCP

    Peut décider
    S'il exécute, en validant les entrées et en appliquant ses propres contrôles d'accès.
    Ne peut pas savoir
    Le motif de l'appel, la conversation qui l'a produit, et si un humain l'a voulu.

  4. Système externe

    Peut décider
    Si le porteur du jeton présenté a le droit d'effectuer cette opération.
    Ne peut pas savoir
    Qu'un modèle est à l'origine de la demande. Pour lui, l'appel ressemble à n'importe quel autre appel authentifié.

Chaque zone est compétente chez elle et aveugle chez les autres. Reste une décision que personne n'a prise : celle-ci, maintenant, avec ces arguments, pour cette personne — est-elle permise ?

Chaque zone sait des choses que les autres ignorent. Aucune ne sait tout.

Version textuelle

Le modèle choisit un outil mais ignore qui demande et ce que la politique permet. L’hôte décide ce qui devient un appel mais ne connaît de l’outil que sa description. Le serveur exécute et valide ses entrées mais ignore le motif et l’existence d’un accord humain. Le système externe vérifie un jeton et ne sait même pas qu’un modèle est à l’origine de la demande.

Ce qui peut mal tourner

Ce que standardiser l'accès ne standardise pas

Une description d’outil est une donnée, pas une garantie. Le modèle choisit d’après ce que le serveur déclare faire. La spécification demande explicitement de tenir ces déclarations pour non fiables hors d’un serveur de confiance — ce qui déplace la question sans la fermer : que veut dire « de confiance », et qui en décide ?

L’identité se dilue en chemin. L’utilisateur parle à l’hôte, l’hôte parle au serveur, le serveur parle au système. Sans effort explicite, ce qui arrive au bout est l’identité du serveur, pas celle de la personne — et le journal du système externe enregistrera un service, pas un demandeur.

Le nombre de branchements est une surface. Chaque serveur ajouté élargit ce que le modèle peut atteindre. Il n’y a pas de seuil visible où l’ensemble devient trop large : la commodité qui rend MCP utile est exactement ce qui rend son périmètre difficile à tenir.

Rien n’enregistre pourquoi. Le résultat d’un appel dit ce qui s’est passé. Il ne dit ni quelle demande l’a motivé, ni quel raisonnement l’a choisi, ni si quelqu’un a approuvé — et ces trois informations sont précisément celles qu’on cherche le jour où l’on veut comprendre.

L'agent a des mains.

Il sait quelles capacités existent, parce qu’il les a demandées. Il sait les appeler, parce que le protocole est le même partout. Il sait quoi faire, parce qu’il a le contexte du chapitre précédent.

Et il peut désormais rembourser un client, arrêter une ligne, supprimer une base — pour peu que quelqu’un ait branché le serveur correspondant.

Le protocole a fait son travail : il a rendu la capacité accessible. Il n’a jamais prétendu décider qui a le droit de s’en servir. Cette question, personne ne l’a encore prise en charge.

Un agent branché

  • Recherche
  • Protocole
  • Appels d'outils

Identité

Politique

Approbation

Preuve

Un système gouvernable

  • Recherche
  • Protocole
  • Appels d'outils
  • Identité
  • Politique
  • Approbation
  • Preuve

Il peut rembourser, arrêter, supprimer. Personne n'a encore décidé qui en a le droit, ni gardé de quoi le montrer.

Vous êtes ici

  1. 01 Modèle
  2. 02 Agent
  3. 03 Connaissance
  4. 04 Action
  5. 05 Contrôle

L'agent a des mains. Qui décide de ce que ces mains ont le droit de faire ?

Mis à jour le 14 août 2026