Le mot « chatbot » recouvre des choses très différentes, dont les coûts et les résultats n’ont rien de comparable. Ce guide explique ce qui existe aujourd’hui, ce qui fait échouer la plupart des projets, et les questions à poser avant de signer.
Les trois familles coexistent sur le marché. Elles ne coûtent pas la même chose et ne rendent pas le même service — et un devis ne précise pas toujours de laquelle il s’agit.
Un arbre de décision avec des boutons. Il ne comprend rien : il suit un chemin écrit à l’avance. Peu coûteux et parfaitement prévisible, mais il ne répond qu’aux questions anticipées et devient ingérable au-delà de quelques dizaines de branches.
La génération des années 2010. Le système reconnaît une intention parmi une liste que vous avez entraînée avec des exemples de formulations. Plus souple, mais chaque nouvelle question demande du réentraînement et un travail d’étiquetage continu.
Le système comprend une question formulée librement et rédige sa réponse à partir de vos documents. Aucun scénario à écrire, aucune intention à entraîner. En contrepartie, il faut encadrer le risque d’une réponse fausse mais crédible.
C’est la question qui change tout : le budget, le délai et le niveau d’exigence. Beaucoup de projets échouent pour avoir traité les deux de la même façon.
C’est le mécanisme qui distingue un assistant fiable d’un générateur de texte plausible.
Conséquence pratique : mettre à jour un document met à jour les réponses. Rien à réécrire, rien à réentraîner.
Les causes d’échec sont étonnamment répétitives, et aucune n’est technique.
Un assistant censé répondre à tout ne répond bien à rien. Ceux qui fonctionnent couvrent un domaine étroit — le support d’un produit, une procédure interne — et annoncent clairement ce qu’ils ne traitent pas.
Le client qui tourne en rond sans pouvoir joindre quelqu’un ne se souviendra que de ça. Le transfert doit être accessible à tout moment, et transmettre l’historique pour ne pas faire tout répéter.
Le chatbot répond à partir de vos documents : si personne ne les met à jour, il énonce fidèlement des informations périmées. Il faut désigner un responsable des contenus avant la mise en ligne, pas après.
Sans relecture régulière d’un échantillon de conversations, personne ne sait s’il répond juste. Les erreurs ne remontent pas toutes seules : un utilisateur insatisfait s’en va en silence.
Elles distinguent rapidement une offre sérieuse d’une démonstration flatteuse.
Nous ne vendons pas de chatbot en tant que produit. Nous construisons des assistants adossés aux documents et aux outils d’une entreprise, quand le besoin le justifie.
Et nous commençons presque toujours en interne : c’est là que le gain est le plus rapide, le risque le plus faible, et qu’on apprend ce qu’il faut savoir avant d’exposer quoi que ce soit à des clients.
Un chatbot classique suit un arbre de décision écrit à l’avance : il ne comprend que ce qui a été prévu et répond à côté dès qu’on formule autrement. Un chatbot fondé sur un modèle de langage comprend une question posée librement et rédige sa réponse. En contrepartie, il peut produire une réponse fausse mais crédible — d’où la nécessité de l’adosser à vos documents et de citer les sources.
C’est le risque principal, et il se maîtrise. La méthode consiste à ne jamais laisser le modèle répondre de mémoire : il cherche d’abord le passage pertinent dans vos documents, puis rédige à partir de ce passage et cite sa source. On lui impose aussi de dire qu’il ne sait pas quand l’information n’y figure pas — c’est une consigne qui se teste et se mesure, pas un vœu pieux.
Un prototype interrogeant vos vrais documents se construit en deux à quatre semaines. Une mise en production destinée à vos clients demande davantage : gestion des cas limites, transfert vers un humain, journalisation, tests de sécurité. Le prototype sert à décider si la suite en vaut la peine.
Non, c’est justement ce qui a rendu la génération précédente ingérable. Vous fournissez vos documents existants — procédures, fiches, conditions générales, historique de support — et le chatbot s’appuie dessus. Mettre à jour un document met à jour les réponses, sans réécrire de scénario.
Oui, et c’est ce qui distingue un assistant utile d’une FAQ déguisée. Consulter un statut de commande, ouvrir un ticket, vérifier une disponibilité : le modèle appelle vos interfaces de programmation avec les permissions que vous définissez. Un serveur MCP est une façon standard d’exposer ces actions.
Deux postes distincts : le développement, chiffré à partir du périmètre, et un coût d’usage facturé par le fournisseur du modèle, proportionnel au nombre de conversations. Ce second poste doit être estimé avant de se lancer à partir de votre volume réel, pas découvert sur la première facture. Un chatbot public sans plafond de dépense est une imprudence.
Non, et le vendre ainsi est le meilleur moyen d’échouer. Il absorbe les questions répétitives — horaires, délais, procédures, statut d’une commande — ce qui laisse à vos équipes les cas qui demandent du jugement. Une escalade vers un humain doit rester possible à tout moment, sans faire répéter au client ce qu’il a déjà écrit.
En le mesurant, ce que peu de projets prévoient. Trois indicateurs suffisent : la part de conversations résolues sans intervention humaine, la part de réponses jugées fausses ou hors sujet lors d’une relecture par échantillon, et le temps gagné par vos équipes. Sans ces chiffres, personne ne saura jamais si l’investissement valait quelque chose.
Décrivez le besoin en quelques lignes. Nous vous dirons franchement si un assistant est la bonne réponse, et par quoi commencer.
