# 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 : 1. **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. 2. **Nommer et reconnaître les 4 patrons multi-agents** : orchestrateur/exécutants (orchestrator/worker), pipeline (chaîne), débat/consensus, superviseur. 3. **Choisir le bon patron** pour un cas métier donné, et justifier ce choix en une phrase. 4. **Décrire les 3 modes de communication entre agents** : mémoire partagée, passage de messages, architecture en tableau noir (blackboard). 5. **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. 6. **Dessiner l'architecture MCP** : Hôte (votre application) ↔ Client (à l'intérieur de l'hôte) ↔ Serveur (qui fournit outils et ressources). 7. **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). 8. **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). 9. **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. 10. **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… 1. **Son prompt système** — une mission unique, claire, sans contradictions. 2. **Ses outils** — uniquement ceux dont il a besoin (rappel Session 5 : principe du moindre privilège). 3. **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) : 1. **Choisissent un patron** (pipeline, orchestrateur, débat) — le plateau affiche les emplacements du patron. 2. **Glissent les agents** de NewsRoom (Chercheur, Rédacteur, Vérificateur, Publieur, Juge, Orchestrateur) dans les emplacements. 3. **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… »). 4. 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 : 1. Chaque `tool` = exactement la définition d'outil de la Session 5 (nom, description, schéma d'entrée) — **vous savez déjà faire**. 2. Écrire le serveur **une fois** → tous vos hôtes (Claude Desktop, vos agents NewsRoom, l'IDE) en profitent. C'est le gain N+M. 3. 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 1. **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. 2. **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. 3. **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. 4. **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. 5. **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. 6. **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. 1. **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é.)* 2. **Citez les 4 patrons multi-agents vus aujourd'hui.** *(Attendu : pipeline (chaîne), orchestrateur/exécutants, débat/consensus, superviseur.)* 3. **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 ».)* 4. **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.)* 5. **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. »