Design d’une interface vocale destinée aux voyageurs du réseau RATP.
RATPLa requête:
Urbanopolis, le réseau des lieux d’innovation et le département Information Voyageur et Digital, travaillent main dans la main au sein du groupe RATP.
Ils œuvrent à trouver et tester la viabilité d’une innovation, concevoir son business model et à accélérer son développement.
Le groupe RATP s’est à adressé Souffl, et lui a proposé de développer un assistant vocal en collaboration avec Snips.
– Urbanopolis.
C’est le réseau des lieux d’innovation du groupe RATP, avec la vocation de partager
les idées pour faire avancer la ville avec ses habitants.
– Service Information Voyageur et Digital.
Structure intégrée à la RATP, créateur d’applications mobiles sur-mesure, pouvant contenir des informations statiques embarquées ou des informations dynamiques lorsqu’elles sont connectées au réseau.
– Snips (devenu depuis Sonos Voice Experience).
Fournisseur de la technologie de reconnaissance vocale propose une solution technique qui présente deux grands avantages:
– le premier est un réel respect de la vie privée de ses utilisateurs (Privacy-by-design): la reconnaissance vocale est effectuée par l’appareil lui-même et aucune donnée de l’utilisateur n’est envoyée à quelque serveur que ce soit.
– le deuxième est une vraie qualité de reconnaissance des demandes de l’utilisateur grâce à l’utilisation de l’Intelligence Artificielle (Deep Learning).
Développer
les idées d’aujourd’hui
pour la ville de demain.
Sensibiliser
à de nouveaux usages.
L’amélioration de l’expérience client est l’une des priorités stratégiques du groupe RATP.
Nous avons été consultés pour intervenir sur le développement d’un assistant vocal intelligent et autonome, capable de fournir aux voyageurs un état du trafic et les heures de passage en temps réel sur les réseaux Métro, Tram et RER de la RATP.
L’objectif est d’une part de sensibiliser les collaborateurs internes et les partenaires à ces nouveaux usages (BtoB); mais aussi d’explorer de nouveaux services à destination des clients du réseau (BtoC).
Une expérience interactive vocale.
Outre les challenges techniques que représentent le développement de ce dispositif, la principale difficulté rencontrée a été de rendre l’expérience interactive vocale la plus pertinente et qualitative possible. Ce qui est le meilleur moyen de la faire accepter par l’utilisateur.
Pour tenir cet objectif, le design des dialogues a joué un rôle prépondérant.
Gage d’efficacité, la genèse de cet assistant s’est faite en co-création entre les équipes de la RATP et de Souffl.
Croisant ainsi expertise métier, connaissance des usagers et savoir-faire en Design et Technologie.
Nous avons appris ensemble, surmonté les difficultés techniques, franchi les obstacles de production et aboutit à un produit dont les deux parties sont fières.
Design d’un dialogue.
Déterminer
le périmètre.
Avant de concevoir la façon dont le dialogue va s’articuler, il est, avant tout, nécessaire d’en déterminer le périmètre.
Dans le cas présent, il s’agit de savoir de quoi on va parler et ainsi de déterminer les questions auxquelles notre assistant devra savoir répondre.
Dès le début du projet, il a été décidé de se concentrer sur deux types de requêtes:
les heures de passage aux stations et arrêts l’état du trafic sur le réseau.
Il a ensuite fallu préciser ce périmètre en listant les cas d’usage réellement utiles:
l’utilisateur veut savoir quand part le prochain métro à telle station, éventuellement sur une ligne précise, dans une direction précise;
l’utilisateur veut savoir quand part le prochain métro de telle station à telle station;
l’utilisateur veut connaître l’état du trafic en général, sur un réseau spécifique, sur une ligne spécifique.
Toutes ces étapes ont fixé un cadre de travail propice à la conception du dialogue.
Y sont déterminés, à la fois les types de questions auxquelles on peut s’attendre et les types de réponses que l’on va donner.
La compréhension des intentions de l'utilisateur.
L’entraînement de l’IA.
Bien utilisée, la technologie de Snips permet de reconnaître les intentions des utilisateurs sur des contextes précis et de façon très fiable tout en laissant la liberté à l’utilisateur du choix du vocabulaire utilisé.
Pour cela, il faut entraîner l’IA avec une série de phrases types que pourrait prononcer l’utilisateur.
Par exemple:
“Dans combien de temps le prochain RER à Auber ?”
“Quand passe le prochain métro Villiers pour Opéra ?”
“Il est à quelle heure le prochain RER A à Nation ?”
Si les exemples choisis sont bien représentatifs, l’IA ainsi entrainée sera capable de comprendre ce qui lui est demandé, et ce, quelle que soit la façon dont l’utilisateur le lui demande.
La démarche générale.
Pour construire un algorithme de gestion de dialogue faisant la part belle à la clarté et à la fluidité de l’échange, il faut avoir une idée précise des informations que l’utilisateur doit nous donner.
Si la requête émise par l’usager n’est pas assez précise, il faut alors rebondir avec une question complémentaire claire et ciblée. Le but étant d’obtenir suffisamment de détails pour pouvoir donner une réponse satisfaisante.
Nous n’avons pas forcément besoin de toutes les informations, mais il faut quand même obtenir les informations minimales nécessaires.
Pour cela nous suivons différents scénarii préétablis, choisis parce qu’ils correspondent à un réel besoin et parce que l’on peut y répondre efficacement.
Dans les faits, si un usager veut savoir quand passe son prochain métro, ce sera forcément à une station précise.
En revanche, si on veut éviter de le noyer sous un tas de réponses inutiles, il faut que l’on en sache un peu plus.
La ligne qu’il veut emprunter, la direction dans laquelle il veut aller, ou à quelle station il souhaite descendre. Bref toute information complémentaire qui précise son besoin et permet de lui donner la réponse la plus pertinente possible. Sachant, bien entendu, que ce besoin de précision dépend de la station.
Si l’usager veut connaître les prochains passages à Alexandre Dumas, c’est simple, il n’y a qu’une ligne et deux directions. On peut donc lui donner directement la réponse sans lui demander davantage de précisions.
Si, en revanche, il fait la même demande pour Nation, c’est beaucoup plus compliqué.
Il y a 4 lignes de métro et 1 de RER, soit 12 directions à donner, ce qui est beaucoup trop. Dans ce cas, il faut lui demander de préciser la ligne, la direction ou la destination.
Une fois qu’on a assez de détails, on peut alors lui donner la réponse qu’il attend.
C’est la liste de tous ces scénarii qu’il faut établir et dans chaque cas prévoir comment nous souhaitons réagir afin de délivrer la meilleure expérience possible.
En pratique.
Cela passe par:
– bien formaliser les attentes de l’utilisateur (il peut juste vouloir les prochains horaires de passage à une station, vouloir les horaires pour aller d’une station à une autre, ou sur une ligne particulière…
– bien formaliser les informations que l’on attend de l’utilisateur;
– bien imaginer les différents cas possibles (si l’utilisateur ne donne qu’une partie des informations: que fait-on ?).
Et bien sûr:
– les gérer.
Il faut aussi savoir régler le bon degré de précision afin de demander assez d’information à l’utilisateur pour qu’il soit possible de lui donner une réponse utile. On aurait pu se contenter de peu d’informations et lui donner toutes les réponses possibles, mais alors la réponse se transformerait en un inventaire à la Prévert qui durerait 3 minutes et serait totalement inefficient.
Restituer l'information à l’utilisateur.
La première étape consiste à construire les phrases de réponse les plus efficaces possibles.
Cela implique de travailler la terminologie: quel vocabulaire précis doit être utilisé ?
Les mots et expressions doivent:
– respecter la terminologie en vigueur à la RATP,
–c’est le langage auquel les usagers sont habitués;
– ne laisser aucune place à une mauvaise interprétation,
– il faut être précis;
– être immédiatement compris par les utilisateurs de la solution.
Nous nous sommes pour cela appuyés sur l’expertise du service Information Voyageur.
Pour encore plus d’efficacité, il a aussi fallu travailler la façon dont les informations sont restituées: leur structure, l’ordre dans lequel elles sont données, leur hiérarchie, leur quantité.
Pour formuler une réponse sans ambiguïté, nous avons choisi d’aller du plus général au plus précis.
Prenons l’exemple d’un usager qui veut connaître les prochains passages à la station Villiers:
– à la station Villiers: on rappelle à l’utilisateur la station qu’il a demandée. Cela permet de donner le contexte et de lever l’incertitude d’une mauvaise compréhension par l’assistant;
– ligne métro 2: on précise la ligne. En effet, une station peut être desservie par plusieurs lignes, on liste donc les horaires de passage ligne par ligne. Cela permet aussi de lever une éventuelle ambiguïté. Toujours dans le but de ne laisser aucun doute, on rappelle qu’il s’agit du réseau de métro;
– direction Porte Dauphine: On précise la direction;
– le prochain train passera dans 2 minutes, le suivant dans 7 minutes: on donne l’information précise demandée; puis on donne les autres directions.
– enfin, on passe à la ligne 3 suivant le même schéma.
Le fait de délivrer hiérarchiquement l’information, de la plus générale à la plus détaillée, et aussi que cette hiérarchisation soit logique, évidente et prédictible; permet à l’utilisateur d’ignorer de façon totalement instinctive les informations qui ne l’intéressent pas.
Si l’assistant donnait d’abord les informations d’une direction, qui n’est pas celle qui intéresse l’utilisateur, instinctivement, ce dernier ‘se mettrait en attente’ d’entendre le nom de la destination qu’il attend. C’est le fait d’entendre cette direction qui va automatiquement réveiller son attention.
Le design.
Fournir un écrin en phase avec l’expérience.
Sur ce projet nous devions non seulement créer l’expérience du dialogue, mais aussi réaliser l’objet qui porte cette expérience. Si l’objectif qui présidait à la conception du boîtier était d’être le plus en phase possible avec cette expérience, il était aussi soumis à certains objectifs.
Des objectifs techniques, et en particulier une bonne qualité d’écoute et de restitution du son.
Des objectifs budgétaires, en maintenant des coûts et délais de fabrication raisonnables.
Electronique.
Pour la partie électronique, et compte tenu du fait qu’il s’agissait de produire une petite série de démonstrateurs, nous sommes partis sur une base de Raspberry Pi que nous avons complétée avec des composants sur étagère de qualité, dont nous maîtrisons bien les caractéristiques.
Avantages: maîtrise des coûts, des développements et de la qualité du produit final.
Design objet.
Le design objet devait à la fois refléter les identités RATP et Urbanopolis tout en véhiculant une dimension « expérimentation », et en étant réalisable pour un coût et des délais raisonnables et maîtrisés.
Nous avons choisi une forme simple, un cube, et opté pour le bois comme matériau.
Les panneaux ont été découpés et gravés au laser ce qui a permis à la fois de pouvoir réaliser des prototypes rapidement et de bien marquer l’identité du produit.
Au final.
RATP LAB.
5 démonstrateurs ont été produits et fournis à la RATP pour leurs tests et leurs labs.
Ils sont aujourd’hui déployés dans différents services et labs de la RATP.
