Architecture et concepts clés

Pourquoi l'architecture avant les cas d'usage

On est souvent tenté d'aborder MCPMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire par la démonstration : brancher un serveur, connecter un client, obtenir un résultat impressionnant en cinq minutes. C'est une bonne façon de se motiver, mais une mauvaise façon de comprendre ce qui se passe réellement — et donc de déboguer le jour où quelque chose ne fonctionne pas.

Ce chapitre prend le parti inverse : poser l'architecture avant les usages. Vous saurez, à la fin, nommer précisément chaque composant d'une intégration MCP, décrire ce qu'il a le droit de faire et ce qu'il ignore par construction, et suivre le déroulé exact d'une session depuis la première trame échangée jusqu'à la fermeture de la connexion.

Ce chapitre suppose que vous avez lu le chapitre 1 (introduction et positionnement de MCP). Nous ne reviendrons pas sur le « pourquoi » de MCP, mais directement sur le « comment ».

Les trois rôles : hôte, client, serveur

MCP définit une architecture à trois rôles, et la confusion entre ces rôles est la source numéro un d'incompréhension chez les équipes qui découvrent le protocole.

L'hôte (host)

L'hôte est l'application avec laquelle l'utilisateur interagit directement : un assistant conversationnel, un IDE augmenté d'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire, une application métier interne. C'est l'hôte qui héberge le modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire, qui décide quand une capacité externe doit être sollicitée, et qui présente le résultat à l'utilisateur final.

L'hôte ne parle jamais directement à un serveur MCP. Il délègue cette communication à un ou plusieurs clients qu'il instancie et gère.

Le client (client)

Le client est le composant technique, généralement une bibliothèque intégrée à l'hôte, qui maintient une connexion un-à-un avec un serveur MCP donné. Un hôte connecté à quatre serveurs différents instancie quatre clients, chacun responsable d'une seule connexion.

Le client a trois responsabilités précises :

• négocier les capacités avec le serveur au démarrage de la session ;
• transmettre les requêtes de l'hôte vers le serveur et les réponses en sens inverse ;
• appliquer les règles de sécurité et de consentement définies par l'hôte (par exemple, demander confirmation avant d'exécuter un tool sensible).

Le serveur (server)

Le serveur est le composant qui expose des capacités concrètes : accès à une base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, appel à une API interne, lecture d'un système de fichiers, exécution d'une action métier. Un serveur MCP est délibérément ignorant du modèle de langage qui l'utilisera : il ne sait rien du promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire système, de l'historique de conversation, ni même de l'identité de l'hôte qui l'a connecté. Cette ignorance est un choix de conception, pas une lacune.

Un serveur MCP n'est pas « un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire IA ». C'est un fournisseur de capacités passif, interrogé à la demande. L'intelligence — la décision de quand et comment utiliser une capacité — reste entièrement du côté de l'hôte et du modèle qu'il héberge.

Cette séparation stricte a une conséquence pratique importante : un même serveur MCP (par exemple, un serveur exposant un CRM) peut être connecté à un assistant conversationnel, à un IDE, et à un pipeline d'automatisation, sans aucune modification. C'est la réutilisabilité que promettait déjà le chapitre 1, mais elle repose entièrement sur cette étanchéité des rôles.

Les trois primitives exposées par un serveur

Un serveur MCP ne présente pas un unique bloc de fonctionnalités indifférenciées. Il déclare explicitement ses capacités selon trois catégories, chacune avec une sémantique et un mode d'invocation propres.

Tools : des actions que le modèle peut décider d'exécuter

Un tool est une fonction que le modèle de langage peut choisir d'invoquer pendant son raisonnement, au même titre qu'un appel de fonction classique. Chaque tool est décrit par un nom, une description en langage naturel et un schéma JSON définissant ses paramètres attendus.

Exemple typique : un tool rechercher_client(nom: string) exposé par un serveur CRM. Le modèle décide, en fonction de la conversation, s'il doit l'appeler, avec quels arguments, et comment interpréter le résultat retourné.

Un utilisateur demande « quel est le statut de la commande du client Dupont ? ». Le modèle identifie qu'il dispose d'un tool rechercher_commande, construit l'appel avec {"client": "Dupont"}, l'hôte transmet la requête au client concerné, qui la relaie au serveur. Le serveur exécute la recherche et renvoie un résultat structuré que le modèle intègre à sa réponse.

Resources : des données que l'hôte peut attacher au contexte

Une resource est un contenu adressable — un fichier, un enregistrement, le résultat d'une requête — que l'hôte (ou l'utilisateur, selon l'interface) peut choisir d'attacher au contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire de la conversation, sans passer par une décision autonome du modèle. C'est une différence essentielle avec les tools : l'initiative de sélectionner une resource appartient généralement à l'application ou à l'utilisateur, pas au modèle en cours de raisonnement.

Une resource est identifiée par une URI (par exemple file:///rapports/q3.pdf ou postgres://prod/clients/482), ce qui permet de la référencer, de la mettre en cache ou de la rafraîchir indépendamment du fil de conversation.

Prompts : des gabarits réutilisables déclenchés par l'utilisateur

Un prompt MCP est un modèle de requête préformaté, paramétrable, que le serveur met à disposition pour des tâches récurrentes. Contrairement aux tools, un prompt est en général sélectionné explicitement par l'utilisateur dans l'interface de l'hôte — par exemple via une commande à barre oblique — plutôt que choisi de manière autonome par le modèle.

Exemple : un serveur de gestion documentaire pourrait exposer un prompt resumer_document(id, longueur) qui construit automatiquement l'instruction adéquate une fois les paramètres renseignés.

Si l'action doit pouvoir être déclenchée automatiquement par le raisonnement du modèle, c'est un tool. Si c'est une donnée à consulter ou à joindre, c'est une resource. Si c'est un point d'entrée pensé pour un usage humain récurrent et paramétrable, c'est un prompt. Beaucoup d'erreurs de conception de serveurs MCP viennent d'un tool qui aurait dû être une resource, ou inversement.

Négociation de capacités : ne rien supposer, tout déclarer

MCP n'impose pas qu'un serveur implémente les trois primitives. Un serveur peut n'exposer que des tools, ou uniquement des resources. Pour que le client sache à quoi s'attendre, le protocole prévoit une étape de négociation de capacités au tout début de la session : chaque partie déclare explicitement ce qu'elle sait faire.

Cette négociation évite deux écueils symétriques : un client qui tenterait d'appeler une primitive non supportée par le serveur, et un serveur qui exposerait des fonctionnalités que le client ne saurait pas exploiter (par exemple, la notification de changement de resources en temps réel).

La négociation de capacités repose sur la bonne foi déclarative du serveur : rien n'empêche techniquement un serveur mal implémenté d'annoncer une capacité qu'il ne gère pas correctement en pratique. Testez systématiquement un nouveau serveur MCP avant de le déployer en production, y compris ses cas d'erreur.

Le cycle de vie complet d'une session

Une session MCP suit une séquence rigoureuse en quatre phases. Comprendre cette séquence est indispensable pour déboguer une intégration qui « ne répond pas » ou qui échoue de façon inexpliquée.

Phase 1 — Initialize

Le client envoie une requête initialize contenant la version de protocole qu'il supporte et ses propres capacités (par exemple, sa capacité à afficher des demandes de confirmation à l'utilisateur). Le serveur répond avec sa propre version de protocole et la liste de ses capacités (tools, resources, prompts, et options associées comme la notification de changement).

Si les versions de protocole sont incompatibles, la session doit être interrompue à ce stade plutôt que de continuer dans un état ambigu.

Phase 2 — Initialized

Une fois la réponse initialize reçue et acceptée, le client envoie une notification initialized confirmant que la session est prête à fonctionner. C'est seulement à partir de ce point que des requêtes opérationnelles (lister les tools, invoquer un tool, lire une resource) peuvent être émises.

Envoyer une requête opérationnelle avant la notification initialized est une cause classique de dysfonctionnement lors de l'écriture d'un client MCP « à la main ». La plupart des SDK officiels gèrent cette séquence automatiquement, mais elle redevient visible dès qu'on implémente un transport personnalisé.

Phase 3 — Opérations

C'est la phase productive de la session : découverte des tools disponibles (tools/list), invocation (tools/call), lecture de resources (resources/read), récupération de prompts (prompts/get), et éventuellement réception de notifications asynchrones si le serveur a annoncé cette capacité (par exemple, une resource dont le contenu vient de changer).

Toutes ces opérations empruntent le même mécanisme de transport sous-jacent, détaillé plus bas.

Phase 4 — Shutdown

La fin de session peut être initiée par l'une ou l'autre des parties. Une fermeture propre libère les ressources associées (connexions ouvertes, processus enfants dans le cas d'un transport local) sans laisser d'état incohérent.

Le transport : JSON-RPC 2.0 comme langue commune

Toutes les interactions décrites ci-dessus circulent sous forme de messages JSON-RPC 2.0, un format d'échange minimal et déjà éprouvé bien avant MCP. Trois types de messages suffisent à tout exprimer :

• une requête, qui porte un identifiant, une méthode (par exemple tools/call) et des paramètres, et attend une réponse ;
• une réponse, qui reprend l'identifiant de la requête et porte soit un résultat, soit une erreur structurée ;
• une notification, qui ne porte pas d'identifiant et n'attend pas de réponse — utilisée par exemple pour signaler qu'une liste de resources a changé.

{
  "jsonrpc": "2.0",
  "id": 17,
  "method": "tools/call",
  "params": {
    "name": "rechercher_commande",
    "arguments": { "client": "Dupont" }
  }
}

Ce choix de JSON-RPC a une vertu discrète mais précieuse : le format est indépendant du transport physique. Les mêmes messages circulent aussi bien sur une entrée/sortie standard locale (un serveur lancé comme sous-processus) que sur une connexion HTTP distante avec flux d'événements. Le chapitre suivant détaillera ces options de transport ; à ce stade, retenez seulement que l'architecture logique décrite ici ne change pas selon le transport choisi.

En s'appuyant sur JSON-RPC 2.0, MCP hérite d'un écosystème d'outillage déjà mature — bibliothèques, validateurs, habitudes de débogage — plutôt que d'imposer un format ad hoc que chaque équipe aurait dû réapprendre.

Séparation des responsabilités : qui décide de quoi

La robustesse d'une architecture MCP tient à ce que chaque rôle reste cantonné à son périmètre. Un tableau récapitulatif aide à fixer ces frontières :

Cette matrice n'est pas un détail administratif : c'est elle qui détermine où placer les contrôles de sécurité. Un serveur MCP bien conçu ne fait jamais confiance aveuglément aux arguments reçus — il les valide comme il validerait une requête HTTP publique, car c'est en réalité ce qu'il est en train de traiter.

Même si l'hôte applique des politiques de consentement, le serveur doit se comporter comme si aucun filtrage n'avait eu lieu en amont. Un modèle de langage peut être manipulé pour produire des arguments inattendus ; seule une validation côté serveur protège réellement le système sous-jacent.

Glossaire opérationnel

Pour fixer le vocabulaire utilisé dans la suite de la formation :

• Hôte (host) : application utilisateur final qui héberge le modèle et orchestre un ou plusieurs clients. - Client : composant qui maintient une connexion un-à-un avec un serveur MCP et relaie les messages. - Serveur : composant exposant des capacités (tools, resources, prompts) sans connaissance du modèle qui les utilise. - Tool : action invocable de façon autonome par le modèle. - Resource : contenu adressable par URI, attachable au contexte par l'hôte ou l'utilisateur.

Ce qu'il faut retenir avant de poursuivre

L'architecture MCP tient en une phrase : des serveurs ignorants du modèle exposent des capacités déclarées, des clients relaient fidèlement les échanges, et un hôte orchestre le tout en gardant la main sur les décisions sensibles. Cette séparation nette est ce qui permet à un même serveur de servir plusieurs hôtes sans modification, et à un hôte de composer plusieurs serveurs sans connaître leur implémentation interne.

Le chapitre suivant s'appuie directement sur ces bases pour détailler les mécanismes concrets de transport — entrée/sortie standard locale ou HTTP distant avec flux d'événements — et les arbitrages de déploiement associés.