# Applied AI — Niveau Avancé — Session 5 # Quiz de validation : MCP en profondeur **Instructeur :** Yann Isola **Format :** 10 QCM (questions à choix multiples) — une seule bonne réponse par question. **Seuil de réussite recommandé :** 8/10 (niveau certification). **Durée :** 15 min. --- **Q1.** Dans l'architecture MCP, quelle est la relation entre clients et serveurs ? - A. Un client peut se connecter à plusieurs serveurs simultanément - B. Un serveur exige un client dédié : la relation est strictement 1:1, et c'est l'hôte qui instancie un client par serveur - C. Les serveurs communiquent directement entre eux pour partager le contexte - D. Le client et le serveur sont le même processus, séparés logiquement **Réponse : B.** L'isolation 1:1 est un choix de sécurité délibéré : chaque serveur est un processus séparé avec son client dédié ; seul l'hôte a la vue d'ensemble. (A décrit le rôle de l'hôte, pas du client ; C est explicitement interdit par le modèle de sécurité ; D confond stdio-sous-processus et fusion de processus.) --- **Q2.** Quel format de message est utilisé par MCP sur tous ses transports ? - A. Protocol Buffers (protobuf) - B. XML-RPC - C. JSON-RPC 2.0 - D. GraphQL **Réponse : C.** Tout message MCP est du JSON-RPC 2.0 : requêtes (avec `id`), réponses (même `id`, `result` ou `error`) et notifications (sans `id`). --- **Q3.** Un développeur ajoute `print("étape 2 OK")` dans son serveur MCP en transport stdio, pour déboguer. Conséquence ? - A. Aucune : le message apparaît dans les logs de l'hôte - B. Le flux JSON-RPC sur stdout est corrompu, le client échoue à analyser les messages ; les logs doivent aller sur stderr - C. Le message est automatiquement converti en notification MCP - D. Le serveur redémarre proprement **Réponse : B.** En stdio, stdout est réservé au flux JSON-RPC (un message JSON par ligne). Toute écriture parasite le corrompt. stderr reste disponible pour la journalisation. --- **Q4.** Quel transport recommandez-vous pour un serveur MCP d'entreprise mutualisé, servant des centaines d'utilisateurs authentifiés via OAuth 2.1 ? - A. stdio, pour la latence minimale - B. SSE (Server-Sent Events), le standard actuel pour le distant - C. Streamable HTTP, qui remplace SSE pour les serveurs distants - D. WebSocket brut, seul transport bidirectionnel **Réponse : C.** Streamable HTTP est le transport distant courant : POST vers un point de terminaison unique, flux de réponse possible, sessions via `Mcp-Session-Id`, authentification web standard. SSE seul est déprécié (piège B). stdio (A) est réservé au local mono-utilisateur. --- **Q5.** Question centrale de certification : qu'est-ce qui distingue fondamentalement les trois primitives MCP ? - A. Le format des données : texte pour les Prompts, JSON pour les Tools, binaire pour les Resources - B. Le contrôleur de l'invocation : le modèle pour les Tools, l'application pour les Resources, l'utilisateur pour les Prompts - C. Le transport : Tools en stdio, Resources en HTTP, Prompts dans les deux - D. Le sens des données : Tools en écriture, Resources en lecture, Prompts en lecture/écriture **Réponse : B.** C'est LE critère discriminant : *model-controlled* / *application-controlled* / *user-controlled*. D est le piège séduisant : lecture/écriture est une corrélation fréquente, pas le critère — une recherche déclenchée par le modèle est un Tool bien qu'elle soit en lecture. --- **Q6.** L'agent doit pouvoir chercher un client par nom dans le CRM au moment où la conversation l'exige, à sa propre initiative. Quelle primitive ? - A. Resource, car c'est une opération de lecture seule - B. Prompt, car la recherche part d'une demande de l'utilisateur - C. Tool, car c'est le modèle qui décide dynamiquement de déclencher la recherche - D. Notification, car le CRM pousse les données **Réponse : C.** Piège d'examen classique : « lecture ⇒ Resource » est faux. Le critère est le contrôleur : ici le modèle décide au fil du raisonnement ⇒ Tool, avec un JSON Schema décrivant l'argument `nom`. --- **Q7.** À quoi sert la négociation de capacités lors du handshake `initialize` ? - A. À chiffrer la connexion entre client et serveur - B. À permettre à un client et un serveur de versions différentes de coopérer sur l'intersection de ce qu'ils supportent, sans casser la compatibilité - C. À mesurer la latence du transport avant d'ouvrir la session - D. À authentifier l'utilisateur auprès du serveur **Réponse : B.** Client et serveur déclarent chacun leurs capacités (tools, resources, prompts, subscriptions, sampling...). Le protocole peut ainsi évoluer : chacun n'utilise que ce que l'autre a déclaré. Ni chiffrement (A), ni authentification (D) — ceux-ci relèvent du transport. --- **Q8.** Un serveur MCP expose `rembourser_commande`. L'exigence métier : bloquer tout remboursement supérieur à 500 $. Où placer ce contrôle pour qu'il résiste à une injection de prompt ? - A. Dans le prompt système de l'agent : « ne rembourse jamais plus de 500 $ » - B. Dans la description du Tool, pour que le modèle s'autolimite - C. Dans le code du serveur, qui refuse et renvoie un statut d'escalade quel que soit ce que demande le modèle - D. Dans l'interface utilisateur, en masquant le champ montant **Réponse : C.** Défense en profondeur : un contrôle dans le prompt ou la description (A, B) n'est qu'une suggestion, contournable si le modèle est manipulé. Le garde-fou côté serveur s'applique mécaniquement. (A et B restent utiles en complément, jamais seuls.) --- **Q9.** Un tableau de bord doit se rafraîchir automatiquement quand un fichier de configuration change côté serveur. Quel mécanisme MCP ? - A. Interroger `resources/read` en boucle toutes les secondes (polling) - B. S'abonner via `resources/subscribe` ; le serveur émet `notifications/resources/updated` et l'hôte relit la ressource - C. Exposer le fichier comme un Tool que le modèle appelle régulièrement - D. Utiliser `notifications/tools/list_changed` **Réponse : B.** C'est le patron d'abonnement aux ressources — à condition que le client ait déclaré la capacité correspondante au handshake. A (polling) gaspille ; C confie au modèle une responsabilité d'infrastructure ; D concerne l'enregistrement dynamique d'outils, pas les ressources. --- **Q10.** Votre client agrège deux serveurs MCP : l'un renvoie des dates au format `15/03/2026`, l'autre `27 Mar 2026`. Quelle est la bonne pratique d'architecture ? - A. Laisser le modèle interpréter les formats : les LLM comprennent les dates - B. Normaliser à la frontière d'intégration vers un format canonique (ISO 8601) dans le serveur ou le client, jamais compter sur le modèle pour deviner - C. Rejeter le serveur tiers tant qu'il n'adopte pas votre format - D. Convertir toutes les dates en horodatage Unix dans les prompts **Réponse : B.** La normalisation des données hétérogènes (dates, devises, unités) se fait en code, à la frontière — le serveur MCP joue le rôle de couche anti-corruption. Compter sur le modèle (A) introduit des erreurs silencieuses (ambiguïté 03/04 : 3 avril ou 4 mars ?) ; C est irréaliste avec des serveurs tiers ; D dégrade la lisibilité sans traiter le fond. --- ## Barème et remédiation | Score | Lecture | |---|---| | 9–10 | Niveau certification atteint sur ce module | | 7–8 | Revoir les questions manquées ; relire le Bloc 3 (primitives) si Q5/Q6 échouées | | ≤ 6 | Reprendre le guide complet + refaire l'Exercice 3 avant de poursuivre | **Questions les plus discriminantes pour l'examen :** Q5, Q6 (contrôleur des primitives) et Q4 (transports). Toute erreur sur ces trois-là doit déclencher une révision ciblée.