Agent IA : définition, fonctionnement et différences avec un chatbot

Qu’est-ce qu’un agent IA ?

Un agent IA est un système qui reçoit des informations de son environnement, choisit des actions en fonction d’un objectif, puis observe leurs effets pour décider s’il doit poursuivre, changer de direction ou s’arrêter. Le mot important est « système » : l’agent n’est pas nécessairement un modèle d’intelligence artificielle pris isolément. Il peut réunir un modèle ou une politique de contrôle, des instructions, des informations contextuelles, des outils, un environnement et des règles qui limitent les actions possibles.

Cette définition décrit un cycle de perception, de décision et d’action. Elle n’exige pas que le système ait une personnalité, une conscience, une mémoire permanente ou la liberté de faire n’importe quoi. Elle n’exige pas non plus l’utilisation d’un grand modèle de langage (LLM). Le cadre classique des agents est plus vaste que celui des assistants génératifs actuels : ces derniers constituent une famille de réalisations possibles, mais ne résument pas la définition.

Dans cette fiche, le terme « agent » est employé dans un sens fonctionnel : ce qui compte, c’est de savoir si le système peut choisir parmi plusieurs actions possibles en fonction de l’état qu’il observe et de la tâche à accomplir. Un système peut disposer d’une autonomie très limitée — par exemple, sélectionner un outil parmi deux options autorisées — tout en ayant un comportement agentique. L’autonomie n’est donc pas un interrupteur binaire.

Composants possibles et cycle de fonctionnement

Un agent peut combiner plusieurs éléments. L’objectif définit le résultat recherché ; le modèle ou la politique de contrôle aide à choisir l’étape suivante ; les instructions et le contexte délimitent la tâche ; l’état rassemble les informations nécessaires pour continuer ; les outils ou les actionneurs permettent d’agir ; et l’environnement correspond à ce que l’agent observe ou modifie. Il peut également y avoir des autorisations, des vérifications, des limites d’utilisation et des conditions d’arrêt. Ce sont des composants possibles, pas une liste d’exigences que tous les agents doivent satisfaire.

Dans une implémentation faisant appel à un modèle génératif, la boucle peut consister à transmettre au modèle la tâche et l’état disponible, à examiner sa réponse, à exécuter un outil si le système y est autorisé, puis à interroger de nouveau le modèle en lui communiquant le résultat. Le processus s’achève lorsqu’une réponse finale est obtenue, qu’un critère d’arrêt est rempli, qu’une limite est atteinte ou qu’une intervention humaine est nécessaire. La documentation d’un SDK donné décrit un cycle d’exécution de ce type ; d’autres architectures peuvent s’organiser autrement.

La mémoire mérite elle aussi d’être définie avec précision. Le système peut conserver des informations pendant une tâche ou recevoir un état enregistré entre plusieurs tâches, mais il ne faut pas supposer que toutes les implémentations le font. De même, un agent peut utiliser un seul outil, plusieurs outils ou aucun. La disponibilité d’outils ne signifie pas que l’agent peut les invoquer sans restriction : les autorisations et les règles de contrôle déterminent les actions réellement possibles.

Quatre exemples dans des domaines différents

Les exemples ci-dessous sont des scénarios illustratifs : ils ne décrivent pas le fonctionnement de tous les produits d’un secteur donné. Dans chaque cas, c’est la boucle entre l’observation, le choix d’actions et l’examen des résultats qui donne au système son caractère agentique. Une tâche bien délimitée peut s’accompagner d’autorisations restreintes et de contrôles humains sans cesser d’être un système qui choisit ses étapes en fonction de ce qu’il découvre.

Dans ces exemples, les actions autorisées, le contexte disponible et les critères d’arrêt font partie de la description de la tâche. Les expliciter aide à distinguer ce qu’un système peut effectivement faire de ce que son nom ou une démonstration pourrait laisser entendre.

Agent, chatbot, outil et automatisation : les différences concrètes

Un chatbot se définit souvent par son interface conversationnelle : il reçoit des messages et produit des réponses. Il peut se contenter de répondre, mais aussi intégrer des actions et une boucle de décision. « Chatbot » et « agent » ne sont donc pas toujours des catégories exclusives : le premier terme peut désigner la forme de l’interaction, tandis que le second décrit la manière dont le système choisit des actions pour avancer vers une tâche.

L’appel à un outil est une capacité ou une étape d’exécution ; il ne garantit pas une autonomie étendue. Un modèle peut décider quel outil appeler, à quel moment et avec quels arguments, comme l’étudie Toolformer. Le système complet comprend néanmoins le mécanisme qui autorise et exécute cet appel. Il existe aussi des agents qui ne font appel à aucun outil externe. Une interface d’outils telle que MCP est un concept connexe, mais la simple connexion à un outil ne suffit pas à déterminer le degré de décision laissé au système.

Une automatisation ou un flux de travail fixe les étapes à l’avance : si une condition est remplie, une action prédéfinie est exécutée. Ajouter un LLM à l’une de ces étapes signifie que le flux fait appel à l’IA, mais ne lui donne pas nécessairement la capacité de choisir dynamiquement ses actions. Dans un sens large, on peut qualifier d’« agentique » un flux qui intègre des décisions. Dans cette fiche, nous réservons l’expression « agent dynamique » à une architecture qui peut choisir l’étape suivante en fonction de la tâche et des observations, au lieu de suivre uniquement une séquence fermée.

Un assistant est une catégorie de produit ou un rôle qui peut couvrir des fonctions allant de la réponse à des questions à l’exécution de tâches avec des outils ; il ne détermine pas à lui seul l’architecture. Un système multi-agent coordonne plusieurs agents, mais le nombre de composants ne prouve pas que la solution est meilleure. La mémoire d’agent, l’ingénierie du contexte, la génération augmentée par récupération (RAG) et l’humain dans la boucle sont des notions connexes susceptibles d’apparaître dans certaines architectures. Aucune n’est une exigence universelle pour qu’un système soit qualifié d’agent.

Erreurs fréquentes et limites

La première erreur consiste à traiter l’agent comme s’il n’était que le LLM. Un modèle peut proposer une action, mais c’est le système qui reçoit cette proposition qui décide s’il faut l’exécuter, avec quelles autorisations et comment renvoyer le résultat à l’étape suivante. Cette distinction compte pour analyser la sécurité et la responsabilité : une réponse textuelle et une action qui modifie une ressource n’ont pas les mêmes conséquences.

La deuxième erreur consiste à déduire une grande autonomie de la seule utilisation d’outils. Le système peut n’avoir accès qu’à un seul outil, exiger une approbation pour chaque action ou fonctionner dans un environnement de test. Inversement, une automatisation sans LLM peut choisir des actions en fonction de ce qu’elle observe. Mieux vaut décrire le comportement et les contrôles que s’en remettre à une étiquette commerciale.

Il ne faut pas non plus confondre autonomie et fiabilité. Un agent peut mal interpréter une tâche, établir un plan inadapté, recevoir des observations incomplètes ou mal utiliser le résultat d’un outil. Il peut répéter des actions en boucle, s’arrêter trop tôt ou produire une synthèse qui ne reflète pas les éléments récupérés. Une réponse fluide, une démonstration ou une exécution réussie ne prouvent pas, à elles seules, la régularité des performances.

Lorsqu’un système traite des instructions ou du contenu externe, ces éléments peuvent tenter d’influencer ses décisions, par exemple au moyen d’une injection de prompt. Le risque dépend des données auxquelles le système accède, des actions qu’il peut exécuter et de la manière dont les instructions fiables sont séparées du contenu observé. Le principe du moindre privilège, la validation humaine des étapes sensibles et la possibilité d’annuler des modifications sont des mesures de conception susceptibles de réduire les conséquences ; elles ne rendent pas pour autant une tâche ouverte infaillible.

Enfin, disposer d’une mémoire persistante, d’une planification explicite ou de plusieurs agents n’est ni une exigence universelle ni une garantie de meilleurs résultats. Ce sont des choix de conception. Leur utilité dépend de la tâche, de leur mise en œuvre et de la manière dont ils sont évalués. Les sources disponibles pour cette fiche ne permettent pas d’établir une comparaison générale des performances entre toutes ces options ni de proposer une classification universelle des agents.

Comment évaluer un agent avant de l’utiliser

Commencez par définir une tâche observable. « Aider les opérations » est trop vague ; « classer les demandes d’une catégorie et préparer une proposition de réponse sans l’envoyer » permet d’identifier les entrées, le résultat attendu et les limites. Décrivez ensuite l’environnement, les informations auxquelles le système accède et les actions qu’il peut effectuer. Vous pourrez ainsi distinguer une réponse générée d’une intervention effective.

Précisez les autorisations et les contrôles : quelles actions sont en lecture seule, lesquelles modifient des données, lesquelles nécessitent une approbation et lesquelles sont interdites. Définissez aussi la conduite à tenir face à des données manquantes, à des résultats contradictoires, à une panne d’outil ou à une situation incertaine. Les conditions d’arrêt doivent être explicites : par exemple, s’arrêter devant une action non autorisée ou transmettre une demande qui ne correspond pas aux critères convenus.

Évaluez séparément la réussite de la tâche et la sécurité. Une mesure peut indiquer si le résultat atteint l’objectif, mais elle ne suffit pas à déterminer si le système a respecté les autorisations, évité les modifications non souhaitées ou demandé de l’aide quand il le fallait. Examinez également les coûts, les délais, la répétition d’actions, la facilité d’examen des résultats et la possibilité d’annuler une opération. La méthode d’évaluation devrait inclure les cas habituels et les cas limites de l’environnement réel.

Le niveau d’intervention humaine n’a pas besoin d’être identique à toutes les étapes. Une intervention peut être nécessaire avant une action irréversible, après une proposition ou lorsque le système détecte une ambiguïté. L’essentiel est de savoir qui donne son accord, quelles informations lui sont présentées et si le système peut agir avant cette approbation. Si la vérification du résultat est confiée au même agent que celui qui l’a produit, demandez-vous si un contrôle indépendant est nécessaire.

Notions connexes et critères à retenir

L’appel à des outils aide à comprendre comment un modèle peut demander une action externe ; la mémoire d’agent et l’ingénierie du contexte concernent les informations que le système conserve ou reçoit ; la RAG consiste à intégrer des informations récupérées à une réponse ou à une tâche. L’humain dans la boucle et le principe du moindre privilège permettent de réfléchir à la supervision et aux limites d’accès. Ce sont des sujets à relier aux fiches correspondantes du glossaire, et non des composants à supposer obligatoires pour chaque agent. La comparaison entre agents et autres formes d’automatisation peut également aider à examiner les cas limites.

En résumé, vous pouvez parler d’agent lorsque vous êtes en mesure de décrire un objectif, des observations de l’environnement et une sélection d’actions qui s’ajuste aux résultats obtenus. Pour l’évaluer, ne vous arrêtez pas à l’étiquette : demandez-vous ce qu’il décide, ce qu’il peut exécuter, ce qui requiert une approbation, comment il vérifie le résultat et quand il s’arrête. Une description précise de ces limites est plus informative que la simple affirmation qu’un produit est autonome.

Concepts associés