- Exemples d’ajout d’une logique liée à la localisation dans une application
- Si vous voulez définir la langue ou la devise de l’application selon la région
- Si vous voulez proposer des réductions aux personnes de certains pays
- Si vous avez un store locator qui doit afficher l’emplacement le plus proche de l’utilisateur
- Si une application météo dépend de la localisation avant de fournir toutes sortes de données
- Si vous voulez géorestreindre l’application pour des raisons légales (ex. : bannière de cookies)
- Quelques thèmes communs se dégagent
- Affichage / expérience utilisateur : utiliser les informations de localisation pour améliorer ou simplifier l’expérience utilisateur
- Fonctionnalité / logique : la logique métier de l’application change selon la localisation
- Politique / conformité : il existe des exigences légales imposant d’inclure ou d’exclure certaines fonctionnalités
- La distinction n’est pas toujours nette. Dans certains cas, ces catégories se recouvrent, mais il est important de les garder à l’esprit, car la gravité d’une erreur varie selon le cas
Comment obtenir la localisation de l’utilisateur
- Demander directement sa localisation à l’utilisateur
- Avantages : facile à implémenter, fiable si l’utilisateur fournit des informations exactes, permet de prendre en charge différentes localisations
- Inconvénients : l’utilisateur peut faire une faute de frappe ou omettre des informations, ou fournir de fausses informations
- Utiliser les heuristiques de l’appareil
- Les appareils modernes peuvent accéder aux informations de localisation via le GPS, les données Wi-Fi, les antennes relais et l’adresse IP
- Les développeurs web peuvent accéder à la position de l’utilisateur via l’API Geolocation du navigateur
- Inconvénient : il faut demander à l’utilisateur l’autorisation de partager sa position, et il peut refuser
- Utiliser l’adresse IP
- L’adresse IP sert à identifier de manière unique un appareil sur le réseau et à le localiser
- Chaque groupe de chiffres d’une adresse IP représente un sous-réseau, d’une portée large vers une portée plus étroite
- Une adresse IP seule ne suffit pas pour connaître la localisation d’un utilisateur ; il faut la comparer à une base de données de localisations de sous-réseaux connus
- Utiliser l’edge computing
- Il s’agit d’exécuter la requête utilisateur sur le serveur le plus proche
- Cela permet de fournir des informations de localisation sans demander l’autorisation de l’utilisateur ni consulter son adresse IP
- Inconvénient : on obtient la localisation du nœud edge, pas celle de l’utilisateur réel
Pourquoi on ne peut pas faire confiance à la localisation de l’utilisateur
- On ne peut pas faire confiance à l’utilisateur
- Rien ne garantit qu’il saisira toujours honnêtement sa localisation réelle
- Il peut aussi entrer une mauvaise information par erreur
- On ne peut pas faire confiance à l’appareil
- L’utilisateur peut refuser l’usage de l’API Geolocation
- Il peut aussi modifier les informations de l’API Geolocation dans les paramètres du navigateur
- On ne peut pas faire confiance à l’adresse IP
- L’utilisateur peut faire transiter sa requête via un VPN
- Vous ne verrez alors que l’adresse IP du VPN, pas l’adresse IP réelle de l’utilisateur
- On ne peut pas faire confiance à l’edge computing
- Comme il s’agit de la localisation du nœud edge, elle peut différer de la localisation réelle de l’utilisateur
- En cas d’utilisation d’un VPN, il est impossible d’accéder à l’adresse IP d’origine
Alors, que faut-il faire ?
- Il existe plusieurs façons d’obtenir des informations de localisation, mais aucune n’est totalement fiable
- Faut-il pour autant abandonner ? No! On peut obtenir de meilleures informations et mieux se préparer
Exemple : traduction de contenu
- Supposons un site web rédigé en anglais, mais prenant aussi en charge d’autres langues
- Vous voulez charger la langue locale de l’utilisateur pour améliorer son expérience
- Comment gérer les utilisateurs en Belgique, où l’on parle néerlandais (flamand), français et allemand ?
- L’utilisateur demande le site web
- Via l’edge computing, vous déterminez que la requête vient de Belgique
- Vous cherchez une préférence linguistique dans les cookies HTTP
- Si un cookie existe, vous utilisez la langue préférée
- S’il n’y a pas de cookie, vous servez la version anglaise ou néerlandaise
- Le site web présente à l’utilisateur la liste des langues prises en charge
- Lorsque l’utilisateur choisit une préférence linguistique, elle est enregistrée dans un cookie
- Dans ce scénario, on combine l’edge computing et les informations fournies par l’utilisateur pour améliorer l’expérience utilisateur
- Il ne semble pas nécessaire d’utiliser l’API Geolocation
- Il existe un risque d’afficher la mauvaise langue, mais le coût reste faible
- Même si la localisation est incorrecte ou absente, le site web continue de fonctionner
- Mise à jour : l’en-tête Accept-Language, qui indique la langue et la locale préférées du client, peut aussi être utilisé
Exemple : application météo
- Il existe une application qui affiche la météo en fonction de la localisation
- Dans ce cas, l’application a besoin d’informations de localisation pour fonctionner. Sans elles, comment afficher la météo ?
- Dans ce scénario, il est acceptable de supposer la localisation de l’utilisateur au premier chargement
- On peut récupérer cette information via l’edge computing ou l’adresse IP pour afficher la météo de la région de l’utilisateur (supposée)
- Comme la localisation est au cœur du site, on peut aussi demander des données plus précises via l’API Geolocation
- Il faut également proposer une option souple permettant à l’utilisateur d’indiquer une autre localisation s’il souhaite consulter les informations d’un autre endroit
- Pour cela, on peut fournir un champ de recherche avec autocomplétion proposant des informations de localisation aussi détaillées que possible
- La gestion des visites ultérieures peut varier : toujours définir la météo « locale » par défaut, ou mémoriser la localisation de la visite précédente
- L’utilisateur demande le site web
- Lors de la première requête, on estime sa localisation via l’edge computing ou l’adresse IP et on démarre l’application
- Au premier chargement côté client, on exécute l’API Geolocation pour mettre à jour les informations
- On peut enregistrer la localisation dans un cookie pour les chargements futurs
- On fournit un champ souple avec autocomplétion pour rechercher d’autres localisations
- Le point important ici est que l’application ne se soucie pas vraiment de l’endroit où se trouve l’utilisateur
- Elle a simplement besoin d’une localisation
- La localisation fournie par l’utilisateur (via la recherche) prime sur celle trouvée via les cookies, l’edge computing ou l’adresse IP
- Comme la météo change tous les jours, il peut aussi être utile de réfléchir à la stratégie de cache et au fait de privilégier un rendu côté serveur ou côté client
Exemple : recherche de magasin
- Supposons que vous exploitiez des magasins physiques sur plusieurs sites
- Vous pouvez afficher en ligne le catalogue produit et les stocks, mais il est préférable de fournir aussi des informations à jour sur le stock en magasin
- Pour cela, il faut savoir de quel magasin afficher le stock, et pour offrir la meilleure expérience utilisateur, ce devrait être le magasin le plus proche de l’utilisateur
- Là encore, il est pertinent d’estimer la localisation de l’utilisateur via l’edge computing ou l’adresse IP
- Ensuite, on fournit un champ souple dans lequel l’utilisateur peut saisir sa localisation, mais l’autocomplétion doit être limitée à une liste de magasins triés par proximité
- Il peut aussi être utile d’exécuter l’API Geolocation
- La différence entre cet exemple et le précédent est que l’objectif principal du site ne dépend pas de la localisation
- Il faut donc attendre que l’utilisateur interagisse avec une fonctionnalité dépendante de la localisation
- Autrement dit, il ne faut demander la localisation que lorsque l’utilisateur place le focus dans le champ de recherche de magasin
Exemple : tarification différenciée selon la région
- C’est un sujet un peu plus délicat : comment facturer des prix différents selon la localisation de l’utilisateur ?
- Par exemple, certaines compagnies aériennes et chaînes hôtelières sont connues pour afficher des prix plus élevés aux utilisateurs qui réservent depuis certaines régions que depuis d’autres
- En laissant de côté les questions éthiques, c’est une question de rentabilité et l’impact peut donc être très important
- Vous ne voudrez donc probablement pas permettre aux utilisateurs de modifier facilement les prix via une localisation déclarative
- Dans ce cas, vous utiliserez sans doute uniquement l’edge computing ou l’adresse IP
- Les utilisateurs peuvent contourner cela avec un VPN, mais ce sera probablement la meilleure option disponible
- Si vous craignez vraiment les fraudeurs, vous pouvez essayer d’utiliser la détection avancée de proxy d’Akamai pour bloquer les requêtes d’utilisateurs passant par un VPN
- Mais dans ce cas, au lieu d’une vente à prix réduit, vous risquez de ne pas conclure de vente du tout. À vous de choisir
Exemple : bannière de cookies
- Ce dernier exemple est davantage centré sur la conformité légale, donc je commencerai par une petite clause de non-responsabilité : je ne suis pas avocat !!!
- Il ne s’agit que d’un exemple hypothétique et cela ne doit pas être pris comme un conseil juridique
- En 2016, l’Union européenne a adopté le règlement général sur la protection des données (RGPD)
- Il s’agit d’une loi protégeant la vie privée des internautes dans l’UE, qui s’applique aussi aux entreprises situées hors de l’UE dès lors qu’elles proposent des biens ou services à des personnes dans l’UE
- Il existe de nombreuses obligations pour les propriétaires de sites web, mais ce sur quoi je veux attirer l’attention, c’est le fléau des bannières de cookies que nous voyons aujourd’hui partout en ligne
- Je ne vais pas discuter ici des questions de confidentialité, du fait que les bannières de cookies soient bonnes ou mauvaises, de leur efficacité ou inefficacité, ni de l’existence de meilleures approches
- Je dirai simplement qu’il est préférable de n’afficher une bannière de cookies que lorsqu’elle est légalement nécessaire, et de l’éviter dans le cas contraire
- Une fois de plus, connaître la localisation de l’utilisateur est extrêmement important
- C’est très similaire au cas précédent, et l’implémentation l’est également. La différence principale réside dans la gravité des conséquences en cas d’erreur, et donc dans le niveau d’effort nécessaire pour bien faire les choses
- Les bannières de cookies sont peut-être l’exemple le plus répandu de la manière dont la loi et la localisation de l’utilisateur peuvent affecter un site web, mais si vous cherchez l’exemple le plus puissant, ce serait probablement le Grand Firewall de Chine
Conclusion
- Il n’existe pas de réponse unique pour déterminer la localisation d’un utilisateur
- Selon le scénario, il faut combiner les informations déclarées par l’utilisateur, les heuristiques de l’appareil, l’edge computing et l’adresse IP
- Points importants
- Avez-vous besoin de la localisation de l’utilisateur, ou juste d’une localisation quelconque ?
- Quel niveau de précision est nécessaire ?
- Est-ce acceptable si la localisation de l’utilisateur peut être falsifiée ?
- Il faut aussi prendre en compte la conformité légale, la réglementation, la fonctionnalité, et se demander si une fiabilité de 95 % est suffisante
- Si vous utilisez une logique de localisation pour des raisons juridiques, il est préférable de prendre des mesures pour vous protéger
- Respect des lois sur la confidentialité des données comme le CCPA, le RGPD, etc.
Aucun commentaire pour le moment.