Chatbot, assistant ou agent IA : quel fonctionnement choisir ?

Un client écrit : « Peux-tu décaler notre rendez-vous et envoyer une confirmation ? » Derrière cette phrase unique se cachent trois architectures possibles, avec des coûts, des risques et des limites très différents. Cet article compare ces trois formes sur la même demande, sans jargon marketing, pour vous aider à choisir le fonctionnement adapté à votre situation.

Trois architectures, une seule demande

Le chatbot répond. Il interroge une base de connaissances ou un modèle et produit du texte : horaires, politique de retour, explication d'un document. Il ne modifie rien. Sur notre exemple, il peut dire « votre rendez-vous est le 3 novembre à 10 h », mais il ne déplacera pas l'événement.

L'assistant IA rédige ou prépare. Il propose un texte de confirmation, structure une demande, remplit un brouillon. Vous relisez et vous validez. C'est une architecture de copilote : la machine produit, l'humain décide.

L'agent IA exécute. Il appelle des outils — agenda, messagerie, CRM — pour réaliser l'action de bout en bout, éventuellement sans relecture humaine. C'est la forme la plus puissante et la plus exigeante en contrôles. Pour cadrer le périmètre d'un agent, le guide sur choisir une mission d'agent IA qui se termine vraiment insiste sur des missions avec un état final vérifiable, ce qui rejoint directement notre exemple.

Ce que chaque forme peut et ne peut pas faire

Le chatbot échoue dès que la réponse dépend d'une donnée personnelle non exposée ou d'une action à mener. Il peut halluciner une réponse plausible si sa base est incomplète. Sa limite principale : il ne tient aucun engagement.

L'assistant limite le risque parce qu'un humain valide chaque sortie. Sa limite est le débit : si vous avez cinquante confirmations à envoyer par jour, la relecture devient le goulot. Il ne convient pas non plus aux demandes où la validation humaine n'apporte rien, comme consulter un horaire.

L'agent peut traiter la demande entière, mais il hérite de tous les problèmes d'intégration : permissions, erreurs d'API, états intermédiaires. Une erreur d'agent n'est pas un texte mal tourné, c'est un rendez-vous supprimé ou un message envoyé au mauvais destinataire.

La même demande, trois traitements concrets

Reprenons : « décale notre rendez-vous et envoie une confirmation ».

• Chatbot : il répond « je ne peux pas modifier d'agenda, voici comment contacter votre interlocuteur ». Réponse correcte, travail non fait.
• Assistant : il rédige le message de confirmation avec la nouvelle date proposée et prépare un brouillon. Vous vérifiez la disponibilité, vous ajustez le ton, vous envoyez. L'agenda reste à votre charge, ou l'assistant prépare aussi un récapitulatif de modification.
• Agent : il consulte l'agenda, propose ou choisit un créneau, modifie l'événement, rédige et envoie la confirmation. Chaque étape est un appel d'outil qui peut échouer.

Le bon choix dépend du volume, du coût d'une erreur et de la tolérance à la relecture. Un tableau de décision arrive plus bas.

État durable : la vraie ligne de partage

Un chatbot vit dans la conversation. Une fois la session fermée, il ne se souvient de rien : pas de rendez-vous déplacé, pas d'historique fiable. C'est acceptable pour des questions isolées, rédhibitoire pour un suivi client.

Un assistant produit des artefacts : brouillons, résumés, propositions. Ces artefacts peuvent persister dans vos outils, mais leur cycle de vie reste manuel. Un brouillon oublié dans une boîte mail est un engagement qui n'a jamais été tenu.

Un agent doit maintenir un état durable : quel rendez-vous a été modifié, quelle confirmation a été envoyée, à qui, avec quel contenu. C'est souvent là que les projets échouent, pas dans la qualité du modèle. Si l'état de l'agent et l'état de vos outils divergent, vous ne savez plus ce qui a été promis au client. Le guide sur le transfert du chatbot à un conseiller humain montre le même problème sous un autre angle : reprendre une conversation exige de reconstruire son contexte.

Gestion des engagements et frontières d'autonomie

« Envoyer une confirmation » est un engagement envers le client. Toute architecture qui franchit cette étape sans contrôle doit répondre à trois questions : qui autorise l'envoi, comment prouver ce qui a été envoyé, et comment annuler une erreur.

Prenons le cas Gmail. Le scope gmail.compose permet de créer mais aussi d'envoyer des brouillons, et les scopes de type gmail.modify autorisent en outre l'envoi direct. Limiter un agent aux brouillons exige donc des contrôles applicatifs : un libellé de scope n'est pas une frontière de permission Gmail. En pratique, cela veut dire vérifier côté application qu'aucun appel d'envoi n'est possible, plutôt que se fier au nom de la permission. La documentation officielle des scopes de l'API Gmail détaille ces niveaux d'accès.

Autre subtilité : l'identifiant d'un brouillon Gmail est stable, mais l'identifiant du message qu'il contient change lors de sa modification. Si votre agent mémorise l'identifiant du message pour prouver ce qui devait être envoyé, cette preuve peut devenir obsolète après une retouche. Conservez l'identifiant du brouillon et une copie du contenu validé.

Sur Calendar, vous pouvez créer des événements avec des identifiants explicites, ce qui facilite le suivi. Mais il n'existe pas de transaction globale garantie entre Calendar et votre système : si l'agent modifie l'événement puis échoue avant d'envoyer la confirmation, vous êtes dans un état intermédiaire. Votre architecture doit savoir décrire et réparer cet état, personne d'autre ne le fera.

Outils, protocoles et limites de l'orchestration

Connecter un agent à ses outils passe souvent par des API ou des protocoles comme MCP. MCP échange des outils et du contexte, il ne choisit pas à votre place les règles métier ni les permissions. « L'agent peut appeler cet outil » et « l'agent a le droit d'envoyer au nom de l'entreprise » sont deux questions distinctes. Le guide sur connecter ses outils via API et MCP détaille cette séparation entre capacité technique et autorisation métier.

Gardez aussi en tête que connexion de transport, autorisation du fournisseur et preuve d'opération sont trois choses différentes. Une connexion qui fonctionne ne prouve ni que l'action était autorisée, ni qu'elle a eu lieu. Pour la preuve, journalisez les identifiants d'opérations retournés par les API et conservez-les avec le contenu concerné.

Le canal de messagerie change aussi les règles

Si la confirmation part sur WhatsApp, la plateforme impose ses propres contraintes. La fenêtre de service de 24 heures est réouverte par un message de l'utilisateur ; au-delà, il faut des modèles approuvés. La tarification de la plateforme est établie par message livré, avec des catégories et des marchés variables ; tous les messages ne sont pas payants, mais le coût unitaire dépend du contexte. Les règles de la plateforme WhatsApp Business encadrent aussi la conformité, la permission et la sortie du canal : un agent qui envoie des messages doit respecter ces règles, pas seulement celles de votre logique métier.

Attention enfin à une confusion fréquente : un QR code affiché dans une application ne prouve pas une connexion officielle à la Business Platform. Vérifiez le canal réel avant de concevoir des automatisations dessus.

Tableau décisionnel

Situation	Fonctionnement recommandé	Pourquoi
Questions fréquentes sur des informations publiques	Chatbot	Aucune action, aucune donnée personnelle, erreur peu coûteuse
Rédaction de réponses personnalisées sensibles	Assistant IA	La relecture humaine capte les erreurs de fond avant envoi
Décalage de rendez-vous avec confirmation, faible volume	Assistant IA	Le geste manuel est rapide, l'erreur d'agent coûte cher en confiance
Décalage de rendez-vous avec confirmation, volume élevé et règles claires	Agent IA	Le volume justifie l'automatisation si les règles sont déterministes
Modification d'agenda sans confirmation extérieure	Agent IA limité	Un seul outil, état vérifiable via l'identifiant d'événement
Envoi de messages sortants sur WhatsApp	Agent encadré	Fenêtre de 24 h, modèles approuvés et coût par message livré à intégrer
Processus réglementé où chaque envoi doit être justifié	Assistant IA	La validation humaine fait partie de la preuve

Quand une règle déterministe bat un agent

Un agent n'est pas toujours la bonne réponse. Contre-exemples où une règle simple est préférable :

• Renvoi par créneau : si la règle est « toute demande reçue après 17 h part le lendemain », un déclencheur horaire suffit. Un agent ajouterait de l'incertitude pour rien.
• Routage par mot-clé fiable : si trois catégories couvrent 95 % des demandes (hypothèse à valider sur vos données), un classement simple et explicable suffit souvent.
• Validation obligatoire : si chaque envoi doit être relu pour des raisons internes, l'agent n'apporte un gain que sur la préparation, pas sur l'exécution.
• Données non fiables : si l'agenda de référence est incomplet, un agent qui « décale » un rendez-vous sur des données fausses aggrave la situation.

La question à se poser : est-ce que la décision contient du jugement, ou seulement de l'exécution ? Si c'est de l'exécution avec des règles claires, une règle déterministe est plus prévisible, moins chère et plus facile à auditer.

Procédure : choisir et cadrer le bon fonctionnement

1. Décrivez la demande en verbes et en objets : « modifier un événement agenda », « envoyer un message de confirmation ». Chaque verbe devient une capacité à autoriser ou non.
2. Classez chaque verbe : lecture sans risque, écriture réversible, écriture irréversible ou engagement client. Les deux dernières appellent un contrôle fort.
3. Choisissez la forme minimale : chatbot si seule la lecture suffit, assistant si une validation humaine est nécessaire, agent seulement si le volume ou l'absence de valeur de la relecture le justifie.
4. Définissez l'état de référence : où vit la vérité (l'agenda, le CRM) et comment votre système la retrouve. Pour Calendar, la documentation sur la création et la synchronisation d'événements explique comment suivre les changements côté service.
5. Prévoyez l'état intermédiaire : que fait le système si l'événement est modifié mais la confirmation non envoyée ? Écrivez la règle de reprise avant la mise en production.
6. Testez les échecs, pas seulement le succès : outil indisponible, permission refusée, destinataire erroné. La recette d'un chatbot ou d'un agent se juge sur ces cas ; le guide sur de la recette à la livraison d'un chatbot propose une démarche de tests acceptables avant mise en service.

Exemple principal commenté : le scénario de confirmation

Voici un scénario hypothétique, construit pour illustrer les arbitrages. Une PME de services reçoit des demandes de décalage par email. Volume supposé : une trentaine par semaine, chaque erreur de confirmation pouvant coûter un créneau perdu.

Architecture choisie : un assistant pour la rédaction, un agent restreint pour la modification d'agenda, un point de validation humain avant envoi. Concrètement : l'agent consulte l'agenda, propose deux créneaux, modifie l'événement avec un identifiant explicite, puis prépare un brouillon de confirmation. Le chargé de clientèle relit le brouillon et envoie. La preuve se compose de l'identifiant d'événement, de l'identifiant de brouillon et d'une copie du texte validé.

Commentaire des choix. La modification d'agenda est automatisée parce qu'elle est réversible et vérifiable : on peut rouvrir l'agenda et voir l'état réel. L'envoi reste manuel parce qu'il constitue un engagement envers le client et que le volume ne justifie pas de supprimer la relecture. Le brouillon sert d'artefact de contrôle : tant qu'il n'est pas envoyé, rien n'est engagé. Et si le client répond « non, finalement pas ce créneau », l'annulation porte sur un événement identifiable, pas sur une promesse vague.

Ce découpage n'est pas universel. Avec un volume hypothétique de plusieurs centaines de demandes par semaine et des règles de replanification écrites, l'envoi pourrait être automatisé avec un échantillon de contrôle relu. Avec des enjeux contractuels forts, même la modification d'agenda pourrait repasser sous validation humaine.

Erreurs fréquentes et conduite à tenir

• Confondre capacité technique et autorisation : un outil accessible n'est pas un outil autorisé. Écrivez la liste des actions permises et faites-la respecter côté application.
• Se fier aux libellés de permissions : comme vu avec Gmail, un nom de scope ne garantit pas le comportement attendu. Testez ce que le système peut réellement faire.
• Négliger l'état intermédiaire : une grande partie des incidents d'agent se situent entre deux appels d'outils. Définissez la reprise avant le premier jour de production.
• Choisir l'agent par défaut : plus autonome ne veut pas dire meilleur. Chaque degré d'autonomie doit être justifié par le volume ou par l'absence de valeur de la relecture.
• Oublier le canal : les règles d'une plateforme de messagerie s'appliquent à votre agent comme à un humain.

Pour structurer un premier projet d'agent avec ces garde-fous, vous pouvez consulter comment créer un premier agent IA, et pour arbitrer entre les formes intermédiaires, comment choisir un assistant virtuel IA.

Questions fréquentes

Peut-on commencer par un chatbot puis évoluer vers un agent ?

Oui, et c'est souvent la trajectoire la plus sûre. Le chatbot vous apprend quelles questions reviennent et où sa base de connaissances est insuffisante. Ces données servent ensuite à cadrer une mission d'assistant ou d'agent sur les cas réellement fréquents, plutôt que sur des hypothèses.

Comment empêcher un agent d'envoyer des emails alors qu'il ne doit que préparer des brouillons ?

En combinant deux niveaux : un compte de service avec des droits aussi réduits que possible, et des contrôles applicatifs qui bloquent tout appel d'envoi. Comme les scopes Gmail peuvent couvrir plusieurs comportements, la restriction doit être prouvée par un test, pas déduite du nom de la permission.

Que faire si l'agent a modifié l'agenda mais n'a pas envoyé la confirmation ?

C'est un état intermédiaire classique. Votre système doit le détecter, l'exposer clairement (événement modifié, confirmation en attente) et proposer une reprise : renvoyer le brouillon, proposer un autre créneau ou annuler la modification. Sans cette règle écrite, l'état reste invisible jusqu'à la réclamation du client.

MCP rend-il un agent plus autonome ?

Non. MCP organise l'échange d'outils et de contexte entre le modèle et vos services ; il ne définit ni vos règles métier ni vos permissions. L'autonomie vient de ce que vous décidez d'autoriser, pas du protocole de connexion.

Un assistant IA peut-il suffire pour le service client ?

Souvent, oui, surtout quand chaque réponse engage l'entreprise. L'assistant rédige une proposition personnalisée, l'humain valide et envoie ; le transfert au conseiller reste organisé pour les cas sortant du cadre. Le gain porte sur la qualité et la vitesse de préparation, pas sur la suppression du contrôle humain.