Boucle de raisonnement, appel d’outils, mémoire, planification, multi-agents, garde-fous, coûts et évaluation : les questions sur les systèmes agentiques.
Cliquez sur une question pour dérouler la réponse attendue.
Un système où le modèle décide lui-même des actions à effectuer, les exécute par des outils, observe le résultat, et recommence jusqu’à ce que l’objectif soit atteint.
Dans un appel classique, vous décidez de tout : ce qui va dans l’invite, combien d’appels, dans quel ordre. Le modèle produit du texte, votre code fait le reste.
Dans un agent, le modèle contrôle le flux. Il choisit quel outil appeler, avec quels arguments, et quand s’arrêter. Votre code exécute ce qu’il demande et lui rend la main.
C’est ce déplacement du contrôle qui définit un agent, et c’est ce qu’il faut savoir énoncer en une phrase.
À quoi s’ajoutent, dans les systèmes réels, une mémoire et des garde-fous.
La capacité de traiter des tâches dont on ne connaît pas les étapes à l’avance. « Trouve pourquoi cette facture est en erreur » peut demander de consulter la commande, puis le contrat, puis l’historique de paiement — un enchaînement qui dépend de ce qu’on découvre en chemin. Aucun graphe écrit à l’avance ne couvre tous les cas.
Il faut savoir le dire, sinon la réponse sonne comme une brochure. On échange la prévisibilité contre la souplesse. Un agent qui décide seul peut décider mal, boucler, appeler dix outils là où deux suffisaient, ou dériver de l’objectif. Le coût devient variable, la latence imprévisible, le débogage plus difficile.
C’est pourquoi la bonne question en conception n’est jamais « comment fais-je un agent » mais « cette tâche a-t-elle besoin d’un agent, ou un enchaînement déterministe suffit-il ».
Le modèle décide d’une action, votre code l’exécute et renvoie le résultat dans l’historique, et l’on recommence. Toute l’ingénierie est dans les conditions d’arrêt.
Lire la réponse détailléeLe modèle ne fait rien lui-même : il produit un nom de fonction et des arguments, votre code les exécute et lui renvoie le résultat. Cette séparation est ce qui rend le contrôle possible.
Lire la réponse détailléeLa description d’un outil est l’interface utilisateur du modèle. C’est la seule chose sur laquelle il s’appuie pour choisir, et la première cause d’un agent qui se trompe d’outil.
Quand utiliser cet outil, et quand ne pas l’utiliser. La seconde moitié est celle qu’on oublie. « Utiliser pour rechercher un client par son nom. Ne pas utiliser si l’on connaît déjà l’identifiant : préférer alors l’outil de lecture directe. »
Ce qu’il retourne, y compris la forme du résultat et le comportement quand il n’y a rien. Un modèle qui ne sait pas qu’une recherche peut renvoyer une liste vide interprétera ce vide comme une panne.
Les arguments décrits un par un, avec leur format exact et un exemple. Une date doit dire « format ISO 8601, par exemple 2026-03-14 », pas « la date ».
Les effets de bord, explicitement. Un outil qui écrit, envoie ou supprime doit le dire dans sa première phrase.
chercher_client et obtenir_client seront confondus. Nommer selon l’action et le critère : chercher_client_par_nom, lire_client_par_id.Écrivez la description comme pour un nouveau collègue compétent mais sans contexte : il sait programmer, il ne connaît pas votre domaine, et il ne peut pas vous poser de question. Tout ce qu’il ne peut pas deviner doit être écrit.
Pas au jugé. On lit les traces des tours où l’agent s’est trompé d’outil, et on corrige la description qui a permis la confusion. C’est un travail itératif, comparable au réglage d’une invite, et il donne des gains rapides. Un agent qui échoue souvent a presque toujours un problème de description avant d’avoir un problème de modèle.
Si vous connaissez les étapes à l’avance, écrivez-les : c’est moins cher, plus rapide et testable. L’agent ne se justifie que quand le chemin dépend de ce qu’on découvre en route.
Lire la réponse détailléeIl faut distinguer l’historique du tour en cours, ce qu’on retient entre deux sessions, et ce qu’on va chercher à la demande. Les trois ont des durées de vie et des coûts différents.
Lire la réponse détailléeIl y a deux écoles, et savoir les opposer est ce qu’on attend de la question.
Le modèle produit un plan complet avant d’agir : la liste des étapes, leurs dépendances, le résultat attendu de chacune. L’exécution suit ce plan.
Avantages : le plan est inspectable — on peut le montrer à un humain avant d’exécuter, ce qui est décisif sur des actions coûteuses. Les étapes indépendantes se parallélisent. Et l’on borne le coût dès le départ.
Faiblesse : le plan est écrit avec les informations du début. Si l’étape 2 révèle que l’hypothèse de départ était fausse, les étapes 3 à 8 sont caduques.
Le modèle décide d’une action à la fois, en fonction de ce qu’il vient d’observer. C’est le schéma raisonner-agir.
Avantages : adaptation naturelle aux surprises, aucun plan à maintenir.
Faiblesses : aucune vision d’ensemble, tendance à la myopie — l’agent poursuit une piste locale sans reconsidérer sa direction — et aucun moyen de parallélisation.
La combinaison. Un plan initial grossier, une exécution pas à pas, et une replanification quand une observation contredit le plan. Le plan sert de cap, pas de rail.
Deux détails d’implémentation qui font la différence :
Les modèles actuels planifient correctement sur des horizons courts — cinq à dix étapes — et se dégradent nettement au-delà, parce que les erreurs se composent. Sur une tâche longue, la bonne architecture n’est pas un meilleur planificateur mais un découpage en sous-tâches vérifiables, chacune validée avant de passer à la suivante.
Rarement, et pour une raison précise : isoler des contextes ou paralléliser des sous-tâches indépendantes. Multiplier les agents pour imiter une organisation humaine ajoute surtout des pannes.
Lire la réponse détailléeOn lit la trace pour voir ce que l’agent croit avoir appris à chaque tour. Une boucle vient presque toujours d’une observation qui ne fait pas avancer : outil muet, erreur illisible, ou but flou.
Lire la réponse détailléeOn suppose que l’agent se trompera ou sera détourné, et on limite ce qu’il peut faire dans ce cas : moindre privilège, validation hors du modèle, confirmation sur l’irréversible.
Lire la réponse détailléeSur le résultat, principalement, et sur la trajectoire seulement pour comprendre les échecs. C’est la distinction à poser d’emblée.
Deux trajectoires très différentes peuvent être toutes deux correctes. Un agent qui trouve la réponse en trois appels et un autre en sept ont tous deux réussi ; noter la conformité à un chemin attendu punit une bonne solution non prévue.
Ce qu’on mesure donc en premier : l’état final est-il correct ? Le ticket a-t-il été classé dans la bonne file, le remboursement calculé au bon montant, le fichier produit conforme.
L’avantage énorme de l’évaluation d’agent sur celle d’un chatbot : quand l’agent agit sur un système, l’état de ce système est vérifiable mécaniquement. Pas besoin de modèle juge pour savoir si la ligne a été créée en base.
Une fois l’échec constaté, on regarde la trace pour classer la cause : mauvais outil choisi, arguments erronés, observation mal interprétée, boucle, abandon prématuré, dérive de l’objectif. Cette taxonomie des échecs est plus utile qu’un score global, parce qu’elle dit quoi corriger.
Des indicateurs de trajectoire valent d’être suivis : nombre d’appels redondants, appels en erreur, écart entre le nombre de tours utilisés et le minimum nécessaire.
Cinquante à cent cas suffisent, et il faut un environnement rejouable : une base de données de test remise à zéro avant chaque cas, des outils simulés dont les réponses sont figées. Sans cela, deux exécutions ne sont pas comparables et tous les chiffres sont du bruit.
Il faut inclure délibérément les cas hostiles : information manquante, outil en panne, données contradictoires, tentative d’injection dans un document, requête hors périmètre à refuser.
Un agent doit être évalué avec ses garde-fous actifs. Mesurer le taux de réussite d’un agent aux droits complets puis le déployer avec une confirmation humaine sur chaque écriture, c’est mesurer un autre système. Les chiffres ne se transfèrent pas.
Parce que le contexte est relu en entier à chaque tour, et qu’il grossit à chaque tour. Le coût n’est pas linéaire en nombre d’étapes, il est quadratique.
Soit un agent avec une invite système de 1000 jetons, et chaque tour ajoutant 500 jetons d’appel et de résultat.
Le total facturé en entrée sur dix tours est d’environ 32 000 jetons, alors que l’information distincte ne représente que 5500 jetons. On paie six fois la même chose. Faire ce calcul en entretien vaut mieux que n’importe quelle liste de conseils.
À quoi s’ajoute la sortie, plus chère au jeton, et une latence qui suit la même courbe.
Le cache d’invite. Le levier numéro un ici, parce que l’agent réenvoie exactement le même préfixe à chaque tour. Les réductions annoncées sur les jetons mis en cache sont importantes, et la mise en œuvre demande seulement de placer la partie stable — invite système, définitions d’outils — au début et de ne rien y insérer dynamiquement. Une date du jour placée en tête invalide le cache à chaque exécution : c’est une erreur classique et coûteuse.
Tronquer les résultats d’outils. Retourner dix lignes et un compteur plutôt que deux cents. Immédiat, sans perte réelle.
Externaliser le volumineux. Écrire le gros résultat dans un fichier, ne garder qu’un chemin, laisser l’agent le relire s’il en a besoin.
Résumer l’historique ancien au-delà d’un seuil de tours.
Router par difficulté. Un petit modèle pour les tours routiniers, un grand pour les décisions difficiles. Les gains sont substantiels parce que la majorité des tours sont simples.
Réduire les outils exposés au sous-ensemble pertinent pour la tâche.
Baisser le plafond de tours. Beaucoup d’agents fixés à cinquante tours réussissent en cinq ou échouent de toute façon. Le plafond ne sert alors qu’à financer les échecs.
Le coût d’un agent est dominé par la relecture du contexte, pas par le nombre de décisions. Toute optimisation qui réduit la taille du contexte à chaque tour paie plusieurs fois ; toute optimisation qui réduit d’un tour ne paie qu’une fois.
À arrêter de réécrire la même intégration pour chaque assistant. C’est un problème d’écosystème avant d’être un problème technique.
Sans standard, exposer votre base de données à trois assistants différents demande trois adaptateurs, chacun avec son format de déclaration d’outils, son mécanisme d’authentification et sa gestion d’erreurs. Multiplié par le nombre de sources de données, c’est un produit cartésien d’intégrations.
Le protocole de contexte de modèle, adopté largement depuis 2024, inverse cela : un serveur par source de données, un client par assistant, et n’importe quel client parle à n’importe quel serveur. La comparaison qu’on fait souvent est celle d’un connecteur universel remplaçant un câble propriétaire par appareil.
Le client interroge le serveur au démarrage pour découvrir ce qu’il propose. C’est ce qui permet d’ajouter une capacité sans modifier l’assistant.
C’est ici qu’on montre du recul plutôt que de l’enthousiasme.
L’authentification et les droits. Un serveur qui expose une base agit avec quelle identité ? Si c’est un compte de service unique, tous les utilisateurs de l’assistant voient tout. Le protocole ne résout pas l’autorisation à votre place, et c’est la faille la plus fréquente des déploiements rapides.
La confiance dans le serveur. Brancher un serveur tiers, c’est lui donner une place dans le contexte du modèle. Un serveur malveillant peut décrire ses outils de façon à détourner l’agent, ou renvoyer des résultats contenant des instructions. La description d’outil est un vecteur d’injection, et peu de gens y pensent.
Le nombre d’outils exposés. Brancher cinq serveurs, c’est parfois quarante outils dans l’invite système : coût élevé à chaque tour, et sélection dégradée. Il faut filtrer.
Le protocole résout la plomberie — découverte, format, transport — et il le fait bien. Il ne résout ni l’autorisation, ni la confiance, ni la sélection d’outils. Ces trois-là restent votre travail, et ce sont eux qui décident si le déploiement est sûr.
L’entrelacement du raisonnement et de l’action : à chaque tour, le modèle écrit ce qu’il pense avant de décider de l’action, puis observe le résultat. C’est le schéma fondateur des agents, et il faut savoir dire ce qu’il apporte.
Pensée, action, observation, et l’on recommence. La pensée est du texte libre — « je n’ai pas l’identifiant du client, je dois d’abord le chercher par son nom » — suivie d’un appel d’outil, puis du résultat renvoyé.
Deux choses distinctes, et il faut les séparer.
Du calcul. Comme pour le raisonnement par étapes, écrire l’analyse avant de choisir étale le travail sur plusieurs jetons plutôt que de tout comprimer dans une décision immédiate. La qualité du choix d’outil s’améliore mesurablement.
De la lisibilité. La pensée est ce qui rend une trace exploitable. Sans elle, on voit un enchaînement d’appels sans comprendre pourquoi. Avec elle, on repère immédiatement où le raisonnement a déraillé — c’est ce qui fait gagner des heures en débogage.
L’apport symétrique, souvent oublié : l’observation ancre le raisonnement dans la réalité. Un modèle qui raisonne seul dérive vers le plausible ; un modèle qui vérifie par un outil se corrige. C’est le principal remède aux inventions dans un contexte agentique.
À faire relire au modèle sa propre production avant de la livrer. Cela fonctionne, mais pas dans tous les cas, et savoir distinguer les deux est ce qui fait la valeur de la réponse.
Après la première production, on demande au modèle d’évaluer son résultat contre les critères de la tâche, d’identifier les défauts, puis de corriger. On peut répéter, avec un plafond d’itérations.
Quand la critique dispose d’un signal externe. C’est la condition décisive.
Dans tous ces cas, l’autocritique n’est pas de l’introspection, c’est une boucle de rétroaction avec la réalité.
Quand le modèle doit juger seul de la justesse d’un fait qu’il a lui-même produit. Il n’a pas d’accès privilégié à sa propre fiabilité : la même limite qui a produit l’erreur l’empêche de la voir. Les travaux sur le sujet montrent des gains faibles ou nuls sur le raisonnement pur en autocritique isolée, et parfois une dégradation — le modèle « corrige » une réponse juste vers une réponse fausse.
Un candidat qui présente l’autocritique comme un correctif universel se trompe ; celui qui pose la condition du signal externe a compris.
Chaque itération est un appel complet avec un contexte élargi : deux à trois fois le coût et la latence. Sur un produit interactif, c’est rarement acceptable sans découpage ou diffusion progressive.
Une boucle de critique n’est utile que si elle est branchée sur quelque chose de vérifiable. Un test, un schéma, une source, un calcul. Sans cela, on paie deux fois pour de la reformulation.
En renvoyant l’erreur au modèle comme une observation, pas en faisant échouer la boucle. C’est la réponse attendue, et elle exploite une capacité réelle : un agent corrige souvent son appel au tour suivant si l’erreur est lisible.
Toutes les erreurs ne se traitent pas de la même façon.
Les erreurs que le modèle peut corriger — mauvais format d’argument, identifiant inexistant, paramètre manquant, requête trop large. On les renvoie avec un message explicite, et le modèle se reprend.
Les erreurs qu’il ne peut pas corriger — service indisponible, délai dépassé, quota épuisé, panne d’authentification. Les renvoyer au modèle est inutile et coûteux : il va réessayer, échouer encore, et consommer des tours. Celles-ci se traitent dans votre code : reprise avec attente croissante, disjoncteur, puis abandon avec un message clair pour l’agent — « ce service est indisponible, ne le réessaie pas ».
Faire cette distinction est ce qui sépare un candidat qui a exploité un agent d’un candidat qui en a écrit un.
Le succès partiel. L’outil a écrit trois lignes sur cinq avant d’échouer. Renvoyer simplement « erreur » laisse l’agent dans l’ignorance de l’état réel, et il risque de tout refaire. L’outil doit rapporter ce qui a été accompli et ce qui reste — c’est le message le plus difficile à concevoir, et celui qui évite les dégâts les plus sérieux.
Deux problèmes, l’un mesurable en argent, l’autre en qualité.
Les définitions d’outils vivent dans l’invite système. Trente outils avec leurs descriptions et leurs schémas représentent facilement plusieurs milliers de jetons, payés à chaque tour de la boucle. Sur un agent à dix tours, cela devient la part dominante de la facture.
Le cache d’invite en atténue une bonne partie, à condition que la liste soit stable et placée en tête.
Le problème plus sérieux. Plus il y a d’outils, plus la probabilité de choisir le mauvais augmente, et de façon non linéaire : les descriptions se chevauchent, les frontières deviennent floues, et le modèle hésite entre trois candidats plausibles. Des évaluations montrent une chute nette de la justesse du choix à partir de quelques dizaines d’outils.
C’est un problème de discrimination, pas de mémoire. Trente outils bien séparés valent mieux que dix outils dont trois se ressemblent.
Réduire, en fusionnant ou en supprimant. Souvent, dix des trente ne servent jamais. Les traces le disent.
Sélectionner dynamiquement les outils selon la tâche : ne charger que ceux qui sont pertinents, choisis par une recherche sémantique sur leurs descriptions ou par un routeur en amont. C’est la réponse la plus solide sur un catalogue étendu, et elle est de plus en plus courante.
Regrouper par sous-agents. Un sous-agent par domaine, avec cinq outils chacun, exposé à l’agent principal comme un outil unique. Cela résout la sélection et isole le contexte, au prix d’un tour supplémentaire.
Hiérarchiser : un outil de découverte qui liste les capacités d’un domaine, puis un appel ciblé. On paie un tour pour économiser des milliers de jetons de définitions.
Améliorer les descriptions avant de restructurer. Une confusion entre deux outils vient plus souvent d’une description imprécise que du nombre. C’est le correctif le moins coûteux, et il faut le tenter d’abord.
Le branchement de plusieurs serveurs d’outils standardisés : trois serveurs, quarante outils, sans que personne l’ait décidé. Le point à souligner est qu’un catalogue d’outils est une surface à gouverner — on filtre ce qu’on expose, comme on filtre les permissions — et non un buffet où l’abondance serait gratuite.
Avec une trace par exécution, hiérarchisée, contenant assez d’information pour rejouer un incident. C’est la première chose à construire, avant le deuxième outil, et un agent sans trace est un agent qu’on ne pourra pas corriger.
Par exécution : un identifiant, l’objectif reçu, l’identité de l’utilisateur, la version de l’invite et du modèle, l’issue, le coût total, la durée.
Par tour, imbriqué dans l’exécution : le raisonnement produit, l’outil choisi, les arguments, le résultat ou l’erreur, les jetons consommés en entrée et en sortie, la latence.
Le point non négociable : les arguments et les résultats d’outils en clair, expurgés des données sensibles. Sans eux, on voit qu’un agent a échoué sans pouvoir dire pourquoi, et c’est exactement la situation où l’on se retrouve à deviner.
Une trace hiérarchique, où l’exécution est le tronc et chaque tour une branche, avec les sous-agents imbriqués. Le vocabulaire de la traçabilité distribuée s’applique directement, et les conventions ouvertes existantes pour l’IA générative permettent de brancher les outils du marché plutôt que d’écrire une visionneuse maison.
Sur le coût par exécution qui grimpe, sur le taux d’atteinte du plafond de tours, sur l’apparition d’appels à un outil sensible hors du profil habituel, et sur une chute du taux de réussite. Les deux premières précèdent généralement les plaintes.
Les traces contiennent les données que l’agent a manipulées. Elles créent donc une seconde copie, souvent moins protégée, conservée plus longtemps, et visible par toute l’équipe technique. Il faut expurger, restreindre l’accès et fixer une durée de rétention — sinon l’observabilité devient le maillon faible de la conformité.
On ne le rend pas déterministe au sens strict. On le rend reproductible pour les tests et prévisible en production, ce qui n’est pas la même chose, et c’est la nuance attendue.
Même à température 0, un même appel peut donner un résultat différent : le regroupement des requêtes côté fournisseur, la précision réduite et l’exécution sur des matériels distincts introduisent une variation. À cela s’ajoute, dans un agent, tout ce qui bouge autour — l’heure, l’état de la base, les réponses des services externes.
Promettre du déterminisme est donc une erreur ; savoir ce qu’on peut garantir à la place est la bonne réponse.
Avec cela, une trajectoire redevient comparable d’une exécution à l’autre, et une régression est détectable.
Puisque la trajectoire variera, on borne ses conséquences :
On évalue le résultat — l’état final est-il correct — et non la conformité à une trajectoire de référence. Deux chemins différents peuvent être tous deux justes, et un test qui exige un chemin exact devient un test qui casse à chaque amélioration.
Sur les tests de non-régression, la pratique utile est d’exécuter chaque cas plusieurs fois et de suivre un taux de réussite plutôt qu’un succès binaire. Un cas qui passe trois fois sur cinq n’est pas un cas qui passe : c’est une information qu’un test unique cache.
Au point où une erreur devient irréversible ou visible de l’extérieur. C’est le critère, et il vaut mieux que n’importe quelle liste.
L’approbation avant action. L’agent s’arrête, présente ce qu’il va faire, attend. Le plus sûr, le plus coûteux en fluidité.
La validation du plan, pas des étapes. Un humain approuve le plan complet, l’exécution se déroule ensuite sans interruption. Bon compromis sur les tâches longues.
L’action différée et annulable. L’agent agit, l’effet est retardé de quelques minutes, l’humain peut annuler. Excellent rapport sûreté-fluidité, et c’est la forme que je recommande le plus souvent : on garde le débit, on garde le filet.
La revue par échantillon. L’agent agit librement, un pourcentage des actions est revu a posteriori. Convient quand le coût unitaire d’une erreur est faible mais le volume élevé.
Le brouillon. L’agent prépare, l’humain envoie. La forme la plus naturelle pour tout ce qui est rédaction.
Le point que peu de candidats abordent, et le plus important en pratique.
La fatigue d’approbation. Un humain à qui l’on demande deux cents confirmations par jour appuie sur « oui » sans lire. L’approbation devient un rituel, et sa valeur de protection tombe à zéro. Il faut donc calibrer le volume : si le taux d’approbation dépasse largement les capacités d’attention réelles, le garde-fou est décoratif.
Une information insuffisante pour décider. « L’agent souhaite envoyer un courriel. Approuver ? » ne permet pas de juger. Il faut montrer le contenu exact, le destinataire, et le motif invoqué par l’agent.
Aucun moyen de corriger. Un choix binaire entre approuver et rejeter perd le travail accompli. Permettre de modifier avant d’approuver change tout, et améliore la trace pour l’amélioration future.
Le taux d’approbation — s’il est proche de 100 %, la validation ne filtre rien et le seuil peut être relevé — et le taux d’intervention, qui dit ce qui est réellement automatisé. Ces deux chiffres pilotent le desserrage progressif des garde-fous à mesure que la confiance se construit, et c’est ainsi qu’on déploie un agent : sévère au début, relâché sur preuves.
Une propriété que la plupart des domaines n’ont pas : le retour est objectif et gratuit. Le code compile ou non, les tests passent ou non, le message d’erreur dit quoi corriger. C’est la raison profonde pour laquelle les agents de codage marchent mieux que les agents de service client, et c’est la réponse à donner en premier.
La boucle d’un agent de codage est branchée sur un oracle. Il écrit, exécute, lit l’erreur, corrige, réexécute. Chaque itération est ancrée dans un fait vérifiable, et non dans son propre jugement. C’est ce qui rend l’autocorrection efficace ici, alors qu’elle est faible ailleurs.
La qualité des tests existants. Un dépôt bien testé donne un agent efficace ; un dépôt sans tests donne un agent qui écrit du code plausible et non validé. Le facteur limitant est souvent le projet, pas le modèle — et le dire montre de l’expérience.
La navigation avant la modification. Un agent qui lit trois fichiers pertinents avant d’écrire produit un code cohérent avec les conventions locales. Un agent qui écrit immédiatement produit du code générique qui ne s’intègre pas.
Un périmètre restreint. Une tâche localisée — corriger un bogue précis, ajouter un test, renommer partout — réussit bien. Une refonte transversale échoue, parce que les erreurs se composent sur une longue trajectoire.
Un contexte de projet écrit. Un fichier de consignes décrivant les conventions, les commandes de test et l’architecture améliore nettement le résultat, et il se rédige une fois.
Bac à sable pour l’exécution, travail sur une branche jamais sur la principale, revue humaine du diff avant fusion, et interdiction d’accès aux secrets du dépôt. L’agent produit une proposition de modification ; la revue reste humaine, exactement comme pour un contributeur nouveau et rapide.
En traitant le contexte comme une ressource à gérer activement, pas comme un journal où l’on empile. La saturation est un symptôme de conception, pas une fatalité de la tâche.
Par ordre de volume, dans les agents que j’ai vus déraper :
Tronquer les résultats d’outils à la source. Un outil doit renvoyer ce qui sert, pas ce qu’il possède : dix lignes plus un compteur, les champs utiles plutôt que l’objet entier. C’est un changement dans l’outil, pas dans l’agent, et c’est le meilleur rapport effort-gain.
Externaliser les gros résultats. Écrire dans un fichier ou un stockage, ne garder qu’une référence, et exposer un outil de lecture ciblée. L’agent relit la partie dont il a besoin, quand il en a besoin. Sur les tâches longues, c’est la technique qui change tout.
Compacter l’historique. Au-delà d’un seuil, résumer les tours anciens en conservant l’objectif, les acquis et les échecs à ne pas répéter, puis repartir avec ce résumé et les derniers tours en clair. Le détail qui compte : le résumé doit préserver ce qui a déjà été essayé, sinon l’agent refait ses erreurs.
Isoler dans un sous-agent. Une exploration coûteuse est déléguée : le sous-agent brûle cinquante mille jetons et rend dix lignes. L’agent principal ne paie que le résumé. C’est l’usage le plus solide du multi-agents.
Restreindre les outils exposés au sous-ensemble utile à la tâche.
Maintenir un état structuré hors contexte — une liste de tâches, un fichier de notes — que l’agent lit et met à jour par des outils. Le contexte cesse d’être la mémoire du système.
Tronquer par le début, silencieusement. C’est le comportement par défaut de beaucoup de cadriciels, et il fait sauter l’invite système et l’objectif : l’agent perd ses consignes sans que rien ne l’indique, et son comportement devient inexplicable. S’il faut couper, on coupe au milieu en préservant les extrémités, et on le journalise.
Se contenter d’un modèle à très grande fenêtre. Cela repousse le mur sans le supprimer, et cela coûte cher à chaque tour. Surtout, le milieu d’un long contexte est mal exploité : un agent avec deux cent mille jetons d’historique n’utilise pas efficacement les cent mille du centre.
Ce qui peut être relu à la demande n’a pas à séjourner dans le contexte. Le contexte sert à ce dont le modèle a besoin maintenant pour décider du prochain pas — le reste appartient à un stockage, accessible par un outil.
Qui décide. C’est toute la différence, et il faut la formuler ainsi.
Le flux est fixe et écrit par vous : on reçoit la question, on cherche dans l’index, on met les passages trouvés dans l’invite, on génère la réponse. Une recherche, un appel au modèle, terminé.
Le modèle ne choisit rien. Il lit ce qu’on lui donne et rédige.
Le modèle décide s’il faut chercher, quoi chercher, s’il faut chercher une seconde fois avec d’autres termes, s’il faut consulter une autre source, et quand il en sait assez pour répondre.
Le RAG agentique : on expose la recherche comme un outil, et on laisse le modèle l’appeler autant de fois qu’il veut.
Ce que cela apporte concrètement, et c’est ce qui fait l’intérêt de la question :
Latence et coût multipliés par le nombre de tours, et une variabilité qui complique les engagements de service. Sur des questions simples et bien couvertes par l’index, le RAG à une passe est meilleur : plus rapide, moins cher, prévisible.
Une passe si les questions sont homogènes et l’index bien aligné sur elles. Agentique si les questions sont composées, si plusieurs sources existent, ou si la reformulation est souvent nécessaire.
Et une bonne réponse ajoute qu’on peut router : un classifieur en entrée envoie les questions simples vers le chemin direct et les complexes vers l’agent. On paie l’autonomie seulement là où elle sert.
En persistant l’état à chaque tour et en rendant les actions idempotentes. Un agent qui vit uniquement en mémoire ne survit pas à un redéploiement, et sur une tâche longue c’est une garantie d’incidents.
Si l’agent est interrompu après avoir envoyé un courriel mais avant d’avoir enregistré ce fait, la reprise le renvoie. Sur un paiement, c’est un incident sérieux.
Les remèdes, dans l’ordre :
Journaliser l’intention avant l’exécution. On écrit « je vais appeler cet outil avec ces arguments » en base, on exécute, on écrit le résultat. À la reprise, une intention sans résultat signale une action de statut inconnu, à traiter explicitement — vérifier son effet réel, ou demander à un humain.
Rendre les écritures idempotentes. Une clé d’idempotence par action, générée par votre code et non par le modèle, dérivée de l’identité de l’action. Rejouer l’appel ne produit pas un second effet. C’est la protection la plus solide, et celle que je mets en place d’abord.
Vérifier avant d’agir quand l’idempotence n’est pas disponible : l’écriture existe-t-elle déjà.
Pas au tour exact, mais au début du tour interrompu, avec l’historique reconstitué. Le modèle refait sa décision à partir d’un état connu, ce qui est plus sûr que de tenter de reprendre au milieu d’un raisonnement.
Sur une interruption longue, il faut se poser la question de la fraîcheur : l’état du monde a peut-être changé. Une reprise après plusieurs heures devrait revalider ses hypothèses plutôt que continuer aveuglément — et le mentionner distingue.
Un agent long ne s’exécute pas dans une requête HTTP. On le fait tourner comme un travail durable : une file d’attente, un état en base, un tour par message, avec reprise automatique en cas de panne. Les moteurs de flux de travail durables se prêtent bien à cet usage, parce que la persistance et la reprise sont précisément leur métier.
Ce déplacement — d’une boucle synchrone vers un travail persistant — est le vrai changement d’architecture quand un agent passe du prototype à la production, et c’est ce que la question cherche à faire dire.
Principalement à isoler un contexte. C’est l’usage le plus solide du multi-agents, et celui qu’il faut citer avant la spécialisation des rôles.
L’agent principal expose un outil du type « déléguer une recherche ». Quand il l’appelle, on lance un agent séparé, avec son propre contexte vierge, ses propres outils et ses propres plafonds. Ce sous-agent travaille, produit un résultat condensé, et disparaît.
L’agent principal ne voit que ce résultat. Les trente tours d’exploration, les résultats d’outils volumineux, les pistes abandonnées : rien de tout cela n’entre dans son contexte.
Une exploration peut consommer cinquante mille jetons pour aboutir à dix lignes utiles. Sans isolation, ces cinquante mille jetons restent dans l’historique et sont repayés à chaque tour suivant. Avec isolation, on paie l’exploration une fois et on ne transporte que sa conclusion.
Le gain secondaire est la clarté : l’agent principal garde un contexte lisible, et ses décisions s’améliorent parce qu’il n’a pas à démêler quarante observations intermédiaires.
Le format du rendu. Un sous-agent qui renvoie tout son travail annule le bénéfice. Il faut spécifier ce qu’il doit rapporter — la réponse, les sources, ce qu’il n’a pas trouvé — et limiter la longueur. Sans cette contrainte, on a payé la complexité du multi-agents sans obtenir l’économie de contexte qui la justifiait.
Les critères ne sont pas ceux d’un chatbot. Ce qui compte ici est la fiabilité de l’appel d’outil et la tenue sur une longue trajectoire, pas l’élégance de la rédaction.
La justesse de l’appel d’outil. Choisir le bon outil, produire des arguments valides, ne pas inventer de paramètre. Un modèle très éloquent qui se trompe d’outil une fois sur dix est inutilisable dans une boucle : à dix tours, la trajectoire échoue plus d’une fois sur deux.
L’appel parallèle. La capacité à demander plusieurs actions indépendantes en un tour. Cela divise le nombre de tours, donc le coût et la latence.
La tenue sur un long contexte. Un agent accumule ; un modèle qui perd le fil au-delà de quelques dizaines de milliers de jetons dérive et refait ce qu’il a déjà fait.
Le respect des consignes. Un agent est piloté par une invite système souvent longue et contraignante. Un modèle qui l’ignore partiellement contourne vos garde-fous logiques.
Le coût par tour, multiplié par le nombre de tours et par la relecture du contexte. Un modèle deux fois plus cher au jeton peut être moins cher au total s’il résout en trois tours ce que l’autre fait en dix — et ce calcul est celui qu’on attend en entretien.
La latence. Elle se multiplie par le nombre de tours. Un modèle lent rend l’agent inutilisable en interactif même s’il est excellent.
La bonne réponse est rarement un modèle unique.
Le routage se fait sur un critère simple — complexité de la tâche, nombre d’outils pertinents, échecs déjà rencontrés — et il produit des économies substantielles.
Un jeu de trajectoires de test et une abstraction dans le code qui rend le modèle remplaçable. Avec cela, on essaie trois modèles en une journée et on décide sur des chiffres. Sans cela, on choisit par réputation.
Sur l’état final, avec des outils simulés et un environnement remis à zéro. Tester la conformité à un chemin de référence est l’erreur classique, et elle produit une suite de tests qui casse à chaque amélioration.
Des outils simulés dont les réponses sont figées par cas. Cela supprime la dépendance aux services externes et rend les exécutions comparables.
Un environnement réinitialisé avant chaque cas, depuis un instantané de base de données. Sans cela, l’ordre des tests influence leurs résultats.
Une horloge figée et des identifiants déterministes.
Une version de modèle épinglée, sans quoi la suite change de sens sans qu’on ait touché au code.
L’égalité à une trajectoire de référence. Deux chemins différents peuvent être tous deux corrects, et figer un chemin transforme chaque amélioration du modèle en échec de test.
En revanche, on peut asserter des propriétés de trajectoire : l’outil de recherche a été appelé au moins une fois avant l’outil d’écriture, la validation a précédé la soumission. Ce sont des invariants, pas des chemins.
C’est ici qu’un candidat expérimenté se distingue, parce que le chemin heureux est facile.
Un agent n’est pas déterministe. Un cas exécuté une fois ne prouve rien.
La pratique utile est d’exécuter chaque cas trois à cinq fois et de suivre un taux de réussite plutôt qu’un succès binaire. Un cas qui passe trois fois sur cinq est une information précieuse, qu’un test unique cache complètement — et c’est le point qui montre qu’on a réellement maintenu une suite de tests d’agent.
Une suite complète d’agent est trop lente et trop coûteuse pour chaque validation de code. Le compromis courant : un sous-ensemble rapide avec outils simulés à chaque changement, la suite complète à chaque nuit, et une comparaison sur trafic réel avant toute bascule de version.
Un agent met des dizaines de secondes, parfois des minutes. On ne peut pas toujours le rendre rapide ; on peut rendre l’attente lisible, et c’est une question de produit autant que de technique.
Montrer ce qui se passe, tour par tour. « Je cherche le dossier client », « je consulte l’historique de facturation ». Cela change complètement la perception : l’utilisateur voit un travail en cours et non un système bloqué. C’est le levier numéro un, et il est presque gratuit puisque l’information existe déjà dans la boucle.
Diffuser la réponse finale dès les premiers jetons.
Livrer des résultats partiels. Un agent qui analyse cinq documents peut afficher le premier résultat sans attendre les quatre autres.
Annoncer un ordre de grandeur au démarrage — « environ trente secondes » — plutôt qu’un indicateur qui tourne indéfiniment.
Permettre d’interrompre. Un bouton d’arrêt, avec un état propre. Savoir qu’on peut arrêter rend l’attente moins pesante, même si personne ne s’en sert.
Au-delà d’une minute ou deux, changer de modèle d’interaction plutôt que d’essayer d’occuper l’utilisateur :
Une partie de la latence est évitable, et il faut le dire pour ne pas répondre uniquement en habillage :
La latence perçue compte plus que la latence réelle, et elle se travaille avec l’information dont vous disposez déjà. Un agent de quarante secondes qui raconte ce qu’il fait passe mieux qu’un agent de vingt secondes muet.
Dans la majorité des cas où l’on en construit un. C’est la question de maturité du sujet, et la meilleure réponse commence par refuser l’agent.
Quand vous connaissez les étapes. Si le chemin est le même à chaque fois, écrivez-le. Un enchaînement déterministe est moins cher, plus rapide, testable, et son coût est borné. Beaucoup de ce qu’on présente comme des agents sont des enchaînements avec une boucle inutile.
Quand le coût d’une erreur est élevé et la vérification impossible. Un agent qui agit sur des transactions financières sans possibilité de contrôle mécanique est un risque mal placé.
Quand la latence doit être basse. Un agent, c’est plusieurs appels séquentiels. Sur un chemin qui doit répondre en une seconde, c’est exclu.
Quand il n’y a pas de retour objectif. Les agents marchent bien là où l’environnement corrige — code compilé, tests exécutés, schéma validé. Sur une tâche dont on ne peut pas vérifier le résultat automatiquement, l’autonomie ajoute de la variance sans mécanisme de rattrapage.
Quand le volume rend le coût prohibitif. Un agent à dix tours sur un million de requêtes quotidiennes est un budget que peu de cas d’usage justifient.
Quand vous n’avez pas d’observabilité. Déployer un agent sans traces, c’est s’engager à ne pas pouvoir le corriger. C’est un préalable, pas une amélioration ultérieure.
Quand une requête ou une règle suffit. « Combien de clients ont résilié en mars » est du SQL. Router un ticket selon trois règles écrites est un if.
Pour équilibrer : quand le chemin dépend de ce qu’on découvre en route, quand la variété des cas rend impossible l’écriture de toutes les branches, et quand un retour vérifiable existe pour ancrer les itérations. Recherche exploratoire, diagnostic, tâches sur du code, traitement de demandes formulées librement.
Commencer par l’enchaînement le plus simple qui pourrait marcher. Mesurer où il échoue. N’introduire de l’autonomie qu’à l’endroit précis où l’échec vient d’un chemin imprévisible. Et à chaque ajout d’autonomie, ajouter le garde-fou et la mesure correspondants.
L’inverse — partir d’un agent libre puis resserrer — conduit à un système dont personne ne sait quelle part de l’autonomie était nécessaire, et qu’on n’ose plus simplifier.
Un agent est un choix d’architecture coûteux qu’on justifie par une imprévisibilité réelle du chemin. Ce n’est pas un niveau supérieur d’ingénierie qu’on atteindrait en progressant : c’est un compromis, et le refuser quand il n’est pas nécessaire est le signe qu’on l’a compris.