Voyage au pays des Chatbots — Journal de bord #1 : Infrastructures des chatbots

Comme vous, l’aventure me tente.

Comme vous je cherche par où rentrer dans ce long voyage au pays des chatbots.

Comme vous, j’entends parler de tellement d’initiatives, de plateformes, de frameworks que je ne sais plus où donner de la tête.

J’ai donc décidé de partager avec vous mes questionnements, mes errances, mes découvertes, puissent-elles vous éclairer ou vos commentaires me remettre sur le droit chemin.

Lors d’un voyage, quoi de mieux que de tenir un journal de bord ? C’est donc celui-ci que je publierai sur ces pages au fil des semaines.

Si l’aventure vous tente, bienvenue à bord !

Première étape du voyage : les infrastructures.

Infrastructure des chatbots

Lorsque j’utilise quelque chose, j’aime bien comprendre comment cela marche, ce qu’il y a sous le capot. Donc même si ce n’est pas la partie la plus sexy d’un chatbot, j’ai décidé d’entamer mon voyage par la partie infrastructure des chatbots. J’ai donc essayé de comprendre quels sont les éléments constitutifs d’un service de chatbot, où sont ils hébergés, comment peuvent-ils aller chercher des informations dans le système d’information de notre organisation sans pour autant mettre en péril la sécurité de celui-ci, etc.

Les 3 piliers d’un chatbot

D’après ce que j’ai pu glaner comme informations, les solutions de chatbots se composent de plusieurs briques côté serveur :

- Une brique “robot” dans laquelle on programme la personnalité du robot : “si on dit ça tu fais ça”. Elle peut être soit hébergée en local soit sur le cloud de son éditeur. Elle peut être open source ou propriétaire. C’est aussi cette brique qui gère les échanges avec le service de messagerie : Facebook Messenger, Skype, Hangout, Slack, Telegram, etc. Il faut donc s’assurer qu’elle soit compatible avec la messagerie ciblée.

- Une brique “NLP” (Natural Language Processing) à laquelle s’adresse le robot pour interpréter ce que dit/écrit l’utilisateur et l’orienter soit vers le bon “scénario de discussion” afin de recueillir plus d’informations de la part de l’utilisateur, soit vers la bonne API pour aller chercher une réponse dans le système d’information interne. En général cette partie est hébergée dans le Cloud car reposant sur une AI propriétaire qui se nourrit de tous les usages que l’ensemble des utilisateurs en font.

- Et pour finir une brique “APIs locales” qui rend accessible au robot des méthodes internes, la plupart du temps sous la forme de webservices REST qui accèdent au services du système d’information de l’institution comme par exemple les pages blanches, les horaires de cours ou les devoirs à rendre sur la plateforme de cours.

Ces briques peuvent être proposées au sein d’une même plateforme ou réparties entre le cloud et vos infrastructures.

Les principales plateformes existantes

Parmi les principales plateformes de création de chatbots disponibles à ce jour on peut citer :

J’ai pour l’instant arrêté mon choix sur le robot Botkit parce qu’il est openSource et peut ne pas reposer sur le Cloud, sur le NLP wit.ai qui est très bien fait et ouvert en terme d’API et je pense programmer les API locales d’interrogation de notre SI en Python pour la diversité des librairies existantes et l’efficacité de développement.

Mon principal questionnement repose sur la protection et la confidentialité des échanges : même sans parler de mots de passe, certaines informations sont susceptibles de transiter par des services Clouds que l’on peut difficilement contrôler. Cela ne doit en aucun cas empêcher les initiatives mais les orienter, comme par exemple au niveau du choix des infrastructures à opérer.

À suivre…

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.