Quiz d'entraînement : les trois quarts des bonnes réponses pour le réussir.
Les agents : un modèle qui agit
Seul, un modèle de langage écrit du texte. Un agent, c'est ce même modèle placé dans une boucle, avec des outils : il choisit une action (chercher, calculer, lire un fichier, envoyer un message), un programme l'exécute, le modèle lit le résultat et décide de la suite, jusqu'à avoir fini. Cette idée, alterner raisonnement et action, a été formalisée en 2022 sous le nom de ReAct.
C'est ce qui fait tourner les assistants qui codent, réservent ou trient des messages. C'est aussi là que les ennuis changent d'échelle : un agent coûte plus cher qu'un appel, se trompe plus souvent, et peut agir à ta place. Ce cours montre comment marche la boucle, quand elle vaut la peine, pourquoi elle échoue plus qu'on ne le croit, et comment elle se souvient.
Pour qui : tu sais ce qu'est un modèle de langage, sans plus. Pas besoin d'avoir codé.
Le fil du cours : l'assistant en ligne d'une médiathèque municipale, qui répond aux lecteurs à partir du règlement (amendes, durées de prêt, réservations). C'est le même règlement que dans le cours sur les architectures de RAG : les recherches des figures tournent vraiment sur lui, avec le même moteur de recherche jouet, et seules les décisions de l'agent sont écrites d'avance.
La boucle
Un agent répète trois gestes. Il observe : il lit la conversation, y compris les résultats précédents. Il décide : répondre, ou demander un outil. Puis il agit : le programme exécute l'outil et ajoute le résultat à la conversation. La boucle s'arrête quand le modèle répond au lieu de demander un outil, ou quand le programme la coupe.
Un lecteur demande quelle amende il paiera pour un DVD rendu avec douze jours de retard. L'agent dispose de deux outils : une recherche dans le règlement et une calculatrice. Avance pas à pas : qui exécute la recherche, le modèle ou le programme ? Et que coûte chaque tour ?
Tout commence par une question. Le programme l'envoie au modèle avec la consigne et la description des outils : c'est le premier appel.
- Renvoyé à chaque appel
Tu es l'assistant de la médiathèque. Réponds à partir du règlement, que tu consultes avec tes outils, et cite l'article utilisé. {"name": "chercher_reglement", "description": "Renvoie l'article du règlement le plus proche de la requête.", "parameters": {"requete": "texte"}} {"name": "calculer", "description": "Évalue une expression : + - * / ( ).", "parameters": {"expression": "texte"}} - Utilisateur
Quelle amende pour un DVD rendu avec 12 jours de retard ?
L'assistant du règlement fictif d'une médiathèque, avec deux outils. Ses décisions sont écrites à l'avance ; la recherche (BM25) et la calculatrice tournent vraiment. Tokens : environ 1,3 par mot.
Le modèle n'exécute jamais rien : il écrit une demande, le programme lance l'outil, et c'est donc le programme qui décide de ce qui est permis. La première recherche, « amende retard DVD », ramène l'article des livres, parce que le règlement parle de pénalité pour les DVD ; l'agent le voit et reformule, ce qu'un enchaînement fixe ne saurait pas faire. Regarde aussi les tuiles : le modèle ne garde rien entre deux appels, si bien que chaque tour renvoie la consigne, les outils et tout l'historique. La facture grossit plus vite que le nombre de tours, et un budget d'appels trop bas coupe la boucle avant la réponse. Le détail d'un outil, sa description et ses arguments, est le sujet du cours Les outils et l'appel de fonction.
Puisque le programme exécute, c'est lui qui tient les garde-fous. Avant de lancer un outil, il peut vérifier que les arguments ont la bonne forme, refuser un outil que cette tâche n'a pas le droit d'utiliser, ou demander une confirmation. Après, il décide de ce qu'il renvoie au modèle : le résultat entier, un extrait, ou un message d'erreur clair qui dit quoi corriger. Un agent n'est jamais plus sûr que le programme qui l'entoure.
Workflow ou agent ?
Anthropic, dans un guide publié en décembre 2024, distingue deux familles. Dans un workflow, le code fixe le chemin : appeler le modèle pour extraire, puis pour vérifier, puis pour rédiger. Dans un agent, le modèle dirige lui-même ses étapes et ses outils. Les workflows les plus courants ont des noms :
- l'enchaînement : chaque appel traite la sortie du précédent ;
- l'aiguillage : un premier appel classe la demande et l'envoie au bon traitement ;
- la parallélisation : plusieurs appels en même temps, dont on combine les résultats ;
- le chef d'orchestre : un modèle découpe la tâche, la confie à d'autres appels et assemble leurs réponses ;
- le rédacteur et le correcteur : un appel produit, un autre évalue et renvoie ses remarques, en boucle.
L'agent se justifie quand on ne peut pas prévoir le nombre d'étapes. La figure présente six demandes faites à l'assistant de la médiathèque. Pour chacune, quel patron choisirais-tu ?
Vérifier la carte, vérifier que personne n'a réservé le document, prolonger, confirmer. Toujours ces quatre étapes, dans cet ordre. Quel patron convient à cette demande ?
Étape 1 sur 6
Prolonger un prêt
Six demandes faites à l'assistant d'une médiathèque. Patrons d'après Anthropic, « Building effective agents » (19 décembre 2024), consulté le 14 octobre 2026.
Cinq demandes sur six se programment : leurs étapes sont connues, on peut les écrire, les tester une par une et prévoir leur coût. Seule la dernière, « tout ce que vous avez sur l'histoire du vélo à Paris », a un chemin imprévisible : on ne sait pas combien de recherches il faudra, ni lesquelles. Remarque aussi que plusieurs patrons se ressemblent. Le chef d'orchestre découpe une tâche qu'il ne connaît pas d'avance, alors que la parallélisation lance des morceaux connus. Le choix tient à une question : qui décide de la suite, le code ou le modèle ?
Quand ne pas faire d'agent
Le conseil d'Anthropic tient en une phrase : chercher la solution la plus simple, et n'ajouter de la complexité que quand c'est nécessaire, ce qui peut vouloir dire ne pas construire d'agent du tout. Un agent demande une forme de confiance dans ses décisions, des tests poussés dans un environnement isolé, et des garde-fous. Trois principes guident sa construction : rester simple, rendre ses étapes visibles, et soigner la description de ses outils autant que leur code.
Voici la même question posée deux fois à la médiathèque. À gauche, un workflow : le code cherche une fois, puis un seul appel au modèle rédige la réponse. À droite, un agent qui cherche, juge et reformule. Change de question : quand l'agent vaut-il son prix ?
« Combien de temps une réservation est-elle gardée ? »
Workflow· le code cherche une fois
Agent· cherche, juge, reformule
Les deux trouvent l'article qu'il faut. L'agent fait le même travail en 2 appels au lieu d'un, pour environ 3 fois plus de tokens : pour une demande prévisible, le workflow suffit.
Barres : un appel au modèle chacune, longues comme les tokens reçus (même échelle partout). Ronds : les articles nécessaires, pleins s'ils ont été trouvés. Recherches calculées (BM25 sur le règlement de la médiathèque) ; les reformulations de l'agent sont écrites d'avance. Tokens : environ 1,3 par mot.
Sur la question simple, les deux trouvent l'article qu'il faut : l'agent fait le même travail avec un appel de plus et environ trois fois plus de tokens, parce qu'il renvoie la consigne, les outils et l'historique à chaque appel. Sur la question ouverte, la recherche unique du workflow ne ramène qu'un des quatre articles utiles, et la réponse sera incomplète ; l'agent reformule deux fois et les trouve tous, pour environ sept fois le coût. Ni l'un ni l'autre n'est meilleur dans l'absolu : un workflow quand les étapes sont connues, un agent quand elles ne le sont pas.
Les tokens ne sont qu'une partie du prix. Un agent fait aussi attendre : chaque appel s'ajoute au précédent, et le lecteur patiente pendant que l'agent cherche. Il est plus dur à tester : son chemin change d'une fois sur l'autre, si bien qu'un test qui passe aujourd'hui peut casser demain sans que le code ait bougé. Et il est plus dur à expliquer : pour comprendre une mauvaise réponse, il faut relire toute la trajectoire, pas seulement la dernière étape. Un workflow, lui, se teste étape par étape, comme n'importe quel programme.
La fiabilité se multiplie
Une tâche de plusieurs étapes ne réussit que si toutes ses étapes réussissent. Les réussites se multiplient, et c'est le calcul le plus important de ce cours. Avant de le voir, parie.
Une tâche de dix étapes, chacune réussie à 95 %. Sur 100 essais, combien réussissent entièrement ?
Réussite de la tâche = pⁿ, en supposant les étapes indépendantes. Calculé.
Dix étapes à 95 % ne réussissent ensemble que six fois sur dix, et vingt étapes à peine plus d'une fois sur trois. Allonge la chaîne et regarde la courbe s'effondrer, puis passe à 99 % : la même tâche tient beaucoup mieux. C'est pourquoi un agent qui enchaîne des dizaines d'actions doit être très fiable à chaque pas, ou s'arrêter souvent pour vérifier. La courbe suppose des étapes indépendantes ; en vrai, une erreur précoce en entraîne souvent d'autres.
Les maths derrière · pourquoi la fiabilité se multiplie
Si chaque étape réussit avec la probabilité p, et que les étapes réussissent ou échouent indépendamment, la tâche entière de n étapes réussit avec :
P(tâche) = pⁿ 0,95¹⁰ ≈ 0,60 0,95²⁰ ≈ 0,36
Réussir la même tâche k fois de suite multiplie encore :
pass^k = P(tâche)ᵏ (0,95¹⁰)⁸ ≈ 0,017
L'indépendance est une simplification : une erreur précoce peut en entraîner d'autres, et une vérification peut en rattraper.
Les bancs d'essai le confirment. En juin 2024, τ-bench a mesuré des agents qui servent des clients simulés en respectant des règles : même les meilleurs réussissaient moins de la moitié des tâches, et moins d'un quart réussissaient la même tâche huit fois de suite dans le domaine du commerce en ligne. Cette mesure, pass^k, est la probabilité de réussir k essais sur k.
L'organisme METR mesure une autre facette : l'horizon de tâche, c'est-à-dire la longueur de tâche, en temps d'un expert humain, qu'un agent réussit une fois sur deux. En mars 2025, il doublait environ tous les sept mois. Au printemps 2026, les meilleurs modèles publics tenaient environ douze heures à 50 % de réussite, mais seulement une heure et demie à 80 % (mesuré entre février et mars 2026, publié en mai). Exiger plus de fiabilité divise la longueur de tâche qu'on peut confier : c'est exactement la courbe de la figure.
Les leviers sont connus : raccourcir la tâche, la découper en sous-tâches qu'on peut vérifier, vérifier après chaque étape (au prix d'appels en plus), et s'arrêter proprement quand quelque chose cloche plutôt que de continuer sur une erreur.
La mémoire
Le modèle n'a pas de mémoire propre : tout passe par ce que le programme lui renvoie à chaque appel. La mémoire de travail est cette conversation, limitée par la fenêtre de contexte. La mémoire longue est faite de notes que l'agent écrit hors de la fenêtre, dans un fichier ou une base, et qu'il relit quand il en a besoin.
La fenêtre se remplit vite, et un contexte trop long dégrade les réponses avant même d'être plein : Anthropic parle de « context rot ». La figure montre la pile de ce que reçoit le modèle. Quand la fenêtre est pleine, qu'est-ce que tu retirerais en premier ?
Tout l'historique est renvoyé, y compris des résultats d'outils déjà exploités. La fenêtre est pleine, et un contexte trop long dégrade déjà les réponses.
La pile de ce que le programme renvoie au modèle, la consigne en bas. Techniques d'après Anthropic, « Effective context engineering for AI agents » (29 septembre 2025), consulté le 14 octobre 2026.
On garde ce qui oriente chaque décision : la consigne, la description des outils, les derniers échanges. On compacte ce qui a déjà servi : les vieux résultats d'outils, longs et périmés, et les anciens échanges, remplacés par un résumé. La mémoire longue se relit à la demande, au lieu d'occuper la fenêtre en permanence. Anthropic décrit trois techniques pour les tâches longues : la compaction, la prise de notes structurée, et des sous-agents qui travaillent dans une fenêtre propre et rendent un résumé. Le sous-agent est une façon de ne pas encombrer la mémoire principale : pour préparer l'exposition sur l'histoire du vélo, l'agent principal peut confier « fouiller les archives » à un sous-agent, qui lit des dizaines de documents et ne rapporte que dix lignes. Le piège à connaître : une mémoire qui grossit sans tri ramène des informations fausses, que l'agent traite comme vraies. Le cours Le contexte d'un agent : règles, mémoire, hooks va plus loin.
Agir sans dégâts
Un agent qui agit peut agir deux fois. S'il relance l'outil « payer l'amende » après une coupure réseau, le lecteur risque de payer deux fois. La parade est connue des services de paiement : un outil idempotent, qu'on peut appeler deux fois sans dégât. Chez Stripe, par exemple, chaque requête porte une clé d'idempotence ; une seconde requête avec la même clé renvoie le résultat de la première au lieu de recommencer, et la clé est gardée au moins vingt-quatre heures.
Trois autres habitudes complètent celle-ci. Un budget : un plafond d'appels, de durée et de coût, pour couper une boucle qui s'emballe. Une confirmation humaine pour les actions irréversibles ou qui sortent du système : payer, envoyer, supprimer. Et l'architecture plutôt que la consigne : un modèle ne sépare pas de façon sûre les données des ordres, donc ce qu'on lui interdit par écrit doit aussi lui être impossible en pratique. Le cours Sécuriser un agent montre comment un contenu piégé peut détourner un agent qui réunit trop de pouvoirs.
Enfin, des traces : garder chaque appel, chaque outil lancé, ses arguments et son résultat. Quand un lecteur se plaint d'une amende fausse, c'est la seule façon de savoir si l'agent a mal cherché, mal lu ou mal calculé, et de corriger la bonne étape.
Ton agent, à régler
Pour finir, une figure libre. Chaque ligne est un essai d'une même tâche, chaque case une étape. Règle la fiabilité par étape et la longueur de la tâche, ajoute ou non une vérification après chaque étape : que faut-il pour que les vingt essais réussissent ?
Sur ce tirage : 13 essais réussis sur 20.
95 % par étape, 10 étapes : la tâche réussit 59,9 % du temps, et 8 fois de suite 1,7 % du temps. Une erreur n'importe où fait échouer le tout.
Chaque ligne est un essai de la tâche, chaque case une étape. Avec vérification, une étape ratée est repérée dans 80 % des cas, puis refaite une fois. 20 essais tirés au hasard. « 8 sur 8 » : réussir la même tâche 8 fois de suite.
Il faut des étapes très fiables, ou des tâches courtes, ou une vérification qui rattrape une partie des erreurs. Chacune de ces solutions a un prix : la vérification double presque le nombre d'appels, et une tâche raccourcie demande à quelqu'un de la découper. Regarde aussi la case « réussir huit fois sur huit » : même quand une tâche réussit souvent, la réussir à chaque fois est une autre affaire. C'est ce qu'on attend d'un agent mis entre les mains de vrais utilisateurs.
Ce qu'on oublie souvent
- Le coût et l'attente. Une boucle de dix appels, c'est dix fois l'attente, et bien plus de dix fois les tokens, puisque chaque appel renvoie l'historique.
- L'agent ne sait pas toujours qu'il a échoué. Il peut répondre avec aplomb à partir du mauvais article, comme la première recherche de la boucle.
- Le modèle change. Une nouvelle version peut modifier la façon dont l'agent choisit ses outils : on relance les évaluations à chaque changement, comme le montre Évaluer un agent et relire son code.
- Un nom ne fait pas un agent. Ce qui compte, c'est qui choisit la suite : beaucoup de produits appelés « agents » sont des workflows, et c'est souvent le bon choix.
- L'agent n'est pas responsable. Ce qu'il fait engage la personne ou l'organisation qui l'a mis en service.
Teste-toi
Une question par notion du cours. La raison s'affiche après chaque réponse : c'est elle qui compte.
Question 1 sur 10
8 bonnes réponses attendues sur 10.
Dans la boucle d'un agent, qui exécute la recherche dans le règlement ?
Une question par notion du cours. Elles reprennent la boucle, les patrons, la fiabilité et la mémoire.
Le vocabulaire en un coup d'œil
| Terme | En une phrase |
|---|---|
| Agent | Un modèle dans une boucle, qui choisit des actions et lit leurs résultats jusqu'à avoir fini. |
| Outil | Une fonction que le programme met à disposition du modèle : chercher, calculer, payer… |
| ReAct | Alterner raisonnement et action : réfléchir, agir, observer, recommencer. |
| Workflow | Un enchaînement d'appels au modèle dont le chemin est fixé par le code. |
| Patron | Une forme de workflow qui revient souvent : enchaînement, aiguillage, parallélisation, chef d'orchestre, rédacteur et correcteur. |
| Budget | Le plafond d'appels, de durée ou de coût au-delà duquel le programme coupe la boucle. |
| pass^k | La probabilité de réussir la même tâche k fois sur k essais : une mesure de fiabilité. |
| Horizon de tâche | La longueur de tâche, en temps humain, qu'un agent réussit une fois sur deux. |
| Mémoire de travail | La conversation renvoyée au modèle à chaque appel, limitée par la fenêtre de contexte. |
| Mémoire longue | Des notes écrites hors de la fenêtre, relues quand il le faut. |
| Compaction | Remplacer les anciens échanges par un résumé quand la fenêtre se remplit. |
| Idempotent | Se dit d'une action qu'on peut répéter sans effet supplémentaire. |
Ce qu'il faut retenir
- Un agent, c'est un modèle dans une boucle, avec des outils : le modèle écrit des demandes, le programme les exécute et décide de ce qui est permis.
- Chaque tour renvoie tout l'historique : un agent coûte bien plus cher qu'un appel.
- Un workflow suffit quand les étapes sont connues ; l'agent se justifie quand on ne peut pas les prévoir.
- La fiabilité se multiplie : 95 % par étape ne donnent que 60 % sur dix étapes, et exiger plus de fiabilité raccourcit les tâches qu'on peut confier.
- La mémoire se gère : on garde ce qui oriente, on compacte ce qui a servi, on relit les notes à la demande.
- Une action qui engage doit être idempotente, plafonnée par un budget, et confirmée par un humain quand elle est irréversible.
Pour aller plus loin
- Yao et al. (2022), ReAct: Synergizing Reasoning and Acting in Language Models : la boucle raisonner-agir (ICLR 2023).
- Anthropic (19 décembre 2024), Building effective agents : workflows et agents, et quand ne pas construire d'agent, consulté le 14 octobre 2026.
- Yao, Shinn, Razavi & Narasimhan (2024), τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains : la mesure pass^k.
- METR (19 mars 2025), Measuring AI Ability to Complete Long Tasks, et (19 mai 2026) Frontier Risk Report, February to March 2026 : l'horizon de tâche à 50 % et à 80 %, consultés le 15 octobre 2026.
- Anthropic (29 septembre 2025), Effective context engineering for AI agents : compaction, notes, sous-agents, consulté le 14 octobre 2026.
- Stripe, Idempotent requests : la clé d'idempotence, consulté le 14 octobre 2026.