API navigateur
navigator.consent est une API fine et neutre — comme navigator.geolocation. Les CMP déclarent leurs fournisseurs et finalités en données structurées. Plus de pistage opaque : chaque acteur révèle ce qu’il traite et pourquoi.
Interopérabilité sans centralisation
La fatigue du consentement est réelle, et la réglementation a contribué à la créer. Le Digital Omnibus veut y remédier — mais le remède proposé risque de concentrer le pouvoir entre une poignée d’éditeurs de navigateurs qui préféreraient ne pas l’avoir. Une troisième voie est possible : une couche d’interopérabilité ouverte où chaque acteur dévoile ses cartes et les utilisateurs choisissent qui agit en leur nom.
Fatigue du consentement
334 M d’heures/an. L’ITP efface les cookies de consentement, les webviews repartent de zéro et les bannières réapparaissent constamment. Les entreprises dépendant du consentement par cookie poussent vers des designs manipulatoires (dark patterns, habituation, culpabilisation).
Vie privée des utilisateurs
Dépend entièrement de la CMP. Les bonnes offrent un vrai choix ; les mauvaises utilisent des dark patterns pour orienter les utilisateurs vers « Tout accepter ». Les extensions ou techniques orientées vie privée, comme ATT ou ITP, poussent les fournisseurs vers le pistage côté serveur et non déclaré.
Durabilité du web ouvert
Les éditeurs peuvent fonctionner avec un consentement éclairé. Le modèle fonctionne, même s’il est inégal.
Spécificité du consentement
Les bonnes CMP offrent des choix par fournisseur et par finalité. Les mauvaises présentent un mur de texte et un gros bouton. L’ampleur du pistage est parfois si grande qu’elle devient accablante.
Auditabilité
Les régulateurs doivent inspecter les registres propriétaires de chaque CMP individuellement.
Distribution du pouvoir
Équilibre fragile entre les autorités de protection des données, les CMP, les associations professionnelles (IAB TCF) et les défenseurs de la vie privée
Qualité inégale. Les bonnes CMP offrent un choix granulaire, les mauvaises utilisent des dark patterns. Les utilisateurs n’ont pas leur mot à dire sur la CMP utilisée par un site. Le stockage du consentement est fragile.
Une alternative concurrentielle : trois couches
Cette architecture s’appuie sur les fondations posées par GPC et ajoute la granularité qu’exige le RGPD : une coordination du consentement structurée, lisible par les machines et auditable, répartie sur trois couches.
L'effort d'intégration repose sur trois éditeurs de navigateurs qui gèrent déjà des API web complexes au quotidien. Pour les utilisateurs, rien ne change : ils peuvent simplement adopter un assistant de consentement pour réduire leur exposition aux bandeaux. Pour les entreprises, la CMP continue d'orchestrer le consentement ; certains visiteurs arriveront 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 portefeuille d'identité numérique européen : un agent personnel qui porte vos préférences vérifiées d'un service à l'autre.
Extensions d’assistance au consentement
Les utilisateurs choisissent un assistant de consentement à partir d’un écran de sélection (comme le choix de moteur de recherche du DMA). Des extensions comme Consent-o-matic, SuperAgent et Taste utilisent l’API pour appliquer les préférences de manière granulaire. Cela crée un marché européen concurrentiel pour l’innovation en matière de vie privée.
Les CMP comme couche de conformité
Les CMP restent responsables de l’information contextuelle, des pistes d’audit, des instructions par fournisseur et de la conformité réglementaire. L’assistant communique avec la CMP, pas en la contournant. Un signal navigateur seul ne peut pas remplir ces fonctions.
Les quatre modèles placent le consentement au niveau du navigateur. La différence est qui contrôle l’expérience.
Les navigateurs sont déjà des services de plateforme essentiels
Le Digital Markets Act qualifie les navigateurs web de services de plateforme essentiels (considérant 14). En septembre 2023, la Commission européenne a désigné Google Chrome et Safari comme services de plateforme essentiels fournis par des contrôleurs d'accès. L'Union reconnaît donc déjà que ces navigateurs constituent des points d'accès majeurs par lesquels les entreprises utilisatrices atteignent les utilisateurs finaux ; c'est précisément ce constat qui justifie leur régulation au nom de la contestabilité et de l'équité.
La couche de consentement se superpose directement à ces services de plateforme essentiels désignés. Si un éditeur de navigateur centralisait ou imposait un modèle unique de consentement, il exercerait un contrôle direct sur une condition d'accès au marché numérique. Le consentement n'est pas une fonctionnalité périphérique : c'est le seuil par lequel toute relation de traitement de données commence.
Les plateformes de gestion du consentement sont le prolongement technique des exigences issues de la directive ePrivacy et du RGPD. De la même manière,
navigator.consent peut être compris comme le prolongement technique des principes d'interopérabilité et de contestabilité consacrés par le DMA.Ce cadrage compte pour l'Article 88b. Plutôt que de créer un nouveau régime de consentement concentrant le pouvoir entre les mains des contrôleurs d'accès désignés, le Digital Omnibus devrait s'appuyer sur ce que le DMA établit déjà : les navigateurs sont une infrastructure critique nécessitant des interfaces ouvertes, pluralistes et non captables. navigator.consent organise précisément cela : une couche de coordination neutre qui garantit que l'expérience de consentement reste contestable jusque dans le navigateur.
Un risque structurel dont personne ne veut
L’Article 88b(6) demande aux éditeurs de navigateurs d’intégrer la gestion du consentement dans leurs produits. L’intention est louable, mais l’architecture crée des risques de concentration difficiles à défaire — et que les éditeurs de navigateurs eux-mêmes préféreraient éviter.
Le design du consentement façonne les résultats
Celui qui conçoit l’interface de consentement influence le résultat. Si quatre éditeurs de navigateurs conçoivent l’expérience pour tous les utilisateurs européens, une poignée de choix de design déterminera les taux de consentement sur l’ensemble de l’internet européen.
Les signaux globaux ne satisfont pas la spécificité du RGPD
Un toggle « accepter/refuser le pistage » au niveau du navigateur ne peut pas satisfaire l’Article 4(11), qui exige que le consentement soit spécifique et éclairé — lié à des finalités et des responsables de traitement particuliers. Un utilisateur qui fait confiance à l’analytique de sa banque n’a aucune raison d’appliquer la même préférence à un réseau publicitaire inconnu.
Le web ouvert perd de façon disproportionnée
Les plateformes avec des utilisateurs connectés conservent leurs données first-party quel que soit le signal. Les éditeurs indépendants, le SaaS européen, le e-commerce et les fournisseurs d’analytique qui dépendent d’un consentement éclairé et spécifique en font les frais.
Les éditeurs de navigateurs héritent d’une responsabilité non souhaitée
Construire une interface de consentement implique des choix de design qui engagent la conformité. Les éditeurs de navigateurs préféreraient fournir une plomberie neutre, plutôt que devenir des gatekeepers du consentement avec une exposition réglementaire.
Les webviews restent un angle mort
Le propre mécanisme du Digital Omnibus — les signaux au niveau du navigateur — échoue dans les navigateurs in-app, où les extensions ne s’exécutent pas. Le correctif proposé laisse intacte la plus grande source de fatigue du consentement.
Du signal binaire au consentement granulaire
Global Privacy Control a prouvé que les signaux de vie privée au niveau du navigateur peuvent fonctionner à grande échelle : plus de 150 millions d’utilisateurs, un ancrage juridique en Californie et une spécification W3C. AB 566 (signée en octobre 2025) exige que tous les principaux navigateurs intègrent GPC nativement d’ici le 1er janvier 2027. C’est une avancée majeure.
GPC est un signal binaire de refus : « ne vendez pas et ne partagez pas mes données. » Ce modèle s’articule bien avec le cadre de refus du CCPA. Le RGPD, en revanche, exige que le consentement soit « libre, spécifique, éclairé et univoque » (Article 4(11)), ce qui appelle une granularité par finalité et par fournisseur qu’un seul bit ne peut pas exprimer.
Si le standard européen de signal reproduit un modèle binaire, le résultat est un toggle unique appliqué uniformément à chaque site et chaque fournisseur. Les éditeurs, le e-commerce et les entreprises SaaS n’auraient aucun moyen de distinguer entre un utilisateur qui s’oppose au retargeting et un qui accepte l’analytique fonctionnelle.
L’opportunité est de construire sur les fondations posées par GPC. GPC établit le socle de refus ; navigator.consent ajoute par-dessus un canal de consentement structuré et spécifique par finalité. Le processus de normalisation européen au titre de l’Article 88b(4) peut s’appuyer sur les deux : un signal de base simple et une couche de coordination granulaire pour le consentement éclairé.
Pour les régulateurs Auditabilité intégrée
Sans couche d’interopérabilité structurée, la réponse rationnelle de l’industrie à la pression du consentement est de devenir opaque : pistage côté serveur, fingerprinting, identifiants déterministes, contenu protégé. navigator.consent inverse cette incitation — si vous déclarez fournisseurs et finalités via un canal structuré, l’application devient possible.
| 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 | — |
Piste d’audit horodatée
Chaque mutation de consentement est enregistrée avec provenance et horodatage. Les régulateurs peuvent voir exactement ce qui a été défini, par qui et quand — sans dépendre uniquement de l’auto-déclaration de la CMP.
Attribution de provenance
L’API enregistre si une préférence a été définie par l’utilisateur, un assistant de consentement ou la CMP. Les choix de l’utilisateur priment toujours. Aucun acteur ne peut silencieusement se substituer à un autre.
Le pistage devient invisible sans cela
Le pistage côté serveur, le fingerprinting et les identifiants déterministes sont invisibles pour les outils d’application actuels. Une API structurée ramène les déclarations de traitement des données dans l’espace ouvert où les régulateurs peuvent les vérifier.
Garde-fous en matière de cybersécurité
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 déjà les CMP. Ce n’est pas un nouveau mécanisme de régulation, c’est l’extension de pouvoirs de contrôle existants à une nouvelle catégorie d’acteur.
Pour les risques cyber tels que l’usurpation de données ou la 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 avant qu’une extension n’atteigne les utilisateurs. Ces contrôles sont en vigueur aujourd’hui et s’appliquent aux assistants de consentement de plein droit.
Une disposition spécifique à l’Article 88b pourrait aller plus loin : exiger une vérification renforcée pour les extensions qui manipulent des données de consentement, au-delà des politiques générales des stores. Cela donnerait aux autorités de contrôle un levier supplémentaire sans créer un cadre de supervision entièrement nouveau.
Normalisation des signaux : interopérabilité, pas uniformité
L’Article 88b(4) charge les organisations européennes de normalisation d’élaborer des standards pour les signaux de consentement lisibles par les machines. C’est la bonne direction — mais le standard doit préserver la spécificité qui donne au consentement son sens au regard du RGPD.
Un signal de consentement doit supporter des décisions granulaires, spécifiques par finalité et par fournisseur. Le modèle binaire de GPC a été conçu pour le refus (opt-out) du CCPA, pas pour le consentement RGPD. Le standard européen devrait aller plus loin, en supportant des signaux contextuels qui distinguent finalités et fournisseurs.
Les fournisseurs de CMP doivent participer au processus de normalisation. Ils combinent une expertise juridique approfondie avec une connaissance technique pratique de la collecte et de la signalisation du consentement. Il convient aussi de ne pas prendre l’IAB Transparency and Consent Framework comme modèle unique — il couvre la publicité des éditeurs mais est inadapté au e-commerce, au SaaS, aux landing pages et à la plupart des autres services en ligne.
La fatigue du consentement a des causes techniques que la réglementation n’aborde pas
La Commission européenne estime que les citoyens de l’UE passent 334 millions d’heures sur les bannières de cookies par an. Mais les causes profondes sont techniques, pas inhérentes au consentement lui-même — et le Digital Omnibus les laisse intactes.
Protection contre le pistage des navigateurs
L’ITP de Safari limite les cookies côté client à 7 jours. L’ETP de Firefox applique des restrictions similaires. Puisque la plupart des CMP stockent le consentement avec document.cookie, vos choix sont silencieusement effacés — et la bannière revient comme si vous n’aviez jamais choisi.
Navigateurs in-app
Une part croissante de la navigation mobile se fait au sein d’applications (Instagram, LinkedIn, applications d’actualités). Ces webviews isolés ne peuvent pas accéder au consentement stocké dans le navigateur principal. Chaque visite ressemble à un nouvel utilisateur — et le Digital Omnibus est muet sur ce sujet.
Dark patterns
Une étude de 2025 a montré que 38 % des bannières conformes au RGPD utilisent encore la manipulation esthétique — boutons « Accepter » mis en valeur, options de refus enfouies. La solution passe par une meilleure qualité des CMP et une meilleure application, pas par l’élimination des CMP.
L’exemption des médias fragilise le cadre
Le Recital 46 exempte les fournisseurs de services de médias du respect des signaux de consentement lisibles par les machines. Mais les sites de médias sont là où la fatigue du consentement est la plus aiguë — les sites d’actualités chargent des dizaines de fournisseurs publicitaires, présentent les interfaces de consentement les plus complexes et déploient des cookie walls suivis de paywalls. Les exempter revient, pour le Digital Omnibus, à réduire la friction là où elle est déjà faible et à la maintenir là où elle est la plus forte.
Ce que nous demandons au Parlement
Ouvrir le consentement navigateur aux extensions tierces
Amender l’Article 88b(6) pour exiger que les mécanismes de consentement au niveau du navigateur soient ouverts aux extensions tierces indépendantes d’assistance au consentement, et non limités aux fonctionnalités intégrées des éditeurs de navigateurs. Chrome et Safari sont déjà désignés comme services de plateforme essentiels au titre du DMA. Ouvrir le consentement à des extensions concurrentes s’inscrit dans la continuité des obligations de contestabilité auxquelles ces contrôleurs d’accès sont déjà soumis. Envisager d’imposer un écran de choix pour les assistants de consentement, comme cela a été fait pour les moteurs de recherche.
Assurer la participation des CMP à la normalisation des signaux
Inclure les représentants de l’industrie des CMP dans le processus de normalisation au titre de l’Article 88b(4). Préciser que le standard doit supporter un consentement granulaire, spécifique par finalité et par fournisseur — pas des signaux globaux.
Exiger des signaux granulaires, pas un refus global
Construire sur le succès de GPC : adopter son socle de refus, et l’étendre avec des signaux de consentement spécifiques par finalité et par fournisseur qui satisfont l’exigence de spécificité du RGPD. Le standard doit supporter des décisions contextuelles qui varient selon le site, le fournisseur et la finalité.
Restreindre l’exemption des médias
Empêcher le Recital 46 de devenir une faille qui exempte le secteur le plus gourmand en consentement du mécanisme central du cadre. Toute exemption doit être strictement définie.
Traiter les causes techniques profondes de la fatigue du consentement
Enquêter sur la protection contre le pistage des navigateurs (ITP, ETP) et l’isolation des webviews comme facteurs structurels des invites répétées. Ces facteurs techniques — et non l’existence des CMP — sont la cause principale des 334 millions d’heures citées par la Commission.
Références
Ces références concernent la proposition de Digital Omnibus (COM(2025)0837) et ne doivent pas être considérées comme du droit en vigueur.
- EU Digital Omnibus regulation proposal
- Official proposal text (CELEX 52025PC0837)
- European Parliament legislative tracking
- California Opt Me Out Act (AB 566), CPPA announcement
- Global Privacy Control, W3C Working Draft
- CMA investigation into Google Privacy Sandbox
- Autorité de la concurrence — Apple ATT fine
- Digital Markets Act (Regulation (EU) 2022/1925)
- European Commission — DMA designated gatekeepers