# Slides — Session 6 : La boucle agentique **Programme :** Applied AI — Niveau Intermédiaire · Instructeur : Yann Isola **Durée :** 2 h · Module 4 — Partie 1 · 28 slides **Palette :** encre `#1A2230` · sarcelle `#0F7A6C` · cuivre `#B4612A` · sarcelle claire `#E9F6F3` · fond `#F4F7F6` --- ## Slide 1 — Titre # La boucle agentique ### Du chatbot qui répond… à l'agent qui agit Applied AI — Niveau Intermédiaire · Session 6 · Yann Isola > **Notes :** Accueil. Annoncez la promesse de la séance : « À la fin, vous saurez exactement ce qu'est un agent, comment il tourne, comment le rendre sûr — et surtout quand ne PAS en utiliser un. » --- ## Slide 2 — Rappel Session 5 ### Ce que vous savez déjà - Le tool calling : le modèle **demande** un appel d'outil, votre code l'**exécute** - La boucle `tool_use` : requête → bloc `tool_use` → exécution → `tool_result` → le modèle continue - Le principe du moindre privilège > **Notes :** 2 minutes max. Question de contrôle : « Qui exécute réellement l'appel d'outil ? » Si la salle hésite, refaites le rappel. Session 5 est le prérequis dur de cette séance. --- ## Slide 3 — Objectifs de la session 1. Distinguer chatbot et agent 2. Dérouler la boucle : **percevoir → réfléchir → agir → observer** 3. Comprendre planification et mémoire de travail 4. Poser les garde-fous indispensables 5. Savoir quand un agent est de la **sur-ingénierie** > **Notes :** Insistez sur le point 5 : une session sur les agents qui enseigne aussi à ne pas en abuser, c'est ce qui la rend crédible. --- ## Slide 4 — L'expérience frustrante ### « Réserve-moi un vol pour Lisbonne » Un chatbot classique répond : > « Voici comment réserver un vol : 1. Allez sur un comparateur… 2. … » **Il explique. Il ne fait pas.** > **Notes :** Accroche de la Séquence A. Demandez à la salle : « Pourquoi ne le fait-il pas ? » Laissez venir les réponses : pas d'accès aux systèmes (→ outils, Session 5), et surtout… il s'arrête après UNE réponse. --- ## Slide 5 — Chatbot vs agent | | Chatbot | Agent | |---|---|---| | Fonctionnement | Un tour : question → réponse → **stop** | Une **boucle** jusqu'à la fin de la tâche | | Arrêt | Mécanique, après la réponse | **Décidé par l'agent** quand l'objectif est atteint | | Production | Du texte | Des **actions** + du texte | | Erreur | Réponse fausse | Action ratée → **rattrapage possible** | > **Notes :** LE slide pivot de la séance. La ligne « Arrêt » est la distinction conceptuelle : le contrôle du « quand c'est fini » passe du code au modèle. Faites-le noter mot pour mot. --- ## Slide 6 — La définition en une phrase > ### Un agent = un modèle de langage **dans une boucle**, avec des **outils**, et le droit de **décider quand il a fini**. > **Notes :** Message central de la session. Vous le répéterez au moins trois fois. Précisez tout de suite le malentendu fréquent : ce n'est PAS un autre modèle plus intelligent — souvent c'est exactement le même modèle, dans une architecture différente. L'agentivité est une propriété du système. --- ## Slide 7 — L'analogie - **Chatbot = consultant au téléphone** : il vous dit quoi faire, puis raccroche. - **Agent = assistant personnel** : vous lui confiez la mission ; il passe les appels, compare, réserve — et revient vers vous quand c'est fait (ou pour demander votre accord). > **Notes :** L'analogie tient toute la séance : l'assistant a des « mains » (outils), un plan, un bloc-notes, et des limites que vous lui fixez (garde-fous). Transition : « Regardons le moteur de cet assistant. » --- ## Slide 8 — La boucle agentique ### Le cycle à quatre temps **PERCEVOIR → RÉFLÉCHIR → AGIR → OBSERVER** → (recommencer) …jusqu'à ce que l'agent juge l'objectif atteint ✅ > **Notes :** Annoncez le plan des 4 slides suivants : un temps par slide, toujours illustré par TripDesk, notre agent de réservation de voyages. Présentez TripDesk et sa mission : « vol Paris–Lisbonne semaine du 14, compatible agenda, réserver, confirmer ». Ses 4 outils : `chercher_vols`, `consulter_agenda`, `reserver_vol`, `envoyer_confirmation`. --- ## Slide 9 — Temps 1 : PERCEVOIR ### Lire l'état du monde - La mission de l'utilisateur - L'historique : ce qui a déjà été fait, trouvé, échoué - **TripDesk, itération 1 :** « Mission reçue. Je ne connais ni les vols ni l'agenda. » > **Notes :** Percevoir = relire tout le contexte. À l'itération 1, c'est la mission seule ; ensuite, ça inclut tous les résultats d'outils accumulés. Teaser mémoire (slide 16). --- ## Slide 10 — Temps 2 : RÉFLÉCHIR ### Décider de la prochaine action - Où en suis-je par rapport à l'objectif ? - Que me manque-t-il ? Quel outil m'en rapproche ? - **TripDesk :** « Il me faut d'abord la liste des vols → j'appelle `chercher_vols`. » > **Notes :** C'est ici que vit le raisonnement du modèle. Mentionnez le terme *reasoning* et, en une phrase, le motif « ReAct » (Reasoning + Acting, raisonner + agir) que certains participants croiseront dans la littérature — même cycle, autre nom. --- ## Slide 11 — Temps 3 : AGIR ### Les outils sont les mains de l'agent ```json { "outil": "chercher_vols", "arguments": { "origine": "CDG", "destination": "LIS", "semaine": "2026-07-14" } } ``` **Vous connaissez déjà cette étape : c'est le tool calling de la Session 5.** > **Notes :** Lien explicite avec la Session 5 : l'appel d'outil EST le « agir ». Rappel sécurité : le modèle demande, votre code exécute. Sans outils, la boucle « réfléchit dans le vide » — elle ne peut que parler. --- ## Slide 12 — Temps 4 : OBSERVER ### Lire le résultat — et reboucler - Succès ? Données ? Erreur ? - Le résultat rejoint le contexte → nouveau **percevoir** - **TripDesk :** « 3 vols trouvés. Maintenant : vérifier l'agenda. » → la boucle repart > **Notes :** Insistez : l'observation n'a de valeur que si elle est *exploitée* au tour suivant. Un agent qui reçoit les erreurs mais n'en tient pas compte est une boucle morte (exercice 2 tout à l'heure). Transition : « Voyons la boucle tourner en vrai. » --- ## Slide 13 — Démo : TripDesk pas à pas ### 🖥️ Visualiseur interactif 5 itérations, de la mission à la confirmation — avec un conflit d'agenda, une validation humaine et une panne en route. > **Notes :** Basculez sur `webpage/index.html` pendant ~15 min. Commentez CHAQUE étape interne (percevoir/réfléchir/agir/observer) à voix haute. Trois choses à pointer : les compteurs itérations/budget (garde-fous), le panneau bloc-notes qui grossit (mémoire), et la décision d'arrêt finale prise par l'agent. Puis pause 10 min. --- ## Slide 14 — La planification ### Décomposer avant d'agir ``` Objectif : vol Paris–Lisbonne compatible agenda Plan : 1. Chercher les vols 2. Consulter l'agenda 3. Choisir le meilleur 4. Validation utilisateur 5. Réserver 6. Confirmer ``` > **Notes :** Reprise après la pause. Le plan est produit par le modèle lui-même (souvent déclenché par le prompt système : « établis un plan avant d'agir »). C'est du texte dans le contexte — rien de magique, pas une fonctionnalité cachée de l'API (Application Programming Interface, interface de programmation applicative). --- ## Slide 15 — Un plan n'est pas un contrat ### Le plan se révise en cours de route - Itération 2 : conflit d'agenda découvert → l'étape 3 change - Comme un **GPS** (Global Positioning System) qui recalcule l'itinéraire > **Notes :** Point d'insistance : un plan agentique est une hypothèse de travail. La force d'un agent n'est pas d'avoir un bon plan initial, c'est de le réviser quand les observations le contredisent. Un agent rigide qui suit un plan périmé = un workflow déguisé qui échoue. --- ## Slide 16 — La mémoire de travail ### Comment TripDesk se souvient des 3 vols ? - **Tout est dans l'historique de conversation** (le *scratchpad*, bloc-notes) - Relu intégralement à chaque itération - Limité par la **fenêtre de contexte** (context window) > **Notes :** Question à la salle avant d'afficher : « Entre l'itération 1 et la 4, où sont stockés les 3 vols ? » Analogie : le bloc-notes d'un enquêteur pendant une affaire. Conséquence pratique : un agent qui boucle 50 fois avec des résultats volumineux sature sa fenêtre → techniques de résumé/troncature. --- ## Slide 17 — Mémoire éphémère ### ⚠️ Le bloc-notes est effacé à la fin de l'exécution - Nouvelle mission = mémoire de travail **vierge** - La mémoire *persistante* (préférences, profils) est un mécanisme **distinct**, à concevoir explicitement > **Notes :** Confusion fréquente à tuer explicitement : non, l'agent ne « se souviendra » pas de la mission précédente par défaut. Rien n'est écrit dans les poids du modèle pendant l'exécution. Teaser : la mémoire persistante fera l'objet d'une session ultérieure. --- ## Slide 18 — Le revers de l'autonomie ### « L'agent décide quand il a fini. » Et s'il ne finit jamais ? Un agent sans limites peut : - 🔁 boucler à l'infini (et brûler du budget à chaque tour) - 💸 entreprendre des actions irréversibles à tort - 🧭 dériver loin de la mission > **Notes :** Séquence garde-fous. Reliez explicitement à la distinction clé du slide 5 : c'est PARCE QUE l'agent décide de sa fin qu'il faut des limites. Les garde-fous ne brident pas l'agent — ils rendent son autonomie acceptable en production. --- ## Slide 19 — Les trois garde-fous canoniques | Garde-fou | Exemple TripDesk | |---|---| | **Itérations max** | 15 tours, sinon arrêt + rapport | | **Plafond budgétaire** | ⚠ p. ex. 0,50 € d'API par mission (les prix évoluent) | | **Human-in-the-loop** (humain dans la boucle) | Validation obligatoire avant `reserver_vol` | > **Notes :** À faire noter tel quel : c'est le kit minimal de tout agent en production, pas une option. Règle pratique : toute action irréversible ou coûteuse passe par un humain. Lire des vols : autonome. Payer un billet : validation. Prolongement direct du moindre privilège (Session 5). --- ## Slide 20 — La récupération d'erreur ### Le motif en 4 temps 1. L'outil **échoue** : `reserver_vol` → « vol complet » 2. Le modèle **lit** l'erreur (elle arrive dans le contexte, comme tout résultat) 3. Il **adapte** sa stratégie : inutile de retenter le même vol 4. Il **réessaie différemment** : l'alternative, après nouvelle validation > **Notes :** Rejouez mentalement l'itération 4 de la démo. Anti-motif à nommer : réessayer À L'IDENTIQUE en boucle — c'est exactement ce que le garde-fou d'itérations max vient stopper. Un agent qui se rattrape, c'est ce qui le distingue le plus visiblement d'un simple script. --- ## Slide 21 — Vos messages d'erreur sont des prompts ### ❌ `"erreur 500"` → l'agent est aveugle ### ✅ `"vol complet — plus de places sur AF1148 ; d'autres vols restent disponibles"` → l'agent rebondit > **Notes :** Écho direct de la Session 5 (« les descriptions d'outils sont des prompts »). Le modèle n'adapte sa stratégie qu'à partir de ce qu'il LIT. La robustesse d'un agent se conçoit côté outils autant que côté modèle. C'est la question 4 bonus de l'exercice 2. --- ## Slide 22 — Journaliser, toujours ### Chaque itération laisse une trace - Quoi : pensée résumée, outil appelé, arguments, résultat - Pourquoi : diagnostiquer les boucles mortes, auditer les actions, facturer > **Notes :** Court (2 min). Sans journal, un agent qui déraille est une boîte noire. Avec journal, l'exercice 2 devient possible : on lira ensemble le log d'un agent parti en vrille. Transition vers la séquence esprit critique. --- ## Slide 23 — Le piège de la sur-ingénierie ### Chaque itération = un appel au modèle = coût + latence + risque > « Résume ce document » → un prompt suffit. > « Quelle météo à Lisbonne ? » → un appel d'outil suffit. > **Si un prompt suffit, un agent est une faute de conception.** > **Notes :** Faites voter la salle à main levée sur 3–4 exemples (résumé, traduction, météo, réservation multi-contraintes). Le contraste doit être évident. Les agents sont à la mode : votre valeur de professionnel, c'est de savoir dire « pas d'agent ici ». --- ## Slide 24 — L'arbre de décision 1. Faut-il **agir** ou lire des données vivantes ? → Non : **prompt** (± RAG, Retrieval-Augmented Generation, génération augmentée par récupération) 2. **Un seul** appel d'outil, ordre connu ? → Oui : **tool calling simple** 3. Étapes fixes, connues d'avance ? → Oui : **workflow** 4. L'ordre dépend des **résultats intermédiaires** ? → **Agent** (+ garde-fous !) > **Notes :** L'arbre est interactif dans la webpage — montrez-le brièvement, les participants l'exploreront chez eux. Formule à faire noter : « Prompt < outil unique < workflow fixe < agent : toujours l'arme la plus simple qui accomplit la mission. » --- ## Slide 25 — Et dans VOTRE métier ? ### À vous : proposez une tâche de votre quotidien Prompt ? Outil unique ? Workflow ? Agent ? > **Notes :** 3–5 min. Prenez 2–3 cas proposés par les participants et classez-les ensemble avec l'arbre. C'est souvent le moment le plus riche de la session — les cas réels révèlent les nuances (beaucoup de « faux agents » sont en réalité de bons workflows). --- ## Slide 26 — Exercice en binômes ### Exercice 1 : dérouler la boucle à la main Agent SupportBot : plainte client → vérifier → rembourser (si justifié) → prévenir. **Tableau : percevoir / réfléchir / agir / observer, itération par itération.** > **Notes :** 10 min. Circulez entre les binômes. Erreur à guetter : rembourser AVANT d'avoir vérifié la commande. Question piège à poser aux binômes rapides : « Où placez-vous la validation humaine, et pourquoi pas ailleurs ? » --- ## Slide 27 — Ce qu'il faut retenir 1. **Agent = modèle + boucle + outils + décision d'arrêt par le modèle** 2. Percevoir → réfléchir → agir → observer, et on recommence 3. Plan révisable + mémoire de travail éphémère (le contexte) 4. Kit minimal : itérations max, plafond budgétaire, human-in-the-loop 5. L'erreur lue est une information : adapter, réessayer différemment 6. **L'arme la plus simple qui accomplit la mission** — souvent, ce n'est pas un agent > **Notes :** Relisez les 6 points à voix haute, lentement. Puis quiz express à l'oral (questions 1, 3, 5, 7, 10 du quiz) et distribution des exit tickets. --- ## Slide 28 — La suite ### Session 7 Vous savez faire tourner **un** agent. La suite du Module 4 vous attend — apportez un cas réel de votre métier : on le passera à l'arbre de décision. **📄 À emporter :** le visualiseur interactif (`index.html`, hors ligne), la feuille d'exercices, le quiz corrigé. > **Notes :** Terminez à l'heure. Rappelez que le visualiseur fonctionne hors ligne : ils peuvent rejouer TripDesk et l'arbre de décision chez eux. Collectez les exit tickets à la sortie — c'est votre thermomètre pour ajuster la Session 7.