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 :

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.
À 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 ?
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 :

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 ?
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.
« 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.
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.

« Reformule ce paragraphe en langage plus simple. »
« Quel est le cours actuel de l’action Airbus ? » ⚠ (donnée volatile)
« 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. »
« 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. »
« Traduis ce contrat en anglais. »
« 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.