# Exercices — Session 6 : La boucle agentique **Programme :** Applied AI — Niveau Intermédiaire · Instructeur : Yann Isola **Consigne générale :** travaillez en binômes. Aucun code à écrire — on raisonne sur papier, comme un architecte d'agent. Les corrigés sont en fin de document : ne les lisez qu'après avoir vraiment essayé. --- ## Exercice 1 — Dérouler la boucle à la main (≈ 15 min) *Objectif : savoir décomposer une exécution d'agent en itérations percevoir → réfléchir → agir → observer.* **Contexte.** L'agent **SupportBot** aide un service client. Ses outils : - 🗄️ `chercher_client(email)` — renvoie la fiche client (nom, abonnement, historique). - 📦 `statut_commande(numero)` — renvoie l'état d'une commande. - 💶 `rembourser(numero, montant)` — effectue un remboursement. **Action irréversible.** - ✉️ `envoyer_email(destinataire, texte)` — envoie un courriel. **Mission reçue :** « Le client paul@exemple.fr se plaint que sa commande C-4812 n'est jamais arrivée. Vérifie, rembourse si c'est justifié, et préviens-le. » **Questions :** 1. Déroulez l'exécution attendue sous forme de tableau, une ligne par itération, avec 4 colonnes : **Percevoir / Réfléchir / Agir (appel d'outil exact) / Observer (résultat plausible)**. Visez 4 à 5 itérations. 2. À quelle itération placez-vous un **point de contrôle humain** (human-in-the-loop, validation par un humain) ? Pourquoi celle-là et pas une autre ? 3. Comment l'agent sait-il, à la dernière itération, qu'il peut s'arrêter ? Qui prend cette décision ? --- ## Exercice 2 — Diagnostic d'un agent qui déraille (≈ 15 min) *Objectif : identifier les garde-fous manquants et le bon comportement de récupération d'erreur.* **Contexte.** Voici le journal (log) réel — simplifié — d'un agent de veille chargé de : « Trouve les 3 articles les plus pertinents de la semaine sur les stablecoins et envoie une synthèse à l'équipe. » ``` It. 1 AGIR: recherche_web("stablecoins actualité") → OBSERVER: erreur 429 (too many requests) It. 2 AGIR: recherche_web("stablecoins actualité") → OBSERVER: erreur 429 It. 3 AGIR: recherche_web("stablecoins actualité") → OBSERVER: erreur 429 It. 4 AGIR: recherche_web("stablecoins actualité") → OBSERVER: erreur 429 ... It. 27 AGIR: recherche_web("stablecoins actualité") → OBSERVER: erreur 429 It. 28 AGIR: recherche_web("stablecoins actualité") → OBSERVER: erreur 429 [interruption manuelle par l'administrateur au bout de 40 minutes] ``` **Questions :** 1. Décrivez précisément le dysfonctionnement. Quelle étape de la boucle l'agent rate-t-il, au sens où il ne l'exploite pas correctement ? 2. Citez **trois garde-fous absents** de ce système, et pour chacun, la valeur ou la règle concrète que vous choisiriez pour cet agent de veille. 3. « Erreur 429 (too many requests) » signifie que le service refuse temporairement les requêtes trop fréquentes. Qu'aurait fait un agent doté d'une bonne **récupération d'erreur** dès l'itération 2 ? Proposez deux stratégies différentes. 4. Question bonus : le message d'erreur renvoyé au modèle était exactement `"429"`. Proposez une meilleure formulation de ce message d'erreur, et expliquez pourquoi elle change le comportement de l'agent. --- ## Exercice 3 — Agent ou pas agent ? (≈ 15 min) *Objectif : appliquer l'arbre de décision et éviter la sur-ingénierie.* Pour **chacune** des six demandes suivantes, choisissez l'architecture la plus simple qui suffit, parmi : **A. Prompt simple** (un appel au modèle, zéro outil) · **B. Appel d'outil unique** (Session 5) · **C. Workflow fixe** (enchaînement d'étapes codé à l'avance) · **D. Agent** (boucle autonome). Justifiez en une phrase, et pour chaque réponse D, indiquez **au moins un garde-fou** obligatoire. 1. « Reformule ce paragraphe en langage plus simple. » 2. « Quel est le cours actuel de l'action Airbus ? » ⚠ (donnée volatile) 3. « Chaque lundi à 9 h : récupère les ventes de la semaine dans la base, calcule le total, génère le rapport PDF (Portable Document Format, format de document portable), envoie-le à la direction. Toujours ces 4 étapes, toujours dans cet ordre. » 4. « Trouve-moi un créneau de réunion d'une heure cette semaine qui convienne aux agendas de Marie, Karim et moi, propose-le-leur par e-mail, et si quelqu'un refuse, trouve une alternative jusqu'à accord. » 5. « Traduis ce contrat en anglais. » 6. « Mon site est lent depuis ce matin. Diagnostique la cause et corrige-la si c'est sans risque ; sinon, explique-moi quoi faire. » **Question de synthèse :** énoncez la règle générale qui vous a guidé, en une phrase. --- --- # Corrigés ## Corrigé — Exercice 1 **1. Déroulé attendu** (les résultats « Observer » sont plausibles, d'autres variantes sont acceptables) : | It. | Percevoir | Réfléchir | Agir | Observer | |---|---|---|---|---| | 1 | Mission : plainte de paul@exemple.fr, commande C-4812 non livrée | Je dois d'abord vérifier que le client et la commande existent | `chercher_client("paul@exemple.fr")` | Fiche : Paul Durand, abonné depuis 2023, 1 réclamation antérieure | | 2 | Client confirmé | Vérifier l'état réel de la commande avant tout remboursement | `statut_commande("C-4812")` | « Perdue par le transporteur, dernière trace il y a 12 jours » — montant 89 € | | 3 | Commande perdue : le remboursement est justifié | Action irréversible → demander validation humaine | *(point de contrôle humain : « Rembourser 89 € à Paul Durand ? »)* | Validation accordée | | 4 | Remboursement autorisé | Exécuter le remboursement | `rembourser("C-4812", 89)` | `{"statut": "ok", "ref": "R-2291"}` | | 5 | Remboursement effectué, il reste à prévenir le client | Rédiger et envoyer le courriel, puis la mission sera complète | `envoyer_email("paul@exemple.fr", "…remboursement de 89 € effectué, réf. R-2291…")` | `{"statut": "envoyé"}` → objectif atteint, **l'agent s'arrête** | Points de notation : l'ordre vérifier **avant** de rembourser (un agent qui rembourse à l'itération 1 sur la seule foi de la plainte est une erreur de conception) ; chaque « Observer » alimente le « Percevoir » suivant. **2. Point de contrôle humain :** avant `rembourser` (itération 3/4), car c'est la seule action **irréversible et financière** de la mission. Ni avant les lectures (`chercher_client`, `statut_commande` : sans risque, la validation ralentirait pour rien), ni avant `envoyer_email` (réversible en pratique : on peut envoyer un correctif ; certains binômes peuvent défendre une validation du texte de l'e-mail — acceptable si argumenté, mais le remboursement reste prioritaire). **3. Fin d'exécution :** à l'itération 5, l'agent relit la mission (« vérifie, rembourse, préviens ») et constate que les trois volets sont accomplis. **C'est le modèle qui prend la décision d'arrêt** — techniquement, il répond sans demander de nouvel outil, ce qui clôt la boucle. C'est la distinction clé avec un chatbot, qui se serait arrêté après sa première réponse quoi qu'il arrive. --- ## Corrigé — Exercice 2 **1. Dysfonctionnement :** l'agent réessaie **28 fois exactement la même action** malgré 28 échecs identiques. Il exécute bien l'étape « observer » au sens mécanique (il reçoit l'erreur), mais il ne l'**exploite** pas dans l'étape « réfléchir » : l'observation ne modifie jamais sa stratégie. La boucle est devenue une boucle *morte* : agir → échouer → recommencer à l'identique. C'est l'anti-motif classique de la répétition à l'identique. **2. Trois garde-fous absents** (valeurs indicatives — toute valeur raisonnable et justifiée est acceptée) : | Garde-fou | Règle concrète pour cet agent de veille | |---|---| | **Itérations max** | 10 tours de boucle maximum ; au-delà, arrêt + rapport « mission non accomplie, voici pourquoi » | | **Plafond budgétaire / temps** | ⚠ p. ex. 0,30 € d'appels d'API ou 5 minutes par exécution (ordres de grandeur ; les prix évoluent) — une veille hebdomadaire ne justifie pas 40 minutes | | **Détection de répétition** | Règle : « même outil + mêmes arguments + même erreur 2 fois de suite → interdiction de réessayer à l'identique » (variante acceptée : alerte à un humain après N échecs consécutifs) | *(La journalisation existait déjà — c'est grâce à elle qu'on diagnostique. Un point bonus si le binôme le remarque.)* **3. Deux stratégies de récupération valables dès l'itération 2 :** - **Attendre puis réessayer** (backoff, attente croissante entre tentatives) : l'erreur 429 est temporaire par nature ; attendre 30–60 s avant une nouvelle tentative, en doublant le délai à chaque échec, avec un maximum de 3 tentatives. - **Changer de moyen** : utiliser un autre outil disponible (autre moteur de recherche, flux RSS — Really Simple Syndication, format de flux d'actualités — interne, base documentaire), ou dégrader proprement : produire la synthèse à partir de ce qui est accessible en signalant la limite, ou remonter la main à un humain. **4. Bonus — meilleur message d'erreur :** au lieu de `"429"` : > `"Erreur : quota de requêtes dépassé (429). Le service refusera les appels pendant environ 60 secondes. Ne réessayez pas immédiatement : attendez, ou utilisez une source alternative."` Pourquoi ça change tout : le modèle ne peut adapter sa stratégie qu'à partir de ce qu'il **lit** dans le contexte. `"429"` n'indique ni la cause ni la conduite à tenir ; le message enrichi contient littéralement la stratégie de récupération. La robustesse d'un agent se conçoit **côté outils** autant que côté modèle. --- ## Corrigé — Exercice 3 | # | Réponse | Justification | |---|---|---| | 1 | **A — Prompt simple** | Transformation de texte pure : aucune donnée externe, aucune action, un seul tour. | | 2 | **B — Appel d'outil unique** | Donnée vivante ⚠ (le modèle seul ne connaît pas le cours actuel), mais UN appel à une API boursière suffit ; aucune boucle nécessaire. | | 3 | **C — Workflow fixe** | Les étapes et leur ordre sont connus d'avance et invariables. Un agent apporterait de la flexibilité dont personne n'a besoin — et de l'imprévisibilité dont personne ne veut. Piège de l'énoncé : « plusieurs outils » ne signifie pas « agent ». | | 4 | **D — Agent** | Le nombre d'étapes est **inconnu à l'avance** (ça dépend des refus), l'ordre dépend des résultats intermédiaires, il faut s'adapter. Garde-fous obligatoires (au moins un) : itérations max (p. ex. 10 allers-retours), validation humaine avant l'envoi des invitations définitives, plafond de temps. | | 5 | **A — Prompt simple** | Traduction : un tour, zéro outil. (Un binôme qui propose une relecture humaine pour un contrat juridique fait preuve de bon sens — mais c'est un contrôle qualité, pas une raison d'agentifier.) | | 6 | **D — Agent** | Diagnostic exploratoire : les étapes suivantes dépendent de ce que révèlent les précédentes (logs ? base de données ? réseau ?). Garde-fous obligatoires : **validation humaine avant toute action corrective** sur la production (« corrige si c'est sans risque » doit être encadré strictement — idéalement, seule la lecture est autonome), itérations max, journalisation complète. | **Règle de synthèse attendue :** « Toujours choisir l'architecture la plus simple qui accomplit la mission : prompt < outil unique < workflow fixe < agent. On ne passe au niveau supérieur que si le nombre d'étapes ou leur ordre dépend des résultats intermédiaires. » Toute formulation équivalente est correcte.