La plupart des équipes d’IA qui cherchent à améliorer les performances des agents actionnent les mêmes leviers : des fenêtres de contexte plus grandes, davantage de documents et des prompts plus intelligents. Cet article affirme que cet instinct est totalement erroné. L’ingrédient manquant n’est pas davantage d’informations. C’est le contrôle. Une couche de contrôle bien conçue distingue un agent efficace en démonstration d’un agent efficace en production.
Donner à un agent d’IA une mémoire plus grande, davantage de documents ou une fenêtre de contexte plus longue ne le rend pas plus intelligent, mais seulement plus lent et plus coûteux. Les véritables gains viennent du fait d’apprendre à l’agent à choisir ce dont il a besoin au moment opportun, plutôt que de tout consommer à la fois.
La fiabilité vient de la boucle, pas du modèle. Ce qui distingue un agent impressionnant en démonstration d’un agent fiable en production n’est pas la qualité de l’IA, mais la capacité du système à vérifier son propre travail. Les agents qui planifient, agissent, observent et vérifient à chaque étape détectent leurs propres erreurs au lieu de se tromper avec assurance.
Aujourd’hui, la plupart des agents d’IA sont essentiellement des chatbots assortis d’étapes supplémentaires : ils ne disposent d’aucun mécanisme pour savoir s’ils sont sur la bonne voie, quand s’arrêter ou quand essayer une autre approche. L’ajout d’une véritable couche de contrôle — critères de réussite clairs, état structuré et contrôles de validation — transforme un objet ressemblant à un agent en système réellement fiable.
Qu’avez-vous mangé hier midi ?
Vous n’avez probablement pas repassé tous vos souvenirs jusqu’à atteindre « hier + déjeuner ». Vous avez directement accédé à la partie de votre expérience où se trouvent ces concepts. C’est un modèle mental utile pour créer des agents :
Une fenêtre de contexte gigantesque n’est pas une mémoire.
Un tas de documents récupérés n’est pas synonyme de compréhension.
Un long raisonnement détaillé (« chain-of-thought ») n’est pas synonyme de fiabilité.
Ce sont des ingrédients. Mais ce qui donne à un agent l’allure d’un agent est aussi ce qui évite à votre cerveau de parcourir par force brute toute votre vie : le contrôle.
Une étude récente, Le raisonnement agentique pour les grands modèles de langage, a remarquablement résumé (et nommé) le changement que beaucoup d’entre nous ressentent en développant : du raisonnement au sein du modèle au raisonnement par l’interaction. Cet article ne résume pas cette étude. Il tente de traduire ce changement en conception pratique de systèmes :
Si vous créez des agents comme des chatbots avec outils, vous continuerez d’obtenir les modes d’échec des chatbots, mais avec des erreurs plus coûteuses.
Pendant un temps, notre méthode par défaut pour « rendre le modèle plus intelligent » consistait essentiellement à utiliser de meilleurs prompts, le raisonnement détaillé (« chain-of-thought »), l’auto-cohérence ou des améliorations fondées sur l’échantillonnage, et éventuellement la recherche.
ReAct a marqué un tournant en rendant naturel l’enchaînement « pensée → action → observation ». Mais remarquez la contrainte implicite : une grande partie de cette approche reste une « inférence en une seule étape, mais avec davantage de tokens ». L’étude propose une vision plus précise : le raisonnement agentique privilégie le développement de l’interaction au moment du test, transformant l’inférence en processus itératif où le modèle, la mémoire et l’environnement restent tous dans la boucle.
Si vous avez créé (ou utilisé) des agents impressionnants en démonstration, mais fragiles dans les workflows réels, cet article est pour vous.
Permettez-moi de décrire un modèle que j’ai souvent observé (et dont j’ai moi-même créé plusieurs versions) :
Prendre un bon modèle de chat
Ajouter quelques outils (recherche, requête de base de données, éventuellement exécution de code)
Ajouter le RAG
Ajouter un prompt système « vous êtes un agent autonome »
Envelopper le tout dans une boucle while jusqu’à l’arrêt ou l’expiration du délai
Félicitations, vous avez un objet qui ressemble à un agent. Mais il tend à échouer de manière prévisible :
Gonflement du contexte : chaque observation est ajoutée ; les prompts deviennent des couches archéologiques.
Utilisation erratique des outils : « le mauvais outil, mais avec assurance » devient le mode d’échec par défaut.
Absence de conditions d’arrêt : il continue parce qu’il le peut, et non parce qu’il le devrait.
Absence de discipline d’ancrage : il ne remarque pas qu’il se trompe, sauf si vous l’y forcez.
Mémoire = historique des conversations : cela revient essentiellement à écrire des journaux et à appeler cela de l’apprentissage.
C’est pourquoi les « agents » semblent souvent magiques en démonstration et désordonnés en production. Notre expérience de mise en production de systèmes agentiques le confirme : dès lors que vous n’évaluez plus un modèle, mais un système, les modes d’échec incluent la navigation, la bonne utilisation des outils, l’élagage du contexte et la conception de l’évaluation, et pas seulement « le modèle a-t-il répondu correctement ? »
La question devient donc : quel est l’agent voulu ?
Pour rendre cela moins abstrait, voici un workflow simplifié que la plupart des gens peuvent imaginer : « Réservez-moi un vol de Londres à New York mardi prochain. Arrivée avant 18 h. Prix inférieur à 900 £. Siège côté couloir. »
Une implémentation courante qui « ressemble à un agent » fonctionne ainsi :
Elle récupère immédiatement de nombreux documents sur les compagnies aériennes et les politiques de voyage (même si aucun n’est encore nécessaire).
Elle appelle un outil de recherche, colle une longue liste de résultats dans le prompt et « en choisit un ».
Elle réserve prématurément sans vérifier les contraintes (heure d’arrivée, bagages, siège, politique).
En cas d’échec, elle réessaie d’une manière légèrement différente, mais sans savoir clairement ce qui a changé ni ce qu’elle a appris.
Le problème n’est pas que le modèle est incapable de raisonner, mais que le système ne contrôle pas le workflow.
Une version plus agentique traite la tâche comme un processus interactif doté d’un état et de contrôles explicites :
PLANIFIER : reformuler les contraintes et énumérer les informations manquantes (p. ex. « quel aéroport préférez-vous ? » ou « une escale est-elle acceptable ? »).
AGIR : appeler la recherche de vols avec une requête structurée (plage de dates, contrainte d’arrivée, budget).
OBSERVER : stocker les résultats dans un objet d’état compact (les 5 meilleurs candidats avec prix, arrivée et escales), et non dans un énorme bloc de texte collé.
ACTUALISER : affiner la requête si les contraintes ne sont pas respectées (p. ex. « une arrivée avant 18 h est trop contraignante : élargir la plage horaire ou augmenter le budget ? »).
VÉRIFIER : exécuter les validateurs (« arrivée < 18:00 », « prix ≤ 900 £ », « conforme à la politique », « sélection du siège disponible »).
ARRÊTER : uniquement lorsque l’API de réservation renvoie une confirmation et que tous les validateurs réussissent.
Le changement est subtil, mais décisif. La récupération est conditionnelle (et non réflexe), le contexte est géré (l’état est structuré, et non accumulé) et la vérification fait partie de la boucle (elle n’est pas laissée à l’utilisateur). Remplacez « réserver un vol » par « créer un bon de commande », « émettre un remboursement », « modifier une configuration de production » ou « livrer une PR » : le constat reste le même. Dès que l’agent peut agir, la boucle compte plus que le prompt.
L’étude précitée organise le raisonnement agentique en trois couches : fondamentale (planification, utilisation d’outils, recherche), auto-évolutive (feedback et mémoire) et collective (coordination multi-agents).
Mais l’idée profonde est la suivante : le raisonnement devient le principe organisateur de la planification, de la prise de décision et de la vérification, et ne sert plus seulement à générer un raisonnement détaillé (« chain-of-thought ») plausible. Cela paraît abstrait jusqu’à ce que vous le mettiez en correspondance avec les changements apportés à votre architecture. Trois points essentiels sont à retenir :
Un bon agent ne devrait pas considérer la récupération comme une opération systématique. La récupération est une décision, pas un réflexe.
Voici une heuristique pratique :
Si votre système effectue une récupération à chaque tour, vous n’avez pas créé un mécanisme de récupération, mais une taxe sur le contexte.
On le constate constamment dans le travail réel. Lors du débogage d’un incident de production, vous ne déversez pas tous les journaux dans le contexte ; vous choisissez les métriques et journaux à récupérer ensuite en fonction de votre hypothèse actuelle. C’est la « récupération agentique ». Voici un modèle plus concret :
Décider si une récupération est nécessaire
Si oui : rédiger une requête, récupérer, parcourir, extraire
Si les preuves se contredisent : effectuer une nouvelle récupération
Synthétiser seulement ensuite
C’est également là que le « RAG agentique » commence à se distinguer du RAG traditionnel : la récupération devient une étape de raisonnement délibérée, et non une étape par défaut du pipeline.
Dès que vous cessez d’évaluer « un modèle » pour évaluer « un système », le suivi et le traçage de l’état deviennent importants.
Le secteur reconnaît désormais plus explicitement l’importance de l’observabilité des workflows d’agents. Par exemple, le SDK Agents d’OpenAI intègre le traçage et un tableau de bord Traces qui enregistre les exécutions des agents (générations, appels d’outils, transferts, garde-fous, événements personnalisés), afin de pouvoir déboguer et auditer précisément chaque étape.
Ce n’est pas un simple « plus ». C’est ce qui distingue un système que l’on peut déboguer d’un système que l’on peut seulement juger au ressenti.
Selon moi, l’aspect le plus concret de l’étude est la franchise avec laquelle elle aborde le feedback. Elle distingue trois régimes : le feedback réflexif (générer → critiquer → réviser), l’adaptation paramétrique (apprentissage par fine-tuning ou RL) et le feedback piloté par un validateur (réessayer jusqu’à validation).
La plupart des équipes devraient commencer par le feedback piloté par un validateur, car cette méthode est banale mais efficace. Si vous pouvez écrire n’importe quel validateur qui effectue des tests unitaires, vérifie le schéma, applique des règles ou contraintes métier (« aucun remboursement supérieur à X sans remontée ») ou contrôle la véracité (« citations obligatoires »), vous pouvez transformer la sortie non déterministe du modèle en résultat véritablement fiable.
L’un des changements relevant des « inconnues inconnues » est simple : dans le monde des agents, la fiabilité vient souvent davantage de la boucle que du modèle.
Voici la discipline de boucle la plus simple que j’ai trouvée pour améliorer le comportement de manière fiable sans entraînement :
Procéder par étapes : Planifier → Agir → Observer → Actualiser,
Après chaque action, résumer l’observation en 1 à 3 puces,
S’arrêter lorsque les critères de réussite sont satisfaits ou le budget atteint ; renvoyer le meilleur résultat connu et les incertitudes restantes.
Il ne s’agit pas de rendre le modèle verbeux. Il s’agit de rendre le système lisible et d’imposer un « contact avec la réalité » à chaque étape. Un exemple très parlant pour les ingénieurs est l’ancrage en boucle fermée de type CI :
Planifier : proposer une liste de modifications
Agir : exécuter les tests et le linting
Observer : analyser les échecs
Actualiser : corriger et réessayer
Quelques questions qui tendent à révéler les conceptions d’agents accidentelles :
« Mon agent choisit-il les informations à récupérer, ou est-ce que je les récupère systématiquement ? »
Si la récupération est systématique, vous le paierez en latence, en coût, en dilution du contexte et en risque accru d’obtenir des résultats médiocres à partir de données médiocres.
« Mon agent peut-il se rendre compte qu’il se trompe ? »
Si le seul signal de feedback de votre agent est « l’utilisateur s’agace », vous faites du RL au prix de la souffrance humaine. Une boucle de nouvelle tentative pilotée par un validateur est le moyen le plus simple de le confronter à la réalité.
« La mémoire est-elle modifiable et s’améliore-t-elle au fil du temps ? »
Si votre « mémoire » se contente d’ajouter l’historique des conversations, vous ne faites en réalité qu’écrire des journaux. La manière dont l’étude présente la mémoire est importante : celle-ci devient un contexte en croissance dynamique que les agents affinent au fil du temps, et non une simple transcription.
Les journaux indiquent ce qui s’est passé, tandis que la mémoire indique quoi faire la prochaine fois. L’historique des conversations est une transcription. La mémoire est une politique évolutive qui détermine ce qui mérite d’être conservé.
Pour commencer concrètement, créez un petit tableau de « leçons apprises » dont la clé regroupe le type de tâche, l’outil et le mode d’échec, et dont la valeur indique ce qui a fonctionné et ce qu’il faut éviter. Le but n’est pas de construire un graphe de connaissances parfait. Le but est de créer un comportement cumulatif : la mémoire et le feedback transforment les agents, de « simples assistants sans état » en systèmes qui s’améliorent au fil du temps.
Il est tentant d’ajouter davantage d’agents au problème, mais cela multiplie souvent les coûts de coordination. Un bon modèle d’« équipe minimale viable » :
Coordinateur : décompose et attribue
Exécutant : appelle les outils et apporte les modifications
Critique/évaluateur : vérifie l’exactitude et les risques
Gardien de la mémoire : consigne et organise les leçons
Si vous ne pouvez pas expliquer la responsabilité de chaque agent, vous n’avez probablement pas encore besoin de plusieurs agents.
Si nous adhérons vraiment à ce changement de paradigme, nous cesserons probablement de tout entasser dans les prompts, de traiter les échecs comme des sorties définitives et d’évaluer les agents comme des chatbots. Et nous commencerons à traiter les agents pour ce qu’ils sont : des systèmes logiciels où le langage constitue le plan de contrôle et où la fiabilité vient de la boucle.
Avant d’ajouter un autre modèle, ajoutez une autre boucle d’évaluation. Avant de tout récupérer, rendez la récupération conditionnelle. Mettez en production un validateur avant d’en déployer dix. Traitez la mémoire comme des décisions de politique, et non comme une base de données. Et lorsque vous passez au multi-agents, commencez avec deux agents, pas vingt. Ce ne sont pas des règles, mais les modèles qui ont résisté à la production.