navigator.geolocation
Le navigateur expose la position de l’appareil. Les sites la demandent, les utilisateurs l’approuvent. Le navigateur ne décide jamais quand la localisation est nécessaire.
Une fine couche de transport, pas un produit de consentement
La réglementation demande aux navigateurs de gérer le consentement. navigator.consent vous permet de répondre à cette obligation sans devenir des gatekeepers du consentement. Vous fournissez la plomberie. Les CMP et les assistants de consentement font le reste.
Une pression réglementaire convergente
Les obligations de consentement pour les navigateurs arrivent des deux côtés de l’Atlantique. La question n’est pas si mais comment.
GPC vous donne navigator.globalPrivacyControl, un signal binaire de refus. navigator.consent étend le même pattern navigator.* d’un signal binaire à une coordination granulaire du consentement, finalité par finalité, conforme à l’exigence de spécificité du RGPD.
California Opt Me Out Act
AB 566 (signé en octobre 2025) exige que tous les principaux navigateurs intègrent une fonctionnalité Global Privacy Control native d’ici le 1er janvier 2027.
Digital Omnibus européen
L’Article 88b(6) exige que les fournisseurs de navigateurs non-PME offrent des moyens techniques permettant aux utilisateurs de donner ou refuser leur consentement via des signaux lisibles par les machines.
Suggestion DevTools : un panneau Consent
Un onglet Consent dédié dans les DevTools, analogue à Application ou Network, donnerait aux développeurs et aux régulateurs une visibilité en temps réel sur l’état du consentement. Une opportunité de différenciation pour les navigateurs, pas une obligation.
| registrationId | reg_a1b2c3 |
| provenance | cmp |
| status | Actif |
| finalités | 3 |
| fournisseurs | 3 |
Finalités
| Finalité | Base légale | Consentement | Défini par |
|---|---|---|---|
| Analytics | legitimate_interest | granted | privacy_assistant |
| Advertising | consent | denied | user |
| Functional | legitimate_interest | granted | cmp |
Fournisseurs
| Nom | Domaine | Finalités | Consentement | Défini par |
|---|---|---|---|---|
| Analytics Co | analytics.example | analytics | granted | privacy_assistant |
| AdNetwork | ads.example | analytics, advertising | denied | user |
| Social Widget | social.example | functional | pending | — |
Pour les développeurs
Inspectez les enregistrements actifs, les catalogues de fournisseurs, les déclarations de finalités et l’état des préférences en temps réel avec attribution de provenance. Déboguez les flux d’événements et identifiez les erreurs courantes comme l’appel de méthodes réservées aux extensions depuis le contexte DOM.
Pour les régulateurs
La chronologie d’audit fournit un journal chronologique de chaque mutation de consentement : qui l’a définie, quand, et ce qui a changé. Un outil de vérification de conformité qui profite à l’ensemble de l’écosystème.
Un pattern familier
navigator.consent reprend le même schéma que les API web que vous implémentez déjà :
navigator.permissions
Le navigateur enregistre quelles permissions ont été accordées et applique la frontière entre accordé et refusé. Il ne choisit pas pour l’utilisateur.
CSP / CORS
Les sites déclarent quelles origines et ressources sont autorisées. Le navigateur applique ces déclarations. Pas d’interprétation, juste l’exécution de la politique.
navigator.consent fonctionne de la même manière : le navigateur fournit le namespace, applique les frontières de permissions entre les contextes DOM et extension, dérive la provenance du contexte d’exécution et distribue les événements. Il ne prend pas de décisions de consentement.
Frontières de permissions
Le navigateur applique une séparation nette entre le contexte DOM (scripts de page) et le contexte d’extension (assistants de consentement). La provenance est dérivée du contexte d’exécution. Les appelants ne peuvent pas la falsifier.
| Capacité | Contexte DOM | Contexte d’extension |
|---|---|---|
| Enregistrer interfaces, fournisseurs, finalités | Autorisé | Refusé |
| Lire les métadonnées fournisseurs/finalités, masquer/afficher, auditer | Refusé | Autorisé |
| Mettre à jour les préférences, retirer le consentement, écouter les événements | Autorisé | Autorisé |
| Lire le contexte réglementaire | Autorisé | Autorisé |
| Modifier le contexte réglementaire | Refusé | Autorisé |
Les mises à jour de provenance utilisateur l’emportent toujours. Entre CMP et assistant (en l’absence de valeur de provenance utilisateur), le dernier écrivain l’emporte. Le navigateur dérive automatiquement la provenance du contexte d’exécution de l’appelant.
Au-delà du consentement : application coopérative des cookies
Avec les enregistrements CMP déclarant quels domaines de fournisseurs ont le consentement, le navigateur dispose de suffisamment d’informations pour appliquer la politique de cookies au niveau réseau. Les cookies tiers provenant de domaines sans signal de consentement correspondant pourraient être bloqués au Set-Cookie ou effacés à la navigation, de manière similaire à la façon dont CSP bloque les sources de scripts non autorisées. Les fournisseurs consentis continuent de fonctionner. Le pistage non consenti s’arrête à la frontière.
Ce que vous n’auriez pas à assumer
navigator.consent est une couche de transport. Le navigateur transporte les messages, il ne les interprète pas. Sa responsabilité s’arrête à la frontière de l’API.
Pas d’interface de consentement
C’est la CMP qui présente l’interface de consentement, pas le navigateur. Aucune décision de design, aucune responsabilité liée aux dark patterns.
Pas de décisions de consentement
L’API est du transport. Elle véhicule les signaux entre CMP et assistants de consentement sans les interpréter ni imposer de décision.
Pas de charge de conformité
La CMP gère les pistes d’audit, la base légale et les preuves réglementaires. Le navigateur n’est pas le système de référence.
Pas de curation de fournisseurs
Modèle d’enregistrement ouvert. Pas de listes blanches, pas de portes d’attestation, pas de responsabilité de gatekeeping.
Explorer la spécification
Source du RFC
La spécification complète.
JSON Schemas
Définitions de payloads lisibles par les machines pour tous les types de l’API.
Démo du shim
Un polyfill fonctionnel pour l’expérimentation.