Le visualiseur : TripDesk en action
TripDesk est un agent de réservation de voyages. Avancez pas à pas et observez chaque temps de la boucle : Percevoir Réfléchir Agir Observer. Vous verrez aussi un point de contrôle humain, une panne… et la décision d'arrêt prise par l'agent lui-même.
🧰 Outils :
chercher_vols · consulter_agenda · reserver_vol (irréversible !) · envoyer_confirmation
Le journal d'exécution apparaîtra ici, étape par étape…
🗒️ Bloc-notes de l'agent (mémoire de travail)
- Vide — l'exécution n'a pas commencé.
💡 Trois choses à remarquer
1️⃣ Les compteurs en haut : itérations max et plafond budgétaire — deux garde-fous qui empêchent une boucle de tourner à l'infini.
2️⃣ Le bloc-notes (scratchpad) qui s'enrichit : c'est la mémoire de travail — l'historique relu à chaque itération. Elle est effacée à la fin de l'exécution.
3️⃣ La fin : personne n'arrête TripDesk — il évalue lui-même que l'objectif est atteint. C'est LA différence avec un chatbot.
Faut-il vraiment un agent ?
Les agents sont puissants… et coûteux : chaque itération = un appel au modèle = coût + latence + risque. Répondez aux questions pour trouver l'architecture la plus simple qui suffit. Règle d'or : prompt < outil unique < workflow fixe < agent.
L'essentiel de la session
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.
Ce n'est pas un modèle « plus intelligent » : c'est souvent exactement le même modèle qu'un chatbot, placé dans une architecture différente. L'agentivité est une propriété du système.
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 (outils) + du texte |
| Erreur | Réponse fausse | Action ratée → rattrapage possible |
La boucle et ses briques
| Brique | Rôle | Exemple TripDesk |
|---|---|---|
| 🔁 Boucle | Percevoir → réfléchir → agir → observer, en cycle | 5 itérations de la mission à la confirmation |
| 🛠️ Outils | Les « mains » de l'agent = l'étape « agir » (tool calling, Session 5) | chercher_vols, reserver_vol… |
| 🗺️ Planification | Décomposer l'objectif en sous-étapes — plan révisable | Le plan change quand le conflit d'agenda est découvert |
| 🗒️ Mémoire de travail | Historique / bloc-notes relu à chaque itération — effacée à la fin | Les 3 vols trouvés à l'itération 1 restent disponibles à l'itération 4 |
| 🚧 Garde-fous | Itérations max · plafond budgétaire ⚠ · validation humaine des actions irréversibles | Max 15 itérations, 0,50 € ⚠, validation avant reserver_vol |
| 🩹 Récupération d'erreur | Lire l'erreur → adapter → réessayer différemment | « Vol complet » → choisir l'alternative, pas le même vol |
⚠ Les montants et nombres d'itérations sont des ordres de grandeur : les prix des API (Application Programming Interface, interface de programmation applicative) et les pratiques évoluent vite.
Quand NE PAS utiliser un agent
Si un seul prompt bien écrit suffit (résumé, traduction), ou si un seul appel d'outil suffit (météo), ou si les étapes sont fixes et connues d'avance (workflow), un agent est de la sur-ingénierie : plus cher, plus lent, plus risqué, pour zéro bénéfice.
« Prenez toujours l'arme la plus simple qui accomplit la mission. »