Comment fonctionnent vraiment les chatbots : règles, récupération, LLM, outils et transfert à un humain

Une conversation avec un chatbot peut sembler sans effort jusqu'au moment où elle échoue. Vous demandez où se trouve un colis. Le bot répète une politique de livraison générique. Vous fournissez le numéro de commande. Il redemande le numéro de commande. Après trois boucles, la petite bulle de discussion qui promettait la commodité devient une porte verrouillée entre vous et la réponse.

L'expérience inverse est presque invisible. Le chatbot reconnaît que vous voulez suivre une commande, capture le bon numéro, vérifie un enregistrement actuel, explique le résultat en une phrase et propose une personne si le cas est inhabituel. La différence ne tient pas simplement au fait qu'un bot a plus d'intelligence artificielle. C'est qu'un système conversationnel a une tâche plus claire, un meilleur état, des outils fiables, des limites plus sûres et un moyen planifié de se rétablir.

Ce guide regarde derrière la bulle de discussion. Il explique les principaux types de chatbots, suit un message à travers une architecture réelle et montre pourquoi un langage fluide n'est qu'une partie d'une conversation fiable.

Qu'est-ce qu'un chatbot ?

Un chatbot est un logiciel qui échange des messages avec une personne par texte, voix ou un autre canal conversationnel. Il interprète une entrée, décide de ce qui doit se passer ensuite et renvoie une réponse ou une action. Cette définition large inclut un menu fixe dans un widget d'assistance, un flux vocal qui collecte un numéro de compte, un assistant de connaissances qui recherche des documents et un système à modèle de langage capable de rédiger des réponses ouvertes.

La conversation est l'interface, pas la technologie sous-jacente. Deux chatbots peuvent sembler identiques tout en fonctionnant de manières complètement différentes. L'un suit un arbre de décision. Un autre fait correspondre une intention et appelle un webhook. Un troisième récupère des documents et demande à un grand modèle de langage d'écrire une réponse. Les systèmes les plus utiles combinent souvent plusieurs approches.

Une leçon d'ELIZA, soixante ans plus tard

En 1966, Joseph Weizenbaum a publié ELIZA, un programme de conversation en langage naturel. Son script DOCTOR bien connu utilisait des motifs et des transformations pour transformer des parties de la déclaration d'un utilisateur en réponse. Une phrase telle que « Je suis malheureux » pouvait être mise en correspondance, réarrangée et reflétée comme une question. L'échange pouvait sembler attentif même si le programme avait peu d'informations sur la vie de la personne et aucun modèle de langage moderne.

ELIZA reste pertinente parce que les gens réagissent socialement au langage. Une question opportune, une phrase sympathique ou une réponse confiante peuvent créer une impression de compréhension qui dépasse la machinerie sous-jacente. Les modèles modernes sont bien plus capables, mais l'interface invite toujours à la même erreur : juger ce qu'un système sait par la façon dont il semble naturel.

Un chatbot professionnel doit donc gagner la confiance par l'exécution correcte des tâches, des limites visibles et des erreurs récupérables. La personnalité peut améliorer une interaction. Elle ne peut pas remplacer l'accès à la bonne information ou un processus sûr.

Trois principales architectures de chatbot

Les chatbots sont plus faciles à comprendre si l'on sépare trois familles architecturales. Ce ne sont pas des générations strictes où chacune rend les autres obsolètes. Ce sont des outils avec des forces différentes.

1. Règles et flux de conversation

Un chatbot à base de règles suit des chemins conçus à l'avance. Il peut afficher des boutons, faire correspondre des mots-clés, remplir un formulaire ou passer d'un état à un autre lorsque des conditions sont satisfaites. La logique peut être explicite : si l'utilisateur veut changer une date de livraison, collectez le numéro de commande, vérifiez si le colis est éligible, affichez les dates disponibles et demandez une confirmation.

Les règles sont précieuses lorsque le processus est étroit et que les actions acceptables sont connues. Elles rendent les étapes de conformité et les actions destructrices plus faciles à contrôler. Leur faiblesse apparaît lorsque les gens formulent des demandes de manière inattendue ou sortent du chemin conçu. Un bon système à règles a besoin de solutions de repli, de corrections et de voies d'évacuation, pas seulement d'un chemin de réussite parfait.

2. Correspondance d'intention et recherche

Un système à base d'intentions estime ce que l'utilisateur essaie de faire, puis extrait des détails utiles appelés entités ou paramètres. « Suivre la commande 4821 » peut correspondre à une intention de suivi de commande et à un paramètre de numéro de commande. La documentation sur les intentions de Dialogflow de Google Cloud décrit ce modèle comme une comparaison d'une entrée avec des phrases d'entraînement pour trouver une correspondance.

La recherche ajoute une couche de recherche. Au lieu de répondre à partir d'une réponse fixe seule, le système trouve des passages pertinents, des entrées de politique, des articles d'aide ou des enregistrements. Un chatbot de recherche peut citer directement une réponse connue ou transmettre du matériel sélectionné à un générateur. Sa qualité dépend de ce qui a été indexé, de la façon dont la requête a été formulée, de la fraîcheur de la source et de la capacité du système à trouver le bon passage.

3. Modèles de langage, outils et systèmes hybrides

Un grand modèle de langage peut interpréter des formulations variées et produire des réponses naturelles sur une gamme beaucoup plus large d'entrées. Il peut résumer, expliquer, traduire, poser une question de clarification ou transformer une sortie d'outil structurée en langage lisible. Pour une explication plus approfondie de la génération de jetons et des limites du modèle, voir Qu'est-ce que l'IA, vraiment ?.

Le modèle a toujours besoin d'aide pour les faits et actions en direct. Il ne peut pas connaître l'emplacement actuel de la commande 4821 à moins que l'application ne fournisse ces informations par le contexte, la recherche ou un outil. Il ne peut pas émettre un remboursement en toute sécurité simplement parce qu'il peut écrire la phrase « Votre remboursement est terminé ». L'application doit connecter le modèle à des services autorisés et vérifier le résultat.

C'est pourquoi de nombreux chatbots modernes sont hybrides. Les règles protègent les transitions critiques. La recherche fournit des connaissances actuelles. Un modèle de langage gère un langage flexible. Les outils lisent ou modifient l'état externe. Le code conventionnel valide les autorisations et les sorties. Un humain prend les cas qui nécessitent du jugement ou de l'autorité.

Ce qui se passe pendant un tour de chatbot

Suivez un message simple : « Où est la commande 4821 ? » Une implémentation réelle peut combiner ou renommer les étapes, mais les responsabilités sous-jacentes restent reconnaissables.

1. Recevoir et normaliser l'entrée. Le canal peut fournir du texte tapé, de la parole transcrite, des sélections de boutons, la langue ou des métadonnées de session.
2. Identifier l'objectif. Le système détermine si la demande concerne le suivi, l'annulation, le paiement, un autre sujet ou quelque chose de non pris en charge.
3. Extraire les détails requis. Dans ce cas, le numéro de commande est 4821. S'il manque ou est ambigu, le bot doit demander plutôt que d'inventer.
4. Vérifier l'état de la conversation. Le système détermine ce qu'il sait déjà, ce qu'il est autorisé à conserver et quelle étape est active.
5. Récupérer des connaissances ou appeler un outil. Un service de suivi renvoie le statut actuel. Le chatbot ne doit pas créer ce statut à partir de modèles de langage.
6. Composer et valider la réponse. L'application transforme le résultat en langage clair, vérifie les champs requis et évite d'exposer des données internes ou personnelles.
7. Répondre, se rétablir ou transférer. Un résultat normal revient à l'utilisateur. Une erreur, un cas non pris en charge ou une demande de personne suit une autre voie.

Google Cloud utilise le terme fulfillment pour la partie d'un tour de conversation qui renvoie une réponse statique, appelle un webhook pour des informations dynamiques, définit des paramètres ou effectue une action. Sa documentation sur le fulfillment de Dialogflow établit une distinction importante : comprendre la demande et la satisfaire sont des responsabilités distinctes.

L'état de la conversation n'est pas la mémoire humaine

Un chatbot a besoin de suffisamment d'état pour éviter de recommencer à chaque tour. L'état de session peut enregistrer que la tâche actuelle est le suivi de colis, que le numéro de commande est 4821 et que l'utilisateur a déjà confirmé un code postal. Sans état, « Et le deuxième colis ? » n'a aucune référence utilisable.

Cet état est une donnée conçue, pas un souvenir humain. Certains systèmes ne conservent que la session en cours. D'autres stockent l'historique de la conversation, des résumés, des préférences ou des informations de compte. Un modèle peut également ne recevoir qu'une partie d'une longue conversation parce que son contexte a une capacité finie ou parce que l'application limite délibérément ce qui est envoyé.

Les utilisateurs ne doivent pas supposer qu'un chatbot oublie lorsqu'une fenêtre se ferme ou se souvient parce qu'il parle comme s'il le faisait. La conservation, le lien au compte, l'utilisation pour la formation et la suppression dépendent du service spécifique. Avant de partager des informations sensibles, examinez l'explication de confidentialité du service et utilisez le minimum d'informations nécessaires à la tâche.

Comment fonctionne la génération augmentée par récupération

Les paramètres d'un modèle de langage sont un mauvais endroit pour conserver une politique de retour fréquemment modifiée. La génération augmentée par récupération, généralement abrégée en RAG, répond à cela en recherchant une collection externe pour du matériel pertinent et en plaçant des passages sélectionnés dans le contexte du modèle avant qu'il n'écrive la réponse.

L'article original Retrieval-Augmented Generation combinait un générateur pré-entraîné avec une mémoire non paramétrique explicite récupérée à partir d'un index. Le modèle général apparaît maintenant dans de nombreux assistants de connaissances : rechercher d'abord, générer ensuite.

Un pipeline RAG utile a au moins quatre occasions d'échouer. La collection source peut être incomplète. Le document peut être obsolète. La récupération peut sélectionner un passage non pertinent. Le générateur peut mal lire ou embellir ce qu'il a reçu. Les citations n'aident que si elles pointent vers la source de support exacte et que l'utilisateur peut l'inspecter.

Le RAG améliore donc l'accès à des connaissances actuelles et inspectables mais ne garantit pas la vérité. Il doit être évalué de bout en bout : la bonne source est-elle entrée dans l'index, la recherche l'a-t-elle trouvée, la réponse est-elle restée dans les preuves et la citation a-t-elle soutenu l'affirmation ?

Les réponses et les actions nécessitent différents niveaux de contrôle

Un chatbot qui explique une politique de remboursement n'est pas la même chose qu'un chatbot qui émet un remboursement. Le deuxième système peut modifier l'état externe. Il peut appeler un service de compte, un calendrier, un système de paiement, un outil de messagerie ou un contrôle d'appareil. Cette capacité est parfois décrite comme une agence, mais la question pratique est plus simple : que peut faire cette application au-delà de produire du texte ?

Un chemin d'action sûr doit garder les contrôles importants en dehors de la prose du modèle :

• Authentifier l'utilisateur et confirmer que le compte ou la ressource lui appartient.
• Autoriser l'action spécifique plutôt que de donner au chatbot un accès large.
• Valider les arguments d'outil, les montants, les destinations et les plages autorisées avec du code conventionnel.
• Exiger une confirmation explicite avant des actions irréversibles ou coûteuses.
• Renvoyer un résultat d'outil vérifié au lieu de supposer qu'une action a réussi.
• Enregistrer suffisamment d'informations pour enquêter sur les échecs sans exposer de données sensibles inutiles.

L'illustration montre une architecture cible, pas une promesse concernant un chatbot particulier. Un modèle de langage peut suggérer quel outil appeler, mais l'application environnante doit décider si l'appel est autorisé. Plus d'autonomie augmente la valeur des limites d'autorisation, des limites de débit, de la confirmation, de la surveillance et de l'examen humain.

Injection de prompt : quand le contenu essaie de devenir une instruction

Un chatbot utilisant des outils ou de la recherche peut lire du texte fourni par les utilisateurs, des sites Web, des e-mails ou des documents. Une partie de ce texte peut contenir des instructions visant le modèle, comme lui dire d'ignorer les règles précédentes, de révéler des informations cachées ou d'appeler un outil d'une manière non intentionnelle. C'est une injection de prompt.

Le projet de sécurité GenAI de l'OWASP répertorie l'injection de prompt comme un risque majeur pour les applications à modèle de langage. Le problème central est que les modèles traitent les instructions et le contenu ordinaire via le même canal de langage. Un document non fiable peut sembler grammaticalement similaire à une instruction de l'application.

Aucun prompt ne peut remplacer les contrôles au niveau du système. Les applications doivent traiter le contenu récupéré et fourni par l'utilisateur comme non fiable, restreindre les outils disponibles, appliquer le moindre privilège, valider les appels d'outils, isoler les opérations sensibles et demander une confirmation lorsque les conséquences comptent. Le modèle ne doit pas recevoir un passe-partout simplement parce que l'interface est conversationnelle.

Pourquoi les chatbots donnent des réponses fausses ou frustrantes

Ils comprennent mal la demande

Le langage est ambigu. « Fermer mon compte » pourrait signifier se déconnecter, supprimer un profil, annuler un abonnement ou fermer un compte financier. Un chatbot fiable reconnaît quand le coût de deviner est plus élevé que le coût d'une question de clarification.

Ils manquent d'informations requises

Un modèle peut connaître le vocabulaire général de l'expédition mais manquer l'enregistrement de commande de l'utilisateur. La recherche peut manquer la politique pertinente. Un outil peut être indisponible. La réponse correcte est de déclarer la limitation ou d'utiliser un repli, pas de combler le vide avec une histoire plausible.

Ils génèrent un faux confiant

Le NIST appelle confabulation le contenu génératif faux ou erroné présenté avec confiance. Son profil d'IA générative note que ce comportement peut inclure une logique ou des citations fabriquées. La fluidité rend ces échecs plus difficiles à remarquer, pas moins susceptibles d'avoir de l'importance.

Ils perdent l'état ou transportent le mauvais état

Une session peut oublier un détail, confondre deux commandes, conserver une hypothèse incorrecte ou appliquer des informations d'une tâche à une autre. L'état doit être suffisamment visible pour être corrigé et suffisamment limité pour éviter un mélange non intentionnel.

Ils n'ont pas de sortie élégante

La boucle la plus pénible est souvent un défaut de conception. Le bot a atteint la limite de ses capacités mais reformule sans cesse la même réponse. Un repli doit changer de trajectoire : demander un détail manquant, proposer une option prise en charge, créer un ticket ou transférer la conversation.

Le transfert vers un humain fait partie du système, ce n'est pas un aveu d'échec

Certaines demandes sont ambiguës, émotionnelles, exceptionnelles ou lourdes de conséquences. D'autres exigent une autorité que le chatbot ne devrait pas avoir. Un spécialiste humain peut interpréter le contexte, négocier une exception, assumer la responsabilité ou reconnaître que le processus documenté ne correspond pas au cas.

Un transfert ne fonctionne que si le contexte l'accompagne. La personne doit recevoir l'objectif de l'utilisateur, les détails confirmés, les résultats d'outils pertinents et la raison de l'escalade. Forcer l'utilisateur à répéter toute la conversation transforme un transfert techniquement réussi en mauvaise expérience.

La documentation sur le transfert vers un agent humain de Dialogflow traite le transfert comme une transition explicite. Ce principe de conception dépasse une seule plateforme : l'escalade doit être un parcours testé avec un responsable, pas une phrase que le bot improvise quand il est bloqué.

Comment juger si un chatbot est bon

Une démo convaincante est facile à mettre en scène. Un chatbot fiable doit gérer les variations ordinaires et les échecs visibles. L'évaluation doit commencer par la tâche que l'utilisateur est venu accomplir.

• Réussite de la tâche : l'utilisateur a-t-il obtenu la réponse ou effectué l'action correctement ?
• Ancrage : les affirmations factuelles ont-elles suivi la source fournie ou le résultat d'outil vérifié ?
• Récupération : les informations manquantes, les événements sans correspondance et les échecs d'outils ont-ils conduit à une étape utile ?
• Sécurité : l'autorisation, la confirmation, le traitement des données et les limites des outils ont-ils tenu face à des entrées adverses ?
• Qualité du transfert : la conversation a-t-elle atteint la bonne personne avec suffisamment de contexte ?
• Langue et accessibilité : le flux a-t-il fonctionné dans les langues prises en charge, les styles de saisie, les conditions vocales, la navigation au clavier et les technologies d'assistance ?
• Effort utilisateur : combien de tours, de répétitions et de corrections ont été nécessaires pour terminer la tâche ?

Les conversations de test doivent inclure plus que le chemin heureux. Utilisez des numéros de commande manquants, deux numéros dans un même message, des fautes d'orthographe, des demandes non prises en charge, des documents obsolètes, des délais d'outil dépassés, des demandes de changement de sujet, des demandes directes de parler à une personne et des instructions malveillantes cachées dans le contenu récupéré. Les conseils de conception d'agent de Google Cloud recommandent également une conception itérative et des cas de test plutôt que de tenter de concevoir chaque parcours à la fois.

Comment utiliser un chatbot sans renoncer à son jugement

1. Énoncez l'objectif et le contexte minimal pertinent. Une demande précise réduit les tours inutiles.
2. Ne collez pas de mots de passe, codes d'authentification, informations de paiement, clés privées ou enregistrements sensibles, sauf si le service de confiance spécifique l'exige explicitement et protège cette saisie.
3. Distinguez une explication d'un résultat en direct. Demandez si la réponse provient d'un enregistrement actuel, d'une source citée ou de la connaissance générale du modèle.
4. Ouvrez les citations et vérifiez les affirmations importantes. Un lien source peut être non pertinent, obsolète ou incohérent avec la réponse.
5. Examinez chaque action avant de la confirmer. Vérifiez le compte, le montant, la destination, la date et si le changement peut être annulé.
6. Demandez à parler à une personne lorsque le bot se répète, manque d'autorité, comprend mal un problème sensible ou ne peut pas montrer d'où vient la réponse.

Le modèle mental à retenir

Un chatbot n'est pas une personnalité vivant dans une bulle. C'est une interface conversationnelle connectée à une combinaison de flux, classifieurs, recherche, modèles de langage, enregistrements, outils, politiques, contrôles de sécurité et personnes. La réponse que vous voyez est la dernière étape de ce système plus vaste.

La meilleure question n'est pas « Ce bot semble-t-il humain ? » Demandez s'il a compris la tâche, utilisé les bonnes preuves, respecté ses autorisations, récupéré honnêtement et vous a laissé le contrôle. Le langage naturel rend le système plus facile à aborder. Une ingénierie solide le rend digne d'être utilisé.

Références principales et techniques

• Joseph Weizenbaum, ELIZA: A Computer Program for the Study of Natural Language Communication Between Man and Machine, 1966.
• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024.
• Google Cloud, Dialogflow CX documentation for intents, fulfillment, agent design, and human handoff.
• OWASP GenAI Security Project, LLM01:2025 Prompt Injection.