La plupart des équipes d’IA qui cherchent à améliorer les performances des agents utilisent les mêmes leviers : de plus grandes fenêtres contextuelles, plus de documents et des invites plus intelligentes. Cet article soutient que cet instinct est complètement erroné. L’ingrédient manquant n’est pas une plus grande quantité d’information. C’est le contrôle. Une couche de contrôle bien conçue distingue un agent qui fonctionne en démonstration d’un agent qui fonctionne en production.
Doter un agent d’IA d’une mémoire accrue, de plus de documents ou de fenêtres contextuelles plus longues ne le rend pas plus intelligent, mais seulement plus lent et coûteux. Les gains réels viennent du fait d’enseigner à 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 robuste 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.
La plupart des agents d’IA actuels sont essentiellement des robots conversationnels assortis d’étapes supplémentaires : aucun mécanisme ne leur permet de 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 qui ressemble à un agent en système réellement fiable.
Qu’avez-vous mangé hier midi?
Vous n’avez probablement pas repassé tous vos souvenirs jusqu’à trouver « hier + dîner ». Vous êtes allé directement à la partie de votre expérience où se trouvent ces concepts. C’est un modèle mental utile pour créer des agents :
De gigantesques fenêtres contextuelles ne constituent pas une mémoire.
Une pile de documents récupérés ne constitue pas une compréhension.
Un long raisonnement détaillé (« chain-of-thought ») ne garantit pas la fiabilité.
Ce ne sont que des ingrédients. Mais ce qui donne à un agent l’impression d’en être un est aussi ce qui empêche votre cerveau de parcourir de force toute votre vie : le contrôle.
Une étude récente — Raisonnement agentique pour les grands modèles de langage — a très bien résumé (et nommé) le changement que bon nombre d’entre nous ressentent en construisant ces systèmes : passer du raisonnement à l’intérieur du modèle au raisonnement par l’interaction. Cet article n’est pas un résumé de cette étude. Il cherche à traduire ce changement en conception pratique de systèmes :
Si vous concevez des agents comme des robots conversationnels dotés d’outils, vous continuerez d’obtenir les mêmes modes d’échec, mais avec des erreurs plus coûteuses.
Pendant un certain temps, notre stratégie par défaut pour « rendre le modèle plus intelligent » consistait essentiellement à utiliser de meilleures invites, le raisonnement détaillé (« chain-of-thought »), l’autocohérence ou des améliorations par échantillonnage, et peut-être un peu de 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 cela demeure une « inférence en une seule étape, mais avec plus de jetons ». La formulation de l’étude est plus précise : le raisonnement agentique met l’accent sur la mise à l’échelle 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 conçu ou utilisé des agents impressionnants en démonstration, mais fragiles dans de véritables flux de travail, ceci s’adresse à vous.
Permettez-moi de décrire un modèle que j’ai souvent observé (et dont j’ai moi-même assurément créé des versions) :
Prendre un bon modèle conversationnel
Ajouter quelques outils (recherche, requête de base de données, voire exécution de code)
Ajouter la RAG
Ajouter une invite 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 façons prévisibles :
Gonflement du contexte : chaque observation est ajoutée; les invites deviennent des couches archéologiques.
Utilisation désordonnée des outils : « le mauvais outil, mais avec assurance » devient le mode d’échec par défaut.
Aucune condition d’arrêt : il continue parce qu’il le peut, et non parce qu’il le devrait.
Aucune discipline d’ancrage : il ne remarque pas qu’il se trompe à moins qu’on l’y oblige.
Mémoire = historique des conversations : ce qui revient essentiellement à écrire des journaux et à appeler cela de l’apprentissage.
Voilà 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 qu’on n’évalue plus un modèle, mais un système, les modes d’échec comprennent la navigation, la bonne utilisation des outils, l’élagage du contexte et la conception de l’évaluation, et non seulement la question « le modèle a-t-il répondu correctement? »
La question devient donc : qu’est-ce qu’un agent intentionnel?
Pour rendre tout cela moins abstrait, voici un flux de travail simplifié que la plupart des gens peuvent imaginer : « Réserve-moi un vol de Londres à New York mardi prochain. Arrivée avant 18 h. Moins de 900 £. Siège côté couloir. »
Une mise en œuvre courante qui « ressemble à un agent » fonctionne ainsi :
Récupère immédiatement de nombreux documents sur les politiques des compagnies aériennes et de voyage (même s’ils ne sont pas encore nécessaires).
Appelle un outil de recherche, colle une longue liste de résultats dans l’invite et « en choisit un ».
Réserve prématurément sans vérifier les contraintes (heure d’arrivée, bagages, siège, politique).
En cas d’échec, réessaie d’une manière légèrement différente, mais sans savoir clairement ce qui a changé ni ce qu’il a appris.
Le problème n’est pas que le modèle ne sait pas raisonner, mais que le système ne contrôle pas le flux de travail.
Une version plus agentique traite la tâche comme un processus interactif assorti d’un état et de vérifications explicites :
PLANIFIER : reformuler les contraintes et dresser la liste des renseignements manquants (p. ex., « quel aéroport préférez-vous? » ou « une escale est-elle acceptable? »).
AGIR : lancer une 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 cinq meilleurs candidats avec prix, arrivée et escales), plutôt que dans un énorme bloc de texte collé.
METTRE À JOUR : affiner la requête si les contraintes ne sont pas respectées (p. ex., « une arrivée avant 18 h est trop contraignante; faut-il é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 offerte »).
ARRÊTER : uniquement lorsque l’API de réservation retourne une confirmation et que tous les validateurs réussissent.
Le changement est subtil, mais décisif. La récupération est conditionnelle (pas un réflexe), le contexte est géré (l’état est structuré plutôt qu’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 », « effectuer un remboursement », « modifier une configuration de production » ou « livrer une demande de tirage » et le constat reste le même : dès que l’agent peut agir, la boucle compte davantage que l’invite.
L’étude mentionnée précédemment organise le raisonnement agentique en trois couches : fondamentale (planification, utilisation d’outils et recherche), autoévolutive (rétroaction et mémoire) et collective (coordination multiagents).
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, plutôt qu’un simple moyen de générer un raisonnement détaillé (« chain-of-thought ») plausible. Cela paraît abstrait jusqu’à ce qu’on l’applique aux changements apportés à l’architecture. Il faut retenir trois points essentiels :
Un bon agent ne devrait pas considérer la récupération comme une action systématique. C’est une décision, pas un réflexe.
Voici une heuristique pratique :
Si votre système récupère de l’information à chaque tour, vous n’avez pas construit un mécanisme de récupération : vous avez créé une taxe sur le contexte.
Cela se produit constamment dans le travail réel. Lors du débogage d’un incident de production, on ne verse pas tous les journaux dans le contexte; on décide quelles mesures ou quels journaux récupérer ensuite selon l’hypothèse actuelle. C’est la « récupération agentique ». Voici un modèle plus concret :
Déterminer si une récupération est nécessaire
Si oui : rédiger une requête, récupérer, parcourir et extraire
Si les éléments probants se contredisent : récupérer de nouveau
Seulement ensuite, effectuer la synthèse
C’est aussi là que le « RAG agentique » commence à se distinguer du RAG traditionnel : la récupération devient une étape de raisonnement délibérée plutôt qu’une étape par défaut du pipeline.
Dès qu’on cesse d’évaluer « un modèle » pour commencer à évaluer « un système », le suivi et le traçage de l’état deviennent importants.
L’industrie reconnaît maintenant plus explicitement l’importance de l’observabilité des flux de travail des agents. Par exemple, le SDK Agents d’OpenAI comprend un traçage intégré et un tableau de bord Traces qui consigne les exécutions des agents (générations, appels d’outils, transferts, garde-fous, événements personnalisés), précisément pour permettre de déboguer et d’auditer chaque étape.
Ce n’est pas simplement « souhaitable ». C’est ce qui distingue un système qu’on peut déboguer d’un système dont on peut seulement évaluer l’impression générale.
À mon avis, la partie la plus concrète de l’étude est sa façon très directe d’aborder la rétroaction. Elle répartit la rétroaction en trois régimes : rétroaction réflexive (générer → critiquer → réviser), adaptation paramétrique (apprendre par ajustement fin ou apprentissage par renforcement) et rétroaction pilotée par un validateur (réessayer jusqu’à ce que la validation réussisse).
La plupart des équipes devraient commencer par la rétroaction pilotée par un validateur, car elle est banale, mais efficace. Si vous pouvez écrire n’importe quel validateur qui exécute des tests unitaires, vérifie le schéma, applique des règles ou contraintes commerciales (« aucun remboursement supérieur à X sans recours hiérarchique ») ou établit la véracité (« citations requises »), vous pouvez transformer la sortie non déterministe d’un modèle en résultat réellement fiable.
L’un des changements imprévus est simple : dans l’univers des agents, la fiabilité vient souvent davantage de la boucle que du modèle.
Voici la boucle minimale qui, selon mon expérience, améliore fiablement le comportement sans entraînement :
Procéder par étapes : Planifier → Agir → Observer → Mettre à jour,
Après chaque action, résumer l’observation en 1 à 3 puces,
Arrêter lorsque les critères de réussite sont satisfaits ou le budget atteint; retourner 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 parlant pour les ingénieurs est l’ancrage en boucle fermée de type intégration continue :
Planifier : proposer une liste de changements
Agir : exécuter les tests et l’analyse statique
Observer : analyser les échecs
Mettre à jour : corriger et réessayer
Quelques questions qui tendent à révéler les agents conçus par accident :
« Mon agent choisit-il ce qu’il doit récupérer, ou est-ce que je récupère toujours l’information? »
Si la récupération est systématique, vous en paierez le prix : latence, coûts, dilution du contexte et risque accru que des données médiocres produisent des résultats médiocres.
« Mon agent peut-il se rendre compte qu’il se trompe? »
Si le seul signal de rétroaction de votre agent est « l’utilisateur s’énerve », vous faites de l’apprentissage par renforcement au prix de la souffrance humaine. Une boucle de nouvelles tentatives pilotée par un validateur est le moyen le plus net de le confronter à la réalité.
« Peut-on écrire dans la mémoire, et s’améliore-t-elle avec le temps? »
Si votre « mémoire » se contente d’ajouter l’historique des conversations, vous ne faites essentiellement qu’écrire des journaux. La façon dont l’étude présente la mémoire est importante : celle-ci devient un contexte en croissance dynamique que les agents peaufinent 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 qu’il vaut la peine de conserver.
Pour commencer concrètement, créez un petit tableau de « leçons apprises », avec comme clés le type de tâche, l’outil et le mode d’échec, et comme valeurs ce qui a fonctionné et ce qu’il faut éviter. Le but n’est pas de créer un graphe de connaissances parfait. Le but est de produire un effet cumulatif : la mémoire et la rétroaction transforment les agents, qui passent d’« assistants sans état » à des systèmes qui s’améliorent avec le temps.
La tentation est d’affecter davantage d’agents au problème, mais cela multiplie souvent les frais généraux de coordination. Un bon modèle d’« équipe minimale viable » :
Coordonnateur : décompose et attribue
Exécutant : effectue les appels d’outils et les changements
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 invites, de traiter les échecs comme des résultats définitifs et d’évaluer les agents comme des robots conversationnels. Nous commencerons plutôt à 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. Déployez un validateur avant d’en déployer dix. Traitez la mémoire comme un ensemble de décisions stratégiques, et non comme une base de données. Et lorsque vous passez aux multiagents, commencez par deux agents, pas vingt. Ce ne sont pas des règles, mais les modèles qui ont résisté à la production.