# Slides — Session 7 : Multi-agents & MCP **Programme :** Applied AI — Niveau Intermédiaire — Instructeur : Yann Isola **Format :** 29 slides. Chaque slide comporte le contenu projeté puis les **notes orateur**. **Palette :** encre `#1A2230`, sarcelle `#0F7A6C`, cuivre `#B4612A`, sarcelle claire `#E9F6F3`, fond `#F4F7F6`. --- ## Slide 1 — Titre # Multi-agents & MCP ### De l'agent solitaire à l'équipe — et la prise universelle qui branche tout **Applied AI — Session 7 — Yann Isola** > **Notes orateur :** Accueil. Teasing : « Session 5 : on a donné des mains au modèle. Session 6 : on l'a mis dans une boucle. Aujourd'hui, deux sauts : on passe de l'employé à l'entreprise, et on invente la prise USB de l'IA. » Annoncer les deux moitiés de session : multi-agents (1re heure), MCP (2e heure). --- ## Slide 2 — Rappel express : Session 6 - Un agent = un modèle **dans une boucle** : percevoir → réfléchir → agir → observer - Les outils sont ses **mains** ; il **décide lui-même** quand la tâche est finie - Garde-fous obligatoires : itérations max, budget, validation humaine - Règle d'or : si un prompt suffit, **pas d'agent** > **Notes orateur :** 2 minutes max. Faites réciter la boucle par un participant. La règle d'or de la ligne 4 reviendra en version multi-agent : « si un agent suffit, pas d'équipe ». --- ## Slide 3 — Objectifs de la session À la fin de ces 2 heures, vous saurez : 1. Justifier le découpage en agents **spécialisés** (séparation des responsabilités) 2. Reconnaître et choisir parmi **4 patrons** : pipeline, orchestrateur, débat, superviseur 3. Citer les **3 modes de communication** entre agents 4. Expliquer **MCP** (Model Context Protocol, protocole de contexte de modèle) : Hôte ↔ Client ↔ Serveur 5. Distinguer les 3 primitives : **Tools, Resources, Prompts** > **Notes orateur :** Contrat clair. Rassurez : « Aucun code à écrire aujourd'hui — mais à la fin, vous saurez dessiner l'architecture complète d'un système multi-agents professionnel, MCP compris. » --- ## Slide 4 — L'expérience de pensée : NewsRoom en UN agent **Mission :** « Chaque matin : synthèse de 500 mots sur les stablecoins — sourcée, vérifiée, relue, publiée. » Version monolithique : **un** prompt système géant + **tous** les outils. ❓ Qu'est-ce qui va mal se passer ? > **Notes orateur :** Fil rouge de la session : NewsRoom 📰. Laissez la salle chercher 2 minutes avant de projeter le slide suivant. Notez leurs réponses au tableau — la plupart des 4 problèmes vont émerger tout seuls. --- ## Slide 5 — Les 4 maladies de l'agent monolithique 1. 🧶 **Prompt-monstre** : « sois exhaustif » (recherche) vs « sois concis » (rédaction) → contradictions 2. 🔓 **Outils sur-exposés** : l'étape rédaction a accès à l'outil de *publication* — risque inutile 3. 🕵️ **Indébogable** : synthèse mauvaise… recherche, rédaction ou vérification fautive ? Mystère 4. 🌊 **Contexte noyé** : recherches + brouillons + relectures dans une seule fenêtre > **Notes orateur :** Reliez chaque point aux sessions passées : point 2 = violation du moindre privilège (S5) ; point 4 = la mémoire de travail (S6) qui déborde. Punchline : « Ça marche… jusqu'au jour où ça ne marche plus, et ce jour-là, vous ne saurez pas pourquoi. » --- ## Slide 6 — La réponse : la séparation des responsabilités Chaque agent spécialisé a : | | | |---|---| | 🎯 **Son prompt système** | une mission unique, sans contradictions | | 🧰 **Ses outils** | uniquement les siens (moindre privilège) | | 🚧 **Ses garde-fous** | ciblés sur *ses* risques | **Analogie : l'entreprise.** Comptable ≠ commercial ≠ juriste. Chacun son rôle, chacun ses clés. > **Notes orateur :** LE slide conceptuel de la 1re heure. L'analogie de l'entreprise portera toute la session : « on n'embauche pas UNE personne pour tout faire — pas parce que c'est impossible, parce que c'est fragile ». La comptable a la clé du coffre, pas le stagiaire. --- ## Slide 7 — L'équipe NewsRoom 📰 - 🔍 **Chercheur** — outils : recherche web, lecture d'articles — « Trouve des sources fiables, cite tout » - ✍️ **Rédacteur** — aucun outil — « Rédige clair, 500 mots » - 🕵️ **Vérificateur** — outil : recherche web — « Traque les erreurs, sois impitoyable » - 📣 **Publieur** — outil : publication (**irréversible** → validation humaine) ⚠️ Souvent **le même modèle** pour les 4 ! Multi-agent ≠ multi-modèle. > **Notes orateur :** Piège n° 1 de la session à désamorcer immédiatement : les 4 agents peuvent tourner sur le même Claude/GPT. Ce qui diffère : prompt, outils, garde-fous. L'agentivité était une propriété du système (S6) ; la spécialisation aussi. Notez que le Rédacteur n'a AUCUN outil : un agent peut être « nu ». --- ## Slide 8 — Patron 1 : le pipeline (la chaîne) ``` 🔍 Chercheur → ✍️ Rédacteur → 🕵️ Vérificateur → 📣 Publieur ``` - Chaque agent transforme la sortie du précédent - Flux **linéaire, fixé d'avance par le développeur** - ✅ Simple, prévisible, débogable (livrables intermédiaires inspectables) - ❌ Rigide : et si le Vérificateur rejette ? > **Notes orateur :** « La chaîne de montage. » Cas d'usage : traitement de documents, génération de contenu, ETL (Extract-Transform-Load, extraction-transformation-chargement) intelligent. Posez la question du rejet : il faut un retour en arrière vers le Rédacteur — et déjà le pipeline pur craque. Transition : « et si les étapes n'étaient pas connues d'avance ? » --- ## Slide 9 — Patron 2 : orchestrateur / exécutants ``` ┌────────────────┐ │ ORCHESTRATEUR │ décompose · délègue · assemble └──┬─────┬────┬──┘ ▼ ▼ ▼ 🔍 ✍️ 🕵️ (les exécutants ne se parlent pas entre eux) ``` - La décomposition est **décidée à l'exécution**, par un agent - ✅ Flexible, parallélisable - ❌ Goulot d'étranglement + point de défaillance unique > **Notes orateur :** « Le chef de projet. » LA distinction avec le pipeline (question de quiz !) : pipeline = chemin fixé par le développeur ; orchestrateur = chemin décidé par le modèle à l'exécution. Cas d'usage : « dossier complet sur l'entreprise X » — la décomposition dépend du cas. Insistez : tout passe par le chef, donc s'il décompose mal, tout rate. --- ## Slide 10 — Patron 3 : débat / consensus ``` ✍️ Rédacteur A ──┐ ├──▶ ⚖️ JUGE ──▶ meilleure version / synthèse ✍️ Rédacteur B ──┘ ``` - Réponses **indépendantes** → un juge tranche (ou un vote) - ✅ Fiabilité par recoupement : deux agents hallucinent rarement *pareil* - ✅ Les **divergences** = de l'information (→ remonter à l'humain) - ❌ Coût × nombre de débatteurs > **Notes orateur :** Cas d'usage pour ce public : validation d'une analyse réglementaire avant envoi au régulateur. Les convergences donnent confiance, les divergences déclenchent la revue humaine — c'est un détecteur d'incertitude. À réserver aux décisions qui méritent le surcoût : « pas pour la synthèse du matin, oui pour l'avis au régulateur ». --- ## Slide 11 — Patron 4 : le superviseur ``` ┌──────────────┐ │ SUPERVISEUR │ observe · valide · interrompt · réassigne └──────┬───────┘ surveille ┌───────────┼───────────┐ ▼ ▼ ▼ Agent 1 Agent 2 Agent 3 ``` **Orchestrateur** = distribue le travail · **Superviseur** = contrôle qualité & sécurité > **Notes orateur :** La confusion orchestrateur/superviseur est LE piège du quiz. Formule à répéter : « le chef de projet vs le contrôle qualité + responsable conformité ». Les deux se combinent souvent — surtout en finance, santé, juridique. Le superviseur détecte : boucles infinies, hors-sujet, violations de règles. --- ## Slide 12 — Les 4 patrons en un tableau | Patron | Qui décide du flux ? | Force | Faiblesse | |---|---|---|---| | **Pipeline** | Le développeur (fixe) | Simple, débogable | Rigide | | **Orchestrateur** | L'orchestrateur (dynamique) | Flexible, parallèle | Goulot central | | **Débat** | Le juge / le vote | Fiabilité ×recoupement | Coût ×N | | **Superviseur** | Agents + contrôle continu | Sécurité, conformité | Complexité | > **Notes orateur :** Slide à photographier. La colonne « qui décide du flux ? » est la clé de lecture. Précisez que les patrons se COMBINENT : pipeline + superviseur, orchestrateur + débat sur une étape critique, etc. Ce sont des briques, pas des cases exclusives. --- ## Slide 13 — Et la règle d'or, version équipe > ### « Si un agent suffit, n'en mettez pas quatre. » Le multi-agent coûte : appels ×N, latence, coordination, points de défaillance. On le choisit pour la **robustesse** et la **maîtrise** — jamais par mode. > **Notes orateur :** Symétrique exact de la règle de la Session 6 (« si un prompt suffit, pas d'agent »). Un formateur crédible dit quand ne PAS utiliser sa techno. Exemple : « reformule cet e-mail » → un prompt. Point. Transition : « Passons à la manipulation. » --- ## Slide 14 — À vous de jouer : le visualiseur d'architectures **Webpage, onglet 1 — 15 minutes en binômes** 1. Choisissez un patron (pipeline / orchestrateur / débat) 2. **Glissez les agents** NewsRoom dans les emplacements 3. Lancez l'**animation des messages** et lisez le journal 4. Bouton « 💥 Injecter une erreur » : observez le retour en arrière ❓ À comparer : le **nombre de messages** échangés en pipeline vs orchestrateur > **Notes orateur :** Séquence C du guide. Circulez dans la salle. Question de débrief : « qui décide du chemin dans chaque patron ? » La bonne verbalisation : pipeline = fixé d'avance, orchestrateur = décidé par un agent. Si pas assez de portables : vous pilotez au vidéoprojecteur, la salle guide. --- ## Slide 15 — ☕ Pause (10 min) **À la reprise :** comment les agents se parlent — puis la prise USB de l'IA. > **Notes orateur :** Lancez le teaser avant la pause : « Question à méditer au café : vos 4 agents doivent partager leurs résultats. Comme dans une entreprise, il y a l'e-mail, le dossier réseau, et le tableau blanc de réunion. Devinez : c'est pareil pour les agents. » --- ## Slide 16 — Communication entre agents : 3 mécanismes | Mécanisme | Analogie entreprise | ✅ | ❌ | |---|---|---|---| | **Passage de messages** | Les e-mails internes | Traçable, découplé | Définir qui parle à qui | | **Mémoire partagée** | Le dossier réseau commun | Simple, tout le monde voit tout | Contexte qui gonfle, interférences | | **Tableau noir** (blackboard) | Le tableau blanc de salle de crise | Chacun contribue quand il peut | Plus complexe (déclenchements) | > **Notes orateur :** L'analogie entreprise fait tout le travail. Le tableau noir : espace commun STRUCTURÉ (sections, statuts) où un agent « se réveille » quand une info qui le concerne apparaît — NewsRoom : le Vérificateur se déclenche dès qu'un brouillon est posé. Messages = mécanisme naturel du pipeline et de l'orchestrateur. --- ## Slide 17 — Nouveau problème : brancher les outils Vos agents parlent entre eux ✅ … mais chacun doit aussi parler à **ses outils** : base de données · recherche web · GitHub · Slack · fichiers · CRM interne… Et là, historiquement : **le chaos.** > **Notes orateur :** Pivot de la session — soignez la transition. « Première heure : les agents entre eux. Mais le Chercheur doit parler à la recherche web, le Publieur à Slack… Chaque branchement était du code sur mesure. Voyons l'ampleur du problème. » --- ## Slide 18 — Le problème N × M ``` 3 applications 4 outils ┌──────────┐ ┌──────────────┐ │ Claude │──┬──┬──┬──│ Base de │ │ GPT │──┼──┼──┼──│ données │ │ Votre app│──┼──┼──┼──│ Recherche web │ └──────────┘ └──┴──┴──│ GitHub │ │ Slack │ └──────────────┘ 3 × 4 = 12 intégrations sur mesure 😱 ``` +1 application → +4 intégrations · +1 outil → +3 intégrations > **Notes orateur :** Dessinez les 12 flèches au tableau si possible — l'effet visuel du plat de spaghettis vaut mille mots. Chaque flèche = code, authentification, maintenance, bugs, refaits à chaque fois. Question à la salle : « Ça vous rappelle un problème déjà résolu dans l'informatique ? » → slide suivant. --- ## Slide 19 — La solution existe déjà : l'USB **Avant l'USB** (Universal Serial Bus, bus série universel) : port souris, port imprimante, port clavier — une prise par périphérique. **Après :** UNE prise, UN protocole → n'importe quel périphérique sur n'importe quel ordinateur. > ### MCP = Model Context Protocol = **l'USB de l'IA** > Proposé fin 2024 ⚠ par Anthropic · standard **ouvert** · adopté largement dans l'écosystème ⚠ **N × M intégrations → N + M connecteurs** > **Notes orateur :** L'analogie officielle — et elle est juste. Expliquez l'acronyme (règle du cours) : Model Context Protocol, protocole de contexte de modèle. Insistez sur « standard ouvert » : initié par Anthropic mais n'appartenant à personne en pratique — c'est la condition pour qu'un standard fonctionne. Les ⚠ : dates et adoption évoluent vite, vérifiez avant chaque session. --- ## Slide 20 — L'architecture MCP : le trio Hôte · Client · Serveur ``` ┌───────────────────────────────┐ ┌────────────────────────┐ │ HÔTE = votre application │ │ SERVEUR MCP │ │ (Claude Desktop, IDE, │ │ = expose des capacités│ │ votre app NewsRoom…) │ │ · Tools │ │ ┌───────────────────┐ │ │ · Resources │ │ │ CLIENT MCP │◀──────┼───────▶│ · Prompts │ │ │ 1 client ↔ 1 serveur │ │ (ex. serveur GitHub) │ │ └───────────────────┘ │ └────────────────────────┘ └───────────────────────────────┘ ``` **Hôte** = l'ordinateur · **Client** = le port USB · **Serveur** = le périphérique > **Notes orateur :** LE slide à connaître par cœur — c'est la question 8 du quiz. Déroulez : l'hôte héberge le modèle et décide quels serveurs brancher ; le client gère UNE connexion (3 serveurs = 3 clients dans l'hôte) ; le serveur expose les capacités. Ouvrez l'onglet 2 de la webpage en parallèle : le diagramme y est cliquable. --- ## Slide 21 — Deux pièges sur le mot « serveur » 1. ❌ « Serveur = grosse machine dans un datacenter » ✅ Souvent un **petit programme local** de quelques centaines de lignes, lancé sur votre poste. « Serveur » = un **rôle** (celui qui fournit), pas une infrastructure. 2. ❌ « Le serveur MCP contient une IA » ✅ Le serveur expose des capacités. **L'intelligence reste côté hôte.** > **Notes orateur :** Désamorcez frontalement : la moitié de la salle imagine du cloud dès qu'elle entend « serveur ». Reformulation utile : « un serveur MCP est un ADAPTATEUR posé devant un service existant, qui le traduit en langage standard MCP ». --- ## Slide 22 — Les deux transports | Transport | Où ? | Comment ? | Cas type | |---|---|---|---| | **stdio** (standard input/output, entrée/sortie standard) | **Local** | Processus lancé par l'hôte, dialogue par l'entrée/sortie | Serveur filesystem sur votre poste | | **HTTP+SSE** (HyperText Transfer Protocol + Server-Sent Events, événements envoyés par le serveur) | **Distant** | Réseau ; le serveur peut pousser des événements | Serveur MCP d'entreprise partagé | Mnémo : **stdio = local · HTTP = distant** ⚠ (le transport distant évolue — retenir l'idée) > **Notes orateur :** Ne pas s'éterniser : la règle mnémotechnique suffit à ce niveau. Le ⚠ : la spécification du transport distant a des variantes (« streamable HTTP ») — l'idée stdio/local vs HTTP/distant reste stable. --- ## Slide 23 — Les 3 primitives : qui a la main ? | Primitive | Qui décide ? | Quoi | Exemple (serveur GitHub) | |---|---|---|---| | **Tools** 🔧 | **Le modèle** | Actions exécutables (= tool calling S5, standardisé) | `créer_issue(titre, corps)` | | **Resources** 📚 | **L'application** | Données en lecture injectées dans le contexte | contenu de `README.md` | | **Prompts** 📋 | **L'utilisateur** | Modèles d'invites prêts à l'emploi | « analyse cette pull request » | > **Notes orateur :** LA colonne qui compte : « qui décide ». Tool → le modèle agit (avec les garde-fous S5–S6). Resource → l'app choisit quoi montrer (esprit RAG, S4). Prompt → l'utilisateur pioche dans un menu. Question piège à poser : « un tool `lire_fichier` et une resource fichier, quelle différence ? » → le déclencheur. Même donnée, contrôle différent — et en production, le contrôle est toute la question. --- ## Slide 24 — La boucle complète, avec MCP 1. Le Chercheur (hôte) a besoin de chercher 2. L'hôte → client : « liste des tools du serveur recherche web ? » 3. Le modèle choisit `recherche_web(requête)` 4. Client → serveur : exécute l'appel 5. Le serveur renvoie le résultat 6. Le résultat entre dans la boucle : c'est l'étape **« observer »** de la Session 6 ! > ### Rien de nouveau dans la boucle — seul le **branchement** est standardisé. > **Notes orateur :** Le slide qui raccroche tout. Insistez sur la continuité : MCP ne remplace pas le tool calling, il le STANDARDISE (analogie : l'USB n'a pas remplacé les claviers, il a normalisé la prise). Les participants doivent repartir en sentant qu'ils connaissaient déjà 80 % de MCP sans le savoir. --- ## Slide 25 — L'écosystème : servez-vous ⚠ Serveurs MCP disponibles sur étagère (liste qui grandit chaque semaine ⚠) : 📁 **filesystem** · 🗄️ **bases de données** (PostgreSQL, SQLite…) · 🔍 **recherche web** 🐙 **GitHub** · 💬 **Slack** · 🌐 navigateur · 📅 calendriers… > ### Réflexe : avant de coder une intégration, cherchez si le serveur MCP existe déjà. > **Notes orateur :** Message d'économie pure : des semaines de développement évitées. ⚠ sur toute la liste : l'écosystème bouge vite, montrez éventuellement un annuaire à jour si vous avez du réseau (sinon, la webpage contient un catalogue statique). Transition : « et quand votre logique métier n'existe pas sur étagère ? » --- ## Slide 26 — Construire SON serveur MCP (pseudo-code) ``` 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) ``` > **Notes orateur :** Trois messages : (1) chaque `tool` = exactement la définition d'outil de la S5 — nom, description, schéma : « vous savez déjà faire » ; (2) écrit UNE fois → tous vos hôtes en profitent (le gain N+M) ; (3) la sécurité ne change pas — moindre privilège, validation humaine pour l'irréversible. Personne ne doit recopier le code : c'est du pseudo-code conceptuel. --- ## Slide 27 — NewsRoom, version finale 🏗️ ``` ┌─ SUPERVISEUR (conformité) ─┐ ▼ ▼ ▼ 🔍 Chercheur → ✍️ Rédacteur → 🕵️ Vérificateur → 📣 Publieur │ │ │ [MCP: recherche web] [MCP: recherche] [MCP: Slack] + validation humaine ✋ ``` **4 agents spécialisés · pipeline supervisé · outils branchés en MCP · garde-fou humain avant publication** > **Notes orateur :** La photo finale qui assemble TOUTE la session (et les sessions 5–6). Faites-la commenter par un participant : patron ? communication ? primitives MCP utilisées ? garde-fous ? S'il sait tout expliquer, la session est gagnée. « Vous avez désormais toutes les pièces d'un système multi-agents professionnel. » --- ## Slide 28 — Ce qu'il faut retenir 1. **Multi-agent = séparation des responsabilités** : chacun son prompt, ses outils, ses garde-fous 2. **4 patrons** : pipeline (fixe) · orchestrateur (dynamique) · débat (recoupement) · superviseur (contrôle) 3. **3 communications** : messages · mémoire partagée · tableau noir 4. **MCP** = l'USB de l'IA : Hôte ↔ Client ↔ Serveur, N+M au lieu de N×M 5. **3 primitives** : Tools (le modèle) · Resources (l'app) · Prompts (l'utilisateur) 6. **Si un agent suffit, n'en mettez pas quatre.** > **Notes orateur :** Lecture rapide, puis quiz express à l'oral (5 questions du fichier quiz) et distribution des exit tickets. Le point 6 en dernier, volontairement : c'est le discernement qui distingue un professionnel d'un suiveur de mode. --- ## Slide 29 — La semaine prochaine # Session 8 ### Vous savez construire. Sait-on si ça marche *vraiment* ? Évaluation · observabilité · mise en production **Défi de la semaine :** repérez dans votre métier une tâche qui mériterait une *équipe* d'agents. Quel patron ? Quels serveurs MCP ? On ouvre la séance avec vos cas. > **Notes orateur :** Le défi hebdomadaire crée la continuité et fournit des cas réels pour la prochaine ouverture de séance. Remerciez, restez 5 minutes pour les questions individuelles — c'est souvent là que sortent les vrais cas d'usage d'entreprise.