# Guide Professeur — Session 6 : La boucle agentique

**Programme :** Applied AI — Niveau Intermédiaire
**Instructeur :** Yann Isola
**Durée :** 2 heures (120 minutes)
**Module couvert :** Module 4 — Partie 1 (La boucle agentique)

---

## 1. Vue d'ensemble de la session

### Objectifs pédagogiques

À la fin de cette session, chaque participant doit être capable de :

1. **Distinguer chatbot et agent** : un chatbot produit *une* réponse puis s'arrête ; un agent **boucle** — il enchaîne des actions jusqu'à ce que la tâche soit accomplie.
2. **Dérouler la boucle agentique** : percevoir → réfléchir → agir → observer → recommencer, et savoir situer chaque étape dans un exemple concret.
3. **Énoncer la distinction clé** : c'est l'**agent qui décide** quand il a terminé (le chatbot, lui, s'arrête mécaniquement après une réponse).
4. **Relier les outils à la boucle** : l'appel d'outil (tool calling, vu en Session 5) *est* l'étape « agir » — les outils sont les mains de l'agent.
5. **Expliquer la planification** : le modèle décompose un objectif en sous-étapes *avant* d'agir, et peut réviser ce plan en cours de route.
6. **Décrire la mémoire de travail d'un agent** : l'historique de conversation et le bloc-notes (scratchpad) servent de mémoire *pendant* une exécution.
7. **Lister les garde-fous indispensables** : nombre maximal d'itérations, plafond budgétaire, points de contrôle humains (human-in-the-loop, littéralement « humain dans la boucle »).
8. **Décrire la récupération d'erreur** : un outil échoue → le modèle *lit* le message d'erreur → adapte sa stratégie → réessaie différemment.
9. **Savoir quand NE PAS utiliser un agent** : si un seul prompt suffit, un agent est de la sur-ingénierie (coût, latence, risques inutiles).

### Prérequis

- **Session 5 (Outils & Tool Calling) est indispensable.** La boucle agentique est littéralement la boucle `tool_use` de la Session 5, généralisée et prolongée. Si des participants ont manqué la Session 5, prévoyez 5 minutes de rattrapage individuel avant le début.
- Savoir lire un objet JSON (JavaScript Object Notation, format d'échange de données) simple.
- Comprendre la notion d'API (Application Programming Interface, interface de programmation applicative).

### Matériel nécessaire

- Vidéoprojecteur + slides de la session (`slides/slides.md`).
- Page web interactive (`webpage/index.html`) — fonctionne **hors ligne** : visualiseur animé de la boucle agentique avec le scénario TripDesk pas à pas, et arbre de décision interactif « Faut-il un agent ? ».
- Feuilles d'exercices (`exercises/exercises.md`) imprimées ou partagées.
- Quiz de fin de session (`quiz/quiz.md`).
- Idéalement : un ordinateur portable pour deux participants, pour manipuler le visualiseur.

### Message central de la session

> « Un agent, c'est un modèle de langage dans une boucle, avec des outils, et le droit de décider quand il a fini. Tout le reste — planification, mémoire, garde-fous — existe pour que cette boucle soit *utile* et *sûre*. »

Répétez cette idée au moins trois fois pendant la session, sous des formes différentes. Un participant qui ne retient que cette phrase repart avec l'essentiel.

### Fil conducteur narratif

Toute la session s'appuie sur **un seul exemple filé : TripDesk**, un agent de réservation de voyages. Sa mission type :

> « Trouve-moi un vol Paris → Lisbonne la semaine du 14, compatible avec mon agenda, réserve-le et envoie-moi la confirmation. »

Ses outils : 🔍 `chercher_vols` (recherche de vols), 📅 `consulter_agenda` (lecture du calendrier de l'utilisateur), ✈️ `reserver_vol` (réservation — action irréversible !), ✉️ `envoyer_confirmation` (courriel de confirmation).

TripDesk sert à illustrer **chaque** concept : la boucle, la planification, la mémoire, les garde-fous (le point de contrôle humain avant `reserver_vol`), la récupération d'erreur (un vol complet → l'agent cherche une alternative). La répétition du même exemple ancre les concepts.

---

## 2. Déroulé minute par minute

| Horaire | Durée | Séquence | Support |
|---|---|---|---|
| 0:00 – 0:05 | 5 min | Accueil, rappel Session 5 (tool calling), objectifs | Slides 1–3 |
| 0:05 – 0:20 | 15 min | Séquence A — Du chatbot à l'agent | Slides 4–7 |
| 0:20 – 0:40 | 20 min | Séquence B — La boucle agentique (percevoir → réfléchir → agir → observer) | Slides 8–12 + visualiseur |
| 0:40 – 0:55 | 15 min | Séquence C — Démo guidée TripDesk pas à pas | Webpage (visualiseur) |
| 0:55 – 1:05 | 10 min | ☕ Pause | — |
| 1:05 – 1:20 | 15 min | Séquence D — Planification & mémoire de travail | Slides 13–17 |
| 1:20 – 1:35 | 15 min | Séquence E — Garde-fous & récupération d'erreur | Slides 18–22 |
| 1:35 – 1:45 | 10 min | Séquence F — Quand NE PAS utiliser un agent (arbre de décision) | Slides 23–25 + webpage |
| 1:45 – 1:55 | 10 min | Exercice flash en binômes (Exercice 1 de la feuille) | Exercices |
| 1:55 – 2:00 | 5 min | Quiz express (5 questions à l'oral), exit tickets, annonce Session 7 | Quiz + slides 26–28 |

> ⏱️ **Marge de sécurité :** si vous prenez du retard, la Séquence F peut être compressée à 5 minutes (l'arbre de décision est aussi dans la webpage, que les participants peuvent explorer chez eux). Ne sacrifiez **jamais** la Séquence C (démo TripDesk) : c'est le moment où « ça clique ».

---

## 3. Notes détaillées par séquence

### Séquence A — Du chatbot à l'agent (15 min)

**Objectif :** faire émerger la définition d'un agent par contraste avec ce que les participants connaissent déjà.

**Accroche (2 min).** Posez la question : « Quand vous demandez à ChatGPT de vous réserver un vol, que se passe-t-il ? » Réponse attendue : il *explique comment faire*, ou il *invente* une réservation. Il ne la fait pas. Pourquoi ? Parce qu'un chatbot fonctionne en **un tour** : une question → une réponse → stop.

**Le contraste fondamental (8 min).** Écrivez au tableau, en deux colonnes :

| Chatbot | Agent |
|---|---|
| Un tour : question → réponse → **stop** | Une **boucle** : agit tant que la tâche n'est pas finie |
| S'arrête mécaniquement après sa réponse | **Décide lui-même** quand il a terminé |
| Produit du texte | Produit des **actions** (via des outils) + du texte |
| Aucun effet sur le monde | Peut modifier le monde (réserver, écrire, envoyer) |
| Erreur = réponse fausse | Erreur = action ratée → il peut **se rattraper** |

**Point d'insistance :** la ligne 2 est LA distinction conceptuelle. Un chatbot s'arrête parce que c'est son architecture. Un agent s'arrête parce qu'il **évalue** que l'objectif est atteint. Le contrôle du « quand c'est fini » passe du code au modèle. C'est puissant — et c'est exactement pour ça qu'il faut des garde-fous (teaser de la Séquence E).

**Analogie qui fonctionne bien (3 min).** Le chatbot est un **consultant au téléphone** : il vous dit quoi faire, puis raccroche. L'agent est un **assistant personnel** : vous lui confiez la mission, il passe les appels, compare, réserve, et revient vers vous quand c'est fait — ou quand il a besoin de votre accord.

**Piège à désamorcer (2 min).** Certains participants croient qu'un agent est « un autre modèle », plus intelligent. Non : **c'est souvent exactement le même modèle** (Claude, GPT, etc.), placé dans une architecture différente — une boucle avec des outils. L'agentivité est une propriété du *système*, pas du modèle seul.

---

### Séquence B — La boucle agentique (20 min)

**Objectif :** que chaque participant sache dessiner et commenter le cycle percevoir → réfléchir → agir → observer.

**Le cycle (10 min).** Dessinez le cycle au tableau (ou projetez le slide 9) :

```
        ┌──────────────┐
   ┌───▶│ 1. PERCEVOIR │  (lire la mission, le contexte, les résultats précédents)
   │    └──────┬───────┘
   │           ▼
   │    ┌──────────────┐
   │    │ 2. RÉFLÉCHIR │  (raisonner : où en suis-je ? que faire ensuite ?)
   │    └──────┬───────┘
   │           ▼
   │    ┌──────────────┐
   │    │ 3. AGIR      │  (appeler un outil — les « mains » de l'agent)
   │    └──────┬───────┘
   │           ▼
   │    ┌──────────────┐
   └────│ 4. OBSERVER  │  (lire le résultat de l'outil : succès ? erreur ? données ?)
        └──────────────┘
              │
              ▼  (si l'objectif est atteint)
        ✅ TERMINÉ — l'agent le décide lui-même
```

Commentez chaque étape avec TripDesk :

1. **Percevoir** : TripDesk lit la mission (« vol Paris–Lisbonne semaine du 14, compatible agenda, réserver, confirmer ») et tout ce qu'il sait déjà.
2. **Réfléchir** : « Je ne connais ni les vols disponibles ni l'agenda. Je commence par chercher les vols. »
3. **Agir** : appel de l'outil `chercher_vols(origine="CDG", destination="LIS", semaine="2026-07-14")`. Rappel Session 5 : le modèle *demande* l'appel, c'est **votre code** qui l'exécute.
4. **Observer** : l'outil renvoie 3 vols. TripDesk lit ce résultat… et la boucle repart : percevoir (nouvel état), réfléchir (« maintenant, vérifier l'agenda »), agir (`consulter_agenda`), observer…

**Lien explicite avec la Session 5 (5 min).** Insistez : « Vous connaissez déjà l'étape 3 ! L'appel d'outil de la Session 5, c'est exactement le "agir" de la boucle. Ce qui est nouveau, c'est qu'on **enchaîne** les tours au lieu de s'arrêter après un seul. » Les outils sont les **mains** de l'agent ; sans outils, la boucle réfléchit dans le vide — elle ne peut rien faire d'autre que parler.

**Vocabulaire (3 min).** Introduisez les termes anglais que les participants croiseront partout : *agentic loop* (boucle agentique), *reasoning* (raisonnement, l'étape « réfléchir »), *tool call* (appel d'outil), *observation* (le résultat renvoyé). Mentionnez que certains frameworks appellent ce motif « ReAct » (Reasoning + Acting, raisonner + agir) — pas besoin d'entrer dans le détail académique, c'est le même cycle.

**Question de contrôle (2 min).** « Dans la boucle, qui exécute réellement l'appel d'outil ? » Réponse attendue (acquis Session 5) : le code de l'application, jamais le modèle. Si moins de la moitié de la salle répond juste, refaites un rappel de 2 minutes.

---

### Séquence C — Démo guidée TripDesk (15 min)

**Objectif :** voir la boucle *tourner*, itération par itération.

Ouvrez `webpage/index.html`, section « Visualiseur de boucle ». Le scénario TripDesk y est simulé en 5 itérations, chacune décomposée en percevoir / réfléchir / agir / observer. Avancez avec le bouton « Étape suivante » et **commentez à voix haute chaque étape** :

- **Itération 1** : recherche de vols → 3 résultats.
- **Itération 2** : consultation de l'agenda → conflit détecté avec le vol le moins cher (réunion le mardi matin).
- **Itération 3** : l'agent **adapte son plan** — il écarte le vol en conflit, choisit le vol de jeudi. ⚠️ Point de contrôle humain : avant de réserver (action irréversible, paiement !), l'agent demande la validation de l'utilisateur. Faites remarquer la pause : *c'est un garde-fou, pas une faiblesse*.
- **Itération 4** : réservation → **échec simulé** (« vol complet »). L'agent lit l'erreur, ne panique pas, ne réessaie pas à l'identique : il **change de stratégie** et réserve le vol suivant (après nouvelle validation). C'est la récupération d'erreur en action.
- **Itération 5** : envoi de la confirmation → l'agent **évalue que la mission est accomplie** et décide de s'arrêter.

**Trois choses à faire remarquer explicitement :**
1. Le compteur d'itérations et le compteur de budget en haut du visualiseur — teaser des garde-fous (Séquence E).
2. Le panneau « bloc-notes » (scratchpad) qui s'enrichit à chaque itération — teaser de la mémoire (Séquence D).
3. Le moment final où l'agent déclare « objectif atteint » : **personne ne l'a arrêté, il l'a décidé** — la boucle sur la distinction clé de la Séquence A.

Si le temps le permet, laissez 3 minutes aux binômes pour rejouer la simulation eux-mêmes.

---

### Séquence D — Planification & mémoire de travail (15 min)

**Objectif :** comprendre comment l'agent structure son travail *avant* et *pendant* la boucle.

**Planification (8 min).** Avant d'agir, un bon agent **décompose** l'objectif en sous-étapes. Pour TripDesk :

```
Objectif : réserver un vol Paris–Lisbonne compatible agenda
Plan :
  1. Chercher les vols disponibles la semaine du 14
  2. Consulter l'agenda pour identifier les conflits
  3. Sélectionner le meilleur vol sans conflit
  4. Demander validation à l'utilisateur
  5. Réserver
  6. Envoyer la confirmation
```

Deux points d'insistance :
- Le plan est produit **par le modèle lui-même** (souvent déclenché par une consigne du prompt système du type « avant d'agir, établis un plan »). C'est du texte, dans le contexte — rien de magique.
- Le plan **n'est pas figé** : à l'itération 2, TripDesk découvre le conflit d'agenda et révise l'étape 3. Un plan agentique est une hypothèse de travail, pas un contrat. Comparez à un itinéraire GPS (Global Positioning System, système de positionnement par satellites) qui recalcule quand vous ratez une sortie.

**Mémoire de travail (7 min).** Question à la salle : « Entre l'itération 1 et l'itération 4, comment TripDesk se souvient-il des 3 vols trouvés ? » Réponse : **tout est dans l'historique de conversation**. Chaque appel d'outil et chaque résultat sont ajoutés au contexte ; à chaque itération, le modèle relit l'ensemble. C'est sa **mémoire de travail** — on parle aussi de *scratchpad* (bloc-notes).

Conséquences pratiques à énoncer :
- Cette mémoire est **limitée par la fenêtre de contexte** (context window, la quantité maximale de texte que le modèle peut lire d'un coup). Un agent qui boucle 50 fois avec des résultats d'outils volumineux peut saturer sa fenêtre — d'où des techniques de résumé ou de troncature des vieux résultats.
- Cette mémoire est **effacée à la fin de l'exécution**. La mémoire *persistante* entre les sessions (profils utilisateur, préférences) est un autre sujet — teaser d'une session ultérieure.

**Analogie :** le bloc-notes d'un enquêteur pendant une affaire. Tout y est noté (indices, pistes écartées, prochaines actions) ; il le relit avant chaque décision ; et il ouvre un bloc-notes neuf à la prochaine affaire.

---

### Séquence E — Garde-fous & récupération d'erreur (15 min)

**Objectif :** comprendre que l'autonomie sans limites est un défaut de conception, pas une prouesse.

**Pourquoi des garde-fous (3 min).** Rappelez la distinction clé : l'agent décide quand il a fini. Et s'il ne finit jamais ? Et s'il se trompe d'objectif ? Un agent sans limites peut : boucler à l'infini (et brûler du budget d'API à chaque itération), entreprendre des actions irréversibles à tort, dériver loin de la mission. Les garde-fous ne bride pas l'agent : ils rendent son autonomie *acceptable*.

**Les trois garde-fous canoniques (7 min).** Au tableau :

| Garde-fou | Ce que c'est | Exemple TripDesk |
|---|---|---|
| **Itérations max** | Nombre maximal de tours de boucle avant arrêt forcé | 15 itérations, sinon abandon avec rapport |
| **Plafond budgétaire** | Limite de coût (jetons/appels d'API) ou de temps | ⚠ p. ex. 0,50 € d'API par mission (ordre de grandeur : les prix des API évoluent) |
| **Point de contrôle humain** (human-in-the-loop) | L'agent DOIT demander validation avant certaines actions | Toujours avant `reserver_vol` (paiement, irréversible) |

Règle pratique à faire noter : **toute action irréversible ou coûteuse passe par un humain**. Lire des vols : autonome. Payer un billet : validation. C'est le prolongement direct du principe du moindre privilège vu en Session 5.

**Récupération d'erreur (5 min).** Déroulez le motif en 4 temps, avec l'échec de réservation de la démo :

1. **L'outil échoue** : `reserver_vol` → `{"erreur": "vol complet"}` (avec le drapeau `is_error` de la Session 5).
2. **Le modèle lit l'erreur** : le message d'erreur est renvoyé *dans le contexte*, comme n'importe quel résultat d'outil. D'où l'importance de messages d'erreur **explicites** : « vol complet » permet d'adapter ; « erreur 500 » ne dit rien.
3. **Il adapte sa stratégie** : inutile de réessayer le même vol — il repart des résultats de recherche et sélectionne l'alternative.
4. **Il réessaie différemment** : nouvelle validation humaine, nouvelle réservation, succès.

**Point d'insistance :** la qualité de la récupération dépend de la qualité des messages d'erreur *que vous écrivez dans vos outils*. Un agent robuste, ça se conçoit côté outils autant que côté modèle. Anti-motif à nommer : l'agent qui réessaie **à l'identique** en boucle — c'est précisément ce que le garde-fou d'itérations max vient arrêter.

---

### Séquence F — Quand NE PAS utiliser un agent (10 min)

**Objectif :** vacciner contre la sur-ingénierie. C'est la séquence « esprit critique » de la session.

**Le piège (3 min).** Les agents sont à la mode ; le réflexe « mettons un agent partout » coûte cher. Chaque itération = un appel au modèle = coût + latence + un risque d'erreur supplémentaire. **Si un seul prompt bien écrit suffit, un agent est de la sur-ingénierie.**

Exemples à trancher avec la salle (faites-les voter à main levée) :
- « Résume ce document » → **un prompt suffit.** Aucune action, aucune donnée externe, aucune décision multi-étapes.
- « Traduis cet e-mail en anglais » → **un prompt suffit.**
- « Quelle est la météo à Lisbonne ? » → **un seul appel d'outil suffit** (Session 5) — pas besoin de boucle.
- « Réserve-moi le meilleur vol compatible avec mon agenda » → **agent** : plusieurs outils, ordre inconnu à l'avance, décisions intermédiaires, adaptation aux résultats.

**L'arbre de décision (5 min).** Projetez l'arbre interactif de la webpage :

1. La tâche exige-t-elle d'**agir** sur des systèmes externes ou de lire des données vivantes ? → Non : **prompt simple** (éventuellement avec RAG, Retrieval-Augmented Generation, génération augmentée par récupération).
2. Un **seul** appel d'outil suffit-il, dans un ordre connu d'avance ? → Oui : **tool calling simple** (Session 5) ou un enchaînement fixe codé en dur (workflow).
3. Le nombre d'étapes ou leur ordre **dépend-il des résultats intermédiaires** ? → Oui : **agent**.
4. Bonus : le coût de l'erreur est-il élevé ? → Ajoutez des points de contrôle humains.

Formule à faire noter : **« Prompt < outil unique < workflow fixe < agent. Prenez toujours l'arme la plus simple qui accomplit la mission. »**

**Passage en revue (2 min).** Faites classer 2–3 cas proposés par les participants eux-mêmes (leurs contextes métier). C'est souvent le moment le plus riche de la session.

---

### Clôture (5 min)

- Quiz express : posez à l'oral les questions 1, 3, 5, 7, 10 du quiz (les réponses complètes sont dans `quiz/quiz.md` pour travail à la maison).
- Distribuez les **exit tickets** (ci-dessous).
- Annoncez la Session 7 et le pont : « Vous savez maintenant faire tourner UN agent. Et si plusieurs agents collaboraient ? » (ou l'accroche adaptée au programme).

---

## 4. Questions fréquentes des participants (et réponses)

**« Un agent, c'est un modèle différent d'un chatbot ? »**
Non. Souvent le même modèle exactement. La différence est architecturale : boucle + outils + critère d'arrêt décidé par le modèle. L'agentivité est une propriété du système.

**« Comment l'agent sait-il qu'il a fini ? »**
À chaque itération, le modèle relit la mission et l'état courant, et évalue si l'objectif est atteint. Concrètement : soit il répond sans demander d'outil (fin naturelle de la boucle `tool_use`), soit il appelle un outil explicite de type `terminer(rapport)`. C'est une évaluation par le modèle — d'où les garde-fous, car cette évaluation peut être erronée.

**« Et si l'agent boucle à l'infini ? »**
C'est exactement le rôle du garde-fou d'itérations max : arrêt forcé + rapport de ce qui a été fait. En pratique, on journalise aussi chaque itération pour diagnostiquer *pourquoi* il tournait en rond (souvent : un message d'erreur d'outil trop vague, ou une mission ambiguë).

**« L'agent peut-il dépenser de l'argent sans autorisation ? »**
Seulement si vous l'avez conçu ainsi — et c'est une faute de conception. Toute action irréversible ou coûteuse doit passer par un point de contrôle humain. Rappel Session 5 : c'est *votre code* qui exécute les appels ; c'est donc votre code qui impose la validation.

**« La planification, c'est une fonctionnalité de l'API ? »**
Non, c'est un comportement du modèle, généralement encouragé par le prompt système (« établis un plan avant d'agir ») et par les capacités de raisonnement du modèle. Le plan vit dans le contexte, comme le reste. ⚠ Certaines plateformes ajoutent des mécanismes dédiés (modes de raisonnement étendu, planificateurs intégrés) — le paysage évolue vite.

**« Combien d'itérations, c'est normal ? »**
⚠ Ordre de grandeur, très dépendant de la tâche : 3 à 10 itérations pour une tâche type TripDesk ; des agents de développement logiciel peuvent en faire des dizaines. Au-delà de ce que vous aviez estimé, c'est un signal d'inspection, pas forcément une panne.

**« Quelle différence entre un workflow et un agent ? »**
Un workflow enchaîne des étapes **fixées à l'avance par le développeur** (étape 1 puis 2 puis 3). Un agent choisit **lui-même** ses étapes et leur ordre en fonction des résultats. Le workflow est plus prévisible et moins cher ; l'agent est plus flexible. Beaucoup de « faux agents » en production sont en réalité des workflows — et c'est très bien ainsi.

---

## 5. Pièges pédagogiques à éviter

1. **Passer trop vite sur la Séquence A.** Si la distinction « l'agent décide quand il a fini » n'est pas ancrée, tout le reste flotte.
2. **Faire la démo TripDesk sans commenter les étapes internes.** Le visualiseur montre percevoir/réfléchir/agir/observer à chaque itération : verbalisez-les systématiquement, sinon les participants ne voient qu'une succession de résultats.
3. **Présenter les garde-fous comme optionnels.** Non : itérations max + budget + validation humaine des actions irréversibles = le kit minimal de tout agent en production.
4. **Glorifier les agents.** La Séquence F existe pour ça. Un formateur crédible est celui qui dit *quand ne pas* utiliser la technologie qu'il enseigne.
5. **Laisser croire que la mémoire de travail est persistante.** Elle disparaît à la fin de l'exécution — dites-le explicitement, la confusion est fréquente.

---

## 6. Exit tickets (5)

À distribuer sur papier ou formulaire dans les 5 dernières minutes. Une phrase de réponse suffit.

1. **En une phrase : quelle est LA différence entre un chatbot et un agent ?**
   *(Attendu : le chatbot s'arrête après une réponse ; l'agent boucle et décide lui-même quand la tâche est accomplie.)*

2. **Citez les 4 étapes de la boucle agentique, dans l'ordre.**
   *(Attendu : percevoir → réfléchir → agir → observer, puis on recommence.)*

3. **Citez deux garde-fous que vous imposeriez à un agent qui peut effectuer des paiements.**
   *(Attendu, deux parmi : validation humaine avant paiement, plafond budgétaire, nombre max d'itérations, journalisation.)*

4. **Un outil renvoie « erreur : vol complet ». Que fait un agent bien conçu ?**
   *(Attendu : il lit l'erreur, adapte sa stratégie — p. ex. choisit un autre vol — et réessaie différemment ; il ne réessaie pas à l'identique.)*

5. **Donnez un exemple de tâche pour laquelle utiliser un agent serait de la sur-ingénierie, et dites pourquoi.**
   *(Attendu : toute tâche en un coup — résumé, traduction, question météo simple — car un prompt ou un appel d'outil unique suffit : moins cher, plus rapide, moins risqué.)*

---

## 7. Pont vers la suite

- **Acquis après cette session :** l'architecture complète d'un agent individuel — boucle, outils, plan, mémoire de travail, garde-fous, récupération d'erreur, et le discernement d'usage.
- **Prochaine session :** approfondissement du Module 4 (selon le programme : conception d'agents en pratique, orchestration multi-agents, ou évaluation d'agents). Accroche suggérée : « Cette semaine, observez autour de vous une tâche de votre métier et demandez-vous : prompt, outil unique, workflow ou agent ? Apportez votre cas, on le décortiquera. »