Permissions de géolocalisation et précision de position
Comprendre le contexte sécurisé, les permissions, la précision et les solutions de repli respectueuses de la vie privée.
Vous voulez la documentation structurée pour Empreinte ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
La géolocalisation Web peut fournir une position après l accord de la personne. C est une capacité médiée par l utilisateur, pas une preuve d identité, de propriété ou d intention. Expliquez le but, demandez dans un contexte sécurisé et gardez un parcours utile en cas de refus, révocation, délai, indisponibilité ou précision insuffisante.
Permission et contexte sécurisé
L API passe par navigator.geolocation et exige un contexte sécurisé. getCurrentPosition() doit suivre une action claire et une explication. Le navigateur peut afficher une demande, refuser ou conserver un état. MDN Geolocation API et Permissions API décrivent les interfaces.
Demandez lorsque la position aide la personne, pas au chargement sans rapport. Un refus ne doit pas créer de boucle ni demander d affaiblir les contrôles. La spécification W3C Geolocation décrit le modèle médié par permission ; navigateur et système décident si une position est disponible.
Une permission peut être révoquée et une politique peut désactiver la localisation. Préservez les données saisies, expliquez l action possible et proposez une adresse manuelle, un lieu mémorisé ou un parcours sans localisation.
Précision, délai et cache
getCurrentPosition() accepte enableHighAccuracy, timeout et maximumAge. Ce sont des compromis : un délai court peut échouer et un délai long faire attendre. Une position en cache est rapide mais peut être ancienne. Demandez la haute précision seulement si la tâche l exige.
coords.accuracy est un rayon estimé en mètres, pas une adresse garantie. Latitude et longitude peuvent être approximatives, anciennes ou absentes. Montrez l incertitude si elle affecte la tâche et ne transformez pas un rayon en adresse précise sans décision explicite.
Définissez les résultats acceptables avant la demande. Une météo peut fonctionner avec une zone large, tandis qu une livraison peut demander la confirmation d une adresse. N actualisez pas sans fin et arrêtez une surveillance après la tâche.
Refus, révocation et indisponibilité
Traitez refus, délai, position absente et résultat invalide comme des branches prévues. Expliquez l échec et ce qui reste possible. Saisie manuelle, code postal, lieu mémorisé ou choix sur carte préservent la tâche. Un refus ne prouve pas l emplacement d une personne.
Au retour d une suspension ou d un changement, recalculez une décision locale courte. Ne conservez pas un historique de coordonnées et ne poursuivez pas une surveillance après navigation. Documentez l environnement testé, pas une promesse universelle.
Minimiser les données de position
Utilisez la précision minimale nécessaire. Gardez une position en mémoire pour une vue et mémorisez un lieu choisi plutôt que des coordonnées. N inscrivez pas de coordonnées dans URL, étiquettes analytiques, identifiants ou dossiers par défaut.
Avant d envoyer une position à un service, expliquez but et conservation et demandez un choix distinct. Un événement peut enregistrer permission_denied, coarse_location ou manual_fallback, pas un historique. Vérifiez SDK, rapports, caches et workers.
La position est un contexte sensible. Ne la combinez pas avec compte, réseau, polices, stockage, temps ou appareil pour inférer identité, habitudes, santé ou intention. Un support doit avoir un but, un accès limité, une courte conservation et un effacement.
Concevoir et tester le repli
Testez contexte non sécurisé, demande, refus, révocation, délai, absence, cache ancien, précision large, délai haute précision et saisie manuelle. Vérifiez tâche, focus, libellés et données ; ne fixez pas une latitude ou adresse particulière.
Les contrôles doivent être accessibles au clavier et au lecteur d écran. Indiquez si le résultat est approximatif, mémorisé ou indisponible. Gardez le focus après la demande et rendez la reprise explicite. Un texte ou formulaire doit remplacer la carte.
Les promesses doivent rester plus étroites que les preuves : permission révoquée, politique désactivée et future version peuvent modifier la précision. Après restauration, changement de politique ou choix d un autre lieu, recalculez la décision locale, expliquez la limite et gardez la tâche normale.
Consultez le guide de confidentialité des permissions et les bases de la vie privée du navigateur.
L horodatage indique quand la position a été obtenue, pas quand la demande a été faite. Une valeur en cache peut être ancienne et doit être signalée.
Testez timeout et maximumAge ensemble : une valeur fraîche peut échouer, tandis qu une valeur mémorisée répond vite mais peut être obsolète.
L état granted ne garantit pas une position, et un cadre intégré peut être limité par Permissions Policy et le document supérieur.
Le contexte sécurisé permet la demande, mais ne garantit ni capteur, ni réseau, ni accord du système. Documentez le résultat visible du contexte testé.
Après un refus, proposez une saisie manuelle ; après un délai, une reprise bornée ; après révocation, exigez une nouvelle action explicite.
La conservation doit suivre la tâche : mémoire pour un écran, lieu choisi pour une préférence, pas d historique de coordonnées sans but.
Avant tout transfert, indiquez destinataire, but, conservation et suppression ; contrôlez rapports, caches et workers pour éviter les copies.
Testez états de permission, cadres, cache, altitude absente, horodatage ancien, suspension et reprise manuelle avec des données synthétiques.
Le repli accessible permet de saisir une adresse, choisir un lieu mémorisé ou continuer avec une zone large au clavier et avec lecteur d écran.
Réexaminez précision, horodatage, altitude, délai, âge maximal, conservation et repli quand la tâche change ; la promesse doit rester inférieure aux preuves.
Les coordonnées représentent un point et accuracy un rayon horizontal estimé ; davantage de décimales ne donne pas plus de certitude. L altitude peut manquer et l horodatage indique l obtention du résultat, pas la présence actuelle de la personne. Pour une limite, demandez de confirmer l adresse ou la région.
Choisissez les options selon la tâche : maximumAge accélère une vue large, timeout borne l attente et enableHighAccuracy peut coûter davantage sans garantir un petit rayon. Expliquez le délai, permettez l annulation et proposez une saisie manuelle.
Séparez les états prêt, demande, accordé, refusé, indisponible et résultat. granted peut encore produire un délai, et un cadre intégré peut être limité par Permissions Policy. Testez chaque contexte.
Gardez une position d écran en mémoire. Un lieu mémorisé doit être modifiable et supprimable. Avant transfert, définissez but, accès, expiration et suppression ; contrôlez URL, caches, rapports et composants de fond.
Le retour doit être textuel et accessible : rendez le focus, annoncez attente, cache ou indisponibilité et permettez annulation, reprise ou saisie au clavier et avec lecteur d écran.
La liste de vérification de compatibilité et de repli doit couvrir contexte non sécurisé, permission acceptée ou révoquée, cadre bloqué, cache, précision, altitude, horodatage ancien, délai, fournisseur absent, navigation, suspension, saisie et suppression avec coordonnées synthétiques.
Le produit doit permettre de changer d avis : arrêter un partage en attente, supprimer un lieu mémorisé et revenir au mode manuel. Indiquez ce qui était local et ce qui a déjà été envoyé, sans utiliser la permission pour identifier quelqu un. Gardez le repli visible.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.