Découvrez enfin la différence entre le chatbot et le metabot

Depuis plusieurs années, les chatbots envahissent le paysage IT. Qu’ils soient positionnés en B2B, B2C ou B2B2BC, ils font partie des nouveaux usages. A défaut d’être réellement « intelligents », ils permettent néanmoins de très bien répondre à un besoin particulier. Ce défaut d’intelligence évoqué n’est ni plus ni moins qu’une limitation d’implémentation : un chatbot est une interface homme-métier, connectée à une base de connaissance dans laquelle des questions et leurs réponses correspondantes sont configurées. Un mode de traitement appliqué à la saisie de l’utilisateur (NLP, NLU, ou moteur « maison ») permet de restituer la réponse appropriée.

De fait, certaines organisations ont parallélisé les chatbots pour répondre à des besoins métier différents (recherche d’informations dans un périmètre particulier, support niveau 1, prise de congés ou saisie de notes de frais, etc.).

 

Il est important de comprendre que cet empilement de chatbots constitue une réponse à des besoins différents (silotage par métier ou par groupe d’utilisateurs). Étant donné la spécificité de chaque besoin, il est courant que ces différents chatbots soient basés sur des technologies différentes voire provenant d’éditeurs différents. Beaucoup d’éditeur ont en effet construit, depuis parfois une dizaine d’années, des chatbots répondant à un besoin métier particulier de manière experte. Les besoins étant potentiellement infinis, le nombre de chatbots est naturellement très conséquent.

La perspective de paralléliser les chatbots pour répondre à des besoins très différents est séduisante (l’influence très positive de ces outils n’est plus à prouver). Il n’en demeure pas moins qu’une problématique émerge à chaque adoption massive d’un nouvel usage : la gouvernance des outils associés.

Point de gouvernance #1 : si tous les chatbots déployés dans une organisation peuvent s’adresser à des groupes de collaborateurs spécifiques, ils sont néanmoins intégrés au SI. Et donc gérés, in fine, par l’IT.

Point de gouvernance #2 : si un utilisateur de l’organisation doit pouvoir effectuer des tâches adressées par plusieurs chatbots, il devra jongler entre différentes interfaces. L’intérêt ergonomique est donc perdu.

La solution la plus logique serait donc de pouvoir brancher tous ces chatbots de façon à ne conserver qu’une interface unique. Or, tous ces chatbot étant spécifiques, il est difficile de trouver un moyen d’interopérabilité. De plus, l’analyse et le traitement des requêtes utilisateurs est très complexe (routage vers la bonne réponse, pondération de réponse en fonction d’un contexte, etc.).

Ce type de technologie est appelé « métabot ». Un métabot interconnecte différents chatbots, redirigeant les requêtes des utilisateurs vers celui le plus approprié pour fournir la réponse. Ceci peut être réalisé de différentes manières : interrogation de tous les chatbots jusqu’à trouver la réponse ; utilisation de technologies de traitement du langage pour analyser la demande et cibler le bon chatbot pour obtenir la réponse ; agréger les « connaissances » de tous les chatbots pour faire un prétraitement.

Finalement beaucoup de possibilités techniques qui se heurtent à la nécessité de traduire techniquement la requête de l’utilisateur dans le format utilisé par chacun des chatbots connecté au métabot. Avec en bonus l’extrême complexité de fournir la bonne réponse lorsqu’elle est trouvée dans plusieurs chatbots…

Et pour Hubi ?

Plutôt que de chercher à orchestrer un ensemble de chatbots non interopérables, dont la gouvernance est difficile, et la qualité de réponse incertaine, Hubi.ai a été architecturé dès le départ comme un métabot.

Expliqué simplement, hubi.ai est un chatbot auquel des modules métiers (bases de connaissances, applications métier, traitements mixtes type helpdesk, RH, etc..) sont connectés. Chacun de ces modules peut communiquer avec des solutions en back-end, type CRM, GED, ou autre. Chaque requête utilisateur, quelle qu’elle soit, est analysée, redirigée vers le bon module, et la réponse restituée de façon très fluide.

Cette conception apporte des avantages dans plusieurs domaines :

  • L’expérience utilisateur est grandement améliorée et bénéficie d’un seul point d’accès, facilement adaptable aux usages à venir (saisie vocale, mobile, branchement de périphériques IoT sur des scénarios automatisés…)
  • La simplification de la gouvernance : étant centralisée, il devient très simple de maintenir une seule solution
  • La rationalisation des coûts de licence / maintenance
  • L’extensibilité de la solution extrêmement simple : plateforme No-Code et magasin de modules pour ajouter de nouvelles bases de connaissances et scénarios métiers

 

Enfin, si vous déjà d’une solution de chatbot disposant d’une API (Microsoft Live Agent, IBM Watson…), Hubi peut même l’adresser en arrière-plan grâce à son connecteur universel.

 

Si vous souhaitez en savoir plus demandez votre démo Hubi dès aujourd’hui !