[ plan utilisateur ]
Utilisateur
Détient les préférences.
Une couche d’interopérabilité ouverte pour les signaux de consentement dans l’écosystème numérique européen
Aujourd’hui, chaque bandeau est renégocié à zéro à chaque visite. Chaque extension de privacy gratte son propre DOM. Chaque navigateur livre son propre signal. navigator.consent, c’est le canal partagé qui permet enfin aux navigateurs, aux CMP et aux assistants qui agissent pour les utilisateurs de se parler. Sans concentrer le contrôle entre les mains d’un seul acteur.
// navigator.consent
Comment ça marche
navigator.consent, c’est le câble entre les navigateurs, les assistants qui agissent pour les utilisateurs et les CMP qui tiennent les registres. Le navigateur achemine les messages. La CMP conserve les preuves.
Pourquoi c’est essentiel
L’interopérabilité, pierre angulaire du débat
La fatigue du consentement peut être résolue sans sacrifier la vie privée des utilisateurs ni centraliser le contrôle dans les navigateurs. navigator.consent propose un standard qui améliore l’expérience pour les utilisateurs, les CMPs et les sites web.
Le consentement est contextuel. Un seul signal ne le porte pas.
Les utilisateurs font des choix différents selon l’interlocuteur, la finalité et le contexte. Une préférence définie au niveau du navigateur, avant toute interaction avec un responsable de traitement précis, ne peut satisfaire par construction l’exigence du RGPD d’un consentement spécifique et éclairé. L’architecture doit préserver le choix contextuel tout en autorisant des préférences globales par défaut.
Pas de piste d’audit, pas de conformité.
Un signal de consentement sans piste documentaire n’est pas une preuve de conformité. Les responsables de traitement ont besoin d’un registre vérifiable : à quoi a-t-on consenti, par qui, quand et pour quelles finalités. Cette fonction d’audit ne peut pas vivre dans le navigateur. Elle suppose une couche indépendante qui enregistre, applique et rend compte de chaque décision de consentement.
Les navigateurs ne doivent pas devenir les nouveaux gatekeepers.
Le marché des navigateurs est tenu par une poignée d’entreprises non européennes : Google, Apple, Microsoft. Toute architecture de consentement qui ferait transiter les signaux exclusivement par les éditeurs de navigateurs risquerait de concentrer le contrôle de l’infrastructure européenne du consentement entre les mains précises des acteurs que le DMA cherche à encadrer. Le standard doit rester ouvert et neutre sur le plan technologique.
Les invites au niveau système plombent les taux de consentement.
Quand Apple a déployé App Tracking Transparency en 2021, près de 80 % des utilisateurs ont refusé au niveau système. Ce n’est pas un problème de design d’interface. C’est ce qui se produit dès que le consentement est arraché à un service spécifique et reconnu pour être déplacé dans une invite système générique. Tout mécanisme placé au niveau du navigateur risque de reproduire cette dynamique, avec des conséquences directes pour les éditeurs et annonceurs européens.
// navigator.consent.governance
Sous la gouvernance de l’European CMP Association
navigator.consent est porté par l’European CMP Association (ECMPA). L’association rassemble les fournisseurs de CMP qui orchestrent aujourd’hui le consentement sur l’essentiel du web européen : Axeptio, Didomi, iubenda, Usercentrics et d’autres. Nous avons écrit la spec parce que ce sont nos produits qui devront l’implémenter.
La spécification est élaborée par l’ECMPA dans le cadre de son mandat de représentation des fournisseurs de CMP au sein des politiques publiques et des travaux de normalisation européens.
Les éditeurs de navigateurs, les assistants de consentement, les éditeurs de contenus, les autres organisations professionnelles et la société civile sont tous invités à participer à la spécification et au processus de gouvernance.
La spécification est un RFC ouvert, publié pour révision et commentaires. Les réponses de toute partie de l’écosystème sont les bienvenues.
SoutiensIls soutiennent
Ils soutiennent navigator.consent
Les personnes citées ci-dessous expédient des bandeaux cookies, conçoivent les extensions qui les balaient, ou les deux. Ce sont elles qui auraient à écrire les parties de cette spec dont on parle ici.
Plateformes de consentement
Assistants de consentement
Entreprises
“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.”
“navigator.consent does not eliminate consent. It eliminates the need to ask for it from scratch every time.”
“With evolving global regulations and users suffering consent fatigue, many site-specific banner controls are reaching their limits. Navigator Consent forms part of a new layer of coordinated solutions which handle how consent is controlled, audited and demonstrated across the web”
“As someone involved at the birth of the cookie banner, I soon realised its rise to ubiquity was due to it not breaking the system that created the need for consent control. Without reform, it’s now at risk of becoming part of the consent fatigue problem. I am delighted Navigator Consent has arrived to form part of an integrated, structured and responsible consent ecosystem that encourages collaboration between CMP’s, privacy assistants and other stakeholders and puts end users back in the driving seat.”
“Consent shouldn't be a wall between users and websites, it should be a bridge. Navigator.consent gives us the interoperability layer to make that bridge solid, and at Gimii, we're building on it to turn every consent into a positive impact.”
Questions fréquentes
Qu’est-ce que navigator.consent ?
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.
En quoi est-ce différent de Global Privacy Control ?
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é.
Quelle est la place du Transparency and Consent Framework de l’IAB dans ce modèle ?
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.
Qui contrôle mes données de consentement ?
La CMP conserve le contrôle total sur le stockage du consentement, la logique de conformité et la signalisation en aval. L’API ne fait que déplacer des octets entre les parties. Elle ne peut se substituer à personne. Les éditeurs de navigateurs n’ont aucune visibilité ni aucun contrôle sur les décisions de consentement.
Est-ce que ça fonctionne sur mobile ?
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.
Ça ne rajoute pas de la complexité alors que l’objectif est de simplifier ?
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.
Quel est l’impact sur les performances ?
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.
Que se passe-t-il si aucun assistant de consentement n’est installé ?
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.
Un assistant de consentement peut-il modifier mes choix à mon insu ?
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.
Est-ce un standard W3C ?
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.