Quatre modèles de consentement en Europe
Les quatre modèles placent le consentement au niveau du navigateur. Ils diffèrent par qui contrôle l’expérience et le degré de granularité offert à l’utilisateur : la CMP du site (aujourd’hui), un en-tête HTTP standardisé (GPC), les éditeurs de navigateurs (Omnibus), ou l’assistant choisi par l’utilisateur (architecture ouverte).
Matrice de comparaison
| Aujourd’hui | GPC (jan. 2027) | Digital Omnibus | Architecture ouverte | |
|---|---|---|---|---|
| Qui conçoit l’expérience de consentement ? Qui contrôle l’interface que l’utilisateur voit | La CMP de chaque site, configurée par le propriétaire du site. Énorme variation de qualité, de l’excellent au manipulatoire. | Entièrement automatique : un en-tête HTTP binaire envoyé par le navigateur avant le chargement de la page. Simple et sans friction, même si les utilisateurs ne prennent pas de décision par site. | Quatre éditeurs de navigateurs : Google, Apple, Microsoft, Mozilla. Ils conçoivent l’interface pour tous les utilisateurs européens. | L’assistant de consentement choisi par l’utilisateur (par ex. Consent-o-matic, Taste, SuperAgent), communiquant avec la CMP du site via une API navigateur neutre. |
| Quelle est la spécificité du consentement ? RGPD Art. 4(11) : le consentement doit être spécifique et éclairé | Dépend de la CMP. Les bonnes implémentations offrent des choix par fournisseur et par finalité. Les mauvaises présentent un mur de texte et un unique bouton « accepter ». | Binaire : un unique signal « ne vendez pas et ne partagez pas » appliqué uniformément. Conçu pour le refus (opt-out) du CCPA ; il n’exprime pas de préférences par finalité ou par fournisseur. | Un signal global (accepter/refuser) appliqué à tous les sites de manière égale. Incapable de distinguer entre l’analytique d’un commerce de confiance et un réseau publicitaire inconnu. | Granulaire, contextuel. L’assistant analyse les fournisseurs et finalités de chaque site, et applique des préférences qui peuvent varier d’un site à l’autre. |
| Y a-t-il de la concurrence ? L’utilisateur peut-il choisir une solution différente ? | Les utilisateurs n’ont pas le choix : ils interagissent avec la CMP que le site utilise. Certaines extensions de navigateur existent mais reposent sur la rétro-ingénierie, et tombent en panne à chaque mise à jour. | Le signal est standardisé par le W3C et intégré au navigateur. Les utilisateurs peuvent l’activer ou le désactiver. Le signal lui-même est uniforme ; il n’existe pas de mécanisme pour des implémentations alternatives ou une granularité supplémentaire. | Non. Chaque éditeur de navigateur implémente sa propre approche. Les utilisateurs sont verrouillés dans le navigateur qu’ils utilisent. Pas d’écran de choix. | Oui. Un écran de choix (sur le modèle de la sélection de moteur de recherche du DMA) permet aux utilisateurs de choisir parmi des assistants de consentement en concurrence. Les incitations du marché stimulent la qualité. |
| Conflit d’intérêts ? L’opérateur du consentement bénéficie-t-il du résultat ? | Les CMP sont payées par les sites, ce qui peut inciter à des designs orientant vers le consentement. L’application réglementaire (CNIL, etc.) agit comme contrepoids. | Indirect. Les éditeurs de navigateurs décident de l’état par défaut (activé/désactivé). Ce choix par défaut a des implications significatives pour le marché, car les plateformes disposant de relations first-party sont moins affectées que celles qui dépendent d’un accès fondé sur le consentement. | Significatif. Les éditeurs de navigateurs exploitent leurs propres plateformes publicitaires et de données. Ils conservent les données first-party quel que soit le signal, tandis que les concurrents dépendent du consentement. | Réduit. Les assistants indépendants se font concurrence pour servir les intérêts des utilisateurs. Si l’un favorise les annonceurs, les utilisateurs changent. La discipline du marché remplace les conflits structurels. |
| Que se passe-t-il sur mobile / dans les navigateurs in-app ? Webviews dans Instagram, LinkedIn, applications d’actualités, etc. | Le consentement est perdu à chaque visite. Les webviews sont isolés et ne peuvent pas accéder au consentement stocké. C’est une cause majeure de la fatigue du consentement aujourd’hui. | Fonctionne dans les webviews : l’en-tête HTTP est envoyé quel que soit le contexte. Le signal reste binaire, il ne peut donc pas refléter les préférences par site ou par finalité de l’utilisateur. | Non traité. Le Digital Omnibus est muet sur les webviews. Les extensions de navigateur ne s’exécutent pas dans les navigateurs in-app. La plus grande source de fatigue du consentement reste intacte. | Partiellement traité. L’API neutre (navigator.consent) est au niveau du navigateur, pas dépendante des extensions, ce qui la rend compatible avec les futures solutions mobiles. Mais le fossé des webviews nécessite une législation séparée. |
| Quel rôle jouent les CMP ? Information contextuelle, piste d’audit, gestion des fournisseurs, conformité | Central. Les CMP collectent le consentement, fournissent l’information, gèrent les permissions fournisseurs et maintiennent des registres auditables. | Limité. Le signal est envoyé avant le chargement de la CMP. Les CMP peuvent lire l’en-tête et le respecter, mais il n’existe pas de canal structuré permettant à la CMP de fournir des informations contextuelles ou de proposer un choix granulaire en retour. | Diminué. Les CMP reçoivent le signal du navigateur et maintiennent les registres, mais perdent la capacité de fournir des informations contextuelles et un choix granulaire au moment de la décision. | Préservé et renforcé. Les CMP continuent de fournir des informations contextuelles, des contrôles granulaires et des pistes d’audit. L’assistant communique avec la CMP, pas en la contournant. |
| Impact sur la fatigue du consentement ? L’objectif déclaré du Digital Omnibus | Fatigue significative. Causée principalement par les navigateurs qui effacent les cookies de consentement (ITP, ETP), les navigateurs in-app et la mauvaise qualité des CMP. Pas par l’existence des CMP elles-mêmes. | Élimine efficacement la fatigue des bannières : le signal est automatique et ne requiert aucune action de l’utilisateur. La contrepartie est que les utilisateurs souhaitant un contrôle par site ou par finalité n’ont aucun mécanisme pour l’exprimer. | Amélioration limitée. Les bannières disparaissent sur les sites non-médias, mais les causes profondes (effacement du consentement, webviews) ne sont pas traitées. Les sites de médias — où la fatigue est la pire — sont exemptés. | Amélioration significative. Les assistants de consentement gèrent les décisions silencieusement pour la plupart des sites. Les bannières CMP disparaissent sauf si l’utilisateur souhaite décider manuellement. Les causes profondes doivent encore être traitées séparément. |
| Bilan | Fonctionne, mais qualité inégale et vrais problèmes de fatigue. Le système a besoin d’amélioration, pas de remplacement. | Éprouvé à grande échelle et très efficace pour réduire la friction du consentement. Le modèle binaire convient bien au CCPA ; pour le RGPD, une couche de granularité par-dessus comblerait l’écart entre la simplicité du refus et la spécificité qu’exige la réglementation. | Échange un problème (la fatigue) contre un autre (la concentration du pouvoir), tout en laissant les principales causes de fatigue non résolues. | Réduit la fatigue grâce à l’automatisation choisie par l’utilisateur, préserve un consentement significatif et crée un marché européen concurrentiel pour les outils de confidentialité. |