Construire son propre chatbot intelligent en entreprise

Monter un chatbot sans écrire de code est devenu facile. C’est même le problème : c’est tellement facile qu’on peut en mettre un en ligne en une soirée, et découvrir trois semaines plus tard qu’il raconte n’importe quoi à vos clients avec une assurance parfaite.

Je vais donc prendre le sujet dans l’autre sens. Pas « comment brancher un modèle sur une interface de chat » — ça, une plateforme no-code le fait pour vous — mais ce qui distingue un chatbot utile d’un chatbot dangereux, et le travail réel que demande le premier.

Un chatbot, c’est trois choses très différentes

Le mot recouvre des objets qui n’ont pas du tout le même coût ni le même risque.

Le chatbot à scénarios ne comprend rien : il propose des boutons, suit un arbre de décision, et transmet à un humain quand il sort du chemin balisé. Aucune IA là-dedans. C’est vieux, c’est limité, et pour une FAQ de dix questions c’est encore souvent la meilleure réponse — parce qu’il ne peut pas inventer.

Le wrapper d’API, c’est un modèle de langage branché sur une fenêtre de chat. Il parle bien, il est agréable, et il ne sait rien de votre entreprise. Interrogé sur vos tarifs ou vos délais de livraison, il produira une réponse plausible et fausse. C’est ce que la plupart des tutoriels appellent « créer son chatbot en 20 minutes », et c’est ce qu’il ne faut pas mettre en contact avec de vrais clients.

Le chatbot documenté, souvent désigné par l’acronyme RAG, va chercher la réponse dans vos contenus avant de rédiger : vos fiches produits, votre FAQ, vos conditions de vente. Il ne répond que sur cette base, et il est censé dire qu’il ne sait pas quand la base ne contient rien. C’est la seule des trois familles qui tienne en service client, et c’est aussi la seule qui demande un vrai travail préalable.

Le travail réel est dans vos contenus, pas dans l’outil

Voilà ce que les guides no-code passent sous silence : la qualité d’un chatbot documenté est très exactement la qualité de la documentation qu’on lui donne. Si vos conditions de livraison existent en trois versions contradictoires — une sur le site, une dans un vieux PDF, une dans la tête de la personne qui gère les commandes — le chatbot livrera les trois, au hasard.

Dans les projets que je mène, la partie la plus longue n’est jamais l’intégration. C’est de rassembler, trancher et écrire ce que l’entreprise répond réellement à ses vingt questions les plus fréquentes. Ce travail a une vertu inattendue : il est utile même si le chatbot ne voit jamais le jour, parce qu’il produit une FAQ propre que l’équipe peut utiliser.

Côté outillage, les plateformes no-code font aujourd’hui l’essentiel : Bubble pour l’interface, Airtable pour structurer les contenus et les conversations, Glide pour une diffusion mobile — et une bonne dizaine d’équivalents qui font la même chose. Le choix de la plateforme est le point le moins déterminant du projet, et je vois régulièrement des équipes y consacrer les trois quarts de leur temps de réflexion — puis brancher le résultat sur une documentation qui n’existe pas encore.

Les garde-fous qui ne sont pas optionnels

Un chatbot en contact avec des clients a besoin de quatre choses, et je n’en cède aucune, même quand elles allongent le projet.

Un périmètre déclaré. Le modèle doit avoir l’instruction explicite de ne répondre que sur la base des contenus fournis, et de renvoyer vers un humain sinon. Sans cette consigne, il comblera les trous.

Une porte de sortie visible. À tout moment, l’utilisateur doit pouvoir joindre quelqu’un. Un chatbot qui enferme est un chatbot qui fait perdre des clients — ce que les gens détestent n’est pas de parler à une machine, c’est de ne pas pouvoir en sortir.

Une trace consultable. Les conversations doivent être relues, au moins les premières semaines. C’est là qu’on découvre les questions qu’on n’avait pas anticipées, et les réponses embarrassantes.

Une limite de dépense. Chaque échange coûte quelque chose. Un chatbot public sans plafond, c’est une facture ouverte, et éventuellement une cible pour qui s’amuse à le solliciter en boucle.

Faut-il aller jusqu’à l’agent ?

La suite logique du chatbot documenté, c’est l’agent : au lieu de seulement chercher dans des documents, il consulte votre système — état d’une commande, disponibilité d’un créneau — et agit. C’est nettement plus utile. C’est aussi un autre métier : dès que le système écrit dans vos données au lieu de seulement les lire, la moindre erreur devient coûteuse.

Ma règle est simple : lecture seule d’abord, écriture ensuite, et jamais d’écriture sans confirmation explicite. Un agent qui annule une commande parce qu’il a mal interprété une phrase ambiguë fait plus de dégâts qu’il n’apporte de gain.

Ce que je conseille de faire dans l’ordre

Commencez par mesurer : notez pendant deux semaines les questions qui arrivent réellement, et à quelle fréquence. Si les trois quarts du volume tiennent dans huit questions, vous n’avez peut-être pas besoin d’un modèle de langage — une FAQ correcte et un formulaire bien fait suffiront, pour un coût nul et un risque nul.

Si le volume et la variété justifient un chatbot, écrivez les contenus avant de choisir l’outil, lancez-le en interne avant de l’ouvrir au public, et gardez la main sur la sortie vers l’humain. C’est la même logique que celle qui guide mes automatisations IA pour PME : on part de la tâche réelle, pas de la technologie disponible.

Si votre besoin est plutôt d’absorber un flux de demandes répétitives sans dégrader la relation, la question du partage entre l’IA et vos conseillers est traitée à part dans l’IA au service du service client. Et si vous vous demandez surtout ce que ces outils changent pour les postes concernés, j’ai répondu à cette question dans l’IA va-t-elle nous remplacer ?.