Guide Professeur — Session 7 : Multi-agents & MCP

Programme : Applied AI — Niveau Intermédiaire Instructeur : Yann Isola Durée : 2 heures (120 minutes) Module couvert : Module 5 — Multi-agents & MCP (Model Context Protocol)

1. Vue d’ensemble de la session

Objectifs pédagogiques

À la fin de cette session, chaque participant doit être capable de :

Expliquer pourquoi découper un agent monolithique en plusieurs agents spécialisés : séparation des responsabilités — chaque agent a son prompt système, ses outils, ses garde-fous.
Nommer et reconnaître les 4 patrons multi-agents : orchestrateur/exécutants (orchestrator/worker), pipeline (chaîne), débat/consensus, superviseur.
Choisir le bon patron pour un cas métier donné, et justifier ce choix en une phrase.
Décrire les 3 modes de communication entre agents : mémoire partagée, passage de messages, architecture en tableau noir (blackboard).
Définir MCP (Model Context Protocol, protocole de contexte de modèle) : un standard universel pour connecter des modèles d’IA (intelligence artificielle) à des outils et sources de données.
Dessiner l’architecture MCP : Hôte (votre application) ↔ Client (à l’intérieur de l’hôte) ↔ Serveur (qui fournit outils et ressources).
Distinguer les 3 primitives MCP : Tools (actions invoquées par le modèle), Resources (données contrôlées par l’application), Prompts (modèles réutilisables).
Citer les 2 transports MCP : stdio (standard input/output, entrée/sortie standard — pour le local) et HTTP+SSE (HyperText Transfer Protocol + Server-Sent Events, événements envoyés par le serveur — pour le distant).
Expliquer l’analogie « USB de l’IA » : un protocole unique pour brancher n’importe quel modèle sur n’importe quel fournisseur d’outils, au lieu de N×M intégrations sur mesure.
Esquisser un serveur MCP maison : exposer sa logique métier sous forme d’outils standardisés.

Prérequis

Sessions 5 (Outils & Tool Calling) et 6 (Boucle agentique) indispensables. Cette session généralise : Session 5 = un outil, Session 6 = un agent, Session 7 = plusieurs agents et un standard pour les outils. Si un participant a manqué la 6, faites-lui redessiner la boucle percevoir → réfléchir → agir → observer en 3 minutes avant de démarrer.
Savoir lire du JSON (JavaScript Object Notation, format d’échange de données).
Notion d’API (Application Programming Interface, interface de programmation applicative) et de client/serveur.

Matériel nécessaire

Vidéoprojecteur + slides (slides/slides.md).
Page web interactive (webpage/index.html) — hors ligne : (1) visualiseur d’architectures multi-agents avec glisser-déposer des agents dans les patrons et flux de messages animés ; (2) explorateur du protocole MCP avec diagramme Hôte ↔ Client ↔ Serveur cliquable et les 3 primitives détaillées.
Feuilles d’exercices (exercises/exercises.md).
Quiz (quiz/quiz.md).
Idéalement un portable pour deux participants (manipulation du visualiseur en Séquence C et E).

Message central de la session

« Un agent seul, c’est un employé qui fait tout. Une équipe d’agents spécialisés, c’est une entreprise : chacun son rôle, ses outils, ses limites. Et MCP, c’est la prise USB qui permet à n’importe quel employé de brancher n’importe quel outil — sans refaire le câblage à chaque fois. »

Répétez cette double idée (équipe + prise universelle) au moins trois fois sous des formes différentes.

Fil conducteur narratif : NewsRoom 📰

Toute la session s’appuie sur un exemple filé : NewsRoom, un système de veille et de rédaction pour une équipe finance. La mission type :

« Chaque matin, produis une synthèse de 500 mots sur l’actualité des stablecoins : sourcée, vérifiée, relue, et publiée sur le canal interne. »

Les agents de NewsRoom :

🔍 Chercheur — outils : recherche web, lecture d’articles. Prompt système : « Trouve des sources fiables, cite tout. »
✍️ Rédacteur — aucun outil externe. Prompt système : « Rédige clair et structuré, 500 mots. »
🕵️ Vérificateur — outils : recherche web (relecture croisée). Prompt système : « Traque les erreurs factuelles, sois impitoyable. »
📣 Publieur — outil : publication sur le canal interne. Action irréversible → garde-fou humain.

NewsRoom illustre chaque patron : en pipeline (Chercheur → Rédacteur → Vérificateur → Publieur), en orchestrateur (un chef d’édition distribue), en débat (deux Rédacteurs proposent, un juge tranche), en superviseur (un contrôleur surveille et reprend la main). Puis, en seconde heure, MCP répond à la question : « comment tous ces agents accèdent-ils à leurs outils sans que je code 12 intégrations ? »

2. Déroulé minute par minute

Horaire	Durée	Séquence	Support
0:00 – 0:05	5 min	Accueil, rappel Session 6 (la boucle), objectifs	Slides 1–3
0:05 – 0:20	15 min	Séquence A — Pourquoi plusieurs agents ? La séparation des responsabilités	Slides 4–7
0:20 – 0:40	20 min	Séquence B — Les 4 patrons : orchestrateur, pipeline, débat, superviseur	Slides 8–13
0:40 – 0:55	15 min	Séquence C — Manipulation : visualiseur d’architectures (glisser-déposer + flux animés)	Webpage (onglet 1)
0:55 – 1:05	10 min	☕ Pause	—
1:05 – 1:15	10 min	Séquence D — Communication entre agents : mémoire partagée, messages, tableau noir	Slides 14–16
1:15 – 1:35	20 min	Séquence E — MCP : le problème N×M, l’architecture Hôte/Client/Serveur, les 3 primitives	Slides 17–24 + webpage (onglet 2)
1:35 – 1:45	10 min	Séquence F — Construire son propre serveur MCP + écosystème existant	Slides 25–27
1:45 – 1:55	10 min	Exercice flash en binômes (Exercice 1)	Exercices
1:55 – 2:00	5 min	Quiz express oral, exit tickets, annonce Session 8	Quiz + slides 28–29

⏱️ Marge de sécurité : la Séquence F peut être compressée à 5 minutes (le catalogue de serveurs MCP est dans la webpage). Ne sacrifiez jamais la Séquence E : si les participants repartent sans comprendre Hôte ↔ Client ↔ Serveur, la session a raté sa seconde moitié. En cas de gros retard, l’Exercice 1 devient un devoir maison.

3. Notes détaillées par séquence

Séquence A — Pourquoi plusieurs agents ? (15 min)

Objectif : faire émerger le besoin multi-agent à partir des limites d’un agent unique.

Accroche (3 min). Repartez de la Session 6 : « Vous savez construire un agent. Alors construisons NewsRoom en UN seul agent : un prompt système géant qui dit “cherche, rédige, vérifie, publie”, avec les 4 familles d’outils. Qu’est-ce qui va mal se passer ? » Laissez la salle chercher. Réponses attendues (ou à souffler) :

Le prompt système devient un monstre : des instructions de recherche, de style, de vérification et de publication se contredisent (« sois exhaustif » vs « sois concis »).
Tous les outils pour tout le monde : l’étape de rédaction n’a aucun besoin de l’outil de publication — mais elle y a accès. Risque inutile.
Impossible à déboguer : quand la synthèse est mauvaise, était-ce la recherche, la rédaction ou la vérification ? Tout est mélangé dans une seule exécution.
Le contexte explose : recherches + brouillons + relectures dans une seule fenêtre de contexte → l’agent se noie.

Le principe (5 min). Énoncez la séparation des responsabilités (separation of concerns) : chaque agent a…

Son prompt système — une mission unique, claire, sans contradictions.
Ses outils — uniquement ceux dont il a besoin (rappel Session 5 : principe du moindre privilège).
Ses garde-fous — le Publieur a un point de contrôle humain ; le Rédacteur n’en a pas besoin.

Analogie filée : l’entreprise. On n’embauche pas une seule personne pour faire comptabilité + ventes + juridique + informatique. Pas parce que c’est impossible — parce que c’est fragile. Un spécialiste par domaine, chacun ses accès (la comptable a la clé du coffre, pas le stagiaire marketing).

Nuance importante (4 min). Comme en Session 6 (« l’agentivité est une propriété du système »), insistez : les 4 agents de NewsRoom peuvent tourner sur le même modèle (même Claude, même GPT). Ce qui change entre eux : le prompt système, la liste d’outils, les garde-fous. Multi-agent ≠ multi-modèle. (On peut mélanger les modèles — petit modèle rapide pour le Chercheur, gros modèle pour le Rédacteur — c’est un raffinement, pas la définition.)

Contre-point à installer tôt (3 min). Le multi-agent n’est pas gratuit : plus d’appels au modèle (coût, latence), plus de coordination, plus de points de défaillance. Règle d’or, symétrique de la Session 6 : si un agent suffit, n’en mettez pas quatre. On y revient en fin de session.

Séquence B — Les 4 patrons multi-agents (20 min)

Objectif : que chaque participant sache dessiner les 4 patrons et citer un cas d’usage pour chacun.

Pour chaque patron : dessin au tableau (ou slide), déroulé avec NewsRoom, cas d’usage typique, limite principale. Environ 5 min par patron, débat/consensus et superviseur peuvent être regroupés si le temps file.

1. Pipeline / chaîne (le plus simple).

Chercheur → Rédacteur → Vérificateur → Publieur

Chaque agent reçoit la sortie du précédent, la transforme, la passe au suivant. Flux linéaire et prévisible.
Cas d’usage : traitement de documents (extraction → normalisation → validation), génération de contenu, ETL (Extract-Transform-Load, extraction-transformation-chargement) intelligent.
Limite : rigide. Si le Vérificateur trouve une erreur, il faut prévoir un retour en arrière (renvoyer au Rédacteur) — et déjà, le pipeline pur ne suffit plus.
À dire : « C’est la chaîne de montage. Efficace quand les étapes sont connues d’avance. »

2. Orchestrateur / exécutants (orchestrator/worker — le plus courant).

            ┌────────────────┐
            │ ORCHESTRATEUR  │  (décompose, distribue, assemble)
            └──┬────┬────┬───┘
               ▼    ▼    ▼
          Chercheur Rédacteur Vérificateur

Un agent central décompose la mission, délègue aux spécialistes (en parallèle si possible), assemble les résultats. Les exécutants ne se parlent pas entre eux : tout passe par le chef.
Cas d’usage : tâches complexes à décomposition variable — recherche approfondie, analyse multi-source, génération de rapport à sections indépendantes.
Limite : l’orchestrateur est un goulot d’étranglement et un point de défaillance unique. S’il décompose mal, tout le reste rate.
À dire : « C’est le chef de projet. Puissant quand la décomposition n’est pas connue d’avance — c’est l’orchestrateur qui la décide à l’exécution. » Contraste clé avec le pipeline : pipeline = étapes fixées par le développeur ; orchestrateur = étapes décidées par le modèle.

3. Débat / consensus.

Rédacteur A ──┐
              ├──▶ JUGE ──▶ meilleure version (ou synthèse)
Rédacteur B ──┘

Plusieurs agents produisent des réponses indépendantes (ou s’affrontent en plusieurs tours d’arguments), puis un juge tranche ou un vote fait consensus.
Cas d’usage : décisions à fort enjeu, réduction des erreurs (une hallucination a peu de chances d’être commise à l’identique par deux agents indépendants), revue critique (un agent « avocat du diable »).
Limite : coût multiplié par le nombre de débatteurs. À réserver aux décisions qui le méritent.
Exemple parlant pour ce public : validation d’une analyse de risque réglementaire — deux agents analysent indépendamment, les divergences remontent à un humain. Les convergences donnent confiance ; les divergences donnent de l’information.

4. Superviseur.

        ┌──────────────┐
        │  SUPERVISEUR │  (observe, valide, interrompt, réassigne)
        └──────┬───────┘
          surveille
   ┌───────┼─────────┐
   ▼       ▼         ▼
 Agent 1  Agent 2  Agent 3   (qui travaillent, éventuellement en pipeline)

Un agent (ou un composant) surveille l’exécution des autres : vérifie les sorties, détecte les dérives (boucles infinies, hors-sujet, violation de règles), peut interrompre ou réassigner.
Différence avec l’orchestrateur : l’orchestrateur distribue le travail ; le superviseur contrôle la qualité et la sécurité. Les deux se combinent souvent.
Cas d’usage : environnements à conformité forte (finance, santé, juridique) — le superviseur est la couche de contrôle permanente.
À dire : « L’orchestrateur est le chef de projet ; le superviseur est le contrôle qualité + le responsable conformité. »

Synthèse (2 min). Tableau récapitulatif (slide 13) :

Patron	Qui décide du flux ?	Force	Faiblesse
Pipeline	Le développeur (fixe)	Simple, prévisible, débogable	Rigide
Orchestrateur	L’orchestrateur (dynamique)	Flexible, parallélisable	Goulot central
Débat	Le juge / le vote	Fiabilité par recoupement	Coût ×N
Superviseur	Les agents + contrôle continu	Sécurité, conformité	Complexité

Séquence C — Manipulation du visualiseur (15 min)

Objectif : ancrer les patrons par la manipulation.

Ouvrez webpage/index.html, onglet « Architectures multi-agents ». Les participants (en binômes si portables disponibles, sinon vous au vidéoprojecteur avec la salle qui guide) :

Choisissent un patron (pipeline, orchestrateur, débat) — le plateau affiche les emplacements du patron.
Glissent les agents de NewsRoom (Chercheur, Rédacteur, Vérificateur, Publieur, Juge, Orchestrateur) dans les emplacements.
Lancent l’animation : les messages circulent le long des flèches, avec le contenu de chaque message affiché dans le journal (« Chercheur → Rédacteur : 5 sources trouvées… »).
Bouton « Injecter une erreur » : le Vérificateur rejette le brouillon — observez comment chaque patron gère le retour en arrière (le pipeline le montre explicitement).

Consigne à donner : « Placez les agents pour le patron pipeline, lancez, puis répondez : à quel moment le Publieur reçoit-il quelque chose ? Que se passe-t-il si le Vérificateur rejette ? » Puis refaire en orchestrateur et comparer le nombre de messages échangés.

Débrief (3 min) : faites verbaliser la différence pipeline/orchestrateur par un participant. La bonne formulation attendue : « dans le pipeline, le chemin est fixé d’avance ; avec l’orchestrateur, c’est un agent qui décide du chemin. »

Séquence D — Communication entre agents (10 min)

Objectif : connaître les 3 mécanismes par lesquels les agents échangent, avec leurs compromis.

1. Passage de messages (message passing). Chaque agent envoie explicitement des messages à d’autres agents (comme des e-mails internes). C’est le mécanisme naturel du pipeline et de l’orchestrateur.

Traçable (chaque message peut être journalisé), découplé.
❌ Il faut définir qui parle à qui — la topologie.
NewsRoom : l’orchestrateur envoie « mission : trouve 5 sources » au Chercheur, qui répond « voici les 5 sources ».

2. Mémoire partagée (shared memory). Tous les agents lisent et écrivent dans un espace commun (l’historique complet, une base, un document partagé).

Simple : tout le monde voit tout.
❌ Le contexte gonfle vite ; risques d’interférences (un agent écrase ou pollue ce qu’un autre utilise) ; pas de cloisonnement — contradictoire avec la séparation des responsabilités si on n’y prend pas garde.
NewsRoom : un dossier partagé où le Chercheur dépose ses sources et où le Rédacteur pioche.

3. Tableau noir (blackboard). Raffinement structuré de la mémoire partagée : un espace commun organisé (sections, statuts) où chaque agent dépose ses contributions et se déclenche quand une information qui le concerne apparaît.

Idéal quand l’ordre des contributions n’est pas connu d’avance ; chacun contribue quand il peut.
❌ Plus complexe à mettre en place (qui se déclenche quand ?).
Analogie : le tableau blanc de salle de crise — chacun vient y écrire ce qu’il sait, et réagit à ce que les autres y ont écrit. NewsRoom : un tableau avec les sections « sources », « brouillon », « objections », « statut publication » ; le Vérificateur se réveille dès qu’un brouillon apparaît.

À dire pour synthétiser : « Messages = les e-mails de l’entreprise. Mémoire partagée = le dossier réseau commun. Tableau noir = le tableau blanc de la salle de crise. Les trois existent dans vos organisations humaines — c’est exactement pareil pour les agents. »

Transition vers MCP (1 min, importante) : « Nous savons faire parler les agents entre eux. Reste un problème : chaque agent doit aussi parler à ses outils — la base de données, la recherche web, GitHub, Slack. Et là, historiquement, c’est le chaos. Voyons pourquoi, et voyons le standard qui y met fin. »

Séquence E — MCP : le standard universel (20 min) ⭐ cœur de la seconde heure

Objectif : architecture Hôte ↔ Client ↔ Serveur comprise et les 3 primitives distinguées.

1. Le problème N×M (4 min). Au tableau : à gauche, 3 modèles/applications (Claude, GPT, votre app interne) ; à droite, 4 outils (base de données, recherche web, GitHub, Slack). Tracez toutes les flèches : 3 × 4 = 12 intégrations à coder, maintenir, sécuriser — chacune avec son format, son authentification, ses bugs. Ajoutez un modèle : +4 intégrations. Ajoutez un outil : +3. C’est le problème N×M.

Rappel historique parlant : avant l’USB (Universal Serial Bus, bus série universel), chaque périphérique avait sa prise propriétaire — port souris, port imprimante, port clavier. L’USB a imposé une prise, un protocole : n’importe quel périphérique sur n’importe quel ordinateur. MCP (Model Context Protocol, protocole de contexte de modèle) est l’USB de l’IA : proposé fin 2024 ⚠ par Anthropic, adopté depuis par les principaux acteurs de l’écosystème ⚠. Avec MCP : N + M connecteurs au lieu de N × M.

2. L’architecture Hôte ↔ Client ↔ Serveur (8 min). Le trio à connaître par cœur — projetez le diagramme (slide 20) et ouvrez l’onglet 2 de la webpage :

┌───────────────────────────────┐      ┌──────────────────────┐
│  HÔTE (host)                  │      │ SERVEUR MCP          │
│  = votre application          │      │ = fournit outils,    │
│  (Claude Desktop, IDE,        │      │   ressources, prompts│
│   votre app NewsRoom…)        │      │ (ex. serveur GitHub) │
│   ┌───────────────────┐       │      │                      │
│   │ CLIENT MCP        │◀─────▶│      │                      │
│   │ = connecteur dans │ 1 ↔ 1 │      │                      │
│   │   l'hôte          │       │      │                      │
│   └───────────────────┘       │      └──────────────────────┘
└───────────────────────────────┘

Hôte (host) : l’application où vit le modèle — Claude Desktop, un IDE (Integrated Development Environment, environnement de développement intégré), votre application NewsRoom. C’est lui qui décide quels serveurs brancher et applique les autorisations.
Client (client) : le composant à l’intérieur de l’hôte qui gère la connexion avec un serveur (relation 1↔1 : un client par serveur). L’hôte qui parle à 3 serveurs contient 3 clients.
Serveur (server) : le programme qui expose des capacités — outils, ressources, prompts. Exemple : le serveur MCP « GitHub » expose créer_issue, lire_fichier…

Analogie complète à donner : l’hôte est l’ordinateur, le client est le port USB, le serveur est le périphérique. Autre formulation qui aide : le serveur MCP est un adaptateur posé devant un service existant (GitHub, votre base…) qui traduit ce service dans le langage standard MCP.

Piège n° 1 à désamorcer : « serveur » ne veut PAS dire « grosse machine dans un datacenter ». Un serveur MCP est souvent un petit programme local de quelques centaines de lignes, lancé sur votre propre poste. Le mot désigne un rôle dans le protocole (celui qui fournit), pas une infrastructure.

Piège n° 2 : le serveur MCP ne contient pas de modèle d’IA. Il expose des capacités ; l’intelligence reste côté hôte.

3. Les deux transports (2 min). Comment client et serveur se parlent-ils concrètement ?

stdio (standard input/output, entrée/sortie standard) : le serveur est un processus local lancé par l’hôte, dialogue par les canaux d’entrée/sortie du système. Simple, rapide, tout reste sur la machine. Cas type : serveur filesystem sur votre poste.
HTTP+SSE (HyperText Transfer Protocol + Server-Sent Events, événements envoyés par le serveur) : le serveur est distant, accessible par le réseau ; SSE permet au serveur de pousser des événements vers le client. Cas type : serveur MCP d’entreprise partagé par toutes les équipes. ⚠ Le transport distant évolue (variantes « streamable HTTP ») — retenez l’idée : stdio = local, HTTP = distant.

4. Les trois primitives (6 min). Ce qu’un serveur peut exposer — faites cliquer les trois cartes dans la webpage :

Primitive	Qui décide de l’utiliser ?	C’est quoi	Exemple (serveur GitHub)
Tools (outils)	Le modèle (model-invoked)	Des actions exécutables — le tool calling de la Session 5, standardisé	`créer_issue(titre, corps)`
Resources (ressources)	L’application (app-controlled)	Des données en lecture que l’hôte injecte dans le contexte	le contenu de `README.md`
Prompts (invites)	L’utilisateur (via l’hôte)	Des modèles d’invites prêts à l’emploi, paramétrables	« analyse cette pull request »

Le point qui différencie tout : qui a la main. Tools → le modèle décide d’agir (avec les garde-fous des Sessions 5–6). Resources → l’application décide quoi montrer au modèle (comme le RAG, Session 4 : on donne à lire). Prompts → l’utilisateur choisit un modèle d’invite dans un menu. Trois primitives, trois « déclencheurs » différents.

Boucle complète à dérouler oralement (avec NewsRoom) : le Chercheur (dans l’hôte) veut chercher → l’hôte demande au client la liste des tools du serveur « recherche web » → le modèle choisit recherche_web(requête) → le client transmet l’appel au serveur → le serveur exécute et renvoie le résultat → le résultat revient dans la boucle de l’agent (l’étape « observer » de la Session 6 !). Rien de nouveau dans la boucle — seul le branchement est standardisé.

Séquence F — Écosystème & construire son serveur (10 min)

Objectif : rendre MCP concret et actionnable dès demain.

L’écosystème existant (4 min). Serveurs MCP disponibles sur étagère ⚠ (l’écosystème grandit chaque semaine) : filesystem (lire/écrire des fichiers locaux), bases de données (PostgreSQL, SQLite…), recherche web, GitHub (issues, PR, code), Slack (lire/poster), navigateur, calendriers… Le réflexe à installer : avant de coder une intégration, cherchez s’il existe déjà un serveur MCP.

Construire le sien (5 min). Quand votre logique métier n’existe pas sur étagère (ex. : votre CRM — Customer Relationship Management, gestion de la relation client — interne), vous écrivez un serveur MCP qui l’expose. Squelette conceptuel (pas de code à écrire en séance, montrez le pseudo-code du slide 26) :

serveur = nouveau ServeurMCP("crm-interne")

serveur.tool("chercher_client",
  description: "Recherche un client par nom ou e-mail",
  schéma: { requete: string },
  exécution: (args) => crm.chercher(args.requete))

serveur.resource("crm://clients/actifs",
  description: "Liste des clients actifs",
  lecture: () => crm.listeActifs())

serveur.démarrer(transport: stdio)

Trois messages à marteler :

Chaque tool = exactement la définition d’outil de la Session 5 (nom, description, schéma d’entrée) — vous savez déjà faire.
Écrire le serveur une fois → tous vos hôtes (Claude Desktop, vos agents NewsRoom, l’IDE) en profitent. C’est le gain N+M.
La sécurité ne change pas : moindre privilège, validation humaine pour l’irréversible — le standard ne dispense d’aucun garde-fou.

Boucler la boucle (1 min) : « Première heure : des agents spécialisés qui collaborent. Seconde heure : une prise universelle pour leurs outils. NewsRoom complet, c’est : 4 agents en pipeline supervisé, chacun branché sur ses serveurs MCP. Vous avez maintenant toutes les pièces d’un système multi-agents professionnel. »

4. Questions fréquentes des participants (et réponses)

« Multi-agent, c’est plusieurs modèles différents ? » Non — souvent le même modèle avec des prompts systèmes, outils et garde-fous différents. On peut varier les modèles (économie : petit modèle pour les tâches simples), mais ce n’est pas la définition.

« Pourquoi ne pas tout mettre dans un seul gros prompt ? » Ça marche… jusqu’à un certain point. Instructions contradictoires, contexte saturé, débogage impossible, outils sur-exposés. Le multi-agent est au prompt géant ce que les fonctions sont au script de 3 000 lignes.

« MCP remplace-t-il le tool calling ? » Non, il le standardise. Le tool calling (Session 5) reste le mécanisme ; MCP normalise la façon de découvrir et brancher les outils. Analogie : l’USB n’a pas remplacé les claviers — il a normalisé la prise.

« Un serveur MCP, c’est un service cloud ? » Pas nécessairement — c’est même souvent un petit processus local (transport stdio). « Serveur » désigne le rôle (fournisseur de capacités), pas une infrastructure.

« Quelle différence entre Resource et Tool en lecture seule ? » Le déclencheur. Un tool lire_fichier est invoqué par le modèle quand il le juge utile. Une resource est injectée par l’application (ou choisie par l’utilisateur). Même donnée, contrôle différent — et le contrôle, c’est toute la question en production.

« Le débat multiplie les coûts par deux ou trois — ça vaut le coup ? » Uniquement pour les décisions à fort enjeu où le coût d’une erreur dépasse largement le coût des appels. Pour une synthèse quotidienne : non. Pour valider une analyse réglementaire avant envoi à un régulateur : oui.

« MCP est-il propre à Anthropic ? » Le protocole a été initié par Anthropic (fin 2024 ⚠) mais publié en standard ouvert ; il est adopté au-delà d’Anthropic ⚠. L’intérêt d’un standard est précisément de n’appartenir à personne en pratique.

5. Pièges pédagogiques à éviter

Empiler les 4 patrons sans les contraster. Ce qui reste en tête, c’est le tableau comparatif « qui décide du flux ». Passez-y du temps.
Présenter MCP comme une techno de plus. C’est un standard — la valeur est dans la mutualisation (N+M), pas dans une fonctionnalité. Sans le problème N×M d’abord, MCP paraît gratuit.
Laisser « serveur » évoquer un datacenter. Dites explicitement : « un serveur MCP tient dans un petit script local ». Sinon la moitié de la salle imagine du cloud.
Noyer la salle dans les 3 primitives. L’essentiel : Tools = le modèle décide, Resources = l’app décide, Prompts = l’utilisateur choisit. Le reste est du détail.
Vendre le multi-agent partout. Symétrique de la Session 6 : un agent (voire un prompt) suffit souvent. Un formateur crédible dit quand ne PAS multiplier les agents.
Oublier le pont avec les Sessions 5–6. Chaque nouveauté doit être raccrochée : tool MCP = définition d’outil S5 ; résultat d’outil = « observer » S6. Les participants doivent sentir une continuité, pas un nouveau monde.

6. Exit tickets (5)

À distribuer dans les 5 dernières minutes. Une phrase de réponse suffit.

Pourquoi découper un agent monolithique en plusieurs agents spécialisés ? (un argument suffit) (Attendu, un parmi : prompts systèmes sans contradictions ; outils limités au besoin de chacun / moindre privilège ; garde-fous ciblés ; débogage par agent ; contexte maîtrisé.)
Citez les 4 patrons multi-agents vus aujourd’hui. (Attendu : pipeline (chaîne), orchestrateur/exécutants, débat/consensus, superviseur.)
Que signifie MCP et quel problème résout-il ? (Attendu : Model Context Protocol, protocole de contexte de modèle — un standard universel qui évite de coder N×M intégrations entre modèles et outils : « l’USB de l’IA ».)
Dans l’architecture MCP, qui sont l’Hôte, le Client et le Serveur ? (Attendu : Hôte = l’application où vit le modèle ; Client = le connecteur dans l’hôte, un par serveur ; Serveur = le programme qui expose outils/ressources/prompts.)
Quelle est la différence entre un Tool et une Resource MCP ? (Attendu : le Tool est invoqué par le modèle (action) ; la Resource est contrôlée par l’application (donnée injectée en lecture).)

7. Pont vers la suite

Acquis après cette session : l’architecture d’équipes d’agents (4 patrons + 3 modes de communication) et le standard universel de connexion aux outils (MCP : Hôte/Client/Serveur, Tools/Resources/Prompts, stdio/HTTP+SSE).
Prochaine session (Session 8) : selon le programme — mise en production, évaluation et observabilité des systèmes agentiques. Accroche suggérée : « Vous savez maintenant construire un système multi-agents. La semaine prochaine : comment savoir s’il marche vraiment — mesurer, surveiller, améliorer. D’ici là, un défi : repérez dans votre métier une tâche qui mériterait une équipe d’agents plutôt qu’un seul, et notez quel patron vous choisiriez. On ouvrira la séance avec vos cas. »