Un consentement qui n’arrive pas jusqu’à l’acheteur se monétise comme un refus
Le taux de consentement est devenu un indicateur suivi comme une ligne de revenu. Il répond à une question précise, combien d’utilisateurs ont accepté, et il n’en traite pas une seconde, qui décide pourtant du chiffre : combien de ces accords sont arrivés intacts jusqu’à l’acheteur.
Entre la fenêtre de consentement et l’enchère, le choix de l’utilisateur cesse d’être un bouton pour devenir une chaîne de caractères transportée dans des paramètres que des spécifications nomment. Quand cette chaîne manque, arrive dans une version périmée ou laisse un canal de côté, le secteur applique une règle par défaut, et elle n’est pas favorable à l’éditeur.
Voici ce transport, ce que chaque rupture coûte, ce qui a changé le 1er mars 2026, et pourquoi, dans une application, le délai de correction ne dépend pas que de l’éditeur. Les citations de spécifications techniques en anglais sont traduites.
Ce que vaut un consentement, mesuré plutôt que supposé
Commençons par le chiffre que le secteur cite sans l’avoir lu. La référence la plus souvent invoquée sur la valeur du suivi pour un éditeur est une étude de Veronica Marotta, Vibhanshu Abhishek et Alessandro Acquisti, présentée à la conférence WEIS en 2019. Elle exploite les transactions publicitaires d’une semaine de mai 2016 sur les sites d’un seul grand groupe de presse, dont plus de 70 % conclues depuis des adresses américaines.
Son résultat est sobre : « lorsque le cookie d’un utilisateur est disponible, le revenu de l’éditeur augmente d’environ 4 % seulement », soit « une augmentation moyenne de 0,00008 dollar par publicité ». Les auteurs se gardent pourtant d’en conclure que le suivi ne vaut rien, et font le calcul à l’échelle : pour un site qui vend quatre millions de publicités par jour, y renoncer coûterait « environ 320 dollars de revenu par jour, soit presque 10 000 dollars par mois ».
Trois précautions vont avec, dont deux que les auteurs posent eux-mêmes. Le résultat « peut s’interpréter comme la valeur générée pour les éditeurs par la présence d’un cookie, mais pas comme la valeur générée par la publicité comportementale », et il « peut ne pas se généraliser à l’univers entier des sites existants ». La troisième est de forme : le document se présente comme un brouillon préliminaire de mai 2019, et il porte sur de l’affichage web, où le téléphone pèse déjà 31 % des transactions mais jamais par une application.
Ce chiffre n’établit donc pas que le consentement ne vaut rien. Il établit que sa valeur se compte en fractions de centime multipliées par un volume, ce qui la rend fragile aux deux bouts : un point de taux gagné se dilue, un signal perdu efface la ligne entière. Le transport, lui, ne se joue pas en pourcentage. Il se joue en tout ou rien.
La règle par défaut : pas de signal, pas de consentement
Cette règle n’est pas une interprétation, elle est écrite dans la spécification technique que suivent les plateformes de gestion du consentement et leurs partenaires. La spécification de l’API CMP du cadre de transparence et de consentement de l’IAB Europe la formule ainsi : « Si une CMP n’est pas présente, ou si la CMP ne répond pas, les fournisseurs doivent supposer l’absence de consentement et l’absence de transparence établie pour l’intérêt légitime, dans les contextes où le RGPD s’applique. »
Une honnêteté s’impose sur cette phrase : elle figure dans le passage qui explique comment un script détecte la présence d’une CMP sur une page, et la partie applicative de la même spécification n’en contient pas d’équivalent. Elle dit l’esprit du cadre, pas une règle écrite pour les applications. Ce qui vaut pour les applications, en revanche, est écrit ailleurs et de façon bien plus tranchée.
Côté acheteur, la documentation de Google Ad Manager paraît d’abord catégorique : « Ad Manager n’effectuera aucune demande d’annonce tant qu’aucune chaîne TC valide n’aura été reçue. » La phrase vise l’éditeur qui transmet lui-même la chaîne à ses tags, et il faut lire la page voisine pour connaître le sort réel de l’inventaire.
Ce sort n’est pas le silence, c’est le déclassement. Google écrit qu’il « essaiera également de diffuser une annonce limitée éligible [...] pour les demandes provenant de l’EEE, du Royaume-Uni ou de la Suisse qui n’incluent pas de chaîne TC provenant d’une CMP certifiée par Google ». L’impression se vend donc, mais au tarif d’une impression sans consentement, sur du trafic où l’utilisateur a peut-être dit oui.
Un silence technique ne se lit donc pas comme une question restée ouverte. Il se lit comme un non, et il se paie au prix d’un non.
CE QUE PORTE UNE REQUÊTE COMPLÈTE gdpr=1 le cadre européen s’applique 0 : il ne s’applique pas. absent : inconnu gdpr_consent=<chaîne TC> le choix, segment des fournisseurs affichés compris addtl_consent=2~1.10~dv.2.3.4 les partenaires Google hors liste globale IAB CE QUE CHAQUE ABSENCE PRODUIT gdpr_consent vide la requête est traitée comme non consentie, repli en annonces limitées chaîne sans le segment des fournisseurs affichés même repli, alors que l’utilisateur a répondu addtl_consent absent ces partenaires n’ont reçu aucun signal
Le 1er mars 2026 a changé ce que vaut une chaîne périmée
La version 2.3 du cadre a été publiée le 19 juin 2025. Elle règle une ambiguïté ancienne : sous la version précédente, un fournisseur qui déclarait à la fois des finalités et des finalités spéciales au titre de l’intérêt légitime ne pouvait pas distinguer, dans la chaîne, le cas où l’utilisateur s’était opposé de celui où il n’avait tout simplement pas été présenté dans l’interface. La version 2.3 rend obligatoire un segment qui énumère les fournisseurs affichés.
L’IAB Europe a fixé la fin de la période de transition au 28 février 2026, et sa formulation est nette : « Les chaînes TC créées après le 28 février 2026 sans ce segment seront considérées comme invalides. » Celles créées avant restent valides, mais seulement jusqu’à ce qu’elles soient remplacées, quand l’utilisateur renouvelle ou modifie ses choix.
Google annonce la même échéance côté achat, avec la conséquence commerciale qui va avec : « La version 2.3 du TCF est obligatoire pour toutes les chaînes TC générées à partir du 1er mars 2026. Si vous ne respectez pas cette exigence, la demande d’annonce associée peut être définie par défaut sur Annonces limitées, ce qui peut avoir un impact sur vos revenus. »
Une correction de conformité devient ici, directement, une variable de revenu. C’est assez rare pour être souligné : les deux sujets ne se rejoignent pas souvent d’aussi près.
Corriger une CMP dans une application : ce qui se change à distance, et ce qui ne s’y change pas
Sur un site, la correction d’une fenêtre de consentement est en place au chargement suivant. Dans une application, la réponse est plus nuancée que le raccourci habituel, et elle mérite d’être vérifiée avant de s’alarmer comme avant de se rassurer.
Ce qui se pilote à distance, c’est le message : chez Google, la fenêtre se compose et se publie depuis la console, bouton de refus au premier niveau compris. Ce qui est compilé dans le binaire, c’est la bibliothèque qui écrit la chaîne. Sur le passage à la version 2.3, Google affirme d’ailleurs que la question ne se pose pas pour sa propre solution : « Le SDK UMP de Google est certifié par l’IAB pour la version 2.3 du TCF sur toutes les versions du SDK », et « aucune action n’est requise si vous utilisez la CMP Google pour vos propriétés Web ou d’application ».
Pour une CMP tierce, le ton change : « nous vous invitons à contacter immédiatement votre plate-forme de gestion du consentement (CMP) pour confirmer son plan et son calendrier de migration de vos propriétés vers sa solution conforme à la version 2.3 du TCF ». C’est là que le mobile se sépare du web. Si cette migration passe par une nouvelle version de la bibliothèque, elle passe par une publication, puis par une installation, et ce délai-là n’appartient pas à l’éditeur.
Une version installée, elle, ne se rappelle pas. Dans le dossier espagnol de 2026, l’éditeur écrivait ne pas pouvoir corriger une version déjà publiée, seulement en publier une nouvelle, tout en indiquant dans le même document disposer d’une fonction capable de forcer la mise à jour depuis une version obsolète. Les deux affirmations cohabitent, et elles posent la bonne question à se poser chez soi : la mise à jour est-elle forcée, ou seulement espérée ?
Un dernier point élargit la portée du problème. Google précise que « la chaîne TC de l’IAB est disponible dans le stockage local des appareils (NSUserDefaults pour iOS ou SharedPreferences pour Android). Les partenaires de médiation peuvent ainsi l’obtenir, l’analyser et l’appliquer lors des appels liés à une demande dans la cascade de la médiation. » Une chaîne périmée n’est donc pas un incident local : c’est la valeur que relit toute la cascade. Où vit ce stockage et ce qu’il contient est entièrement décrit par la spécification.
Ce que les annonces limitées retirent de l’inventaire
Le repli n’est pas une panne, c’est un mode de diffusion documenté. Google le décrit ainsi : « Les annonces limitées permettent de diffuser des annonces sans utiliser de données personnelles à des fins de personnalisation. » Le membre de phrase compte : la personnalisation s’arrête, pas le traitement. La même page précise que l’adresse IP continue de servir à acheminer l’annonce, et que des cookies de détection de fraude restent posés. Google nomme aussi le déclencheur le plus courant, qui n’a rien à voir avec une chaîne périmée : « La diffusion d’annonces limitées s’applique en l’absence de consentement pour la première finalité du TCF de l’IAB. »
Ce qui disparaît alors touche le produit vendu autant que le ciblage. Google liste les fonctionnalités désactivées, à commencer par toutes celles qui reposent sur un identifiant local : le plafonnement de répétition, à une bêta fermée près, le reporting sur la couverture par cookie et sur la couverture unique, et les conversions dans l’application. Il ajoute que, sauf à activer le mode programmatique dédié, « les capacités de détection de fraude peuvent être réduites », et recommande aux éditeurs d’en informer les annonceurs.
L’inventaire reste vendable, mais il perd les attributs qui font son prix. Cette perte-là n’apparaît sur aucun tableau de bord de consentement, puisqu’elle se produit après la fenêtre, dans la requête.
Le second canal, celui qu’on oublie de vérifier
Le choix de l’utilisateur est unique, son transport ne l’est pas. À côté de la chaîne TC, Google maintient une seconde chaîne, dite de consentement supplémentaire. Sa spécification en donne la raison : elle « permet d’envoyer des signaux de transparence et/ou de consentement aux fournisseurs qui ne sont pas encore inscrits sur la liste globale des fournisseurs de l’IAB Europe », dès lors qu’ils figurent sur la liste des partenaires de technologie publicitaire de Google.
Elle voyage sous son propre paramètre et porte son propre format, du type 2~1.10~dv.2.3.4 : le numéro de version de la spécification, la liste des identifiants consentis, puis celle des fournisseurs simplement présentés. Google précise que seule une CMP enregistrée auprès du cadre de l’IAB Europe peut la créer, et que les fournisseurs ne doivent pas la fabriquer eux-mêmes.
La conséquence est concrète : un éditeur peut afficher un taux flatteur, transmettre correctement sa chaîne TC, et ne rien transmettre du tout à cette famille de partenaires. De leur point de vue, l’utilisateur n’a pas répondu.
À l’autre bout, le revenu encaissé avant le choix
La monétisation ne se perd pas seulement par défaut de transport. Elle se prend aussi trop tôt, et cette faute-là se chiffre.
Le 1er septembre 2025, la formation restreinte de la CNIL a prononcé une amende de 150 millions d’euros contre la société irlandaise qui exploite le site de SHEIN pour l’Europe, au titre de l’article 82 de la loi Informatique et Libertés. Les constats sont ceux qu’une capture met au jour : des traceurs, « notamment à finalité publicitaire », déposés « dès leur arrivée sur le site, avant même qu’ils n’interagissent avec le bandeau d’information pour exprimer un choix ». Et après le refus : « lorsqu’un utilisateur [...] cliquait sur le bouton “Tout refuser” présent dans le bandeau [...] de nouveaux traceurs étaient pourtant déposés et d’autres, déjà présents, continuaient d’être lus. »
Le même jour, deux amendes d’un montant total de 325 millions d’euros ont été prononcées contre Google, dont 200 millions contre GOOGLE LLC et 125 millions contre GOOGLE IRELAND LIMITED. Elles couvrent deux griefs distincts, dont l’affichage de publicités entre les courriels de Gmail. Sur le seul volet traceurs, la CNIL retient que, jusqu’en octobre 2023, le consentement des utilisateurs créant un compte Google n’était pas libre « puisque le refus des traceurs liés à la publicité personnalisée était plus difficile à effectuer que leur acceptation ». Ce manquement concernait plus de 74 millions de comptes.
Les deux dossiers portent sur des sites web, et il faut le dire dans un article consacré au mobile. Ils valent pourtant ici, parce que l’article 82 de la loi Informatique et Libertés ne distingue pas le navigateur du téléphone, et que la CNIL a bâti sa recommandation applications mobiles sur ce même fondement. Ce que ces décisions sanctionnent n’est pas un détail d’interface, ce sont des mécaniques de monétisation : encaisser avant le choix, et rendre le refus plus coûteux que l’accord. Dans une application, la même mécanique se mesure sur le trafic, et un SDK peut la produire sans que son fournisseur la voie.
Monétiser le refus : payer ou consentir
Reste la voie choisie par une partie des éditeurs quand le refus coûte trop cher, faire payer. La CNIL décrit l’intention sans détour : les éditeurs cherchent ainsi « à compenser la perte de revenus publicitaires résultant de l’absence de traceurs par un autre mode de rémunération ».
Le cadre tient à une décision du Conseil d’État du 19 juin 2020, plus étroite qu’on ne le lit d’ordinaire. Le juge n’a pas validé les murs de traceurs : il a censuré la position par laquelle la CNIL les interdisait en bloc. « En déduisant pareille interdiction générale et absolue de la seule exigence d’un consentement libre [...], la CNIL a excédé ce qu’elle peut légalement faire, dans le cadre d’un instrument de droit souple. » Ni « cas par cas » ni « alternative » ne figurent dans la décision.
Le test que tout le monde cite ensuite, celui du cas par cas et de l’« existence d’alternative réelle et satisfaisante proposée en cas de refus des cookies », est la lecture qu’en a tirée la CNIL dans ses premiers critères d’évaluation, publiés le 16 mai 2022. Elle y part du constat que des sites web comme des applications mobiles ont recours à ces murs, même si la suite du document ne parle plus que de sites.
Le CEPD a resserré le cadre pour les grandes plateformes dans son avis 08/2024, adopté le 17 avril 2024. C’est un avis, non un texte contraignant, et il est rédigé en recommandations : « Dans la plupart des cas, il ne sera pas possible aux grandes plateformes en ligne de satisfaire aux exigences d’un consentement valable si elles ne confrontent les utilisateurs qu’à un choix binaire entre consentir au traitement à des fins de publicité comportementale et payer des frais. » L’avis demande d’abord d’envisager une « alternative équivalente » qui n’implique pas le paiement de frais. Et si le responsable choisit malgré tout de faire payer cette alternative équivalente, il doit envisager d’en proposer « une autre, gratuite, sans publicité comportementale, par exemple avec une forme de publicité impliquant le traitement de moins de données personnelles, voire d’aucune ».
Son périmètre est expressément limité aux grandes plateformes en ligne. Il donne néanmoins la direction du raisonnement, et la CNIL applique déjà la même grille d’alternative réelle aux autres.
Les questions auxquelles seule l’exécution répond
Un tableau de bord de consentement répond à une seule question, ce que l’utilisateur a cliqué. Les autres se posent après, sur le fil, et aucune interface ne les affiche.
Quelles requêtes partent avant que la fenêtre ne s’affiche ? Lesquelles continuent après un refus ? Quels paramètres de consentement la requête porte-t-elle réellement quand elle quitte le téléphone, et lesquels sont vides ? La chaîne inscrite dans le stockage local est-elle celle que produit la version installée aujourd’hui, ou celle d’une version publiée il y a un an et jamais mise à jour ?
On y répond en exécutant l’application sur un vrai téléphone, en marquant le moment où l’on accepte et celui où l’on refuse, puis en lisant le trafic. Skanopy situe chaque échange par rapport à ces moments et nomme les acteurs contactés : la cartographie des acteurs tiers et ce que la bannière déclenche vraiment, rejouées à chaque version publiée. Le rapport établit des faits datés, il ne prononce pas de verdict de conformité : la qualification reste au DPO. C’est la matière d’un audit RGPD d’application mobile.
Sources
Chaque constat de cet article renvoie à l’un de ces documents.
- IAB ’26All You Need to Know About the Transition to TCF v2.3 : publication le 19 juin 2025, fin de transition le 28 février 2026, segment des fournisseurs affichés obligatoireIAB Europe
- IAB Tech LabCMP API v2 : macros ${GDPR} et ${GDPR_CONSENT_XXXX}, et règle par défaut en l’absence de CMPIAB Tech Lab, Transparency and Consent Framework v2
- GoogleIntégration du TCF de l’IAB Europe pour les éditeurs : échéance du 1er mars 2026, repli en annonces limitées, chaîne lue dans le stockage local par les partenaires de médiationAide Google Ad Manager
- GoogleAnnonces limitées : ce que le mode désactive, des fonctionnalités à identifiant local au reportingAide Google Ad Manager
- GoogleMessage lié aux réglementations européennes : le SDK UMP certifié pour la version 2.3 du TCF sur toutes ses versions, et le repli en annonces limitées sans consentement pour la première finalitéAide Google AdMob
- GoogleSpécification technique de Google concernant le consentement supplémentaire : format de la chaîne AC et partenaires hors liste globaleAide Google Ad Manager
- WEIS ’19Online Tracking and Publishers’ Revenues : An Empirical AnalysisVeronica Marotta, Vibhanshu Abhishek, Alessandro Acquisti, Workshop on the Economics of Information Security, brouillon préliminaire de mai 2019
- CNIL ’25Cookies déposés sans consentement : amende de 150 millions d’euros, délibération SAN-2025-005 du 1er septembre 2025CNIL, communiqué du 3 septembre 2025
- CNIL ’25Publicités insérées entre les courriels et cookies : amende de 325 millions d’euros à l’encontre de GOOGLECNIL, communiqué du 3 septembre 2025
- CNIL ’22Cookie walls : premiers critères d’évaluationCNIL, 16 mai 2022
- CE ’20Décision n° 434684 : la CNIL ne pouvait pas déduire une interdiction générale et absolue des murs de traceurs de la seule exigence d’un consentement libreConseil d’État, 19 juin 2020
- CEPD ’24Avis 08/2024 sur la validité du consentement dans les modèles « consentir ou payer » des grandes plateformes en ligneComité européen de la protection des données, adopté le 17 avril 2024
- CNIL ’25Recommandation relative aux applications mobiles, version modifiéeCNIL, délibération n° 2025-024 du 27 mars 2025
Questions fréquentes
- Un taux de consentement élevé garantit-il les revenus publicitaires d’une application ?
- Non. Le taux mesure ce que l’utilisateur a répondu dans la fenêtre, pas ce que la requête d’annonce transporte ensuite. La spécification de l’API CMP de l’IAB Europe prévoit qu’en l’absence de CMP ou de réponse de sa part, les fournisseurs doivent supposer l’absence de consentement, et Google indique qu’il servira une annonce limitée aux demandes européennes dépourvues de chaîne TC issue d’une CMP qu’il certifie. L’impression se vend donc, mais au tarif d’une impression sans consentement : un accord qui n’arrive pas produit le même résultat commercial qu’un refus.
- Qu’est-ce qui a changé le 1er mars 2026 pour les chaînes de consentement TCF ?
- La version 2.3 du cadre de l’IAB Europe, publiée le 19 juin 2025, rend obligatoire un segment qui énumère les fournisseurs affichés à l’utilisateur. L’IAB Europe a fixé la fin de la période de transition au 28 février 2026 et indique que les chaînes créées après cette date sans le segment seront considérées comme invalides. Google précise de son côté que la version 2.3 est obligatoire pour toute chaîne générée à partir du 1er mars 2026 et qu’à défaut la demande d’annonce peut retomber en annonces limitées.
- À quoi sert la chaîne de consentement supplémentaire de Google ?
- Elle transporte le consentement vers les partenaires de technologie publicitaire de Google qui ne figurent pas encore sur la liste globale des fournisseurs de l’IAB Europe. C’est un second canal, distinct de la chaîne TC, avec son propre paramètre et son propre format. Seule une CMP enregistrée auprès du cadre de l’IAB Europe peut la créer. Si elle ne voyage pas, ces partenaires ne reçoivent rien, même lorsque l’utilisateur a accepté.
- Corriger une fenêtre de consentement dans une application oblige-t-il à publier une nouvelle version ?
- Cela dépend de la CMP. Le message lui-même se compose et se publie à distance ; ce qui est compilé dans l’application, c’est la bibliothèque qui écrit la chaîne de consentement. Google indique que son propre SDK UMP est certifié par l’IAB pour la version 2.3 du TCF sur toutes les versions du SDK, et qu’aucune action n’est requise pour les éditeurs qui utilisent sa CMP. Pour une CMP tierce, il renvoie l’éditeur vers le plan de migration de son fournisseur : si ce plan suppose une nouvelle version de la bibliothèque, il suppose une publication puis une installation, et les versions déjà installées continuent d’émettre entre-temps.