English

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

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

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

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 ?

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

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.

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.

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 ?

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

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

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é

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é

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.

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

Slide 15 — ☕ Pause (10 min)

À la reprise : comment les agents se parlent — puis la prise USB de l'IA.

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)

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.

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

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

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

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.

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)

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 »

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é.

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à.

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)

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

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.

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: 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).

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 ».

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. »

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.

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. »

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.

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 ».

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 ? »

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.

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 ».

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.

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.

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. »

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.

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. »

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.

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. »

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.

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.

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.

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 ».

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.

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.

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.

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 ? »

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.

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. »

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.

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.