Applied AI · Intermédiaire 🟡 · Session 7
✏️ Exercices
← Retour au programme 📄 Source .md

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

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

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

3. Transports.

4. Primitives.

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 :

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.

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 :

6. Réponse au collègue.