Cours
Concevoir des systèmes agentiques évolutifs
1 h 30 min
16K
Il y a un an et demi, le Model Context Protocol était encore un terme de niche en dehors d’Anthropic. Aujourd’hui, il apparaît dans les entretiens pour l’ingénierie IA, les relations développeurs et les rôles backend, car de nombreuses équipes qui déploient des agents ont un serveur ou un client MCP quelque part dans leur pile.
MCP (Model Context Protocol) est un protocole ouvert qui standardise la façon dont les applications d’IA se connectent à des outils externes, des données et des modèles d’invite. Il résout le problème d’intégration N x M : sans protocole commun, chaque paire modèle-outil requiert son propre connecteur. Avec MCP, vous construisez le connecteur une fois et tout hôte conforme peut l’utiliser. Vous l’entendrez parfois qualifié de « USB‑C de l’IA », utile comme première analogie, pas au-delà.
Les questions posées varient fortement selon le poste. Un développeur junior devra peut‑être expliquer la différence entre tools et resources. Un ingénieur plateforme se fera plutôt demander comment un cœur de protocole sans état change le déploiement. J’ai organisé ce guide par niveau de difficulté et cas d’usage : concentrez‑vous sur les sections qui correspondent à votre rôle.
Le calendrier compte, et je le précise car MCP évolue encore. À la date de rédaction, la spéc stable actuelle est 2025-11-25. Une release candidate pour le 2026-07-28 est figée et doit être publiée dans environ quatre semaines ; tout ce qui vient de cette RC est donc signalé comme prospectif.
Questions MCP pour débutants
Celles‑ci reviennent souvent, quel que soit le niveau. Commencez par le vocabulaire.
Qu’est‑ce que MCP et pourquoi a‑t‑il été créé ?
MCP est une norme ouverte, initialement développée par Anthropic et open‑sourcée en novembre 2024, pour connecter des applications d’IA à des outils et des sources de données externes. Plus simplement : implémentez MCP une fois et vous pouvez dialoguer avec n’importe quel serveur compatible MCP sans réécrire un connecteur pour chaque outil.
Qu’est‑ce qu’un serveur MCP ?
Un serveur est un programme qui expose des tools, des resources et des prompts à un client MCP. Il peut s’exécuter en sous‑processus local via stdio ou en processus distant joignable via HTTP. Le serveur n’a aucune connaissance du modèle lui‑même ; il répond aux requêtes selon le protocole.
Qu’est‑ce qu’un client MCP ?
Le client est le connecteur au niveau protocole intégré dans une application hôte (pensez à Claude Desktop, VS Code ou Cursor) et parle à un serveur à la fois via JSON‑RPC. Un même hôte peut exécuter plusieurs clients, chacun maintenant sa propre connexion un‑à‑un avec un serveur.
En quoi MCP diffère‑t‑il d’une API REST classique ?
Une API REST est conçue pour être appelée dans du code par des développeurs. MCP est pensé pour qu’un LLM découvre et appelle des capacités à l’exécution. Cette distinction compte plus que le format sur le fil. Un client peut demander à un serveur tools/list et obtenir une description structurée des capacités disponibles, ce qu’une API REST typique n’offre pas par défaut. Pour une intégration simple, un appel direct d’API reste souvent plus rapide et moins coûteux.
Quels types de resources un serveur peut‑il exposer ?
Tout ce qui est adressable par une URI : fichiers, enregistrements de base de données, documents, valeurs de configuration, réponses d’API. Les resources sont du contexte en lecture seule, pas des actions, ce qui est une confusion fréquente chez les débutants.
Questions sur les concepts clés MCP
Une fois le vocabulaire acquis, les questions portent sur la façon dont les éléments échangent.
Quelle est l’architecture d’ensemble ?
Trois rôles : host, client, server. Le host est l’application utilisée par la personne. Il instancie un ou plusieurs clients, et chaque client maintient une connexion unique à un serveur. Chaque message entre client et serveur est en JSON‑RPC 2.0, ce qui vous offre un format de transport stable quel que soit le canal.
Quelles sont les trois phases du cycle de vie d’une connexion ?
Initialisation, opération, arrêt. Pendant l’initialisation, le client envoie sa version de protocole et ses capacités prises en charge, et le serveur répond avec les siennes. Une fois l’accord trouvé, les requêtes normales comme tools/list et tools/call ont lieu pendant la phase d’opération. L’arrêt est simplement une fermeture propre.
Quels transports MCP utilise‑t‑il aujourd’hui ?
stdio pour les serveurs locaux en sous‑processus, et Streamable HTTP pour les serveurs distants. Streamable HTTP a remplacé l’ancien transport HTTP+SSE dans la spéc du 2025-03-26, donc décrire deux points de terminaison SSE séparés est déjà obsolète.
Quelle est la vraie différence entre tools, resources et prompts ?
La distinction porte sur le contrôle, pas sur le type de données :
- Les tools sont contrôlés par le modèle. Le LLM décide quand les appeler selon le contexte.
- Les resources sont contrôlées par l’application. L’hôte ou l’utilisateur décide quand les charger.
- Les prompts sont contrôlés par l’utilisateur. Une personne sélectionne explicitement un modèle d’invite avant l’inférence.
Beaucoup de candidats les définissent par le type de données véhiculées, ce qui passe à côté de l’essentiel.
Questions sur les tools, resources et prompts MCP
Une fois le modèle de contrôle compris, la question suivante est : à quoi ressemblent ces primitives en pratique ?
Que contient la définition d’un tool ?
Un name, une description, un inputSchema rédigé en JSON Schema, et depuis la spéc du 2025-06-18, un outputSchema optionnel plus des annotations décrivant des comportements tels que lecture seule ou destructif. Les clients doivent considérer les annotations comme non fiables sauf si elles proviennent d’un serveur de confiance. Ce sont des indices, pas des garanties.
Quand faire d’une chose un tool plutôt qu’une resource ?
S’il y a un effet de bord ou qu’un calcul à jour est nécessaire, c’est un tool. Si c’est une donnée de référence statique ou semi‑statique sans effet de bord, c’est une resource. Une requête météo en direct auprès d’une API est un tool. Une liste mise en cache des villes prises en charge est une resource.
Qu’est‑ce qui fait un bon tool MCP, au‑delà du simple fonctionnement ?
Concevez‑le autour de ce que l’utilisateur veut accomplir, pas autour des endpoints disponibles. Un tool doit encapsuler un flux de travail complet, pas un simple appel brut d’API. Sa description compte aussi : ce texte entre dans le contexte du modèle et influe sur le choix du bon tool. Voici un exemple minimal avec la couche FastMCP du SDK Python :
from mcp.server.fastmcp import FastMCP
app = FastMCP("weather-demo")
@app.tool()
async def get_weather(city: str) -> str:
"""Get the current weather for a city."""
return f"Weather data for {city}"
@app.resource("config://units")
async def get_units() -> str:
"""Static configuration for the unit system in use."""
return '{"temperature": "celsius"}'La docstring du tool devient sa description ; la resource est une donnée statique derrière une URI, sans effet de bord.
Comment un client récupère‑t‑il une resource ?
Il appelle resources/read sur une URI obtenue via resources/list. Si le serveur prend en charge la capacité listChanged, il peut notifier le client d’un changement de la liste des resources. Sans cette capacité, le client n’a aucun signal et doit sonder ou actualiser manuellement.
Questions sur le développement de serveurs MCP
Ici, la connaissance conceptuelle doit se traduire en quelque chose qui tourne.
Quels SDK officiels existent, et sont‑ils tous aussi matures ?
Non. Les SDK sont hiérarchisés : TypeScript, Python, C# et Go sont en Tier 1 avec prise en charge complète, Java et Rust en Tier 2, et Swift, Ruby, PHP et Kotlin en Tier 3. Le SDK Python inclut FastMCP, son API serveur à base de décorateurs.
Quel est le bug le plus courant qui casse un serveur local ?
Écrire sur stdout quand il ne faut pas. Un transport stdio utilise stdout exclusivement pour les messages JSON‑RPC ; un print() ou console.log() parasite corrompt le flux et le parseur du client s’étouffe. Tout ce que vous souhaitez journaliser pour le débogage doit aller sur stderr.
MCP Inspector affichant tool et resource. Vidéo de l’auteur.
Comment la gestion des erreurs fonctionne‑t‑elle dans MCP, et pourquoi cela compte en entretien ?
Il y a trois niveaux. Les échecs au niveau transport sont des problèmes de connexion. Les erreurs au niveau protocole utilisent les codes JSON‑RPC standard (-32700 pour une erreur d’analyse, -32600 à -32603 pour requêtes invalides, méthodes inconnues, etc.). Les échecs au niveau applicatif, comme une API appelée par votre tool qui renvoie une erreur, doivent revenir avec isError: true dans le résultat du tool afin que le modèle puisse le voir et réagir.
return {
"content": [{"type": "text", "text": "Rate limit exceeded, try again later"}],
"isError": True
}Ce drapeau permet au modèle de constater l’échec et d’essayer autre chose.
MCP est‑il à état actuellement ?
Oui, les sessions sont aujourd’hui suivies au niveau de la connexion. Cela crée des problèmes de mise à l’échelle en production, que je couvre dans la section design système.
Questions sur la sécurité et la gouvernance MCP
Les questions de sécurité arrivent désormais souvent dans les entretiens MCP, surtout pour les rôles plateforme et entreprise.
En quoi l’authentification diffère‑t‑elle entre les transports stdio et HTTP ?
Pour les serveurs locaux stdio, l’authentification est en pratique optionnelle ; vous faites déjà confiance au processus que vous lancez. Pour les serveurs distants sur HTTP, OAuth 2.1 est le cadre, et les serveurs sont classés comme OAuth 2.0 resource servers depuis la spéc du 2025-06-18. OAuth n’est pas exigé partout dans MCP.
Qu’est‑ce que le tool poisoning ?
Ce sont des instructions malveillantes cachées dans les métadonnées d’un tool, généralement la description ou le schéma, que le modèle lit en décidant quel tool appeler. Le tool n’a pas besoin d’être invoqué pour que cela compte, car le modèle a déjà vu ces instructions au moment du listing.
En quoi une attaque « rug pull » diffère‑t‑elle du tool poisoning ?
Le tool poisoning est un problème au point d’entrée. Le rug pull est un problème de persistance : un tool est propre lors de votre approbation, puis sa définition change ensuite, et la plupart des clients n’ont aucun moyen intégré d’imposer une ré‑approbation. Se défendre contre l’un ne protège pas de l’autre.
Qu’est‑ce que l’Enterprise‑Managed Authorization, et pourquoi c’est important maintenant ?
EMA est une extension MCP devenue stable le 18 juin 2026. Elle déplace la décision d’autorisation vers l’IdP de l’organisation au lieu d’un clic de consentement par serveur et par employé. Le client obtient un Identity Assertion JWT signé lors du SSO et l’échange contre un jeton d’accès à portée limitée depuis le serveur d’autorisation du serveur. Anthropic, Microsoft et Okta la prennent en charge.
Questions MCP liées aux agents d’IA
C’est ici que le protocole rejoint le design d’agent.
Pourquoi MCP est‑il important spécifiquement pour les agents ?
Les agents ont besoin de contexte et d’action. MCP regroupe les deux dans un seul protocole. Comme indiqué plus haut, tools/list permet à un agent de découvrir ce qui est disponible au lieu de s’appuyer sur une liste en dur dans son code.
Modèle hôte, client et serveur d’agent. Image de l’auteur.
Quelle est la différence entre MCP et A2A ?
La règle courte : MCP connecte les agents aux outils, A2A connecte les agents entre eux. Les deux protocoles relèvent désormais de l’Agentic AI Foundation et sont donc vus comme des couches distinctes, pas comme des concurrents.
Qu’est‑ce que la primitive de sampling, et faut‑il encore la mentionner ?
Sampling permet à un serveur de demander via le client une complétion par le modèle, ce qui permet à un serveur d’adopter un comportement d’agent sans détenir de clés d’API. Connaissez la primitive, mais ajoutez la précision : la RC du 2026-07-28 marque Sampling, Roots et Logging comme dépréciés selon la nouvelle politique de cycle de vie. Ils restent fonctionnels au moins douze mois, mais on conseille de plus en plus aux auteurs de serveurs d’appeler directement l’API d’un fournisseur de modèles.
Comment les agents évitent‑ils d’exploser leur fenêtre de contexte avec des définitions de tools ?
En ne chargeant pas toutes les définitions de tools d’emblée. L’approche Tool Search d’Anthropic diffère le chargement des schémas de tools jusqu’au moment du besoin, et le retour d’expérience d’ingénierie fait état d’une réduction de 85 % de l’usage de jetons pour les environnements riches en tools tout en gardant l’accès à l’intégralité de la bibliothèque. En entretien, j’associerais ce chargement différé à des serveurs à périmètre étroit.
Questions de design système MCP
Les scénarios testent votre capacité à appliquer ces idées sous contraintes, pas juste à réciter des définitions.
Concevez un système de recherche documentaire avec MCP.
MCP et RAG ne sont pas en concurrence ici. RAG gère la recherche vectorielle pré‑indexée ; MCP expose cette recherche en tant que tool ou resource que l’agent peut appeler en direct, à côté des autres actions nécessaires. Traitez la question comme un assemblage des deux, pas un remplacement de l’un par l’autre.
Concevez un serveur MCP pour des données internes d’entreprise.
Partez du principe de responsabilité unique : un serveur par domaine, par exemple un serveur base de données et un serveur fichiers séparés, plutôt qu’un serveur qui fait tout. Ajoutez OAuth 2.1, des scopes de moindre privilège par tool, et l’audit logging dès le début, car le contrôle d’accès est plus difficile à corriger après mise en production.
Comment mettre à l’échelle un déploiement MCP aujourd’hui, avant la publication du cœur sans état ?
Les candidats trébuchent souvent en décrivant la future spéc comme déjà sortie. L’étatfulness mentionnée plus haut est le vrai enjeu : l’échelle horizontale exige un routage affinité, un store de session partagé, ou une passerelle MCP. La RC du 2026-07-28 supprime les sessions au niveau protocole, mais ce n’est pas encore en production.
Comment éviter qu’un large déploiement multi‑serveurs n’inonde le modèle en jetons ?
Le chargement différé vu dans la section agents aide ici aussi. Au niveau du déploiement, filtrez et agrégerez côté serveur avant d’alimenter le contexte du modèle, et paginez toute liste. La règle clé : contrôlez ce qui entre dans la fenêtre de contexte.
Questions d’intégration MCP
Les questions d’intégration vérifient où MCP apparaît dans les outils développeur courants.
Comment MCP se manifeste‑t‑il dans les produits Claude ?
Claude.ai, Claude Desktop et Claude Code prennent tous en charge MCP, et Anthropic maintient un répertoire de connecteurs avec des serveurs pré‑construits. Il existe aussi un connecteur MCP dans l’API Messages pour les serveurs distants, encore en bêta au moment d’écrire.
Claude Desktop affichant un serveur MCP connecté. Image de l’auteur.
MCP n’est‑il utile qu’avec Claude ?
Non. OpenAI a adopté MCP dans ses Agents SDK et Apps SDK à partir de mars 2025. VS Code a livré la prise en charge de la spéc complète mi‑2025, Cursor prend MCP en charge via mcp.json, et Google Cloud comptait plus de 50 serveurs MCP managés en disponibilité générale ou en préversion en avril 2026.
Concrètement, en quoi MCP diffère‑t‑il de RAG ?
C’est la réponse de design système en plus court : RAG répond depuis une base de connaissance planifiée, tandis que MCP gère les consultations et actions en direct.
Questions MCP avancées
Les questions avancées testent si vous suivez l’évolution du protocole, pas seulement son état actuel.
Pouvez‑vous retracer l’historique des versions de la spéc ?
Les interviewers posent la question pour voir si vous savez ce qui a changé et quand. Cinq révisions comptent, et une seule est encore spéculative :
|
Version |
Date |
Changements |
|
2024-11-05 |
Nov 2024 |
Version initiale |
|
2025-03-26 |
Mar 2025 |
Streamable HTTP remplace HTTP+SSE ; introduction d’OAuth 2.1 |
|
2025-06-18 |
Juin 2025 |
Sorties d’outils structurées, elicitation, classification en OAuth resource server |
|
2025-11-25 |
Nov 2025 |
Spéc stable actuelle ; Tasks asynchrones (expérimental), gouvernance formalisée |
|
2026-07-28 |
RC figée mai 2026 |
Cœur sans état, MCP Apps, cadre d’extensions |
L’essentiel est de savoir quelle ligne est réellement sortie.
Qui gouverne MCP aujourd’hui ?
Anthropic a confié le protocole à l’Agentic AI Foundation, un fonds dirigé sous l’égide de la Linux Foundation, le 9 décembre 2025. Block et OpenAI ont cofondé l’AAIF aux côtés d’Anthropic, avec Google, Microsoft, AWS, Cloudflare et Bloomberg comme membres de soutien. Les mainteneurs ont conservé les décisions techniques ; la gouvernance a été élargie.
Qu’est‑ce qui change concrètement dans la version du 2026-07-28 ?
Le principal changement est le cœur sans état évoqué en design système : la poignée de main initialize/initialized et l’en‑tête Mcp-Session-Id disparaissent, remplacés par des informations de capacités qui voyagent dans _meta à chaque requête. Cela supprime le besoin de routage collant. Un cadre d’extensions définit aussi comment des capacités optionnelles comme MCP Apps et Tasks évoluent et se stabilisent séparément.
Que sont les extensions MCP, et fonctionnent‑elles partout ?
Non. Les extensions sont des capacités opt‑in, comme Enterprise‑Managed Authorization, OAuth Client Credentials pour l’authentification machine‑à‑machine, et MCP Apps pour des interfaces interactives dans un hôte. La prise en charge varie selon les clients, n’en faites pas une dépendance universelle.
Questions MCP basées sur des scénarios
Elles testent le raisonnement diagnostique plus que les faits mémorisés ; structurez vos réponses du symptôme à la cause puis au correctif.
Les appels de tools échouent par intermittence. Que vérifiez‑vous d’abord ?
Vérifiez si les échecs reviennent avec isError: true dans le résultat du tool ou comme erreur au niveau protocole. Cela indique si le problème est dans la logique du tool ou dans le transport. Ensuite, regardez les limites de taux de l’API encapsulée et les timeouts avant d’incriminer le modèle.
Un agent agit sur des données de resource obsolètes. Pourquoi ?
On revient à la question des resources : listChanged informe le client qu’une resource a changé. Sans cette déclaration, le client n’a aucun signal et continue de servir un instantané en cache jusqu’à un rafraîchissement forcé.
Un serveur MCP est devenu un goulet d’étranglement. Quelle est votre action ?
Découpez par domaine, ajoutez du pooling de connexions et scalez horizontalement. Tant que le cœur sans état n’est pas publié, vous aurez peut‑être besoin de l’affinité de session mentionnée en design système.
Des données sensibles ont fuité via un appel de tool. Comment cela a‑t‑il pu arriver ?
Deux causes fréquentes : un tool avec des permissions trop larges, ou une absence de sanitization de sortie avant l’injection dans le contexte du modèle. Le moindre privilège par tool et une étape de sanitization avant le contexte sont les remèdes. Le tool poisoning est lié : un modèle peut être incité à transférer des données sans code d’exfiltration explicite.
Erreurs fréquentes en entretien MCP
Quelques schémas reviennent suffisamment souvent pour être cités :
-
Considérer MCP comme un remplacement REST prêt à l’emploi, malgré la distinction expliquée plus haut
-
Définir tools vs resources par type de données après avoir expliqué le modèle de contrôle
-
Supposer la même règle d’auth pour
stdioet HTTP -
Donner la réponse SSE héritée après le changement de transport évoqué plus haut
-
Mélanger la spéc publiée et la RC du 2026-07-28
-
Omettre les risques de sécurité évoqués plus haut lorsqu’on vous demande de concevoir un système d’appel d’outils
La plupart de ces erreurs viennent d’anciens tutoriels.
Comment se préparer aux entretiens MCP
La pratique concrète est essentielle pour ce protocole.
-
Créez un petit serveur avec FastMCP ou le SDK TypeScript, exposez un tool et une resource, et faites‑le tourner
-
Installez l’Inspector officiel (
npx @modelcontextprotocol/inspector) et observez le trafic JSON‑RPC brut affiché -
Connectez votre serveur à un client réel, Claude Desktop, VS Code ou Cursor, et regardez la poignée de main d’initialisation
-
Lisez le vrai changelog de la spéc plutôt qu’un résumé de seconde main, surtout les entrées 2025-06-18 et 2025-11-25
-
Choisissez un scénario de design système de cet article et rédigez une réponse complète avant votre entretien
Ces étapes séparent la connaissance des définitions de la vraie familiarité pratique.
Conclusion
Mémoriser les définitions MCP ne suffit plus. La partie difficile est de savoir quelle réponse correspond à quelle version de la spéc. Les déploiements actuels gèrent encore des sessions au niveau connexion ; la RC du 2026-07-28 va vers un cœur sans état. Si vous mélangez les deux, votre réponse d’architecture sonne plus confiante que précise.
C’est pourquoi MCP doit se tester, pas seulement se lire. Construisez le petit serveur décrit dans la préparation, observez un client lister des tools et lire des resources, et repérez où le protocole s’arrête et où commence votre design applicatif. La bonne réponse d’entretien n’est pas « MCP est l’USB‑C de l’IA ». C’est « voici ce que MCP standardise, ce qu’il ne standardise pas, et ce qui a changé récemment ».
Pour aller plus loin de manière structurée, notre cours Building Scalable Agentic Systems couvre MCP et A2A dans le contexte du design, du test et du déploiement d’agents.