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

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

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.