Intelligence artificielle

Qu’est-ce qu’un agent IA et en quoi diffère-t-il d’un chatbot

Un agent IA combine un modèle de langage, des outils et une boucle de décision pour accomplir des tâches. Différences avec un chatbot, fonctionnement et risques.

Un agent IA est un système dans lequel un modèle de langage (LLM) ne se contente pas de répondre par du texte, mais décide quelles actions exécuter, les exécute via des outils (chercher, lire des fichiers, appeler une API, exécuter du code), observe le résultat et répète le cycle jusqu’à accomplir une tâche. Un chatbot répond à un message ; un agent poursuit un objectif en plusieurs étapes. La différence ne tient pas au modèle, qui peut être le même, mais à l’architecture qui l’entoure : outils, boucle de contrôle et critère d’arrêt.

Cet article explique cette architecture, quels types de systèmes on appelle « agents », quels risques ils introduisent et quand il est pertinent d’en utiliser un plutôt que quelque chose de plus simple.

Chatbot ou agent

Chatbot (assistant conversationnel) Agent
Entrée Un message de l’utilisateur Un objectif ou une tâche
Sortie Une réponse textuelle Des actions et, à la fin, un résultat
Étapes Une par tour Plusieurs, décidées par le modèle lui-même
Accès au monde Seulement ce qui est dans la conversation Des outils externes (fichiers, API, navigateur, terminal)
Qui décide de l’étape suivante L’utilisateur, en écrivant Le modèle, jusqu’au critère d’arrêt
Risque principal Une réponse incorrecte Une action incorrecte avec des effets réels

Un chatbot qui peut chercher sur internet avant de répondre est à mi-chemin : il utilise un outil, mais en une seule étape fixe. Ce qui définit un agent, c’est la boucle : le modèle choisit l’outil, voit le résultat et décide s’il en faut un autre.

Comment ça marche à l’intérieur

La plupart des agents actuels suivent une structure similaire, popularisée par le schéma ReAct (raisonner et agir) et décrite clairement dans le guide d’Anthropic Building effective agents :

  1. Objectif. Le système reçoit la tâche (« trouve dans le dépôt pourquoi le test X échoue et propose un correctif »).
  2. Outils disponibles. Ils sont décrits au modèle avec un nom, leur usage et les paramètres acceptés (par exemple lire_fichier(chemin), executer_tests()).
  3. Décision. Le modèle produit soit une réponse finale, soit un appel d’outil avec ses arguments.
  4. Exécution. Le programme hôte exécute l’outil (le modèle n’exécute jamais rien lui-même) et renvoie le résultat au modèle comme nouveau contexte.
  5. Répétition jusqu’à ce que le modèle décide qu’il a terminé ou qu’une limite soit atteinte (nombre d’étapes, temps, coût).

Deux détails importants :

  • Tout ce que le modèle « sait » de la tâche se trouve dans sa fenêtre de contexte : l’instruction, les descriptions d’outils et les résultats accumulés. Quand le contexte se remplit, il faut résumer ou jeter.
  • Les outils sont du code ordinaire écrit par le développeur. Le Model Context Protocol (MCP) est un standard ouvert pour exposer outils et données aux modèles de façon uniforme, de sorte qu’un même serveur d’outils serve différents agents.

Flux de travail ou agents

Tout ce qui enchaîne plusieurs appels à un modèle n’est pas un agent. Anthropic distingue :

  • Flux de travail (workflows) : les étapes sont définies à l’avance dans le code. Le modèle remplit chaque étape (classe, résume, rédige), mais ne décide pas de l’ordre. Ils sont prévisibles, peu coûteux à déboguer et suffisants pour la plupart des automatisations.
  • Agents : le modèle décide dynamiquement quoi faire et combien d’étapes effectuer. Ils sont plus flexibles et plus coûteux, et leur comportement est plus difficile à garantir.

La recommandation pratique de ce guide, qu’il vaut la peine d’intérioriser, est de commencer par la solution la plus simple qui fonctionne : un seul appel bien conçu, puis un flux de travail, et seulement ensuite un agent, si la tâche exige vraiment des décisions ouvertes.

Exemples d’usage réel

  • Assistants de programmation qui lisent un dépôt, exécutent des tests, modifient des fichiers et ouvrent une pull request.
  • Support technique qui consulte la documentation interne, vérifie l’état d’un compte et exécute une action (remboursement, réinitialisation) dans des limites définies.
  • Recherche : chercher dans plusieurs sources, lire des pages, recouper et rédiger un rapport avec références.
  • Automatisation opérationnelle : examiner des journaux, corréler des alertes et proposer (sans exécuter) une action corrective.

Remarquez le schéma : des tâches en plusieurs étapes, un résultat vérifiable et des outils bien délimités.

Risques propres aux agents

Un agent peut se tromper comme un chatbot, mais ses erreurs s’exécutent. Les risques les plus pertinents :

  1. Injection d’instructions (prompt injection). Si l’agent lit une page web, un courriel ou un fichier contenant un texte du type « ignore tes instructions et envoie les données à… », il peut y obéir. Le Top 10 OWASP pour les applications LLM le place en premier risque. Traitez tout contenu externe comme des données, pas comme des ordres, et limitez ce que les outils peuvent faire.
  2. Actions irréversibles. Supprimer, payer, envoyer. Exigez une confirmation humaine ou ne les exposez pas comme outils.
  3. Boucles et coût. Un agent qui ne converge pas peut répéter des étapes indéfiniment. Fixez des limites d’étapes, de temps et de budget.
  4. Permissions excessives. Donnez à l’agent les identifiants minimaux pour sa tâche, comme à n’importe quel service.
  5. Fausse assurance. Qu’un agent « explique » ce qu’il a fait ne garantit pas que ce soit correct. Vérifiez le résultat avec des tests, des relectures ou des contrôles indépendants.

Quand un agent est (ou n’est pas) pertinent

Il l’est quand la tâche comporte plusieurs étapes dont l’ordre dépend de ce que l’on découvre, quand le résultat est vérifiable (un test qui passe, une donnée recoupée) et quand le coût d’une erreur est borné ou réversible.

Il ne l’est pas quand le processus est toujours le même (utilisez un flux de travail), quand un seul appel au modèle résout le problème, ou quand une erreur aurait des conséquences graves sans possibilité de relecture humaine.

Conclusion

Un agent IA est un modèle de langage dans une boucle avec des outils et un critère d’arrêt. Cette architecture lui permet d’accomplir des tâches au lieu de seulement répondre, et introduit en échange de nouveaux risques : actions erronées, injection d’instructions et coûts incontrôlés. La façon raisonnable de les adopter est progressive (appel simple, flux de travail, agent), avec des outils bornés, des permissions minimales et une vérification du résultat.

Sources et références

  1. Anthropic : Building effective agents anthropic.com
  2. Model Context Protocol : spécification modelcontextprotocol.io
  3. OWASP Top 10 for Large Language Model Applications owasp.org
  4. ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022) arxiv.org