Qu'est-ce qu'un agent IA ? (et en quoi il diffère d'un chatbot)

Tout le monde dit « agent » aujourd'hui. Souvent, c'est juste un chatbot avec un nom plus vendeur. La différence n'est pourtant pas cosmétique : un chatbot répond, un agent agit. Voici de quoi les distinguer, en langage clair, et décider si votre besoin appelle vraiment un agent.

La définition en une phrase

Un agent IA, c'est un logiciel qui reçoit un objectif, décide des étapes pour l'atteindre, utilise des outils pour faire des actions concrètes, puis vérifie le résultat et se corrige. Un chatbot s'arrête à la première étape : il produit du texte. L'agent va jusqu'à l'action, et il boucle jusqu'à ce que l'objectif soit atteint ou qu'il rende la main à un humain.

Chatbot ou agent : le même exemple, deux comportements

Prenez une demande banale au support : « annulez ma commande 4837 et remboursez-moi ». Un chatbot vous explique comment faire, ou rédige un message poli. Il ne touche à rien. Un agent, lui, retrouve la commande dans votre système, vérifie qu'elle est encore annulable, déclenche le remboursement, envoie la confirmation, et note le tout dans le dossier client. Même question, deux mondes.

• Le chatbot produit une réponse. Vous, ou un agent humain, exécutez ensuite les actions à la main.
• L'agent exécute les actions lui-même, dans vos outils, et rend compte de ce qu'il a fait.
• Sur un support, l'écart est réel : un chatbot désengorge la FAQ ; un agent bien cadré tient un support 24h/24 avec 50% de tickets en moins escaladés vers un humain.

Les quatre briques : percevoir, décider, agir, se corriger

Sous le capot, un agent tourne en boucle sur quatre gestes. C'est cette boucle, et non le modèle lui-même, qui le sépare d'un chatbot. Le quatrième geste, se corriger, est le plus sous-estimé : un chatbot qui se trompe vous rend une réponse fausse et s'arrête là, alors qu'un agent qui se trompe peut le remarquer et rattraper le coup. C'est aussi ce qui le rend plus délicat à cadrer : une boucle qui se corrige seule doit avoir des limites nettes, sinon elle part loin.

• Percevoir : il lit la demande et rassemble le contexte utile (la fiche client, un niveau de stock, le contenu d'un document).
• Décider : il choisit l'étape suivante, quel outil appeler, avec quels paramètres.
• Agir : il exécute l'action dans un vrai système et récupère le résultat.
• Se corriger : il regarde ce qui s'est passé. En cas d'échec ou d'objectif non atteint, il réessaie autrement au lieu de s'arrêter.

Les outils, et le lien avec MCP

Un agent sans outils, c'est un cerveau sans mains : il raisonne mais ne peut rien faire. Les outils, ce sont ses branchements vers vos systèmes : lire une commande, créer un ticket, interroger une base, envoyer un email. Plus les outils sont fiables et bien décrits, plus l'agent est utile. C'est là qu'intervient le standard MCP : au lieu de recâbler chaque branchement sur mesure, MCP donne une prise commune entre l'IA et vos logiciels. Il est passé de curiosité à standard en moins de deux ans, adopté par Anthropic, OpenAI, Google et Microsoft, puis confié à la Linux Foundation fin 2025. Concrètement, ça veut dire des agents moins chers à brancher et moins dépendants d'un fournisseur unique.

Un agent simple, ou plusieurs agents orchestrés

La plupart des besoins réels tiennent avec un seul agent bien cadré, sur un périmètre précis. On passe à plusieurs agents orchestrés quand la tâche se découpe naturellement en métiers distincts : un agent qui cherche, un qui rédige, un qui vérifie, coordonnés par un chef d'orchestre. C'est plus puissant, mais chaque agent ajouté, c'est une source d'erreur et un coût de plus. Ma règle : je commence toujours par un seul agent, et je n'orchestre que quand le mono-agent bute pour de vraies raisons, pas pour l'élégance de l'architecture.

Un agent, ce n'est pas un modèle plus intelligent. C'est un modèle à qui on a donné une boucle, des outils et le droit d'agir. Tout l'enjeu est dans le cadrage de ces trois choses.

Ce qu'un agent ne sait pas encore bien faire

• Garantir zéro erreur : il se trompe encore, surtout sur les cas rares. Sur les actions irréversibles (un paiement, une suppression, un message client), je garde une validation humaine.
• Tout expliquer par défaut : il peut justifier ses étapes, mais la traçabilité complète se construit, elle n'est pas gratuite. C'est tout l'objet de mesurer un agent en production.
• Tenir un objectif flou : plus la consigne est vague, plus l'agent dérive. Il lui faut un but clair et des limites claires.
• Deviner votre contexte tacite : ce que « tout le monde sait » dans votre entreprise lui reste invisible tant qu'on ne le lui a pas donné.

Agent ou simple workflow : comment trancher

Beaucoup de besoins présentés comme « il nous faut un agent » se règlent mieux avec un workflow classique : une suite d'étapes fixes, prévisibles, sans IA qui décide. Si le chemin est toujours le même, un workflow est plus simple, moins cher et plus fiable. L'agent se justifie quand le chemin varie à chaque fois et qu'il faut décider en cours de route.

• Chemin fixe, règles claires, peu d'exceptions : c'est un workflow. Voir automatiser sans tout casser.
• Chemin qui change selon les cas, beaucoup de jugement, des exceptions permanentes : c'est un agent.
• Entre les deux : commencez par le workflow, ajoutez de l'IA seulement là où il coince.

L'agent n'est donc jamais l'objectif : c'est un moyen, et souvent pas le premier à sortir. La bonne question de départ n'est pas « comment on construit un agent », c'est « est-ce que ce chemin décide, ou est-ce qu'il ne fait que dérouler » : répondez à ça, et le choix entre un agent, un workflow et un meilleur prompt se fait presque tout seul.