Ici archive

Mois : octobre 2021

« Chaque organisation aura non seulement besoin d’adopter les dernières technologies, mais également de construire sa propre technologie », préconisait Satya Nadella, président-directeur de Microsoft, dans sa vidéo d’ouverture (1) de Microsoft Build 2021 (2).

Pour démocratiser l’utilisation de ces nouvelles technologies, Microsoft a ainsi déployé des applications qui permettent aux experts métiers ou aux « citizen dev » de s’approprier et de développer des outils destinés originellement aux populations informatiques. Le but ? Répondre à un besoin avec plus d’agilité et de rapidité.

C’est le cas de Power Virtual Agent.

Power Virtual Agent pour déployer des chatbots intelligents

De la même manière qu’il est possible de créer une application sans coder (ou peu) grâce à Power Apps, il est possible de déployer des chatbots intelligents avec Power Virtual Agent et ce, sans expertise en intelligence artificielle. Donner la main à des experts non-techniques brise le « mur de verre » qui sépare les utilisateurs et les développeurs, permettant ainsi aux éditeurs de bots de se concentrer davantage sur l’expérience utilisateur.

Power Virtual Agent fait partie intégrante de la suite d’outils Power Platform, la plateforme Microsoft « no code, low-code » d’automatisation de tâches et de création d’applications et d’analyse de données. Cette solution est proposée sous forme de Paas, les entreprises n’ayant donc pas à se préoccuper de son installation ou de la gestion de son infrastructure.

Pour créer un bot depuis Teams, il suffit d’ajouter l’application Power Virtual Agent dans la barre latérale gauche. Le processus est simplifié, le bot étant édité et déployé directement dans l’application. Depuis peu, la création d’un chatbot peut également se faire depuis l’interface de Power Apps.

Pourquoi Power Virtual Agent ?

Power Virtual Agent est donc une application de création de chatbot, grâce à laquelle des « citizen devs » peuvent automatiser un certain nombre d’actions sans compétences ni prérequis techniques. La prise en main de l’outil est facile : on peut y créer un bot intégré dans l’environnement Microsoft et ce, à partir d’une nouvelle brique (arrivée fin 2020) de la Power Platform devenue prioritaire dans la roadmap de l’éditeur. Par ailleurs, cette brique sera alimentée en IA (intelligence artificielle) pour améliorer automatiquement son efficacité.

Déployer un bot au sein d’une entreprise permet d’automatiser les réponses à des questions récurrentes, laissant les professionnels concernés se concentrer sur des problèmes plus complexes. Cette solution peut, par exemple, désengorger les lignes téléphoniques de support et donc réduire les coûts logistiques de l’entreprise.

Power Virtual Agent (PVA) va même plus loin en couplant la conversation à l’action. En effet, faisant partie intégrante de la Power Platform, elle bénéficie d’une connexion native à Power Automate. Les actions comme le relais humain, la prise de rendez-vous, la recherche d’une donnée spécifique ou le statut d’un ticket IT, pour n’en citer que quelques-unes, sont donc automatisées.

Power Virtual Agent utilise la compréhension du langage naturel, une sous-rubrique de l’IA permettant au bot d’assimiler une question à un sujet. De fait, le nombre de questions « entonnoirs » posées par le bot pour apporter la bonne information diminue considérablement. L’expérience est plus agréable et « humaine » pour l’utilisateur, qui n’a pas l’impression de s’adresser à une machine. 

Dans cette même logique, le chatbot est configurable dans 20 langues différentes.

Comment utiliser Power Virtual Agent ? 

Tout collaborateur, quel que soit son niveau au sein d’une structure, peut créer un chatbot pour répondre à un besoin spécifique.

Tout d’abord, il est nécessaire de définir les sujets qui seront déclenchés à partir de mots-clés, grâce à la création de rubriques et d’entités. Autrement dit, lorsqu’un utilisateur posera une question, le bot identifiera ces mots et les assimilera à une rubrique déterminée pour fournir l’information demandée.

Chaque rubrique comprend un arbre de décision qui modélise un schéma de conversation et préétablit des scénarios couvrant l’ensemble des questions posées et leurs réponses.

Lors de l’édition d’un bot, une fenêtre de conversation test est affichée à gauche de l’écran, permettant d’ajuster et d’alimenter les différentes rubriques au fur et à mesure. Le créateur du bot n’aura plus qu’à sélectionner et configurer un canal puis à cliquer sur « Publier ».

De leur côté, les utilisateurs peuvent accéder au chatbot depuis un canal sélectionné parmi un large choix : Slack, Teams, Facebook, une application mobile ou un site web, entre autres exemples.

Enfin, la page d’analyse, référençant des indicateurs comme la proportion de conversations résolues, relayées à un humain ou abandonnées, permet de mesurer l’efficacité du chatbot et donc d’améliorer sa performance. À partir de ces informations, l’utilisateur peut ajuster son bot pour qu’il réponde plus efficacement aux questions qui lui sont posées.

Faites la connaissance d’Ask It !

Chez Saegus, nous avons créé Ask It, un chatbot qui répond aux questions relatives aux ressources humaines (droits aux congés, formation, RTT, primes de vacances, congés exceptionnels…).

Hébergé par Teams, ce chatbot a été créé dans le but d’aider les Saegusiens et Saegusiennes à trouver ces informations rapidement et efficacement, sans passer par des professionnels RH. Il est relié à une équipe Teams dédiée et peut transmettre un message laissé par l’utilisateur à un responsable RH sur le canal de cette équipe, grâce à Power Automate.

Construire un chatbot de ce type nécessite plusieurs étapes : le recensement des questions et des cas d’usages, la construction du chatbot, les premières phases de tests et la construction des V1, V2, V3… jusqu’à la publication du bot à l’échelle de l’entreprise. Ce processus peut prendre entre trois jours et une semaine.

Un bot PVA est en mesure de répondre à 800 requêtes ou questions par minute, soit 100 requêtes pour 8 personnes par minute. Il est également possible de mesurer certains KPI (nombre de sessions, satisfaction client…) depuis l’application.

Contraintes

L’interface de création d’un chatbot est facile d’utilisation, la maîtrise des arbres de décisions et des rubriques se faisant instinctivement. En revanche, certaines contraintes doivent être respectées si l’on souhaite créer un chatbot qui exploite correctement les rubriques, favorisant ainsi une expérience utilisateur interactive.

Tout d’abord, les mots-clés qui activent la bonne rubrique doivent être courts, distincts et assez nombreux. Il est recommandé de réaliser une phase d’entraînement du bot avec un maximum de collaborateurs, avant sa diffusion : cela multipliera nécessairement le nombre de formulations, ce qui améliorera l’efficacité du bot.

Lorsque les rubriques portent sur des sujets similaires, il peut être difficile pour le chatbot de les distinguer entre eux. Il revient alors automatiquement aux questions « entonnoirs », ce qui réduit « l’humanisation » de l’expérience.

Le taux d’erreur de compréhension du chatbot reste plus élevé lorsque l’on privilégie la technique des rubriques – le chatbot est paramétré pour avoir une conversation avec l’utilisateur final – aux arbres de décisions – ici, il décide à partir d’une série de choix. Cette seconde technique possède un taux d’erreur moins élevé car l’utilisateur clique simplement sur des options prédéfinies pour trouver la réponse qu’il recherche.

Il convient de noter que le chatbot peut ne pas comprendre une information basique à cause d’une majuscule, même avec une correspondance active. L’utilisation de cette correspondance est toutefois fortement recommandée, car elle permet au bot de faire correspondre les fautes de frappe, d’orthographe et de grammaire aux mots ayant la même signification. En d’autres termes, le bot peut ainsi comprendre un mot même s’il a une petite faute et donc, répondre correctement à la question qui lui est posée. D’une conversation à l’autre, le taux d’erreur peut varier. S’il devient très important, il est préférable de ne plus utiliser le chatbot pendant un certain temps.

Licences

Power Virtual Agent est accessible depuis Teams avec une licence Office 365 E3 (3). Il est pour cela nécessaire d’activer la fonctionnalité PVA depuis la console d’administration. Pour pouvoir créer un chatbot depuis le client légé (4), il faut souscrire à un abonnement Power Virtual Agent standard, soit 843,30 euros pour 2000 sessions. Une session équivaut soit à un échange de 60 minutes ou à 100 échanges entre un utilisateur et le chatbot, soit à 30 minutes de non-activité entre deux interactions (qui sont donc comptées comme telles). Dans les deux cas, certaines fonctionnalités sont restreintes et il n’existe qu’un canal de diffusion : Teams. De plus, l’automatisation des tâches se cantonne à des templates prédéfinis (canvas) sur Power Automate.

L’automatisation de tâches complexes, comme la restitution d’une information stockée dans une base de données externe ou la connexion à des services tiers, nécessite un abonnement premium. Ce type d’abonnement permet également d’avoir un plus large panel de canaux de diffusion.

Envie de développer à votre tour un chatbot créé pour vos besoins, rapidement et efficacement ? N’hésitez plus, contactez nos équipes Workplace !

Contactez-nous

Vous souhaitez en savoir plus sur la Power Platform ? Retrouvez nos derniers articles sur la gouvernance et les nouveautés proposées par l’outil de Microsoft.

Sources :
(1) Vidéo d’ouverture de Microsoft Build 2021
(2) Microsoft Build 2021
(3) Licence Office 365 E3
(4) Power Virtual Agents

De plus en plus important au sein des équipes agiles, le rôle du Proxy Product Owner (PPO) n’est pas défini dans la méthode classique de l’Agile Scrum. Ce rôle a été créé ad hoc pour répondre aux besoins de soutien du Product Owner (PO) pour des programmes et projets Agiles au sein d’organisations complexes.

En effet, le Product Owner a un rôle central dans les équipes Scrum. Il est responsable de la vision du produit, construite et alimentée par les besoins des utilisateurs et la stratégie de l’organisation, ainsi que de la gestion du backlog en lien avec l’équipe de développement pour concrétiser les solutions à développer.

Voilà pour la théorie du PO ; dans les faits, que ce soit dans des organisations complexes ou sur des projets et produits composés de plusieurs solutions techniques et services métier, le PO, qui est un représentant métier, voit sa charge augmenter. Entre la gestion des nombreuses parties prenantes et la préparation des instances internes, le PO est rarement dédié – et n’a que peu de temps à dédier – à l’opérationnel. C’est pour cela que le PPO, ou Proxy Product Owner, est un nouveau rôle indispensable : le bras-droit du PO.

Le PPO a pour mission de décharger le PO d’une partie des tâches très opérationnelles (gestion du backlog, suivi rapproché avec les équipes de développement…). Il fait partie intégrante de l’équipe Scrum, en binôme avec le PO. Il est à l’interface entre les utilisateurs, les métiers et les équipes techniques.

Nos expert·e·s PPO Saegus Jean-Baptiste, Consultant Senior, et Marouchka, Manager Acceleration Tactics, répondent à nos questions pour y voir plus clair sur ce rôle qui s’est imposé nécessaire dans beaucoup de grandes organisations.

#1 Concrètement, quel est votre rôle au quotidien chez votre client ?

Déjà, le PPO doit comprendre et préciser les besoins des utilisateurs et gérer le backlog du projet sur lequel il est impliqué. Il doit produire et ajuster tous les éléments nécessaires (epics, user stories, tâches…) pour répondre à la vision des prochains sprints.

Par exemple, chez notre client actuel nous contribuons à la mise en place d’un outil de gestion de portefeuille de projets. Celui-ci doit notamment permettre à divers métiers de renseigner des projets et études prévisionnels puis de les mettre à jour au gré de leurs concrétisations. Des formulaires, des tableaux de suivi et des interfaces de paramétrage ont donc été développés.

Pour ces fonctionnalités, il a fallu préciser le besoin des métiers, la manière d’intégrer les formulaires et tableaux à l’outil existant, la manière dont les informations doivent être liées avec d’autres systèmes de gestion des données, mais aussi prendre en compte leur adoption et leur intégration aux usages des métiers.

Une fois le contexte des métiers compris, il faut traduire les solutions à mettre en place sous forme d’user stories permettant d’alimenter le backlog du produit. Ce travail hebdomadaire génère des dizaines d’user stories, voire des centaines.

La méthode d’Agile Scrum reposant sur des cycles courts et itératifs de développement, appelés Sprints, toutes ces US ne peuvent être développées en même temps. En tant que PPO nous participons à la priorisation des US à intégrer à lors des itérations de l’équipe. C’est un rôle qui permet d’avoir une vision d’ensemble sur tout ce qui est en cours de développement et à venir.

Pour chaque itération nous suivons la réalisation avec l’équipe de développement et en interaction avec les métiers. Nous coordonnons ensuite les tests avec les métiers pour valider la bonne réalisation de chacune des user stories.

Le PPO coordonne les sprints de l’équipe de A à Z en collaboration constante avec le PO. Le Product Owner se concentrant généralement essentiellement à la définition de la vision et la stratégie du produit, ainsi qu’au cadrage des besoins avec les métiers, là où le PPO est davantage engagé dans les tâches plus opérationnelles du cadre de travail Agile.

#2 Quels challenges rencontrez-vous à travers vos différentes missions ?

Les challenges sont multiples ! D’abord, puisque c’est une fonction en interaction avec les métiers d’une part et avec les équipes de développement d’autre part. Il faut d’abord comprendre les besoins, attentes et contraintes de ces parties prenantes essentielles au projet. Il faut réussir à adopter un langage et des codes adaptés à chacune d’entre elles.

Le deuxième challenge, c’est de réussir à faire comprendre les besoins métiers aux équipes de développement, et inversement de présenter aux métiers les réalisations des équipes de développement, ainsi que les limites et les difficultés rencontrées liées, par exemple, aux contraintes des outils ou des écosystèmes IT de l’entreprise.

Enfin, il y a un sujet de légitimité : le PPO doit faire en sorte que son rôle de coordination et de support soit bien compris étant donné qu’il ne produit pas les solutions présentées aux utilisateurs et qu’il n’a pas toujours la réponse aux questions posées par les métiers (notamment sur les sujets très techniques).

Pour éviter toute incompréhension, la règle d’or est de communiquer régulièrement sur le fonctionnement de l’équipe Scrum et les rôles de chacun.

#3 Pourquoi le rôle de PPO est de plus en plus présent dans les projets en agile ?

Historiquement, sur le framework Scrum, le Product Owner est responsable de la vision du produit auprès de son équipe et ses sponsors ainsi que de la gestion du backlog.

Dans les grandes organisations, ou sur des produits et programmes avec plusieurs solutions technologiques et services, le Product Owner est rarement dédié à 100% à cette fonction. Il a également la charge de tâches et missions qui lui incombent sur d’autres dimensions de son poste. Il lui est donc difficile de gérer les aspects opérationnels du rôle de PO.

Le PPO a donc pour fonction de suppléer le PO sur les aspects les plus opérationnels de ses attributions.

D’autre part, les principes de l’agilité et la méthode Agile Scrum sont adoptés progressivement dans des organisations dont le cœur de métier est éloigné du digital et dont les héritages culturels et organisationnels liés aux méthodes antérieures de gestion de projet restent forts.

Ainsi, pour favoriser le fonctionnement en mode agile dans ces organisations complexes, le rôle de PPO, complémentaire à ceux de la méthode Agile Scrum, est nécessaire.

#4 Quelles sont pour vous les trois qualités d’un bon PPO ?

La première qualité, sans hésitation, c’est la diplomatie ! Face à des métiers qui ont des demandes parfois complexes voir techniquement irréalisables, il faut savoir trouver des solutions pour répondre à leurs besoins en prenant en compte les contraintes techniques. Notre rôle est de « comprendre et faire comprendre » les enjeux, les besoins, les contraintes de l’ensemble des parties prenantes du projet, en prenant le temps de valoriser l’implication de chacun.

Ensuite, il faut faire preuve de multidisciplinarité. Le PPO doit à la fois comprendre le besoin de métiers éloignés du sien, le point de vue – souvent très technique – des développeurs ainsi que les bonnes pratiques UX/UI issues du design pour faire la synthèse des solutions à mettre en place.

La dernière qualité est forcément la rigueur : c’est à lui de gérer le backlog, afin que les US soient claires et compréhensibles pour les développeurs et les testeurs de l’équipe produit. Sans rigueur, le PPO ne peut remplir sa mission d’intermédiaire et de facilitateur.

#5 Quels outils utilisez-vous au quotidien ?

D’un point de vue général, nous privilégions des outils agiles tels qu’Azure DevOps ou Jira d’Atlassian, mais certaines missions peuvent également nous contraindre à utiliser des outils internes aux entreprises. Le PPO doit d’ailleurs assurer la migration d’un outil vers un autre lorsque cela est nécessaire. C’est par exemple le cas chez notre client actuel, pour qui nous assurons la migration de l’équipe et du backlog sur ServiceNow.

Ce qui reste primordial est qu’il faut des outils adaptés, pensés pour une gestion agile, pas des outils détournés pour ce genre de gestion. En plus du backlog, l’outil doit aussi par exemple permettre de stocker la documentation technique ou de stocker les maquettes métiers. Il nous arrive donc parfois d’utiliser plusieurs outils pour un même projet : par exemple, une équipe collaborative permettant la gestion documentaire, comme Teams, est indispensable !

Conclusion

Pour conclure, le rôle de PPO est un rôle multifacette. En interaction avec les parties prenantes d’une mission en agile, il doit être capable de comprendre les besoins des utilisateurs tout en communiquant avec les équipes de développement, et de porter les messages du PO lorsque cela est nécessaire.

C’est un rôle que nous conseillons à toute personne qui fait de l’agile pour comprendre l’ensemble des processus, apprendre à utiliser de nouveaux outils et s’adapter à un environnement complexe.

Envie d’en savoir plus sur le rôle ou de rejoindre les équipes Saegus ? N’hésitez pas à nous contacter ! Et retrouvez toutes les offres disponibles ici : https://bit.ly/3mZjDZM.

Contactez-nous