Orientation sur l’élaboration d’API prenant en charge des applications d’assistance vocale

Sur cette page

1. Principaux composants
2. Utilisation de SSML
3. Traduction
4. Gestion des appels
5. Développer pour Amazon et Google

Le présent document vise à fournir des recommandations et des conseils sur la conception et la mise en œuvre d’interfaces de programmation d’applications (API) afin de permettre la technologie d’assistant vocal comme Amazon Alexa et Google Voice Assistant. Le public visé est les praticiens techniques comme les développeurs et les architectes. Il ne s’agit en aucun cas d’un document d’orientation ou de politique pour l’élaboration d’application d’assistance vocale et les équipes de développement qui cherchent à élaborer ces types d’applications, qui doit être confirmé par rapport aux lois, politiques et lignes directrices applicables (p. ex., accessibilité, protection des renseignements personnels, langues officielles, sécurité).

• Qu’est-ce que la technologie d’assistant vocal? Les assistants vocaux sont communément considérés comme des appareils, par exemple, les points Amazon Alexa Echo ou les dispositifs Google Home. Cette technologie s’étend au-delà du matériel en plusieurs formats, y compris les applications mobiles disponibles pour les téléphones Android et iOS. Compte tenu du rythme d’innovation dans l’espace, il est préférable de penser aux assistants vocaux matière de fonction plutôt que de la forme de leur appareil.
• Pourquoi est-ce important? Les achats de haut-parleurs intelligents augmentent; ces appareils dédiés deviennent de plus en plus omniprésents chaque jour chez les utilisateurs moyens. Du point de vue de l’accessibilité, les assistants vocaux sont rapidement adoptés pour faciliter non seulement à la collecte de renseignements, mais aussi la fonctionnalité de maison intelligente (p. ex., les commandes de lumière et de fenêtre). Les Canadiens explorent cette technologie et s’attendent à ce que les services du gouvernement du Canada (GC) fassent de même.
• Dans quelles circonstances devrais-je l’utiliser? La technologie vocale est bien adaptée aux demandes de renseignements ciblées, comme la météo et la musique. Dans un contexte de service du GC, les renseignements sur le Web doivent déjà être mis en forme pour aider la technologie vocale à lire les pages Web. Les recherches de renseignements (p. ex., les rappels et les alertes de sécurité) ainsi que les guides de processus (p. ex., comment renouveler un passeport) sont des occasions privilégiées pour la technologie d’assistant vocal. À l’heure actuelle, le gouvernement du Canada n’est pas prêt à s’engager au niveau des comptes liés à l’identité.
• Devrais-je remplacer ma prestation de services existante par des assistants vocaux? La technologie des assistants vocaux est encore adoptée. À ce titre, il ne devrait pas servir de substitut aux méthodes de prestation de services existantes. Au lieu de cela, les assistants vocaux doivent être utilisés comme complément à une approche globale de prestation de services à canaux multiples, pour rencontrer les Canadiens là où ils sont et pour aider à réduire la congestion aux points de prestation existants.

1. Principaux composants

L’élaboration d’applications pour assistants vocaux peut sembler intimidant, mais les clients Google et Amazon sont bien adaptés à l’élaboration itérative et à la conception collaborative. Même s’il y a d’autres technologies d’aide vocale, au moment de la rédaction de cet article, la recherche menée pour produire cet article ne couvrait que les deux principales plateformes ayant des écosystèmes de développement matures.

• Appareils et client de produit – Que ce soit avec Amazon Alexa ou Google Voice Assistant, le processus commence de la même manière : avec des demandes propres à un appareil. Ces demandes sont transmises par Internet au client du produit concerné. Ces clients sont hébergés dans l’API GCP Speech de Google ou sur la plateforme de compétences Alexa d’Amazon. Ces clients de produits sont élaborés et entretenus par le fabricant. Ces clients consomment les demandes de renseignements et de forme aux services d’assistant vocal indiqués. Lorsque les services d’assistance vocale répondent, leurs réponses sont transmises aux appareils au moyen de ces mêmes clients de produits. Ces clients de produits sont élaborés et entretenus par le fabricant (c’est-à-dire, Google et Amazon), de sorte que les développeurs n’ont pas besoin de se soucier de la connectivité à des appareils individuels.
• Le Service d’assistance vocale – Une API webhook personnalisée doit être utilisée entre le client du produit et l’API de données sources. Cette API webhook est appelée ici le service d’assistance vocale. Il agit comme un traducteur et façonne l’expérience utilisateur pour être plus naturel et moins mécanique (p. ex., pauses, cadence vocale, inflexion). Par conséquent, les composants suivants doivent être inclus dans toute conception de service webhook :
  • Prise en charge multilingue – Le paramètre de langue doit être extrait des en-têtes de demande du client du produit pour effectuer les bonnes demandes du système principal à l’API source (p. ex., les demandes en français doivent fournir une réponse avec des données en français).
  • Prise en charge SSML – La langue parlée des assistants vocaux est le langage SSML (langage de balisage de synthèse vocale). Par conséquent, le service doit regrouper les réponses au format SSML pour une expérience utilisateur plus fluide. Voir ci-dessous pour plus de renseignements sur la prise en charge SSML.
  • Prise en charge de la pagination – Si un résultat est une collecte d’éléments, la norme recommandée est que l’utilisateur entend un résultat à la fois. L’utilisateur peut décider d’entendre plusieurs éléments ou passer à autre chose pour demander autre chose. Cette prise en charge ne fait pas toujours partie des API de données et doit faire partie du service.
  • Prise en charge de la mise en cache – Il est recommandé d’obtenir des renseignements sur la mise en cache lorsque cela est possible afin d’améliorer la réactivité du service. Cette prise en charge est particulièrement importante lorsque les résultats des données comprennent de grandes collections.
• L’API source – Les applications d’assistance vocale sont en fin de compte pilotées par les données. L’API source, est l’emplacement où ces applications d’assistance vocale récupèrent les données. Votre API source doit être conçue à l’aide d’une méthodologie du premier marché. Cela signifie se concentrer sur la création d’une structure de données atomique et claire qui peut être décompressée par n’importe quel consommateur pour répondre à ses besoins, que ce consommateur soit une application mobile, un site Web ou un service d’assistance vocale. L’API doit respecter les Normes du gouvernement du Canada sur les API et avoir un modèle de données clairement défini. La construction d’API réutilisable exige des données propres dans une structure claire qui peut être consommée par un large éventail de clients.

2. Utilisation de SSML

La technologie de reconnaissance vocale existe depuis un certain temps déjà. Les assistants vocaux tirent parti de cette technologie et d’autres encore pour imiter la dynamique réelle de la conversation. Afin de simuler les modèles de langage humain, SSML a été développé pour définir une syntaxe pour le flux de conversation, comme les pauses et le débit de la voix. Afin d’obtenir des résultats de manière claire et convergente, le service Webhook doit fournir des réponses à l’aide de SSML, en particulier pour des données comme des heures, des dates, des devises et des chiffres. La mise en œuvre de SSML doit être testée à fond à l’aide d’une grande variété de jeux d’échantillons de données.

3. Traduction

Normalement, la traduction est effectuée isolément, le traducteur extrapolant le contexte du document seul. La traduction est plus compliquée pour les assistants vocaux. Les conversations avec l’assistant vocal ne sont pas linéaires, et en tant que tel vous perdez beaucoup du contexte essentiel à la traduction. On obtient les meilleurs résultats en demandant à un traducteur de s’asseoir avec un développeur et d’examiner des scénarios. Ensuite, après avoir effectué les changements, on doit consulter le traducteur pour une autre itération dans une variété de scénarios pour vérifier que tout le texte est toujours logique. Il faudra peut-être faire des compromis lorsque les échanges varient entre l’anglais et le français. L’adoption d’un flux commun pour simplifier la solution peut rendre les interactions dans une langue plus difficile que dans l’autre, tandis que la création de la meilleure expérience absolue peut entraîner des solutions effectivement séparées (c’est-à-dire, flux) pour l’anglais et le français.

4. Gestion des appels

Très rapidement dans les tests, les appels d’applications manquantes que d’autres considèrent comme courants seront révélés. Ce delta se développe de façon exponentielle lorsqu’une application vocale est lancée. Les propriétaires d’applications doivent s’attendre à ce que quelqu’un vérifie régulièrement les clients du produit pour les phrases d’appel qui ne sont pas traitées par l’application. Google et Amazon ont tous deux facilité le suivi de ces données anonymes et l’intègrent rapidement dans le flux des appels. Ces mises à jour sont essentielles non seulement pour des raisons de commodité, mais aussi afin de veiller à ce que les applications soient accessibles aux utilisateurs qui pourraient ne pas utiliser les modèles de langage standard pour interagir avec les assistants vocaux. Les testeurs d’accessibilité doivent être introduits pendant les tests bêta afin de veiller à ce que le plus grand nombre d’utilisateurs possible puisse faire appel à l’assistant vocal.

5. Développer pour Amazon et Google

En général, les utilisateurs doivent avoir la même expérience sur différents appareils d’assistants vocaux. En outre, les assistants vocaux Google et Amazon ont les mêmes exigences en matière de support multilingue et de format de réponse SSML. La principale différence entre les différents assistants vocaux est les trousses d’élaboration de logiciels (SDK) qui rendent possible l’intégration entre les clients du produit et les API de voix. Ce point commun signifie que la plupart des services API vocaux doivent être écrits une fois pour toutes les technologies d’assistance vocale ciblées. Il devrait y avoir un contrat de service en couche mince dans le service Webhook pour permettre la communication avec les clients du produit. Cette couche mince peut être mise en œuvre pour n’importe quel produit pris en charge, tandis que le cœur du Webhook reste uniforme sur toutes les plateformes.

• Outils vocaux de développeur Google et hébergement – Pour Google, les requêtes de conversation et les phrases (appelées intentions) sont gérées dans Dialogflow. Afin de gérer cette conversation, Google exige que vous déployiez ceci dans son client de produit. Google exige que ce composant soit hébergé sur la Plateforme Google Cloud (GCP), pour lequel le propriétaire devra payer les frais d’hébergement correspondants. Cette API GCP Speech se connecte au service d’assistance vocale, qui peut être hébergé n’importe où.
• Outils vocaux de développeur et hébergement Amazon – Amazon achève son développement sur son Alexa Developer Portal. Veuillez prendre note que ce portail est séparé de leur service d’informatique en nuage Amazon Web Services (AWS) et exige un compte différent. La conversation et les phrases qui en résultent sont déployées sur la Alexa Skill Platform, qui n’exige pas du propriétaire de payer les frais d’hébergement. La Alexa Skill Platform se connecte au service d’assistant vocal, qui peut également être hébergé n’importe où.