“Buzz Query”, un moteur de requêtes pour dashboarding bigdata serverless

L’histoire commence par la rencontre entre l’équipe DataPy et Rémi Dettai… Rémi est un ingénieur de talent spécialisé en Data et Cloud. Rémi a eu de nombreuses expériences dans les domaines de la tech, chez des industriels comme Continental ou encore dans des startups. Rémi a fondé Cloudfuse en 2020 et sa solution opensource mérite d’être partagée. 

Le but de cet article est donc de présenter son produit “Buzz Query”, une solution innovante de moteur de requêtes de dashboarding qui présente l’avantage d’être peu coûteuse comparée aux solutions des GAFA, tout en offrant des temps de latences très faibles. 

Cet article est donc l’opportunité de partager un panorama des solutions du marché de dashboarding BigData, d’en comprendre les enjeux et de mesurer pourquoi la solution de Rémi pourrait vous séduire.

C’est aussi l’opportunité pour des potentiels passionnés d’open source de rentrer en contact avec Rémi et de contribuer à sa belle initiative.

Compte tenu de la richesse technique des technologies mises en oeuvre au sein de cet article, nous vous proposons d’aborder successivement les thèmes suivants: 

  • Qu’est-ce que le dashboarding de BigData?
  • Le serverless, une approche efficace à bas prix
  • Forces et faiblesse de Spark et Elasticsearch
  • “Buzz Query”, une solution  de dashboarding serverless bigdata idéale pour les startups

Bonne lecture 😉

Qu’est-ce que le dashboarding de BigData?

On peut segmenter le monde du bigdata en deux parties, à l’image du moteur de recherche Google. 

D’une part, certaines solutions BigData vont permettre à un grand nombre d’utilisateurs d’accéder à un service (une application) en même temps. A titre d’exemple, Google aspire les sites du web, classifie les éléments clefs de chacun d’entre eux, puis permet à des millions d’utilisateurs d’obtenir les réponses à leurs requêtes en parallèle.

D’autre part, certaines solutions de BigData permettent à un nombre restreint d’utilisateurs d’accéder à un grand volume de données, en leur donnant la possibilité d’avoir des vues synthétiques, tout en leur permettant d’aller les étudier dans le détail. Là aussi, par exemple, Google permet aux webmasters ou autres responsables marketing d’analyser les audiences des sites (pages vues à telle heures… par tel type de population, dans tel et tel pays …). Cette solution qui s’appelle Google Analytics est une solution de dashboarding. Les utilisateurs veulent avoir des résultats de manière rapide, être capable à la fois d’aller dans le détail et d’avoir une vue de synthèse.

On commence à saisir le dilemme qui s’offre à l’ingénieur BigData lors de la création de chaque nouvelle architecture bigdata… Au moment de la création de telles solutions, leurs créateurs ne connaissent généralement pas totalement les usages futurs. Leur tendance est donc de vouloir stocker toutes les données, toutes leurs dimensions. La finesse des résultats demande des capacités de stockage et de calculs importantes. Une exigence du client interne est également souvent d’avoir une réponse à ses requêtes au bout de quelques secondes. On imagine mal devoir attendre plus de 30 secondes les stats de Google Analytics. Le temps de réponse est donc un paramètre clef de l’expérience utilisateur. Mais plus on souhaite avoir un temps de réponse rapide, et plus le coût de la solution augmentera. Faut-il donc stocker toutes les informations ou seulement des agrégations? Ne pourrait-on pas trouver d’autres types d’architectures combinant capacité à traiter des gros volumes de données, dans un temps satisfaisant pour l’utilisateur et à un prix ‘acceptable’?

C’est là que le serverless commence à intervenir, et nous vous présenterons cette approche dans un article dédié la semaine prochaine.

Modèle économique du RPA, technologie d’automatisation de tâches digitales

Pourquoi adopter ce type de solution pour gagner en productivité et en agilité ? Quels sont les autres bénéfices de cette technologie ? Comment se décider à la déployer ?

Tout d’abord, de quoi parle-t-on ?

Le Robotic Process Automation est une technologie qui permet d’automatiser des tâches répétitives que nous devons mener sur nos PC. Cette technologie est développée par plusieurs éditeurs logiciels depuis le début des années 2000. On compte parmi ces leaders : UiPath, Automation Anyware, Blue Prism et Microsoft.

A quoi ça sert ? Toutes les entreprises ont leurs process internes, process qui assurent d’une part leur bon fonctionnement, mais qui peuvent s’avérer consommateurs de temps et de précieuses ressources. L’idée du RPA est de reproduire le comportement d’un humain sur son PC et d’automatiser les tâches pertinentes, pour que l’humain se concentre sur les activités à plus forte valeur ajoutée.

Plus précisément, le RPA va permettre de reproduire, et de rejouer facilement des opérations de type ‘clics de souris’ ou saisie de textes dans différents applicatifs ou sites web. Le RPA permet d’extraire du contenu de documents, PDF, emails et formulaires. Il est également possible de déplacer des fichiers et des dossiers. Cette technologie d’automatisation permet également d’interfacer différents applicatifs, voir les interconnecter à des bases de données.

Dans quels domaines utilise-t-on le RPA ? Le RPA peut s’appliquer à tous les domaines de l’entreprise, à savoir Finance, Ressources Humaines, Marketing, Vente, Legal… et sur des process très variés. Quelques exemples : le RPA peut automatiser le contrôle de TVA intracommunautaire pour la déclaration d’un nouveau fournisseur. Il peut également accélérer l’onboarding d’un nouveau collaborateur en récupérant et traitant l’ensemble de ses documents, formations etc… Le RPA peut également permettre de scraper des données de sites web pour faire des études de marché. Il peut aussi générer des contrats automatiquement, saisir des comptes rendus d’activités… Les possibilités sont infinies.

Y a-t-il des secteurs prédisposés au RPA ? Là également, tous les secteurs peuvent bénéficier du RPA. Le secteur financier a peut-être une longueur d’avance. A ce jour, chez DataPy, nous intervenons dans les secteurs des Télécoms (plus de 200 robots développés), de l’Aerospace, de la Finance et de l’Agroalimentaire.

Figure 1: interface de développement UiPath (appelée Studio

Techniquement, il suffit d’installer un logiciel sur un PC utilisateur, et de configurer ce logiciel pour qu’il reproduise l’enchainement des actions attendues pour qu’il reproduise le processus attendu.

Approche opérationnelle ou stratégique ?

Les apports de cette technologie sont multiples : gain de temps et réduction des coûts sont souvent les bénéfices les plus évidents. Dans une seconde mesure, cela permettra aussi de gagner en qualité (éviter les erreurs humaines), réduire des risques, améliorer la satisfaction client et aussi améliorer la satisfaction des employés. Le confort de travail est accru, les salariés peuvent se focaliser sur des taches plus intéressantes et à plus forte valeur ajoutée.

Ces bénéfices adressent des process unitaires. Ils sont donc très opérationnels.

On peut aussi voir le RPA de manière plus stratégique : la pandémie a accru le besoin des entreprises de devenir résiliantes par rapport à l’imprévisible. Aucune prévision de risque n’avait anticipé ce que nous avons vécu. Les entreprises ont dû s’adapter comme elles ont pu, et souvent dans la douleur. Le RPA peut être vu comme une solution pour rendre les process plus souples, plus agiles. En effet, un robot RPA se développe en quelques semaines. Fini l’effet tunnel et les développements de plusieurs mois. Enfin, le RPA est totalement réversible par rapport aux postes clients ou à votre infrastructure IT. Inutile de modifier des API pour faire communiquer des applications entre elles, le RPA permet ces interconnections sans toucher la moindre ligne de code de vos applications métiers.

Comment se décider à adopter cette technologie ou pas ?

On peut souvent commencer par une analyse opérationnelle, puis la compléter par une vision plus stratégique.

D’un point de vue opérationnel, commençons par un cas simple et qualifions l’éligibilité technique du process. Est-ce que le process est suffisamment systématique et répétitif pour être automatisé ? Est-il suffisamment clair dans l’esprit des utilisateurs pour être formalisé ? Est-ce que les entrées de ce process sont suffisamment structurées pour permettre un traitement automatique ?

Une fois le process qualifié techniquement, il est d’usage d’évaluer un ROI potentiel. Les facteurs favorisant un ROI seront :

  • Avoir un nombre important d’utilisateurs,
  • Avoir des tâches unitaires chronophages,
  • Que ces tâches soient répétées fréquemment.

Le coût de conception dépendra de la complexité du process. Il faudra compter quelques semaines pour un process simple.

Le ‘ticket d’entrée’ d’un point de vue licence sera de quelques kilos euros.

Les 1ers process sont donc souvent amortis en un an ou moins. Nous avons des clients qui rentabilisent leur investissement en quelques mois.

Figure 2: Exemple de modèle économique du RPA

Au-delà de cette analyse de ROI, il y aura aussi des éléments business quantitatifs complémentaires, comme éviter des dépenses supplémentaires, gagner des revenus supplémentaires en détectant des erreurs …

Enfin, des éléments qualitatifs complémentaires pourront augmenter l’attractivité du business case. Le temps gagné pourra être réutilisé à des tâches davantage créatrices de valeur, en lien avec votre métier.

Nous venons de voir l’analyse pour un process. Les gains se démultiplient quand on commence à déployer la technologie plus largement. Un même robot (ie. une instance sur un PC utilisateur) peut accueillir plusieurs process. Dans ce cas, le coût de la licence est partagé entre les différents process du même robot.

Il est également une bonne pratique de challenger les différents process éligibles entre eux en faisant une matrice ‘bénéfices’ vs ‘complexité’ pour tout d’abord se concentrer sur les process simples à mettre en œuvre, et qui apporteront des bénéfices le plus rapidement.

Figure 3: Exemple d’étude de priorisation de processus – Bénéfices vs Complexité

Viendront ensuite les améliorations incontournables les ‘Must-do improvements’, une fois les premiers succès confirmés.

Cette approche pluri-process permet d’initialiser une démarche plus globale d’adoption de l’automatisation, et c’est là qu’on comme à avoir une approche plus stratégique.

Un cas concret : comment digitaliser la génération d’un contrat de vente d’un avion?

Jean-Philippe Diez, Directeur des négociations de contrats de vente d’avions au sein d’ATR, constructeur numéro un mondial d’avions régionaux, témoigne : « Dans le cadre de sa transformation digitale, ATR s’intéresse à toutes les technologies qui peuvent permettre à nos équipes de se concentrer sur l’essentiel : offrir à nos clients la réponse la mieux adaptée à leurs besoins. 

Rédiger des offres de vente d’avions implique d’effectuer de nombreuses tâches indispensables, dont certaines s’avèrent chronophages et à faible valeur ajoutée. J’ai fait part de cette problématique à DataPy, qui a proposé d’étudier l’automatisation de la génération des nouvelles offres de vente. A la suite d’un atelier de deux heures où nous avons expliqué en détail notre processus, l’équipe de DataPy a confirmé son éligibilité à l’automatisation grâce à la technologie RPA. Ils ont également évalué la complexité du processus et estimé en séance un retour sur investissement atteignable en quelques mois.

Avec le soutien du Directeur en charge de la transformation digitale d’ATR et de son équipe, nous avons convaincu la direction d’ATR de mettre à profit le premier confinement pour lancer avec DataPy un projet pilote. DataPy a impliqué l’équipe des négociateurs tout au long du projet afin d’améliorer la solution grâce à nos retours, de nous former à l’utilisation du robot et ainsi de susciter notre adhésion à ce nouvel outil.

Le robot est maintenant en production et toute l’équipe est ravie de s’en servir. Les gains directs sont au rendez-vous, tant en termes de temps gagné que de fiabilité des tâches accomplies par le robot. Nous pouvons désormais nous concentrer sur des tâches à plus forte valeur ajoutée, comme le développement de solutions sur mesure pour nos clients. La qualité de notre relation avec chacun d’entre eux s’en trouve renforcée, un atout inestimable en ces temps inédits.

Aujourd’hui nous présentons les résultats positifs de ce pilote dans toutes les fonctions de l’entreprise afin que chacun s’approprie le sujet et puisse également se libérer du temps, que ce soit pour travailler différemment ou tout simplement pour améliorer son équilibre vie professionnelle/vie privée.»

Pourquoi le RPA devient un axe stratégique ?

Au-delà des gains opérationnels qu’apporte le RPA, au-delà de l’agilité qu’il permet grâce à la rapidité de sa mise en œuvre et sa réversibilité, le RPA permet de développer une culture de l’efficacité.

Bill Gates avait créé le PC avec la vision d’un ordinateur personnel, un ordinateur par personne. Daniel Dines, cofondateur d’UiPath, éditeur leader du marché RPA a une vision proche pour le RPA, qu’il appelle Assistant Personnels. Il rêve d’un monde où chaque personne aurait son assistant personnel qui automatiserait ses tâches les plus systématiques pour qu’il se concentre sur ses tâches à plus haute valeur ajoutée. Cette vision devient réalité et nous fait poser la question suivante : « parmi les tâches que nous faisons, quelles sont-elles que nous pourrions faire faire à un robot ? ». Cela pose la question de notre valeur ajoutée en tant qu’humain dans les entreprises. Les tâches automatisable sont à la fois pléthore, mais il y a tant besoin d’humain. Le RPA est donc une occasion pour que chacun se pose la question de sa propre valeur ajoutée au sein de l’entreprise, et fasse évoluer son apport à l’entreprise. J’y vois donc une opportunité de cultiver le sens du progrès, du développement des compétences, et c’est tout aussi important que l’amélioration de l’efficacité.

Alors, êtes-vous prêts à vous lancer dans l’automatisation avec du RPA ?

En route vers l’automatisation : iceberg, procrastination et nœud gordien

Quels sont les freins et accélérateurs du DevOps ?

 

Iceberg

Lorsque l’on évoque l’automatisation, le top management dispose trop souvent de peu d’indicateurs sur le volume de taches automatisables dans son département. En effet, les collaborateurs ont tendance naturellement à en minimiser le volume. Ils ne savent pas que c’est automatisable, ou pire ce n’est pas leur intérêt. C’est l’iceberg. Les taches automatisables sont invisibles et le management n’en a pas conscience. L’épouvantable : « On a toujours fait comme cela » est un premier élément du diagnostic. Lorsque, à la question de ce qui est automatisable, l’on obtient de ses collaborateurs une réponse du type : « Ne touchez à rien. Cela ne marche pas comme cela », il est temps de justement s’y intéresser et y toucher !

Pour paraphraser mon ami Henri Beyle*, l’automatisation est un univers où il est plus important d’avoir une opinion sur les softs que de maitriser les softs. Parmi ceux-ci, voici quelques exemples de technologies utilisées pour l’automatisation : Ansible, Terraform, Gitlab, Jenkins…

 

Procrastination

Procrastination : du latin pro « en avant » et crastinus « du lendemain ». Contraints par des tâches quotidiennes, une fois conscient de l’enjeu, il n’est pas simple de cerner l’automatisation : qu’est ce qui est réellement automatisable. Est-ce que le R.O.I est clair ? Que va faire mon équipe de ce temps gagné ?  Bref, cela représente un effort, pas franchement le bienvenu. C’est donc le classique « il faudrait que je m’en occupe, mais là je n’ai pas temps. »

 

Concrètement, il n’est pas nécessaire de prévoir un plan complet. Mieux vaut partir d’un premier ensemble de taches automatisables, pas le plus considérable, ni celui qui n’a aucun impact. Si je le reformule, choisir le « bloc » qui est le plus impactant ET le moins complexe, le plus démonstratif. Il y a ici un enjeu stratégique où votre pilotage est totalement indispensable :  il s’agit de comprendre les impératifs métiers de chaque intervenant et évaluer la pertinence de chaque tache. Comprendre toutes ces micro-taches est indispensable pour disposer d’une vision complète et réaliser un choix pertinent.

 

En n’oubliant pas que vos intervenants ont rarement une vision claire du sujet. Par exemple des experts routeurs (eg Cisco) maitrisent le plus souvent le fonctionnement de leurs matériels mais ont une connaissance très vague de ce qui est automatisable.

Lorsque le sujet passe de « on verra demain » à « plus jamais cela » vous avez atteint la maturité pour envisager notre 3eme étape : la mise en œuvre aussi nommée industrialisation.

Ce qui est nouveau ici c’est la consumérisation des machines. Par exemple, avec un script Terraform, lorsque l’on utilise une variable, on change d’échelle.

Noeud gordien*

Il arrive donc un moment où le besoin devient patent, ou sort du POC pour aller vers l’industrialisation. C’est le cas dans le domaine du Big Data. C’est aussi (et ce sera plus démonstratif par exemple lorsqu’il s’agit de générer des centaines voire des milliers de machines virtuelles. Sans automatisation, le travail serait titanesque. En 5 minutes, grâce à l’automatisation avec la mise en place d’un script réalisé en quelques jours il est possible de créer des centaines de machines virtuelles.   La mise en place de l’automatisation devient un nœud gordien. Vous êtes prêt pour le trancher.

La mise en place des automatisations requiert un changement culturel profond -penser automatisation- et une somme d’expertises rares de DevOps dont vos équipes ont rarement l’expertise. Bref, vos équipes ont besoin d’un « pied à l’étrier » et il est plus facile et efficace de greffer une « culture Devops automatisation » que d’essayer de la faire pousser « ex nihilo ». Sauf bien sûr si un de vos collaborateurs vous relance avec ce sujet depuis plusieurs mois. Mais si c’était le cas liriez-vous cet article ?

Ce « pied à l’étrier » peut être temporaire (une mission à durée limitée) afin d’acquérir les compétences en interne ou penser comme une mission externe permanente (un œil externe qui ne pense qu’automatisation).

Le DevOps se base sur la culture de partage avec les parties prenantes.

Grâce à l’automatisation on simplifie les taches courantes. Vous avez aussi à ce stade un rôle clef à jouer en validant la liste de priorités. Croyez-nous vos collaborateurs ont un talent extraordinaire pour complexifier les taches les simples. Un arbitre est donc particulièrement utile dans cette phase.

 

Les questions à trancher sont :

Toutes les taches sont-elles nécessaires ?

Comment mesure-t-on la pertinence de chaque tache et comment on va les automatiser ?

Ces taches vont-elles impacter les autres services. Si oui, comment effectuer une liaison efficace avec les autres ?

 

Le secret d’une bonne automatisation est la détection via les tests que les scénarios du pire ont bien été pris en compte. Avez-vous prévu tous les cas de figure ? Vos équipes ont-elles signé que tous les automatismes sont totalement sécurisés ?

Dans la culture DevOps on doit tout tester constamment et donc aucune erreur ne doit arriver. Vous pouvez mesurer la conscience de vos collaborateurs sur ce point. Les réponses du type « Pourquoi cela arriverait ? » est un indice absolu de l’impréparation de vos équipes. Ils n’ont pas conscience de l’essentiel.

Enfin, pour finir, il s’agit après avoir trancher notre nœud, de nettoyer et de ranger. Concrètement, il n’y a pas de DevOps sans documentation parfaitement à jour. Votre responsabilité est clef.

La documentation doit être écrite, connue de tous et transmise religieusement. En gros c’est à intégrer dans votre processus qualité. La documentation doit être sanctuarisée comme une phase de test en propre.

Ici un pipeline Gitlab. Derrière cet écran dépouillé se cache un ensemble de tests complets.

Et maintenant ?

Vous en conviendrez, l’automatisation n’est pas si compliquée à mettre en œuvre avec une bonne équipe et le bon accompagnement d’experts compétents.

Oui Datapy a une forte expertise dans ce domaine depuis bien avant que ce ne soit à la mode. L’automatisation est même à la genèse de la création de notre société.

Non, nous n’avons pas de plaquette ou de livre blanc. Chaque cas est unique.

Oui bien sûr, nous pouvons réaliser un audit (avec vous) de votre situation.

Comptez quelques semaines pour commencer à produire des résultats pertinents.

Oui, le TJM dépend du contexte, mais rien de stratosphérique non plus.

 

Depuis Lamarck et Darwin on sait que les entreprises qui n’évoluent pas disparaissent. Pour évoluer, un modèle économique a deux options : améliorer son produit/service, ou devenir plus compétitif que ses confrères. C’est là que l’automatisation a son rôle à jouer.

Nous avons évoqué ici le DevOps, qui permet d’automatiser des processus et taches IT, mais l’automatisation est aussi possible dans la Data (nous parlerons de DataOps) et dans des domaines métiers (finances, achats ou RH par exemple) grâce  au RPA ou au BPM .

 

 

Olivier Tyrbas de Chamberet avec l’amicale aide de Jerome Taurines et de François De le Rue.

 

 

 

* Henri Beyle, dit Stendhal. La France est un pays où il est plus important d’avoir une opinion sur Homère que d’avoir lu Homère

* L’expression nœud gordien désigne, métaphoriquement, un problème qui ne présente pas de solution apparente, finalement résolu par une action radicale. Par extension, la solution apportée à ce problème est radicale, ce qui a forgé l’expression « trancher le nœud gordien ».

SEO vocal et monétisation des applications vocales

Les assistants vocaux s’inscrivent dans les enjeux du marketing digital mais les règles et techniques du web et des applications mobiles ne s’appliquent plus.

Il est nécessaire de penser un positionnement marketing spécifique, tout en l’inscrivant dans une expérience digitale multi-support.

Découverte

L’usage premier des assistants vocaux est intuitif.

L’utilisateur ne consulte pas toujours les répertoires d’applications, ou s’il le fait, a du mal à retenir les noms précis des applications. 48% des utilisateurs d’enceintes connectées ont déjà utilisé une application tierce, hors de fonctions natives d’Alexa ou Google (source Voicebot).

Alexa nécessitait jusqu’à présent de s’abonner à des skills.

Google Assistant permet d’appeler des applications directement sans s’y abonner. Pour cela, on peut consulter un répertoire d’applications et dire le nom de l’application (“évocation explicite”), ou être conseillé par l’assistant qui propose des applications correspondant aux besoins exprimés par l’utilisateur.

Alexa évolue progressivement vers ce modèle (“évocation implicite”).

-Les répertoires d’applications et l’évocation explicite

La mise en avant dans les répertoires d’applications multiplie les visites (x10 à x1000 selon notre propre expérience) mais nécessite un travail spécifique et constant pour se maintenir.

Ces techniques s’apparent à du SEO, mais avec des règles bien spécifiques que seule l’expérience nous a permis de découvrir.

Le choix du nom de l’application est important pour l’audience, et nécessite d’être accompagné en fonction de retours d’expériences similaires. En parallèle, aux États-Unis, plusieurs skills Amazon ont mené des campagnes digitales de communication classique pour faire connaître leur nom.

 

-L’évocation implicite

La plupart du temps, l’utilisateur utilise des noms communs pour exprimer son besoin plutôt que le nom d’une marque. C’est l’assistant vocal qui l’oriente vers la bonne application.

Contrairement au SEO et au SEA sur le web, les assistants vocaux ne proposent qu’un résultat. Au mieux un nombre très restreint. Le premier remporte tout le trafic !

Les algorithmes de choix par Google et Alexa ne sont pas publics, mais là encore, l’expérience nous ont permis de mieux les appréhender.

Chaque cas doit s’étudier spécifiquement mais on citera en particulier quelques règles générales :

– l’importance des avis

– l’adaptation à l’historique de l’utilisateur

– l’importance d’être la première application à répondre à un besoin ou un mot-clef

– l’intérêt du “deep linking” vocal, et la nécessité de le concevoir de manière spécifique

Monétisation

 

Dans un marché naissant, le retour sur investissement des applications vocales est encore un pari; beaucoup essaieront sans trouver un modèle clair, mais les premiers qui réussiront trouveront un différenciant.

Il est difficile d’isoler un retour sur investissement spécifique à la voix sans l’intégrer dans un parcours plus global.

 

Les méthodes de monétisation directe reste à inventer, à ce jour on recense :

– les achats de voice commerce mentionnés au paragraphe précédent, correspondants à des situations d’achats et des types de produits précis

– des achats in-app de contenus à valeur ajoutée

 

Le retour sur investissement est encore aujourd’hui essentiellement indirect

– association de la marque à un nom propre et visibilité digitale

– accès facilité au service client, et fonctions simples de relation avec la marque ou le service client.

 

Les possibilités de monétisation sont dépendantes des fonctions mises à dispositions par Google et Amazon, qui évoluent rapidement. L’API de transaction n’a par exemple été ouverte en France qu’en Avril 2018.

Il est important d’assurer une veille pour anticiper leur ouverture et pouvoir les exploiter en premier.

Ce type d’information sur les perspectives et les roadmaps est souvent diffusé par le réseau de développeurs et notamment les animations réservés aux développeurs avancés.

Engagement et Rétention

Sans veiller à la rétention, une fois qu’un utilisateur trouve une application, il n’y a que 6% de chances qu’il continue à l’utiliser après 2 semaines (source VoiceLabs report).

Aujourd’hui, des systèmes d’abonnements et de notifications sont disponibles. Ce sont des outils efficaces pour renforcer l’engagement; il est cependant nécessaire de bien tester la pertinence et le nombre des notifications.

Le premier facteur d’engagement est la qualité de sa première expérience. La conception de l’expérience utilisateur lors du premier usage, puis lors des réusages, est essentielle.

Concevoir une Application vocale

Les interfaces vocales ont des spécificités dont la conception doit tenir compte.

Nous les résumons selon 9 principes :
Immédiateté

 Naturel

 Facilité

 Linéarité

 Unidirectionnalité

 Ecoute

 Norme

 Contexte

 Expérience

 

Immédiateté

L’appel à une commande vocale est immédiat :
“ Alexa, quelle est la météo à Paris pour demain ?”

Une même demande sur une application mobile nécessite de :

– chercher et prendre son téléphone

– le déverrouiller

– chercher l’application

– l’ouvrir, attendre qu’elle se charge

– reposer son téléphone

 

L’expérience utilisateur la plus appréciée sera celle qui conserve cette immédiateté.

Les réponses longues, les listes de choix à rallonge sont à éviter.

 

Naturel

Le voicebot s’appuie sur le langage oral commun, qui ne peut être encadré. Il est bien différent de la manière dont on s’exprime par écrit.

La compréhension des mots et du langage naturel ne sera pas la même dans un bot écrit et un bot vocal, un apprentissage spécifique est à prévoir.

Dans le cas de la construction simultanée d’un chatbot et d’un voicebot, il est recommandé de commencer la construction du dialogue par la partie vocale car celle-ci doit respecter plus de contraintes. Et bien qu’il soit possible de s’inspirer du schéma de dialogue d’un chatbot pour l’interface vocale, il n’est pas recommandé de transposer le chatbot qui pourrait avoir des réponses que ne sont pas adaptées.

 

Facilité

Les mots sont dits trois fois plus vite qu’ils ne sont écrits.

Même s’il est nécessaire de demander des réponses précises, l’utilisateur ne doit pas se sentir contraint dans ses réponses comme dans un serveur vocal interactif
(“choix 1”), ni devoir retenir des fonctions et des mots d’appels.


Linéarité
Quand une personne lit un texte ou regarde une image, elle a tout le loisir de s’arrêter sur un mot qu’elle n’a pas compris. Lorsque celle-ci écoute la réponse à sa commande vocale, il lui est impossible de mettre en pause. Elle est souvent obligée d’être attentive à son assistant et d’attendre la fin de la réponse pour pouvoir le réengager. Pour limiter cette gêne, il est recommandé de marquer des temps de pause dans le dialogue si beaucoup d’informations sont énoncées.

 

Unidirectionnalité

Il sera plus difficile pour un usager de naviguer dans du contenu au format audio interactif que sur une interface tactile. Sur une interface vocale, Il ne pourra pas facilement passer un passage qui lui apportera peu de substance ou revenir en arrière sur une information qui l’a marquée. Pour dynamiser le dialogue, il est recommandé d’utiliser des énoncés concis.

Ecoute

L’usager d’une interface vocale n’a pas de support graphique pour accompagner son expérience. Il doit écouter et retenir chaque choix qui lui est proposé. Pour ne pas saturer sa charge mentale, il est conseillé de proposer un nombre d’options disponibles limités.

Quand c’est au tour de l’application vocale d’écouter, si on attend de l’utilisateur plusieurs informations, il vaut mieux lui demander en plusieurs étapes pour alléger sa charge mentale.

 

Norme

Afin de garantir une homogénéité d’interaction pour des demandes similaires faites dans des applications existantes, des normes existent : pour les transactions sur Google Home, l’écoute d’un média sur Alexa. L’utilisateur s’habitue à ces normes spécifiques à chaque plateforme et il est préférable de les suivre.

 

 

 

Contexte

L’interface vocale sera conçue différemment selon le contexte d’usage (en cuisinant, au volant, en effectuant des tâches manuelles…). Chacun de ces contextes doit être précisé dès le début de la création de l’application vocale.

 

Expérience

L’interaction vocale est ressentie comme plus “humaine” qu’une interaction texte.

On s’attend à une relation personnelle, qui nécessite le design d’une expérience personnalisée.

 

 

 

Voici 10 recommandations à suivre pour une application vocale réussie.

 

1. Se concentrer sur une fonction

– éviter un risque de confusion auprès des usagers

– optimiser la qualité d’un usage de l’application en particulier

2. Commencer par écrire le dialogue idéal

– puis gérer chaque sortie du script

– rediriger l’usager vers le chemin idéal

3. Simuler le dialogue à voix haute

– mieux visualiser le rendu du parcours à l’oral
– optimiser les tournures de dialogue

 

4. Écrire des dialogues courts

– ne pas saturer la chargement mentale de l’usager

– ne pas proposer trop d’options à l’utilisateur

 

5. Récupérer les choix de l’usager séparément

– faire énoncer les informations attendues une par une

– indiquer qu’une réponse est attendue via une forme interrogative ou impérative

 

6. Guider l’utilisateur dans la formulation du dialogue

– l’utilisateur ne sait pas forcément ce qu’il faut dire ou faire
– présenter les choix disponibles clairement : “Désirez-vous lire vos nouveaux messages ou en écrire un nouveau ?” VS “Que souhaitez-vous faire ?

7. Utiliser des silences et des “icônes” audio

– accentuer certains mots importants

– rendre l’expérience plus divertissante et se démarquer

 

8. Organiser une bêta test

– impossible de prédire comment va réagir un utilisateur au script de dialogue

– itérer en continue en fonction des retours

 

9. Personnaliser l’expérience

– raccourcir certains passage de dialogue pour les utilisateurs expérimentés

– créer une expérience sur-mesure, ex : “Bonsoir Quentin”

 

10. Faciliter la découverte de l’application

– améliorer les manières de déclencher l’application via le Voice SEO

– optimiser la présentation de l’application (titre, icône, description)