# Exercices — Session 7 : Multi-agents & MCP

**Programme :** Applied AI — Niveau Intermédiaire · Instructeur : Yann Isola
**Consigne générale :** travaillez en binômes. Aucun code à écrire — on raisonne comme un architecte de systèmes d'agents. Les corrigés sont en fin de document : ne les lisez qu'après avoir vraiment essayé.

---

## Exercice 1 — Choisir le bon patron (≈ 15 min)

*Objectif : savoir associer un besoin métier au patron multi-agents adapté, et justifier.*

Pour **chacun** des cinq besoins suivants, choisissez le patron le plus adapté parmi :
**A. Agent unique** (pas de multi-agent — rappel Session 6) · **B. Pipeline (chaîne)** · **C. Orchestrateur/exécutants** · **D. Débat/consensus** · **E. Superviseur** (en combinaison avec un autre patron si besoin).

Justifiez chaque choix en une ou deux phrases. Plusieurs réponses défendables existent : ce qui compte, c'est la justification.

1. **Traitement de factures fournisseurs :** extraire les champs du PDF (Portable Document Format, format de document portable) → normaliser les montants et devises → vérifier la cohérence avec le bon de commande → enregistrer en comptabilité. Les 4 étapes sont toujours les mêmes, toujours dans cet ordre.

2. **Analyse de risque avant publication d'un avis réglementaire :** l'erreur coûterait très cher (réputation, régulateur). On veut réduire au maximum le risque d'hallucination ou d'oubli.

3. **« Prépare-moi un dossier complet sur l'entreprise X avant mon rendez-vous de jeudi »** : selon l'entreprise, il faudra creuser la presse, les données financières, les réseaux sociaux, le registre du commerce… La décomposition exacte n'est pas connue d'avance.

4. **« Reformule cet e-mail sur un ton plus diplomatique. »**

5. **Un système d'agents de trading assisté** (préparation d'ordres, jamais d'exécution autonome) opérant dans un cadre de conformité strict : chaque sortie doit être contrôlée, toute dérive détectée et stoppée immédiatement.

**Question bonus :** pour le cas 1, que faut-il prévoir si l'étape « vérifier la cohérence » détecte une incohérence ? En quoi cela « tord »-il le patron choisi ?

---

## Exercice 2 — Architecte MCP (≈ 20 min)

*Objectif : appliquer l'architecture MCP (Model Context Protocol, protocole de contexte de modèle) à un cas d'entreprise réel.*

**Contexte.** Vous êtes dans une société de courtage. Trois applications internes utilisent l'IA (intelligence artificielle) :

- **AssistDesk** — assistant du service client (application de bureau des téléconseillers)
- **RiskWatch** — agent de surveillance des risques (tourne sur un serveur d'équipe)
- **DevCopilot** — l'IDE (Integrated Development Environment, environnement de développement intégré) augmenté des développeurs

Ces applications ont besoin d'accéder à quatre systèmes :

- La **base clients** (CRM — Customer Relationship Management, gestion de la relation client)
- Le **référentiel de conformité** (documents réglementaires internes, lecture seule)
- **GitHub** (code source, issues)
- La **messagerie d'équipe** (poster des alertes)

**Questions :**

1. **Sans MCP :** combien d'intégrations sur mesure faudrait-il coder si chaque application se connecte directement à chaque système dont elle a besoin ? Détaillez qui a besoin de quoi (choix raisonnable à justifier) puis comptez. Puis donnez le nombre maximal théorique (toutes les applications × tous les systèmes).

2. **Avec MCP :** combien de serveurs MCP faut-il écrire ou installer ? Lesquels existent probablement déjà sur étagère ⚠, lesquels faudra-t-il développer en interne ?

3. Pour chaque serveur MCP, dites quel **transport** vous choisiriez — stdio (standard input/output, entrée/sortie standard, local) ou HTTP+SSE (HyperText Transfer Protocol + Server-Sent Events, distant) — et pourquoi. Indice : où tourne chaque application, et le serveur doit-il être partagé ?

4. Classez chacun des éléments suivants dans la bonne **primitive MCP** — Tool (outil, invoqué par le modèle), Resource (ressource, contrôlée par l'application) ou Prompt (modèle d'invite, choisi par l'utilisateur) :
   a. `chercher_client(nom_ou_email)` dans le CRM
   b. Le texte intégral de la procédure interne « traitement des réclamations »
   c. Un modèle pré-rédigé « Analyse cette réclamation client selon notre grille conformité », que le téléconseiller sélectionne dans un menu
   d. `poster_alerte(canal, message)` dans la messagerie
   e. La liste des issues GitHub ouvertes, injectée automatiquement dans le contexte de DevCopilot à l'ouverture d'un projet

5. **Sécurité :** l'outil `poster_alerte` publie sur un canal lu par 200 personnes. Quel garde-fou (Sessions 5–6) appliquez-vous, et où le placez-vous — dans le serveur MCP ou dans l'hôte ? Argumentez.

---

## Exercice 3 — Concevoir l'équipe d'agents (≈ 20 min)

*Objectif : concevoir un système multi-agents complet — agents, patron, communication, branchement MCP.*

**Mission à automatiser.** Le service juridique reçoit chaque semaine des dizaines de contrats fournisseurs à examiner. Le processus humain actuel :

1. Lire le contrat et en extraire les clauses clés (durée, résiliation, responsabilité, pénalités).
2. Comparer chaque clause à la politique contractuelle interne de l'entreprise.
3. Rédiger une note de synthèse : clauses conformes ✅, clauses à négocier ⚠, clauses bloquantes ⛔.
4. Si au moins une clause est bloquante : alerter immédiatement le juriste référent par messagerie.
5. Archiver la note dans la GED (Gestion Électronique de Documents).

**Questions :**

1. **Découpage :** proposez une équipe de 3 à 5 agents spécialisés. Pour chacun : un nom, sa mission en une phrase (l'essence de son prompt système), et la liste de ses outils. Respectez le moindre privilège : aucun agent ne doit avoir un outil dont il n'a pas besoin.

2. **Patron :** quel patron multi-agents choisissez-vous ? Dessinez le flux (flèches entre agents). Justifiez face à au moins une alternative que vous rejetez.

3. **Communication :** messages, mémoire partagée ou tableau noir ? Justifiez en une phrase.

4. **Branchement MCP :** listez les serveurs MCP nécessaires (étagère ou maison) et dites quel agent se branche sur lequel.

5. **Garde-fous :** identifiez la ou les actions sensibles du système et placez le ou les points de contrôle humain (human-in-the-loop, humain dans la boucle). L'alerte au juriste (étape 4) doit-elle être soumise à validation humaine ? Défendez votre position — il y a un vrai débat.

6. **Question critique :** un collègue vous dit « tout ça tiendrait dans UN seul agent avec un bon prompt ». Donnez deux arguments pour lui répondre… puis un cas de figure où il aurait raison.

---
---

# Corrigés

## Corrigé — Exercice 1

**1. Factures fournisseurs → B. Pipeline.** Les étapes sont connues d'avance, fixes, ordonnées : extraction → normalisation → vérification → enregistrement. C'est la chaîne de montage type. Un orchestrateur serait de la sur-ingénierie : il n'y a aucune décomposition à décider dynamiquement.

**2. Avis réglementaire à fort enjeu → D. Débat/consensus.** Deux (ou trois) agents analysent **indépendamment** ; un juge compare. Les convergences renforcent la confiance ; les divergences remontent à un humain — c'est précisément de l'information sur le risque. Le surcoût (appels ×2 ou ×3) est négligeable devant le coût d'une erreur face au régulateur. *(Réponse E acceptée en complément : un superviseur peut s'ajouter au débat.)*

**3. Dossier entreprise X → C. Orchestrateur/exécutants.** La décomposition dépend de l'entreprise (cotée ou non, présence médiatique, etc.) : elle n'est pas connue d'avance, c'est l'orchestrateur qui la décide à l'exécution, puis délègue en parallèle (presse, finance, registre…) et assemble. Un pipeline fixe serait tantôt trop, tantôt pas assez.

**4. Reformulation d'e-mail → A. Agent unique** — et même, en toute rigueur, un **simple prompt** sans outil (rappel Session 6 : ne pas sur-ingénierer). Toute architecture multi-agents ici est du gaspillage : coût, latence, complexité sans bénéfice.

**5. Trading assisté sous conformité stricte → E. Superviseur** (combiné, typiquement, à un pipeline ou un orchestrateur pour le travail lui-même). Le besoin dominant est le **contrôle continu** : vérifier chaque sortie, détecter les dérives, interrompre. À distinguer de l'orchestrateur : celui-ci *distribue le travail*, le superviseur *contrôle qualité et sécurité*. Dans la finance, les deux se combinent presque toujours.

**Bonus (cas 1).** Il faut un **retour en arrière** : la vérification échoue → renvoi à l'étape d'extraction ou mise en file « traitement humain ». Le pipeline pur est strictement linéaire ; dès qu'on ajoute des boucles de retour, on le « tord » — soit on accepte un pipeline avec rebouclage explicite, soit on bascule vers un orchestrateur qui décide des reprises. Leçon : le patron est un point de départ, pas un dogme.

---

## Corrigé — Exercice 2

**1. Sans MCP.** Attribution raisonnable des besoins :

| Application | CRM | Conformité | GitHub | Messagerie |
|---|---|---|---|---|
| AssistDesk | ✅ | ✅ | — | ✅ (alertes internes) |
| RiskWatch | ✅ | ✅ | — | ✅ |
| DevCopilot | — | — | ✅ | ✅ (notifications d'équipe) |

Soit **8 intégrations** sur mesure avec cette attribution (toute attribution justifiée est acceptée, généralement 7 à 9). **Maximum théorique : 3 × 4 = 12.** Chaque intégration = du code, de l'authentification, de la maintenance, des bugs — et chaque nouvelle application repart de zéro. C'est le problème N×M.

**2. Avec MCP : 4 serveurs**, un par système — c'est le gain N+M (3 hôtes + 4 serveurs = 7 connecteurs au lieu de 8–12 intégrations, et l'écart se creuse à chaque ajout).
- **GitHub** : existe sur étagère ⚠ (serveur MCP officiel/communautaire).
- **Messagerie** : existe très probablement sur étagère ⚠ si c'est Slack ou équivalent répandu.
- **CRM interne** : à développer en interne — c'est votre logique métier.
- **Référentiel de conformité** : à développer en interne (ou serveur filesystem/base sur étagère si les documents sont dans un format standard — réponse acceptée si justifiée).

**3. Transports.**
- **CRM** et **Conformité** : **HTTP+SSE** — serveurs partagés par plusieurs applications sur plusieurs machines (AssistDesk sur les postes des téléconseillers, RiskWatch sur un serveur). Un serveur central distant évite d'installer et de mettre à jour N copies locales, et centralise le contrôle d'accès.
- **GitHub** : les deux se défendent — stdio local lancé par l'IDE de chaque développeur (simple, l'authentification reste sur le poste) ou HTTP centralisé. L'important est l'argument.
- **Messagerie** : HTTP+SSE si partagé, stdio acceptable pour un poste isolé.
Règle mnémotechnique attendue : **stdio = local à la machine, HTTP+SSE = partagé/distant.**

**4. Primitives.**
- a. `chercher_client(...)` → **Tool** : action invoquée par le modèle quand il en a besoin.
- b. Texte de la procédure interne → **Resource** : donnée en lecture, injectée sous contrôle de l'application.
- c. Modèle « Analyse cette réclamation… » sélectionné dans un menu → **Prompt** : modèle d'invite choisi par l'utilisateur.
- d. `poster_alerte(...)` → **Tool** : action (et action sensible !).
- e. Liste des issues injectée automatiquement à l'ouverture → **Resource** : c'est l'application qui décide de l'injecter, pas le modèle. *(Piège du lot : « liste d'issues » sonne comme GitHub-outil, mais le déclencheur est applicatif → Resource.)*

**5. Garde-fou `poster_alerte`.** Attendu : **validation humaine avant publication** (human-in-the-loop) — l'action est irréversible et à large audience. Où la placer ? Les deux réponses sont défendables, la meilleure copie les combine :
- **Dans l'hôte** : c'est lui qui connaît l'utilisateur et le contexte, et qui peut afficher « Confirmer l'envoi ? ». C'est la place naturelle de l'expérience de validation.
- **Dans le serveur MCP** (défense en profondeur) : limites codées en dur — canaux autorisés, quota de messages, journalisation. Le serveur ne doit pas faire confiance aveuglément à ses hôtes.
Principe à retenir : **la sécurité se met en couches ; le standard MCP ne dispense d'aucun garde-fou des Sessions 5–6.**

---

## Corrigé — Exercice 3

*(Corrigé type — toute variante bien argumentée est valable.)*

**1. Équipe proposée (4 agents).**

| Agent | Mission (essence du prompt système) | Outils |
|---|---|---|
| 📄 **Extracteur** | « Lis le contrat, extrais les clauses clés (durée, résiliation, responsabilité, pénalités) en format structuré. N'interprète pas, extrais. » | lecture de documents (GED) |
| ⚖️ **Comparateur** | « Compare chaque clause extraite à la politique contractuelle interne. Classe : conforme ✅ / à négocier ⚠ / bloquante ⛔. Cite la règle interne à chaque fois. » | lecture du référentiel de politique interne |
| ✍️ **Rédacteur** | « Rédige la note de synthèse à partir de la comparaison : claire, structurée, à destination d'un juriste. » | aucun outil externe |
| 📣 **Notifieur-Archiveur** | « Archive la note dans la GED ; si au moins une clause ⛔, alerte le juriste référent. » | écriture GED, messagerie |

Moindre privilège respecté : l'Extracteur ne peut pas poster de message ; le Rédacteur n'a aucun outil ; seul le dernier agent touche à la messagerie et à l'écriture.

**2. Patron : pipeline** Extracteur → Comparateur → Rédacteur → Notifieur-Archiveur, **avec superviseur** en option (contexte juridique = contrôle bienvenu). Justification : les étapes sont fixes et ordonnées, connues d'avance — exactement le cas d'école du pipeline. Alternative rejetée : l'orchestrateur — inutile, il n'y a aucune décomposition dynamique à décider ; il ajouterait un point de défaillance central sans bénéfice. *(Un débat/consensus sur le Comparateur est un raffinement défendable pour les contrats à fort enjeu.)*

**3. Communication : passage de messages.** Le flux est linéaire, chaque agent passe un livrable structuré au suivant — traçable, journalisable (précieux en contexte juridique : qui a produit quoi). Mémoire partagée ou tableau noir : sur-dimensionnés pour un flux aussi séquentiel.

**4. Serveurs MCP.**
- **GED** : serveur maison (ou serveur filesystem sur étagère ⚠ si la GED expose un système de fichiers) — branché sur l'Extracteur (lecture) et le Notifieur-Archiveur (écriture). Bonne pratique : deux niveaux d'accès distincts (lecture seule pour l'Extracteur).
- **Politique interne** : serveur maison ou base documentaire sur étagère ⚠ — branché sur le Comparateur ; ses documents sont un candidat idéal au format **Resource** (lecture contrôlée) plutôt que Tool.
- **Messagerie** : serveur sur étagère ⚠ — branché uniquement sur le Notifieur-Archiveur.

**5. Garde-fous.** Actions sensibles : **écriture en GED** (pollution de l'archivage) et **alerte au juriste** (dérangement, crédibilité du système). Le débat attendu sur l'alerte :
- *Pour la validation humaine* : une fausse alerte ⛔ répétée détruit la confiance (effet « garçon qui criait au loup ») ; le classement ⛔ vient d'un modèle qui peut se tromper.
- *Contre* : l'alerte n'est pas destructrice, elle est corrigible (« fausse alerte, ignorez ») — et exiger une validation humaine pour *alerter un humain* est presque circulaire : autant laisser passer et laisser le juriste juger.
- Position médiane solide : **alerte automatique, mais avec la clause citée et le raisonnement joints** (le juriste peut vérifier en 30 secondes), plus un suivi du taux de fausses alertes. Toute position argumentée est acceptée ; la qualité du débat prime.

**6. Réponse au collègue.**
- Argument 1 — *contradictions de prompt* : « extrais sans interpréter » (Extracteur) et « classe et juge » (Comparateur) tirent dans des directions opposées ; dans un prompt unique, ces instructions se parasitent.
- Argument 2 — *moindre privilège et débogage* : un agent unique cumule tous les outils (dont la messagerie — risque) et quand la note est mauvaise, impossible d'isoler l'étape fautive ; en pipeline, chaque livrable intermédiaire est inspectable.
- *(Aussi accepté : maîtrise du contexte, garde-fous ciblés, réutilisabilité des agents.)*
- **Cas où il aurait raison :** volume faible et enjeu modéré — p. ex. deux contrats simples par mois, relus de toute façon intégralement par un juriste. Un agent unique (voire un simple prompt en un tour) suffit alors : la règle « l'architecture la plus simple qui suffit » (Session 6) s'applique aussi au multi-agent.