Les requêtes d'autorisation sont le principal mécanisme du Web pour protéger les fonctionnalités puissantes potentiellement dangereuses pour la confidentialité et la sécurité des utilisateurs. Avec les requêtes d'autorisation, les navigateurs visent à s'assurer qu'un utilisateur a l'intention d'autoriser le site Web à demander l'accès à la fonctionnalité en question. Les requêtes d'autorisation sont utilisées pour un certain nombre d'API, y compris la capture multimédia (appareil photo et micro), la géolocalisation, l'accès au stockage, MIDI et les notifications (pour en savoir plus, consultez la documentation de l'API Permissions sur MDN).
Ce guide présente les bonnes pratiques à suivre pour afficher des requêtes d'autorisation aux utilisateurs en fonction des statistiques d'utilisation de Chrome et des recherches sur l'expérience utilisateur. En suivant ces bonnes pratiques, les utilisateurs devraient rencontrer moins d'invites inutiles, ce qui entraînera moins de décisions de blocage pour les développeurs. L'article se termine par quelques modèles de code pour travailler avec des API soumises à autorisation et des bonnes pratiques pour aider les utilisateurs à se rétablir d'un état bloqué.
Bonnes pratiques concernant les requêtes
Vous devez demander l'autorisation après une interaction avec l'utilisateur, au moment où il peut comprendre pourquoi vous la demandez et quel avantage il en retirera. Dans la mesure du possible, vous devez autoriser les utilisateurs à utiliser un autre moyen d'accéder à la même fonctionnalité. En règle générale, demander des autorisations moins fréquemment en choisissant soigneusement les moments où vous le faites réduit les risques que vos utilisateurs se retrouvent dans un état bloqué difficile à récupérer. Les bonnes pratiques suivantes fournissent des informations plus détaillées sur chacune de ces suggestions.
Ne jamais demander au moment du chargement de la page ni sans interaction de l'utilisateur
Demander aux utilisateurs une autorisation lors du chargement de la page équivaut à demander à un client des informations sensibles lorsqu'il entre dans un magasin physique. L'affichage d'une invite d'autorisation (parmi plusieurs autres invites d'inscription à la newsletter et d'autorisation des cookies) est une expérience très dérangeante. Les utilisateurs ne comprendront pas pourquoi ils sont invités à le faire et à quel avantage cela leur sera bénéfique.
Même si votre application Web ne peut pas fonctionner sans accès à une certaine fonctionnalité, vous devez donner aux utilisateurs la possibilité de comprendre pourquoi elle est nécessaire. Par exemple, en préfixant la requête d'autorisation par une requête de votre choix qui explique la nécessité et donne aux utilisateurs le choix (par exemple, dans la mesure du possible, en fournissant d'autres moyens d'exécuter la même fonctionnalité). Si vous ne trouvez pas de meilleur moment pour demander l'autorisation que lors du chargement de la page, vous trouverez quelques exemples plus loin dans ce guide.
Une situation tout aussi mauvaise pour demander une autorisation est de ne pas avoir d'interaction préalable avec l'utilisateur (également appelée activation temporaire de l'utilisateur). La télémétrie Chrome indique que 77% des requêtes d'autorisation dans Chrome pour ordinateur sont affichées sans un tel signal très basique de l'intention de l'utilisateur. Par conséquent, seules 12 % de ces requêtes sont autorisées. Après une interaction de l'utilisateur, les taux d'autorisation augmentent à 30%. Ne demandez donc l'autorisation qu'après que l'utilisateur a interagi avec la page d'une manière ou d'une autre.
Ne posez des questions que lorsque les utilisateurs peuvent comprendre pourquoi vous les posez.
Les décisions d'autorisation sont souvent des décisions liées à la confidentialité. D'après le cadre d'intégrité contextuelle, nous savons que les décisions de confidentialité sont très contextuelles. Comprendre pourquoi un accès est nécessaire peut être considéré comme un aspect clé de ce processus. Par conséquent, vous ne devez demander que les fonctionnalités dont vous avez besoin pour apporter de la valeur aux utilisateurs (et pour lesquelles les utilisateurs sont susceptibles de vous dire qu'ils en tireront effectivement profit). De plus, vous devez demander l'autorisation à un moment où l'utilisateur comprend clairement pourquoi cette fonctionnalité est utile. L'objectif est de permettre aux utilisateurs de comprendre le contexte d'utilisation aussi facilement que possible.
Nos études sur l'expérience utilisateur montrent que les utilisateurs sont beaucoup plus susceptibles d'autoriser l'accès lorsqu'ils comprennent pourquoi un site demande l'accès et qu'ils perçoivent un avantage. Nous constatons également que les utilisateurs s'attendent à pouvoir d'abord explorer les sites inconnus pour mieux comprendre la valeur qu'ils peuvent obtenir en échange de l'accès. Ils ignorent ou ignorent souvent les invites d'autorisation en attendant. Avec les autorisations ponctuelles, elles peuvent d'abord autoriser une seule visite. Votre application doit prendre en charge ces comportements.
Fournir d'autres moyens d'utiliser la même fonctionnalité, si possible
Les résultats de certaines fonctionnalités peuvent ne pas être utiles aux utilisateurs. Par exemple, la géolocalisation d'un ordinateur de bureau sans capteur GPS peut renvoyer la mauvaise position, car la personne est connectée à un VPN. D'autres utilisateurs peuvent ne pas vouloir accorder l'accès au presse-papiers, car ils préfèrent garder le contrôle et déclencher manuellement ces événements à l'aide de combinaisons de touches. Dans de telles situations, il est important de proposer un autre moyen d'obtenir les mêmes résultats. Par exemple, si vous demandez l'autorisation de géolocalisation, proposez un champ de texte dans lequel vos utilisateurs peuvent saisir eux-mêmes un code postal ou une adresse. Avec le presse-papiers, assurez-vous que les éléments à copier peuvent également être sélectionnés et copiés à l'aide d'une combinaison de touches ou du menu contextuel. Avec les notifications, proposez aux utilisateurs de recevoir des e-mails au lieu de notifications push.
Un modèle utile consiste à utiliser l'UI alternative pour expliquer pourquoi l'accès peut être bénéfique. Les utilisateurs qui voient une option permettant de saisir un emplacement à côté d'un bouton qui déclenche l'API de géolocalisation auront le sentiment de contrôler ce qui va se passer, car ils comprendront qu'ils peuvent aussi simplement saisir leur adresse. De même, si les utilisateurs ont le choix entre recevoir des notifications par notification push ou par e-mail, ou rejoindre une réunion sans autoriser l'accès à la caméra et au micro, ils comprennent plus naturellement les compromis qu'ils font.
Ne vous bloquez pas, car il est difficile de revenir en arrière.
Une fois qu'un utilisateur a décidé de ne pas autoriser définitivement l'accès à une fonctionnalité soumise à autorisation, les navigateurs respectent cette décision. S'il était possible de continuer à demander l'accès, les sites malveillants continueraient de bombarder les utilisateurs de requêtes. Par conséquent, la récupération de l'état bloqué d'une capacité demande intentionnellement un peu d'effort de la part de l'utilisateur. Par conséquent, évitez de demander aux utilisateurs une autorisation dans les situations où il est probable que de nombreux utilisateurs n'autorisent pas l'accès.
Pour ce faire, il est courant d'utiliser une invite préalable, dans laquelle vous expliquez à vos utilisateurs ce qui va se passer et pourquoi votre application a besoin de la fonctionnalité que vous allez demander. Vous ne devez déclencher l'invite d'autorisation du navigateur que lorsque les utilisateurs réagissent positivement à une telle pré-invite. Il peut arriver que les utilisateurs aient besoin de récupérer cet état. Pour en savoir plus, consultez la section Aider les utilisateurs à se rétablir après un blocage.
Faire attention aux contenus tiers
Une source inattendue d'invites d'autorisation doit être prise en compte. Si vous incluez des scripts tiers sur votre site, ils peuvent déclencher des invites d'autorisation que vous n'aviez pas l'intention d'afficher. Cela peut avoir un impact sur l'expérience utilisateur sur votre site Web, en particulier si ces invites ne respectent pas les bonnes pratiques déjà décrites. Pour garder le contrôle de l'expérience de vos utilisateurs, vous devez lire attentivement la documentation de toutes les bibliothèques et scripts tiers que vous ajoutez à votre propre code.
Quand demander l'autorisation ?
Voici quelques exemples de moments propices à demander l'autorisation, en suivant les bonnes pratiques déjà décrites:
- Une fois qu'un utilisateur a cliqué sur le bouton "Utiliser ma position" à côté d'un champ de formulaire permettant de saisir manuellement une adresse.
- Après qu'un utilisateur s'est abonné à une chaîne vidéo ou à des posts, et qu'il a cliqué sur un bouton d'acceptation dans une boîte de dialogue indiquant que les mises à jour peuvent être envoyées par e-mail ou par notification sur son téléphone ou son ordinateur.
- Lorsqu'un utilisateur accède à une page qui le prépare à rejoindre un appel vidéo et répond par l'affirmative à une invite préalable indiquant qu'il souhaite être vu et entendu (voir cette étude de cas Google Meet).
Modèles de code pour demander une autorisation
L'obtention de l'autorisation d'utiliser une API se fait de différentes manières, en fonction de l'API. Certaines API (généralement plus anciennes) utilisent un modèle dans lequel le navigateur demande automatiquement l'autorisation la première fois que vous essayez d'utiliser l'API. L'API Geolocation est un exemple d'API qui appelle navigator.geolocation.getCurrentPosition()
.
try {
navigator.geolocation.getCurrentPosition((pos) => console.log(pos));
} catch (error) {
console.error(error);
}
D'autres API utilisent un modèle dans lequel vous devez d'abord demander explicitement l'autorisation à l'aide d'une méthode statique. Notification.requestPermission()
est un bon exemple pour autoriser les notifications, ou le moins courant DeviceOrientationEvent.requestPermission()
, qui fait partie de l'API Device Orientation Events. Notez que certains navigateurs peuvent accorder automatiquement des autorisations à certaines API. Par exemple, Chrome autorise toujours l'accès à l'orientation d'un appareil, tandis que Safari affiche une invite.
const result = await DeviceOrientationEvent.requestPermission();
console.log(`The user's decision when prompted to use the Device Orientation
Events API was: ${result}.`);
if (result === 'granted') {
/* Use the API. */
}
Vérifier l'état des autorisations
Pour vérifier si vous pouvez utiliser une API spécifique, utilisez la méthode navigator.permissions.query()
de l'API Permissions.
const result = await navigator.permissions.query({ name: 'geolocation' });
console.log(`The result of querying for the Geolocation API is:
${result.state}.`);
if (result.state === 'granted') {
// Use the API.
}
Aider les utilisateurs à se rétablir après un blocage
Pour aider les utilisateurs à résoudre les problèmes d'accès, détectez qu'ils ont bloqué l'accès à l'aide de l'API Permissions et proposez-leur un guide pour modifier leurs paramètres. Par exemple, lorsque les utilisateurs interagissent avec des éléments d'interface utilisateur associés à une fonctionnalité soumise à autorisation, utilisez le modèle décrit dans la section précédente et ouvrez une boîte de dialogue de dépannage. La procédure exacte pour modifier l'état des autorisations varie selon le navigateur. Vous pouvez donc proposer des descriptions correspondantes en fonction de la chaîne user-agent et des navigateurs les plus couramment utilisés dans votre produit.
Dans Chrome, les utilisateurs doivent accéder à Paramètres du site en cliquant sur l'icône en forme de diapason sur le côté gauche de la barre d'adresse. Il peut alors activer l'autorisation correspondante. Dans certains cas, il peut être nécessaire de recharger la page avant d'utiliser cette fonctionnalité. Dans ce cas, une barre de message s'affiche en haut de la fenêtre et propose de recharger la page lorsque vous cliquez sur le bouton correspondant.
D'autres navigateurs proposent des UI similaires pour contrôler les autorisations (par exemple, voir comment cela fonctionne dans Firefox).