Chatbots

Ce qui est inclus dans la prestation

Nous concevons et assemblons des chatbots pour la vente et le support : nous élaborons les scénarios de dialogue, nous écrivons la logique de traitement des requêtes, nous connectons les sources de données du client et nous déployons le bot sur Telegram, sur le site ou dans les messageries. D'abord nous analysons les demandes réelles du client, nous dégageons les questions et les transactions récurrentes, puis nous les transformons en arbre de scénarios et en ensemble de réponses basées sur vos données, et non sur des modèles abstraits. Nous connectons le bot au CRM, pour que les leads et l'historique des échanges arrivent automatiquement dans les fiches, sans transfert manuel. Si l'équipement du client est dans le circuit, nous écrivons pour lui la partie logicielle et configurons l'échange de données, mais l'appareil lui-même reste le vôtre et fonctionne de votre côté. À l'arrivée, vous recevez un système opérationnel avec une documentation sur les scénarios et les accès, et non un script ponctuel que personne ne pourra maintenir.

Comment cela fonctionne, au fond

Le bot reçoit un message, identifie l'intention de l'utilisateur et choisit une branche : répondre depuis un scénario prédéfini, remonter des données depuis la base ou transmettre la question à un modèle de langage. Les cas simples et fréquents sont traités par des règles strictes, parce qu'ils sont prévisibles et moins coûteux à exploiter, tandis que les formulations libres et les requêtes atypiques partent vers le LLM avec un contexte prédéfini sur votre produit. Entre ces couches se trouve un orchestrateur sur n8n, qui relie en un flux unique l'API de Telegram, la base de connaissances, le CRM et le modèle, et décide où diriger chaque requête. Toutes les demandes sont journalisées, on voit donc où le bot a répondu lui-même, où il a passé la main à un opérateur et où il s'est trompé, et nous utilisons ces données pour affiner les scénarios. Ce schéma donne le contrôle des réponses : les chatbots ne fabulent pas là où il existe une règle précise, et ne sollicitent le modèle que là où il est réellement nécessaire.

D'où viennent les chatbots

Le premier programme de ce genre est considéré comme étant ELIZA, que Joseph Weizenbaum a créé au Massachusetts Institute of Technology en 1966 ; son scénario DOCTOR imitait les répliques d'un psychothérapeute par substitution de modèles, bien que la machine ne comprenait pas le sens du dialogue. En 1972, le psychiatre Kenneth Colby a écrit PARRY, qui modélisait la parole d'un patient, et en 1995 Richard Wallace a publié A.L.I.C.E. avec une vaste base de règles de type « modèle — réponse ». En 2001 est apparu SmarterChild d'ActiveBuddy, qui fonctionnait directement au sein d'AOL Instant Messenger et de MSN Messenger et a montré le premier des chatbots dans des messageries grand public. Tous ces systèmes restaient scénarisés : ils comparaient des motifs et ne construisaient pas de réponse par le sens. Le tournant est venu avec les modèles de langage : le lancement de ChatGPT le 30 novembre 2022 a rendu les réponses génératives accessibles à un large marché et a fixé le format actuel de la prestation.

Pourquoi un paramétrage précis est important

Le bot communique au nom de l'entreprise, c'est pourquoi le prix d'une erreur dans la logique, c'est un lead perdu ou une réponse erronée au client, et pas seulement un plantage du code. Un modèle de langage sans cadre strict tend à inventer des faits, des prix et des conditions, et cela ne s'élimine pas par magie, mais par l'ingénierie : des scénarios précis, la vérification des réponses sur la base de données et la limitation du modèle au seul contexte autorisé. La qualité du résultat est définie non par le simple fait de connecter un réseau de neurones, mais par le soin de l'assemblage — comment les intentions sont décrites, comment les branches sont séparées, comment sont traités les cas vides et litigieux. Le même principe vaut lorsque nous préparons le programme de l'équipement du client : la machine découpe, soude ou imprime selon le programme de commande, et c'est de sa justesse que dépend le résultat sur le métal, et non d'une belle interface. C'est pourquoi l'essentiel du travail se trouve dans la partie logicielle et son débogage, et non dans la connexion d'une API toute prête en deux clics.

Notre stack et nos outils

Le socle du bot dans la messagerie, nous le construisons sur l'API Telegram Bot — c'est l'interface officielle pour recevoir les messages, envoyer les réponses, les boutons et les webhooks. Le maillon de liaison, c'est n8n, une plateforme d'automatisation open source où, à partir de nœuds, on assemble un flux : une requête arrive, on vérifie dans la base, au besoin on sollicite le modèle, on inscrit le résultat dans le CRM. Le dialogue libre et la compréhension des formulations sont assurés par le LLM, à qui nous donnons le contexte du produit et les règles de comportement, afin que les réponses s'appuient sur vos données, et non sur des connaissances générales issues de l'entraînement. Les intégrations avec le CRM (transmission des leads, des statuts et de l'historique des échanges) bouclent le circuit, pour que les échanges se transforment en transactions comptabilisées, au lieu de rester dans le chat. Nous sélectionnons la stack selon la tâche : si le client dispose déjà d'un équipement ou de son propre système, nous écrivons la couche logicielle correspondante et configurons l'échange, au lieu d'imposer un remplacement.

Quand sont apparus les outils clés

L'API Telegram Bot a été ouverte le 24 juin 2015, et c'est précisément à partir de ce moment qu'il est devenu possible de créer massivement des chatbots directement au sein de la messagerie, sans applications séparées. La vague actuelle des modèles de langage a été lancée par l'article de Google « Attention Is All You Need » de 2017, qui décrivait l'architecture du transformeur sur laquelle reposent les LLM actuels. Sur sa base, OpenAI a publié GPT-1 en 2018 et GPT-3 avec 175 milliards de paramètres le 28 mai 2020, et le ChatGPT public est sorti le 30 novembre 2022. La plateforme d'automatisation n8n, que nous utilisons comme orchestrateur, est apparue en tant que projet open source : la première version a été publiée sur GitHub le 23 juin 2019 par Jan Oberhauser à Berlin. Ces dates montrent que toute la stack de travail s'est constituée littéralement au cours de la dernière décennie, et son application actuelle constitue une compétence d'ingénierie à part entière.

Pourquoi vous pouvez nous le confier

L'expérience cumulée de l'équipe de développement dépasse 45 ans dans l'IT, et ce n'est pas une ligne marketing, mais des écueils accumulés sur les intégrations, les files d'erreurs et la maintenance de systèmes en production. Nous abordons un bot comme une tâche d'ingénierie : nous fixons les exigences, nous analysons les données du client, nous concevons les scénarios et nous vérifions le comportement sur un environnement de test avant le lancement en production, au lieu de déployer du brut dans un chat en direct. Avant le démarrage, nous passons les scénarios courants et limites, nous examinons les logs et nous corrigeons les endroits où le modèle pourrait produire une imprécision. Nous gardons honnêtement le cadre de notre rôle : nous écrivons des programmes et configurons l'équipement du client, qui découpe, soude, imprime ou transporte de son côté, et nous répondons du logiciel et du paramétrage, pas de ce que nous ne faisons pas physiquement. Cette approche donne un résultat prévisible et un système que l'on peut ensuite faire évoluer, au lieu de le réécrire à zéro.