La capacité à choisir ce qui est fait de nos données personnelles est un droit humain fondamental. C'est la manifestation de notre libre-arbitre contre le déterminisme numérique. Cela permet à des entreprises du monde entier de créer de la valeur proprement sur les données des internautes. Cela permet à l’Open Web de résister à la tentation de la fermeture.
Pourtant, la réglementation a raté le coche. Les utilisateurs sont ensevelis sous des centaines de partenaires, noyés par un jargon juridico-technologique qu’ils n’ont jamais demandé à lire. De plus, les navigateurs sacrifient les préférences renseignées sur l'autel de la privacy, forçant les mêmes bannières à réapparaître après sept jours. Le résultat : habituation, méfiance et fatigue.
Plusieurs développeurs ont répondu en créant des assistants de consentement, donnant aux utilisateurs des systèmes capables de gérer cette complexité à grande échelle. Mais l’hétérogénéité de la gestion du consentement en ligne, combinée à des standards et une réglementation en constante évolution, rend ce travail fragile dur à populariser.
Il existe une voie qui réconcilie utilisateurs et entreprises, les plateformes de gestion du consentement et assistants de consentement. Il s’agit de l’interopérabilité du consentement, opérée par les navigateurs. La spécification navigator.consent l'incarne à travers une nouvelle API.
Le navigateur fait le passe-plat : les CMP conservent le contrôle total de la conformité, et les assistants de consentement accèdent à des métadonnées structurées au lieu de scraper le DOM.
Vous choisissez un assistant de consentement de confiance, et il applique vos préférences partout. Vous restez maître de la granularité : quelles données, quels fournisseurs, quelles finalités, et à quelle fréquence on vous demande.
En savoir plus →Analysez les finalités, les fournisseurs et l’état du consentement de n’importe quelle CMP. Sans scraping et sans que ça casse à chaque mise à jour. Cette spécification devient une rampe de lancement idéale pour toucher des millions d’utilisateurs.
En savoir plus →La CMP devient une couche de conformité de référence, avec des paramètres de consentement lisibles par l’humain comme par la machine, et une intégration prévisible. Plus seulement un bout de code, mais bien un citoyen de première classe.
En savoir plus →Vous ne preniez aucune responsabilité en matière de design de l'invite de consentement. La CMP gère l’interface, le navigateur fournit simplement le canal. Et les assistants de consentement opèrent en transparence pour automatiser le tout.
En savoir plus →Un standard décentralisé qui assure l’interopérabilité sans effet de captivité, moins de bandeaux cookies, plus de consent fatigue.
En savoir plus →
navigator.consent
“This specification, even if it looks somewhat technical, can profoundly change the daily lives of millions of people”
“This specification provides a very important clarification of what the EC's draft in Art. 88b Digital Omnibus means when it states that "browsers (...) shall provide the technical means to allow data subjects to give their consent".
This sentence does not mean that browser providers themselves provide consent management services. That would be like putting the fox in charge of the henhouse, as Apple's ATT impressively demonstrates.
Art. 88b Digital Omnibus rather means that browsers enable the technical interface for seamless communication between consent agents (of other providers than browsers) and the digital services that request consent.
This specification therefore clarifies what this technical interface of browsers must look like so that end users and digital services can finally establish user-friendly consent processes”
“Rewarded Interest believes the historical model of confronting consumers with cookie banners is broken – there doesn't need to be a tradeoff between usability and privacy. Consumers deserve both.”
“We always wanted to make consent very simple. This specification would help us simplify it even more.”
“This browser spec can be a game changer for Taste, and other assistants.”
“Super Agent has been applying user consent preferences at scale for years, through scraping, reverse-engineering, and constant maintenance as CMPs shift under our feet. navigator.consent is the substrate that makes this sustainable: a structured contract between assistants and platforms that eliminates fragility without centralizing control.”
“It's absolutely the right path.”
“A very promising initiative.
A standardized browser consent API could give users a much more effective way to manage their preferences, while dramatically reducing the endless stream of consent pop-ups across the web. A clear step toward a more user-centric and less frustrating privacy experience.”
“This initiative would help Privacy Badger empower users to more easily express their consent preferences.”
L’article 7a de la proposition de directive Omnibus introduit des exigences d’interopérabilité pour les logiciels de gestion du consentement, signe que le législateur reconnaît la nécessité d’une couche de coordination.
Global Privacy Control a démontré que les signaux de vie privée intégrés aux navigateurs fonctionnent à grande échelle. L’infrastructure existe, la demande aussi. Ce qui manque, c’est l’interopérabilité structurée du consentement.
Des chercheurs de l’Université d’Aarhus, de l’Université de la Ruhr à Bochum et d’autres institutions ont documenté la fragilité du scraping actuel des CMP ; autant de travaux qui confirment la nécessité d’un contrat d’API stable.
Une proposition d’API navigateur qui agit comme une couche de coordination neutre entre les plateformes de gestion du consentement (CMP) et les extensions d’assistance au consentement. Elle offre aux deux parties une interface partagée et structurée au lieu de contraindre les extensions à faire de la rétro-ingénierie sur le DOM de chaque CMP.
GPC a prouvé que les signaux de vie privée au niveau du navigateur fonctionnent à grande échelle. Il envoie une préférence binaire de refus à chaque site visité par l’utilisateur. navigator.consent ajoute par-dessus une couche structurée de consentement par fournisseur et par finalité. Les études utilisateur montrent de façon constante que les personnes prennent des décisions contextuelles, pas un refus ou un accord global. Les deux sont complémentaires : GPC comme socle, navigator.consent pour la granularité.
Le TCF fonctionne déjà avec des finalités, des fournisseurs, des bases légales et des réglementations ; c’est encore plus vrai avec le GPP. Ses composants techniques (le stub __tcfapi et la TC String) sont conçus pour l’interopérabilité avec l’écosystème publicitaire, pas avec le navigateur. Décoder une TC String et appeler les méthodes d’enregistrement de navigator.consent est simple. L’API ne remplace pas le TCF : elle lui offre une interface lisible par le navigateur. Elle couvre aussi ce que le TCF ne couvre pas : des commandes impératives pour définir des préférences. Le getTCData du TCF est en lecture seule ; navigator.consent permet la lecture et l’écriture.
La CMP conserve le contrôle total sur le stockage du consentement, la logique de conformité et la signalisation en aval. L’API est une couche de transport en lecture/écriture. Elle coordonne, elle n’impose rien.
Oui. Si la spécification est adoptée, les éditeurs de navigateurs implémenteraient l’API de manière native. Un polyfill JavaScript existe pour la démonstration et le prototypage, mais l’objectif reste une primitive intégrée au navigateur, pas un shim en espace utilisateur.
L’API est pensée au niveau du navigateur : elle fonctionnerait dans tout navigateur mobile qui l’implémente. Deux obstacles subsistent : les assistants de consentement sont aujourd’hui des extensions de navigateur, et les plateformes mobiles les restreignent ou les interdisent. S’ajoutent les webviews, ces navigateurs sandboxés intégrés aux applications, qui devraient eux aussi donner accès au contexte extension pour que les assistants puissent y opérer.
L’effort d’intégration repose sur trois éditeurs de navigateurs (Google, Apple, Microsoft) qui gèrent déjà des API web complexes au quotidien. Pour tous les autres, c’est une simplification. Les utilisateurs continuent de naviguer comme avant, avec la possibilité d’adopter un assistant de consentement pour réduire leur exposition aux bandeaux. Les entreprises gardent leur CMP ; une partie de leurs visiteurs arrivera simplement avec des préférences déjà renseignées. Pour le législateur, le discours est concret : installez un assistant, et les bandeaux cookies disparaissent. Ce modèle rejoint aussi naturellement le concept de portefeuille d’identité numérique européen : un agent personnel qui porte vos préférences vérifiées d’un service à l’autre.
Un assistant de consentement répond toujours plus vite qu’un humain. Il n’intervient pas sur chaque page : uniquement lorsque l’utilisateur aurait été sollicité. Puisque le stockage et la durée du consentement restent de la responsabilité de la CMP, l’assistant ne se manifeste que lorsqu’un humain aurait dû prendre une décision. Le bilan net, c’est moins d’allers-retours d’interface, pas plus.
Les autorités de protection des données sont chargées de s’assurer que les assistants de consentement respectent le RGPD et ePrivacy, exactement comme elles supervisent les CMP aujourd’hui. Pour les risques cyber (usurpation de données, corruption de l’espace utilisateur), les stores d’extensions de navigateur imposent déjà des revues de sécurité, la signature du code et des déclarations de permissions. Ces contrôles sont en vigueur dès maintenant. Une disposition spécifique à l’Article 88b pourrait exiger une vérification plus poussée pour les extensions qui manipulent des données de consentement, au-delà des politiques générales des stores.
C’est un vrai sujet de souveraineté et de concurrence. Cela reste toutefois une concentration de pouvoir moindre que de laisser les navigateurs gérer directement le consentement, ce qui est la trajectoire actuelle de l’Omnibus. Avec une API ouverte, des entreprises européennes indépendantes peuvent rivaliser sur la qualité et la confiance. Imposer un écran de choix pour les assistants de consentement (comme pour les moteurs de recherche sous le DMA) garantirait que les utilisateurs découvrent des alternatives. Nous défendons la libre concurrence et pensons que des assistants indépendants, conçus pour cet usage, sauront offrir un meilleur service qu’une fonctionnalité intégrée par défaut dans le navigateur.
Rien ne change. Le CMP fonctionne exactement comme aujourd’hui : il affiche sa bannière, recueille les choix et stocke le consentement. L’API est purement additive. Elle offre aux CMP un canal structuré pour publier leurs métadonnées et recevoir des préférences, mais si aucun assistant n’écoute, le CMP garde le contrôle intégral. Aucune expérience utilisateur ne se dégrade.
L’API impose un système de provenance : les préférences définies directement par l’utilisateur l’emportent toujours sur celles définies par un assistant. Chaque mutation est enregistrée avec sa source et son horodatage, et les utilisateurs avertis peuvent inspecter l’intégralité de la piste d’audit. Cela dit, la confiance joue dans les deux sens. Déjà aujourd’hui, rien n’empêche un CMP de dire une chose et d’en faire une autre. Et même quand le CMP est honnête, ce qui se passe en aval est une autre histoire : tag managers, plugins CMS et code client peuvent tous déclencher des trackers indépendamment de ce que la couche de consentement a décidé. L’API ne résout pas ce problème, mais elle rend la couche de consentement elle-même transparente et auditable, ce qui est déjà mieux que le statu quo.
Pas encore. C’est une proposition ouverte de type RFC. La spécification est disponible publiquement et nous accueillons les retours des implémenteurs, chercheurs et décideurs politiques.
La démo interactive exécute le polyfill dans votre navigateur et vous guide à travers le flux d’enregistrement de la CMP, de lecture des métadonnées et de mise à jour du consentement.