Favoriser l’implémentation d'un chatbot avec le BizDevOps

Le BizDevOps a fait son entrée récemment, ajoutant à la coopération DevOps, les interlocuteurs métiers. Un projet de chabot est une réalisation qui peut totalement rentrer dans ce cadre.

On entend parler depuis plusieurs années de chatbots ou agents conversationnels en français, permettant d’offrir un nouveau type d’interaction avec le SI, plus orienté et plus automatisé, pour optimiser le temps d’accès à l’information pour l’utilisateur. Le BizDevOps a fait son entrée plus récemment, ajoutant à la coopération DevOps, les interlocuteurs métiers. La réalisation d’un chabot est une réalisation qui peut totalement rentrer dans ce cadre, ce dont est l’objet de cet article.

Anatomie du chatbot

L’architecture d’un chatbot se découpe en trois parties :
  • Le canal utilisateur : le moyen par lequel arrive l’utilisateur, ce qui peut être Skype, WhatsApp, Facebook Messenger, SMS…
  • Le moteur de chat : l’intermédiaire entre l’utilisateur (par le biais du canal emprunté) et l’intelligence artificielle
  • L’intelligence artificielle (IA) : l’analyseur de langage naturel (NLP) de ce qui lui est envoyé, et qui renvoie l’intention formulée par l’utilisateur la plus probable
 
Les tests ont été faits sur deux IA, celle de IBM (Watson) et celle de Microsoft (Luis), essentiellement parce que Microsoft offre une intégration native avec ses outils collaboratifs (Teams, Skype…) et qu’IBM occupe une place de leader sur ce positionnement depuis une longue période.

Terminologie

Peu importe la technologie de ChatBot utilisée, le vocabulaire est relativement similaire et normalisé, on retrouve les termes suivants :
  • Intent/intention : Intention probable analysée par l’IA, sur la base de la formulation utilisateur en entrée. Par exemple, les saisies utilisateurs « Quel temps fait-il aujourd’hui ? » ou « Il fait beau aujourd’hui ? » pourraient toutes deux retourner l’intention « #QueltempsAujourdhui ». Ces intentions sont pré-définies avant la mise en production du chatbot, en fournissant pour chaque intention possible dans le périmètre du robot, un jeu de phrases d’exemple que l’utilisateur pourrait transmettre pour que le robot résolve l’intention voulue, sous forme d’intention la plus probable.
  • Entities/entités : Structure organisée, permettant de variabiliser ou de normaliser l’intention. Les cas d’usages des entités sont vastes, mais on pourra par exemple introduire au sein d’une intention une entité synonyme afin de comprendre aussi bien « Quelle température fait-il aujourd’hui » ou « Quel temps fait-il ce jour », sans avoir à décliner toutes les combinaisons de phrases possibles. L’entité permet aussi d’intégrer un paramètre de date à l’intention, « Aujourd’hui », « Demain », « Lundi prochain », qui sera transmis en complément de l’intention la plus probable. L’entité permettrait aussi d’ajouter un paramètre de nombre si le cas d’usage s’y prête « Fera-t-il plus de 19° aujourd’hui ».
  • Dialog/dialogue : Certaines IA à l’instar de Watson (IBM) permettent de gérer une conversation simple (pas d’appel à une application/API externe) directement depuis l’interface d’entrainement de l’IA, sans aucun code, avec même des questions imbriquées et conditionnées des réponses utilisateurs, de manière à ressembler à une conversation humaine.
Exemple : Interface de paramétrages Watson

Entrainement du robot

L’IA lors d’une saisie utilisateur, envoie l’intention la plus probable, avec ses paramètres s’il y en a. Il renvoie aussi une liste d’autres intentions avec leurs probabilités (0.xx). L’objectif d’un bon entrainement est d’avoir des intentions sans ambiguïté, et donc d’avoir une intention retournée probable avec plus de 50% de certitude.
Cette « configuration » consiste à entraîner l’IA, en fournissant un jeu de phrase exemple plus vaste, en intégrant lorsque c’est possible des entités.
Une fois l’entrainement terminé, il sera possible de tester l’IA, en saisissant une expression en langage naturel et en voyant les probabilités retournées, et en affinant les exemples en cas de résultats non satisfaisants (trop proche ou mauvaise intention renvoyée).
Il est possible de forcer la résolution d’une phrase ayant récolté une mauvaise probabilité, vers une intention, afin que le robot s’en souvienne pour les fois futures et qu’il en tienne compte pour améliorer sa reconnaissance.
Que cela soit sur Watson ou Luis, la phase d’entrainement se fait sensiblement de la même manière, via une interface graphique web assez similaire. 
L’objectif de cet article n’est pas de comparer les outils du marché, cependant il y a des avantages que certaines technologies d’IA offrent et pas d’autres, chez IBM-Watson et Microsoft-Luis mais également chez les autres éditeurs non étudiés ici :
  • Luis gère bien le versionning de son paramétrage, avec la possibilité d’avoir une version d’intégration (staging) et une version de production, idéal pour faire des tests en tampon avant la mise en production
  • Watson gère nativement une conversation basique et simple, et surtout sans code, ce qui offre la possibilité à une personne non technique de réaliser un premier jet représentatif du robot. C’est l’objet du prochain chapitre. 

Chatbot assisté par ordinateur

La conception d’un chatbot commence par la définition des intentions, sur papier ou par brainstorming, afin de définir le périmètre du chatbot et d’avoir une idée de ses fonctionnalités ou des traitements qui seront implémentés.
Ensuite ces intentions peuvent être déclinées dans l’outil retenu (Watson, Luis, autre…) avec les différentes phrases exemples, ainsi que des entités pour la variabilité ou la normalisation des intentions.
Avec suffisamment d’intentions et de phrases d’exemple, l’entrainement peut avoir lieu, en soumettant du texte et analysant le résultat renvoyé par le robot, et en affinant les phrases d’exemples.
Si l’interface graphique le permet (Watson par exemple), l’utilisateur peut même enregistrer des réponses simples aux intentions, réponses qui peuvent être conditionnées (dépendantes d’une variable récupérée lors d’une précédente intention) afin d’avoir un arbre de dialogue tel qu’on pourrait l’avoir dans une conversation humaine où des réponses peuvent amener naturellement à d’autres questions.
Une fois la partie définition des intentions terminées, le développeur réalise (via du code), des traitements ou calculs aboutissants à une réponse de la part du robot, par exemple un robot RH permettant de récupérer son solde de congés, pourra interroger le SIRH (via une API, un WebService ou autre) afin de récupérer le compteur de congés et le retransmettre à l’utilisateur à travers le canal emprunté pour poser la question.
De manière générale, la partie amont à la réalisation du code effectuant les divers traitements, peut être faite par une personne n’ayant que très peu de compétences techniques, tout se fait via l’interface web, sans aucun code. L’essentiel de ce travail se résume à déclarer les entités, les intentions, saisir des phrases d’exemple et entraîner le robot de manière à améliorer ses réponses, la formation nécessaire pour arriver à la maîtrise de l’outil est minime.
Le temps passé par un développeur à définir tout cela est du temps qu’il ne passera pas à développer les traitements de fond de tâche, permettant d’ajouter du dynamique à un ChatBot, ce qui constitue selon le cas d’usage une valeur ajoutée importante.
Avoir une contribution du métier sur la phase amont, pendant que le développeur se concentre sur le code, permet :
  • D’avoir un time-to-market amélioré, les deux phases sont parallélisées sans dépendances entre elles
  • D’avoir un retour direct du métier, sur le périmètre des questions possibles et de leurs réponses (si l’outil utilisé intègre les dialogues simples dans son interface)
  • D’améliorer la cohésion entre équipes métiers et développeurs ; les deux équipes parlent le même vocabulaire chatbot (intentions, entités…)
  • De rendre autonome le métier sur les ajouts de nouvelles formulations d’intention
La mise en place de cette organisation « BizDevOps » agile réduit les silos en faisant travailler les différents types d’acteurs ensemble, ce qui est rendu possible grâce à la facilité de manipulation des outils et de compréhension des concepts.
La partie technique « Ops » est gérée par l’éditeur fournissant le service de chatbot SaaS, et ce de manière transparente. La gestion et la supervision des coûts de run doit cependant être faite par la DSI "Ops".
Avant de s’atteler à la réalisation d’un chatbot, il faut tout d’abord trouver un cas d’usage intéressant pour l’utilisateur final en termes d’optimisation de l’accès à l’information ou de son traitement. Cette phase n’est pas à négliger et doit être abordée préalablement sous l’angle métier.