Chatbot Microsoft 365 : quels usages pour vos bots ?

Quand on parle d’Office 365, ou plus globalement de Microsoft 365, on entend tout et son contraire, des demi-vérités et des approximations.

Cet article a pour objectif de déminer le terrain et de permettre aux décideurs de comprendre jusqu’où un chatbot peut aller dans Microsoft 365. Dans la perspective d’un cadrage de l’usage des chatbots en lien avec Office 365, plusieurs questions doivent être traitées:

• Que souhaitez-vous que votre chatbot fasse ?
• Sur quel support souhaitez-vous que votre chatbot soit disponible ?
• D’où provient la donnée que votre chatbot utilise ?
• Algorithme ou IA, démêler le vrai du faux !
• Parle-t-on d’un chatbot ou de plusieurs chatbots qui ont des comportements différents selon l’endroit où ils sont utilisés ?
• Le chatbot doit-il être capable de réaliser des actions dans le contexte de l’utilisateur connecté ?

Tout un programme…

 

Quel usage pour vos chatbots ?

Les usages d’un bot sur Microsoft 365 peuvent différer selon les organisations et selon les populations ciblées:

• Pour les populations internes:

1. 1. Obtenir rapidement de l’information contextuelle à l’entreprise (générale, RH, juridique, services généraux, etc.)
   2. Se former à des outils et à des usages internes
   3. Effectuer des demandes standards
   4. Automatiser les tâches du quotidien dans mon propre contexte
   5. Automatiser des tâches en lien directe à mes droits hérités de M365
   6. Rentrer en contact avec des personnes (sachants ou supports)
   7. Obtenir du support concernant les problèmes les plus courants
   8. Obtenir des informations depuis des outils métiers
   9. Communiquer massivement en conversation directe

• Pour les population externes

• 1. Informer vos clients (sur des sites web ou des portails extranets)
  2. Partager l’information tout en limitant les accès au support
  3. Interagir avec vos clients (livechat)
  4. Récupérer des informations simplifiant l’interaction avec vos clients (prise de contact, sondages, etc.)
  5. Identifier des produits pertinents en affinant les besoins

Que l’on soit sur des populations internes ou externes, on peut classer ces usages en 3 catégories :

• L’accès à la connaissance
  • La connaissance interne, celle de l’entreprise ou celle des sachants (RH, Juridique, etc.)
  • L’adoption des outils internes, qu’ils soient des outils du quotidien, tels que Office 365, ou des outils métiers
  • La connaissance spécialisée, mais non liée à de l’outillage (comme par exemple des connaissances en lien avec une règlementation nationale)
  • La connaissance du web, une sorte de Google intégré

• L’automatisation
  • L’exécution d’actions dans le contexte d’une conversation entre un utilisateur et le bot
  • La récupération de données localisées dans des outils internes
  • L’envoi de données dans des outils internes ou SaaS
  • La soumission de demandes dans un workflow de validation

• L’aide à la décision
  • L’intégration avec des IA métiers qui vous aideront à prendre les bonnes décisions
  • L’utilisation d’arbres de décisions via un ensemble de questions fermées

Évidemment, dans un premier temps, vous n’envisagerez pas l’ensemble de ces opportunités et vous démarrerez, comme tout le monde, par un cas d’usage tel que le partage d’informations ou la demande de congés, ou l’aide aux Deskless workers, etc.,etc.…

Quelque soit le métier (RH, IT, Commerce, Formation…) ou le domaine (Assurances, mutuelles, Secteur Public…), ces usages restent les mêmes, et sont juste contextualisés au domaine d’activité.

Découvrir et présenter l’information

La connaissance d’une entreprise provient de plusieurs sources. Certaines sont d’ores et déjà normalisées (dans le meilleur des cas), au sein d’une plateforme de KM, d’une GED, d’un CRM, d’un ERP, voire d’une plateforme de cartographie de processus. Certaines de ces informations ne sont tout simplement pas matérialisées car encore dans la tête des sachants. Dans tous les cas, c’est bien l’ensemble de ces savoirs qui constituent la connaissance d’une entreprise.

• Sources normalisées
  • Knowledge management (KM)
  • Gestion électronique de documents (GED)
  • ERP
  • Outils de cartographies de processus
  • Etc…
• Sources non normalisées
  • Sachants
  • Documents non standards (Fichiers Excel, échanges de mail, etc.)

Nous avons donc une connaissance qui est en partie digitalisée (et espérons-le, bien catégorisée via une taxonomie partagée) dans des outils intégrant généralement des moteurs de recherche et des connaissances qu’il faudrait intégrer. C’est là qu’une réflexion poussée doit être menée : doit-on utiliser les outils actuels qui fournissent des outils de recherche tantôt performants, tantôt limités ou doit-on faire confiance à l’IA pour faire le travail de recherche, de lecture et de restitution ? Certes la promesse de l’IA est belle : une capacité de compréhension au niveau sémantique via les derniers moteurs de NLU (à ne pas « confondre » avec le NLP).

En savoir plus : Comment choisir entre NLP et NLU pour un chatbot ?

Mais à quel prix ? Les moteurs de NLU (tous sans exception) sont chers et demandent de lourdes ressources pour fonctionner. Mon organisation peut-elle se permettre cet investissement ? Tant mieux si la réponse est « oui ». Toutefois, il faut vraiment comprendre qu’il s’agit d’un coût non négligeable.

J’expliquais récemment à un prospect qui souhaitait justement aller dans cette voie les possibilités d’interaction entre OpenAI et Hubi.ai (aucun problème pour intégrer la découverte automatisée de contenus de notre côté)… Là où le frein est quasi direct c’est lorsqu’on explique le modèle de prix d’OpenAI. Plusieurs milliers (voire dizaine de milliers) d’euros de puissance de calcul. Et là, retour à la réalité. L’avenir (proche en tout cas) passera par l’intégration des données des plateformes hébergeant de la connaissance et par la capacité des plateformes de bots à interagir avec ces plateformes pour restituer une information cohérente.

Pour faire simple :

• Il est possible de programmer une IA pour aller indexer et intégrer l’ensemble de l’information de l’entreprise et intégrer ces informations à un chatbot tel que Hubi.ai. Ce sera super performant mais très cher.
• Il est possible d’intégrer de la connaissance sur une plateforme de chatbot dont l’IA interne (lorsqu’il y a vraiment une IA, c’est-à-dire des mécanismes de NLP et de NLU pour comprendre le sens des phrases), et le chatbot pourra également aller requêter les différents outils pour récupérer le reste de la connaissance.
• Il est bien entendu possible de faire les deux : indexer les documents (ou les sites) les plus importants grâce à une IA intégrée à votre bot et, en prime, aller requêter les outils de KM, de GED ou de CRM.

=> Bien entendu, la réponse est plutôt un compromis des deux approches. Il faut en effet trouver un consensus qui mêle temps et coût d’implémentation. Je traite plus loin dans cet article le sujet de l’automatisation.

 

Gouverner l’information

« Qui est responsable de la connaissance RH, sinon les RH ? »

« Qui est responsable de la connaissance du service juridique, sinon le service juridique lui-même ? »

Intégrer de la connaissance sur une plateforme de chatbot multi-canal nécessite que cette plateforme puisse cloisonner cette connaissance. Ce cloisonnement doit pouvoir être géré nativement et les connaissances créées ou récupérées par la plateforme devraient pouvoir être cloisonnées a minima par verticale métier. Sans cela, il vous sera impossible de mettre votre plateforme dans les mains de métiers friands de créativité, les fameux citizen developers.

Idéalement, silotées par verticale, l’usage de ces données devrait être monitorable et suivable via des dashboards complets et évolutifs en fonction de vos besoins!

 

En résumé : une plateforme qui ne vous permettrait pas de cloisonner l’information vous empêcherait de multiplier vos usages tout en sécurisant vos connaissances. Vous seriez alors cloisonné au malheureux paradigme « un chatbot, un usage ».

 

Quid de l’automatisation

Les données de l’entreprise sont souvent stockées sous une autre forme que de la documentation ou des données de connaissance structuré. Les outils Legacy ou SaaS intègrent des données qui ne sont souvent accessibles (en lecture ou en écriture) que via les outils ou via leur interface API (et avec des règles d’authentification).

C’est bien beau un chatbot qui répond aux questions, mais un chatbot qui peut également aller chercher de l’information (ou la mettre à jour) dans des outils du quotidien, c’est mieux… Beaucoup mieux!

Les outils d’automatisation permettent de connecter les processus aux données et facilitent ainsi le maintien de la qualité des données de l’entreprise. Dans un contexte chatbot, ces mécanismes de synchronisation de données devraient être facilités par l’outil lui-même. Le volume important de données échangé lors d’une conversation pourrait aussi être des informations utiles pour améliorer la connaissance interne de l’entreprise.

Il ne faut pas oublier que l’objectif de vos chatbots n’est pas seulement d’intégrer de la connaissance, mais aussi d’automatiser des processus et de collecter de la donnée. En cela, une plateforme de bot se doit d’intégrer un outil de design d’arbres de décisions permettant d’interagir avec les outils du quotidien. Le nombre de conversations possibles est potentiellement illimité. Choisir un outil avec une prise en main rapide et qui facilite la création de conversations complexes doit être un véritable sujet d’analyse. Favoriser le No-Code versus le Low-Code.
Pourquoi faire ce distinguo ? Tout simplement, parce que les outils de Low-code ne sont pas à mettre entre toutes les mains. Petit indice qui pourrait d’ailleurs faire tilt : lorsque vous voyez une solution se dire « NoCode-LowCode », dites-vous plutôt que c’est du Low-Code, et non du No-Code ! Les populations ciblées ne sont pas les mêmes.

Les plateformes utilisant des outils tiers sont potentiellement à proscrire car l’intégration de ces outils, qui est souvent coûteuse, n’est en fait qu’un pont entre les plateformes avec peu d’interactions, et vous devrez souvent utiliser plusieurs outils différents. Quel dommage ! Power Virtual Agent et PowerAutomate en sont le meilleur exemple : 2 outils différents (certes complémentaires) mais qui, sur du gros volume, deviennent ingouvernables.

Je vois parfois des mots tels que chatbot et RPA mixés ensemble… Ceci est une aberration. Travaillant dans le milieu de l’IPA, depuis bientôt 10 ans, ce genre de solution est à fuir ! Cela revient à charger une Tesla avec un générateur à gasoil !

Préférez les plateformes automatisées en se connectant directement aux API et, dans la mesure du possible, qui vous permettront d’étendre le nombre de connecteurs. Dans ce domaine, la palme revient, disons-le, à PowerAutomate et ses 700 connecteurs (avec la possibilité de créer de nouveaux connecteurs sur demande). Mais avez-vous besoin d’autant de connecteurs ? Peut-être pas… Ce qu’il vous faut, c’est l’assurance que quel que soit l’outil auquel vous souhaiteriez vous connecter, vous aurez un connecteur disponible.

Dans un contexte chatbot, vous avez également parfois besoin que les scénarios d’automatisation soient exécutés dans le contexte de l’utilisateur connecté : « C’est bien le compte de Michel qui doit créer la demande de congés », « C’est bien le compte de Florian qui doit créer cette équipe Teams », etc. Pour ça, on suit le protocole OAuth2. Il est parfois disponible dans certains connecteurs. Dans sa version pour O365, celui-ci s’appelle MSGraph. Si vous souhaitez exécuter une action en tant qu’utilisateur connecté, il faudra forcément passer par là. Assurez-vous donc que votre solution le permette !

 

En résumé, les points importants, privilégiez :

• Une solution intégrant un outil d’automatisation
• Une solution No-Code (et pas Low-Code, comme PowerAutomate, car cela limitera l’extension de vos usages)
• Une solution pouvant créer de nouveaux connecteurs, sans passer par l’éditeur (qui souvent vous chargera les coûts d’intégration)
• Spécial O365 : afin de pouvoir exécuter des actions en tant qu’utilisateur connecté, assurez-vous que la solution favorise l’intégration à MSGraph. Si ça n’est pas le cas, il y a fort à parier que vous devrez passer par un compte de services.

 

Le client chatbot

Microsoft 365 intègre de nombreux outils dans sa suite (Teams, SharePoint, OneDrive, Power Platform…). Par défaut, l’interface préconisée pour un bot devrait être Teams. Pourquoi ? Tout simplement car Teams devrait/sera l’interface de prédilection des échanges dans l’entreprise. Est-ce suffisant ? Clairement pas ! En 2022, bon nombre d’applications sont encore développées sur SharePoint Online, et de nombreuses Digital Workplaces sont intégrées à SharePoint & Teams. A minima, la cible d’un bot Microsoft 365 devrait donc être Teams + SharePoint.

Idéalement, celui-ci devrait également s’intégrer au sein de la digital workplace en place, quelle qu’elle soit (Powell365, Lumapps, voire Jalios).

Dans une autre mesure, imaginer à plus long terme une intégration sur des applications tierces (pour remplacer typiquement la FAQ de ces produits), sur des sites web, voire même sur l’environnement desktop des collaborateurs.

Mais ces clients ont-ils tous la même capacité ? Rien n’est moins sûr. Par exemple, Teams ne supporte pas le HTML, mais fonctionne avec plusieurs autres technologies : le « MarkDown » avant tout, et les cartes adaptatives ensuite. Malheureusement, Teams ne supporte pas encore les dernières versions des adaptatives Cards (1.5). Teams se limite à la version 1.4. Le webchat du bot framework Microsoft, lui, ne supporte que la version 1.3. Malheureusement pour tous les éditeurs, Teams est limitant. Quid des éditeurs qui utilisent un standard HTML ? Dur à dire…

 

En résumé, opter pour un chatbot « TeamsMade » est une bonne option. S’assurer que les clients existent également pour Sharepoint est une meilleure idée encore !

 

Chatbot ou metabot ?

Kezako un metabot ? Si vous souhaitez avoir un chatbot unique… le sujet ne vous concerne pas.

Si vous souhaitez un bot qui peut avoir plusieurs facettes selon sa localisation, et avoir des comportements distincts selon les usages, vous avez sûrement besoin d’un metabot ! En fait… non, vous avez tous besoin d’un metabot, mais vous ne le savez pas encore !

 

Pourquoi ?

• Vous allez prendre le chatbot de votre ITSM favori.
• Vous allez prendre le chatbot de votre outil KM favori
• Votre direction marketing va vouloir un chatbot pour communiquer avec ses clients
• Votre comm’ interne va vouloir un chatbot pour communiquer avec les collaborateurs.

Bravo, vous venez d’acheter plusieurs produits différents !

Et lorsque vous voudrez que tous ces bots parlent ensemble et partagent des comportements communs, vous allez vous dire : « Mince, c’est bien d’un métabot dont j’avais besoin ! ».

 

En résumé, viser un metabot, c’est l’assurance de ne pas se limiter à « un chatbot, un usage ».

 

Pour conclure :

Il n’existe pas de solution idéale (même Hubi.ai qui répond à l’ensemble des sujets abordés ici, a ses limites).

Néanmoins, vous déminerez beaucoup de pièges du marketing en suivant quelques recommandations proposées dans cet article ! Hubi.ai et ses partenaires peuvent également vous aider à aller plus loin dans votre réflexion sur l’intégration de bots dans vos organisations.