La vraie différence entre un chatbot et un agent

L’un répond à une question. L’autre décide quoi faire, le fait, vérifie son propre travail et passe à l’étape suivante — sans attendre que vous le demandiez. Cette différence n’est pas académique. Elle change ce qui peut mal tourner, et qui est censé le rattraper.

Un chatbot prend ce que vous tapez, génère une réponse et s’arrête. Un agent prend ce que vous tapez, décide de ce qui doit se passer, agit, vérifie si cela a fonctionné et décide de l’étape suivante — seul, souvent sur de nombreuses étapes — avant qu’une personne n’en voie quoi que ce soit. Toute la distinction est là. Tout ce dont les gens débattent quand ils débattent des « agents d’IA » — le risque, la supervision dont un système a besoin, et l’essentiel de la confusion marketing — découle de cette seule différence.

Ce que fait réellement un chatbot

Un chatbot est un système à un seul passage. Vous lui donnez du texte, il génère du texte en retour, et l’interaction s’arrête là. Même un chatbot qui garde une longue mémoire de votre conversation ne fait toujours qu’une chose par tour : lire tout ce qui a été dit jusqu’ici et prédire le message suivant. Il n’interroge jamais une base de données pour vérifier un fait, n’envoie jamais rien en votre nom, et ne revient jamais plus tard voir si sa réponse a tenu. S’il se trompe, le dégât est une phrase qu’une personne lit — et qu’elle peut, dans le cours ordinaire des choses, rattraper avant d’agir.

La plupart de ce qu’on demande aux chatbots a cette forme sans que personne ne le remarque : résume ce document, rédige un message d’anniversaire, explique notre politique de remboursement, propose trois titres. Rien de cela n’exige que le système vérifie quoi que ce soit dans le monde réel ou agisse en dehors de la fenêtre de chat. Cela reste vrai quand l’interface s’appelle « assistant IA » ou « copilote » plutôt que « chatbot » — l’étiquette sur la boîte ne change pas ce qui se passe à l’intérieur.

Ce que fait réellement un agent

Un agent tourne en boucle, pas en un seul passage : planifier une étape, agir en appelant un vrai outil — interroger une base de données, envoyer un message, modifier un fichier, appeler une API — regarder ce que cette action a réellement renvoyé, et utiliser ce résultat pour décider de l’étape suivante. Il répète cela jusqu’à ce que la tâche soit faite, qu’il soit bloqué, ou qu’il soit construit pour vérifier auprès d’une personne. Le point important : personne n’approuve chaque étape individuelle en chemin. Le système décide, seul, de ce qu’il essaie ensuite, d’après ce qui s’est réellement passé la dernière fois qu’il a agi — et il peut se tromper à chacun de ces points de décision, pas seulement dans une réponse finale.

Cette boucle n’est ni nouvelle ni exotique. Des chercheurs en décrivent des versions — raisonner sur quoi faire, agir, observer le résultat, raisonner à nouveau — depuis des années, et c’est ce qui tourne réellement sous les produits qui se disent agents, du logiciel qui dépose des notes de frais aux outils de code qui ouvrent un terminal et lancent leurs propres commandes. Ce qui fait d’une chose un agent plutôt qu’un chatbot très bavard, c’est qu’elle agit sur le monde, observe ce qui s’est passé et s’ajuste — à plusieurs reprises, sans qu’un humain approuve chaque mouvement.

La même demande, exécutée de deux façons

Voici à quoi ressemble cette différence quand deux systèmes reçoivent des instructions qui sonnent de façon similaire.

Posez la deuxième question à un chatbot et il vous rendra quand même quelque chose qui ressemble à une réponse : trois e-mails de relance au ton plausible, générés à partir de ce que vous avez collé dans la conversation. Ce qu’il ne fera pas : interroger votre vrai système de facturation, vérifier le nombre, ou déposer quoi que ce soit dans un vrai dossier de brouillons. Le résultat peut sembler similaire. Ce que le système a réellement fait ne l’est pas.

Pourquoi ce n’est pas qu’une dispute de mots

La distinction compte parce qu’elle change ce qui peut mal tourner, et qui le rattrape. Le pire cas d’un chatbot est une mauvaise réponse. Quelqu’un la lit et, dans le cours normal des choses, soit repère l’erreur, soit décide de ne pas agir — la faute ne quitte jamais la conversation. Le pire cas d’un agent est une mauvaise action déjà prise dans le monde réel : la relance partie au mauvais client avec le mauvais solde, l’enregistrement mis à jour avec la mauvaise valeur, le remboursement émis deux fois — avant que quiconque ait relu quoi que ce soit. L’erreur n’est plus une phrase. C’est un événement, et les événements ne se défont pas.

C’est pourquoi un agent a besoin d’une supervision différente de celle d’un chatbot. Un chatbot a surtout besoin de quelqu’un qui vérifie ses réponses, quand cette personne s’y met. Un agent a besoin que ses concepteurs aient déjà décidé, avant qu’il ne tourne, quelles actions il peut prendre sans demander, lesquelles exigent qu’une personne voie le plan d’abord, et ce qui se passe quand il est bloqué. Réglez cela après coup, et vous découvrirez à vos dépens ce que l’agent a déjà fait.

On ne peut faire confiance qu’à ce qu’on peut voir

C’est la même idée que le concept de Legibility chez FabricLoop : on ne peut gouverner que l’accès, et le comportement, que l’on peut réellement voir. Pour un chatbot, c’est presque automatique — toute sa sortie est un message qu’une personne lit, donc l’action et la trace de l’action sont la même chose. Pour un agent, non. Ses actions se produisent dans d’autres systèmes — un CRM, une boîte mail, une base de données, un fichier — et si rien ne journalise ce qu’il a touché, modifié ou envoyé, il n’y a aucun moyen de le revoir après coup, encore moins de l’arrêter avant. La Legibility n’est pas un plus de conformité posé par-dessus un agent. Pour un agent, c’est toute la question, parce que sa « réponse » n’est pas une phrase que l’on peut relire — c’est un ensemble d’actions dont on peut ne jamais savoir qu’elles ont eu lieu, sauf si le système a été construit pour les montrer.

C’est le lien pratique entre les deux idées : un agent prend plus de risque, et un risque différent, qu’un chatbot, et c’est exactement pourquoi il a besoin d’une trace visible de ce qu’il a fait et, dans les cas à plus fort enjeu, d’un point de contrôle avant d’agir — ce que le concept de Taux d’intervention humaine de FabricLoop traite comme un nombre que l’on conçoit et que l’on mesure, pas comme un ajout qu’on visse une fois que quelque chose a déjà mal tourné.

Le marché évalue cela à l’envers, en permanence

Une fois le vrai test en main, on voit à quel point l’étiquette ment dans les deux sens. Beaucoup de produits vendus durement comme « agents d’IA » — le mot dans le titre d’accueil, dans les paliers de prix — sont, en dessous, un seul prompt bien réglé : lire l’entrée, générer la sortie, terminé. Pas d’appel d’outil indépendant, pas de boucle, pas de décision prise sans qu’un humain approuve le clic suivant. Pendant ce temps, beaucoup de logiciels qui n’utilisent jamais le mot « agent » — un flux de facturation automatisé, un système de surveillance qui reroute le trafic tout seul, un script d’exploitation qui redémarre un service en panne et vérifie si cela a corrigé le problème — font tourner en silence exactement la boucle décrite plus haut. Le mot sur l’étiquette ne dit rien de fiable sur la machine que vous utilisez vraiment.

Rien de tout cela n’exige un bagage technique. La prochaine fois qu’un fournisseur, ou un collègue, appelle quelque chose un agent, demandez ce qu’il a réellement fait entre votre instruction et le résultat — et combien de ces étapes il a décidées seul.