Quels papiers lire pour comprendre l’IA agentique ?

Je lirais ces cinq papiers pour comprendre l’IA agentique sans me perdre dans un gros survey. Ils montrent le cœur du sujet : raisonner, agir, utiliser des outils, mémoriser, apprendre par feedback et faire collaborer plusieurs agents.

Pourquoi ReAct change la logique des agents ?

ReAct change un truc assez profond dans la logique des agents. Le modèle ne reçoit plus juste une question avec mission de sortir une réponse propre. Il avance par cycles, un peu comme quelqu’un qui réfléchit, tente une action, regarde ce que ça donne, puis ajuste.

Publié par Yao et al., ReAct veut dire Reasoning + Acting. L’idée est simple : faire travailler ensemble le raisonnement et l’action dans un même flux. Le raisonnement sert à planifier, à garder le fil, à repérer qu’on s’éloigne du but. L’action sert à aller chercher quelque chose dehors : une API, une base de données, un moteur de recherche, un fichier, un outil métier.

La boucle ressemble à ça : think → act → observe → update. Le modèle pense à la prochaine étape, il agit avec un outil, il observe le résultat, puis il met à jour son raisonnement. Ce n’est pas une décoration. C’est la mécanique qui rend l’agent plus robuste qu’un simple générateur de texte.

On le voit très bien dans les agents LLM actuels. Un LLM, pour Large Language Model, c’est un modèle de langage qui prédit et génère du texte. Un agent inspiré de ReAct fait plus que ça. Il découpe une tâche, exécute une action, attend un retour, puis décide quoi faire ensuite. S’il interroge une base client et que le résultat est vide, il peut reformuler la requête. S’il appelle une API et reçoit une erreur, il peut changer les paramètres. S’il trouve une info contradictoire, il peut vérifier ailleurs.

Mon observation terrain est assez simple. Quand je vois un agent échouer chez un client, ce n’est pas toujours le modèle qui est mauvais. C’est souvent la boucle d’observation ou de correction qui est trop pauvre. L’agent agit, mais il ne comprend pas assez bien ce qui revient. Ou alors il n’a pas de vraie règle pour corriger sa trajectoire. Résultat, il répète la même erreur avec beaucoup d’assurance, ce qui est rarement une bonne stratégie.

LLM classique	Agent inspiré de ReAct
Répond directement à une demande	Avance par cycles de réflexion, action et observation
Reste surtout dans le texte	Interagit avec des outils externes
Corrige peu sa trajectoire pendant l’exécution	Ajuste la suite selon les résultats obtenus
Produit une réponse finale	Construit une réponse à partir d’étapes vérifiées

À quoi servent les outils dans l’IA agentique ?

Quand je regarde l’IA agentique, le vrai déclic n’est pas juste “le modèle réfléchit”. C’est plutôt “le modèle sait quand il doit arrêter d’inventer et demander de l’aide”. C’est exactement ce que Toolformer, le papier de Schick et al., met sur la table.

L’idée forte est simple, mais énorme. Un modèle de langage peut apprendre à appeler des outils externes. Pas seulement recevoir un outil branché à côté de lui. Il apprend quand l’utiliser, avec quels arguments, puis comment intégrer le résultat dans sa réponse finale.

Toolformer montre qu’un LLM peut sortir de ses limites internes. Un modèle n’est pas fiable pour faire un calcul précis de tête. Il peut appeler une calculatrice. Il ne connaît pas forcément une information récente. Il peut appeler un moteur de recherche. Il peut traduire avec un outil dédié, interroger une base de connaissance, poser une question à un système de question-réponse, ou consulter un calendrier avant de proposer un créneau.

Pour moi, c’est une vraie bascule. Le LLM n’est plus seulement une machine à produire du texte plausible. Il devient un orchestrateur. Il décide qu’un autre système est mieux placé que lui pour une partie du travail. C’est très proche de ce qu’on veut en entreprise : un agent qui ne bavarde pas, mais qui agit avec les bons outils.

Le point important, c’est que ça marche seulement si l’usage des outils est cadré. J’ai déjà vu des prototypes très propres en démo, mais dangereux en pratique. L’agent appelle le mauvais outil, envoie une mauvaise date au calendrier, confond un identifiant client, ou fait confiance à un résultat de recherche sans contexte. Et là, ce n’est plus un problème de “qualité de réponse”. C’est un problème business.

Avant de connecter un outil à un agent, je me pose toujours trois questions très terre à terre :

• Quand l’appeler ? L’agent doit savoir dans quels cas l’outil est utile, et dans quels cas il doit répondre sans l’utiliser.
• Quoi lui transmettre ? Les paramètres doivent être précis, minimaux, et sans données sensibles inutiles.
• Comment vérifier sa réponse ? Le résultat doit être contrôlé, contextualisé, et parfois recoupé avant d’être utilisé.

Toolformer reste un papier important parce qu’il pose cette idée proprement : un agent utile n’est pas un modèle plus bavard. C’est un modèle qui sait demander de l’aide au bon moment.

Pourquoi la mémoire rend les agents crédibles ?

La mémoire, c’est souvent le détail qui fait passer un agent de “chatbot sympa” à “assistant crédible”. Parce qu’une réponse intelligente, seule, ne suffit pas. Ce qui compte, c’est la continuité. Ce que l’agent a vu, ce qu’il a compris, ce qu’il décide d’en faire ensuite.

Le papier Generative Agents de Park et al. montre très bien ça. Les chercheurs ont créé des agents capables d’évoluer dans un petit monde interactif, un peu comme dans The Sims. Les agents se parlent, organisent leur journée, réagissent à des événements, gardent une cohérence sociale. Ce n’est pas juste parce qu’ils ont un bon modèle de langage derrière. C’est surtout parce qu’ils ont une architecture simple mais puissante : mémoire, réflexion, planification.

La logique est assez saine :

• La mémoire stocke les expériences de l’agent. Une discussion, une observation, une action passée.
• La réflexion transforme ces souvenirs en idées plus générales. Par exemple “Cette personne aime travailler tôt” ou “Ce sujet revient souvent”.
• La planification utilise ces éléments pour décider quoi faire ensuite. Pas juste répondre, mais agir avec un minimum de continuité.

C’est là que l’IA agentique devient intéressante. Un agent sans mémoire repart presque de zéro à chaque interaction. Il peut donner une bonne réponse au dernier message, mais il ne construit rien. Il ne suit pas une trajectoire. Il ne sait pas vraiment où il en est avec vous.

En entreprise, ça change tout. Prenez un assistant commercial. S’il se souvient que le prospect a déjà objecté sur le prix, que la plaquette produit a été envoyée mardi, que le ton de la conversation est plutôt prudent, et que la prochaine étape prévue est une démo avec le DAF, il devient utile. Il peut relancer proprement, éviter de répéter les mêmes arguments, adapter son message. Un chatbot classique, lui, répond surtout au dernier email. Et parfois, ça se voit très vite. J’ai déjà vu des assistants “IA” proposer trois fois le même document à un prospect. Là, la crédibilité tombe.

Il faut quand même rester lucide. La mémoire n’est pas magique. Elle pose des vraies questions : qu’est-ce qu’on garde, combien de temps, où, avec quel niveau de confidentialité, et comment on évite d’accumuler du bruit inutile ? Tout mémoriser est une mauvaise idée. Une bonne mémoire d’agent, ce n’est pas une archive géante. C’est une mémoire utile, priorisée, nettoyée, qui aide vraiment l’action future.

Comment un agent apprend en explorant ?

Un des papiers que je trouve vraiment utile pour comprendre l’IA agentique, c’est Voyager de Wang et al. À première vue, ça parle d’un agent qui joue à Minecraft. Dit comme ça, on peut avoir envie de passer son chemin. Mais le vrai sujet n’est pas Minecraft. Le vrai sujet, c’est comment un agent apprend dans un environnement ouvert, avec des objectifs qui changent, des erreurs concrètes, et du feedback qui vient du monde réel.

Voyager ne suit pas juste une liste d’instructions figées. Il explore, il tente des actions, il observe ce qui marche, il corrige ce qui casse. Et surtout, il garde ce qu’il apprend. C’est là que ça devient intéressant pour nous, côté automatisation, data, IA en entreprise.

Le papier repose sur trois idées fortes :

• Un curriculum automatique. L’agent se fixe progressivement des objectifs adaptés à ce qu’il sait déjà faire. Il ne part pas dans tous les sens. Il cherche des tâches qui le font progresser.
• Une bibliothèque de skills. Quand l’agent réussit une action utile, il la transforme en compétence réutilisable. Une skill, c’est simplement une procédure qu’il peut rappeler plus tard au lieu de tout réinventer.
• Une boucle d’itération. L’agent exécute, observe les erreurs, lit les retours de l’environnement, ajuste son code ou sa stratégie, puis réessaie. C’est très proche de ce qu’un humain fait quand il debug une automatisation.

Le parallèle business est assez direct. Imaginez un agent d’automatisation qui doit créer une facture, appeler une API, mettre à jour un CRM et notifier une équipe. Il teste une séquence. L’API renvoie une erreur parce qu’un champ est mal formaté. L’agent ajuste le paramètre, relance, vérifie le résultat, puis documente la procédure qui marche. La prochaine fois, il réutilise cette compétence au lieu de repartir de zéro.

C’est exactement ce qui rend les agents plus intéressants que des workflows figés. Un workflow classique casse souvent dès que le contexte bouge. Un agent bien conçu peut diagnostiquer, adapter, apprendre une variante. Attention, ça ne veut pas dire autonomie totale en production. J’ai vu chez des clients que la valeur arrive quand le cadre est très clair, pas quand on lâche l’agent partout.

L’apprentissage par interaction demande un environnement contrôlé, des permissions limitées, des logs propres, des tests, et une validation humaine dès que l’action a un impact sensible. Sans ça, on ne construit pas un agent apprenant. On construit juste un risque automatisé.

Pourquoi faire collaborer plusieurs agents ?

Quand je lis AutoGen de Wu et al., le papier porté par Microsoft Research, je vois surtout une idée très simple : arrêter de demander à un seul agent de tout faire, et organiser une discussion entre plusieurs agents qui ont chacun un rôle clair.

Un agent unique peut vite devenir une espèce de stagiaire surchargé. Il doit comprendre le besoin, choisir une stratégie, appeler les bons outils, écrire du code, vérifier le résultat, corriger ses erreurs. Ça marche sur des tâches simples. Ça devient fragile dès que la tâche demande plusieurs compétences ou un vrai contrôle qualité.

Avec AutoGen, la conversation devient le mécanisme de coordination. Les agents s’envoient des messages, se répondent, déclenchent des actions, exécutent du code, demandent une validation humaine si besoin. Ce n’est pas juste du “chat entre IA”. C’est une façon d’orchestrer le travail.

Dans une architecture multi-agent, je peux avoir des rôles comme :

• Un agent planificateur qui découpe le problème et propose une stratégie.
• Un agent développeur qui écrit ou exécute du code dans un environnement contrôlé.
• Un agent vérificateur qui relit les résultats, cherche les erreurs et challenge les hypothèses.
• Un agent outil qui interroge une base de données, une API, un moteur de recherche ou un fichier interne.
• Un humain dans la boucle qui valide les décisions sensibles avant exécution.

J’ai vu ce pattern fonctionner sur des cas où il fallait générer une analyse, exécuter du Python, vérifier les chiffres, puis produire une synthèse. Le fait de séparer “celui qui fait” et “celui qui vérifie” change beaucoup de choses. On évite certaines erreurs bêtes, pas toutes, mais certaines.

Il faut quand même être lucide. Le multi-agent n’est pas magique. Ça coûte plus cher, ça peut tourner en boucle, ça peut produire des débats inutiles entre agents, et ça rend le système plus dur à déboguer. Si la tâche est simple, un seul agent bien prompté avec les bons outils sera souvent meilleur.

Je garde le multi-agent pour les cas où la séparation des rôles apporte vraiment quelque chose : contrôle, vérification, orchestration, ou réduction du risque.

Critère	Agent unique	Multi-agent
Complexité de la tâche	Tâche courte, objectif clair, peu d’étapes.	Tâche longue, plusieurs sous-problèmes, dépendances entre étapes.
Besoin de contrôle	Contrôle léger, résultat facile à relire.	Validation, revue, séparation entre production et vérification.
Nombre d’outils	Un ou deux outils simples.	Plusieurs outils, API, code, base de données, recherche externe.
Niveau de risque	Faible impact en cas d’erreur.	Décisions sensibles, données critiques, besoin d’un humain dans la boucle.

Alors, par quel papier commencer maintenant ?

Je commencerais par ReAct si vous voulez comprendre la mécanique de base : raisonner, agir, observer, corriger. Ensuite Toolformer pour voir comment les outils changent le rôle du LLM. Generative Agents ajoute la mémoire et la continuité. Voyager montre l’apprentissage par exploration. AutoGen ouvre la logique multi-agent.

Ces cinq papiers donnent une carte assez propre de l’IA agentique moderne, sans se noyer. Vous voyez ce qui rend un agent vraiment utile : une boucle d’action, des outils, une mémoire, du feedback et une coordination maîtrisée. Le bénéfice pour vous, c’est simple : mieux concevoir vos agents avant de les mettre en production.

FAQ

• Qu’est-ce que l’IA agentique ?
  L’IA agentique désigne des systèmes capables de raisonner, choisir des actions, utiliser des outils, observer les résultats et ajuster leur comportement. L’idée n’est pas seulement de produire une réponse, mais d’agir dans un environnement avec une forme de boucle de décision.
• Pourquoi ReAct est souvent cité dans les agents IA ?
  ReAct est important parce qu’il formalise une boucle simple et puissante : penser, agir, observer, corriger. Beaucoup d’agents LLM modernes reprennent cette logique, même quand elle est cachée derrière une interface ou un framework.
• Quelle différence entre un chatbot et un agent IA ?
  Un chatbot répond principalement à des messages. Un agent IA peut aller plus loin : appeler un outil, exécuter une action, lire un retour d’environnement, mémoriser des éléments et coordonner plusieurs étapes pour atteindre un objectif.
• Pourquoi la mémoire est-elle importante pour un agent ?
  La mémoire permet à l’agent de garder une continuité. Il peut réutiliser des expériences passées, adapter ses plans et éviter de traiter chaque interaction comme si elle arrivait de nulle part. Mais elle doit être contrôlée, sinon elle ajoute du bruit et des risques de confidentialité.
• Quand faut-il utiliser une architecture multi-agent ?
  Une architecture multi-agent devient utile quand la tâche demande plusieurs rôles, de la vérification, de l’exécution de code, des outils différents ou une validation humaine. Pour une tâche simple, un seul agent bien cadré est souvent plus fiable et plus facile à maintenir.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes sur des sujets très concrets : données fiables, workflows automatisés, agents IA utiles, pas juste des prototypes qui brillent en démo. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer ou déployer des agents IA dans votre business, contactez-moi.