TCF et Consent Mode : le signal de consentement est-il honoré dans l’app ?
Le cadre de consentement de l’IAB (le TCF) et le Consent Mode de Google poursuivent un but commun : encoder le choix de l’utilisateur dans un signal transmissible. Encore faut-il que ce signal soit honoré au bout de la chaîne, dans l’application.
Un cadre de plus en plus contraignant
Depuis janvier 2024, Google impose aux éditeurs qui diffusent des publicités personnalisées dans l’EEE et au Royaume-Uni de passer par une CMP certifiée, intégrée au TCF. À défaut, seules des publicités limitées peuvent être servies.
De son côté, l’IAB Europe surveille les intégrations : un acteur qui altère une TC string peut être suspendu de la liste globale des fournisseurs. Le cadre existe, et il se durcit.
La version 2.3 du cadre l’illustre : lancée en avril 2025, elle rend obligatoire la section des fournisseurs divulgués dans la TC string, et laissait aux participants jusqu’au 28 février 2026 pour l’adopter. Côté application, ce signal vit dans le stockage du téléphone, où chaque SDK vient le lire : voici où, et comment le décoder.
Encoder n’est pas respecter
Un signal correctement encodé ne garantit pas un comportement correct. La TC string peut être ignorée par un SDK mal intégré, arriver après que la requête est déjà partie, ou être contredite par un déclenchement trop précoce.
Le signal décrit une intention. Le comportement de l’application décrit ce qui se passe vraiment. Les deux peuvent diverger, et c’est cette divergence qui expose l’éditeur comme le fournisseur.
Ce qui s’observe sur le terrain
Ce qui manque, c’est une vue du comportement réel, là où le SDK s’exécute. Sur un vrai téléphone, on observe ce que le SDK fait et à quel moment par rapport au choix exprimé dans la bannière : avant, ou après un refus.
Ce constat reste une cartographie factuelle et datée. Il ne rend pas de verdict de conformité au TCF ou au Consent Mode : il documente ce qui se passe, et laisse l’appréciation juridique à l’éditeur et à son conseil.
La vérification côté fournisseur
Pour un acteur adtech, savoir comment son SDK se comporte, sur un échantillon d’applications réelles, une fois le choix exprimé, complète utilement ce que déclare sa documentation. C’est un moyen de repérer les intégrations où le choix n’est, en pratique, pas suivi d’effet.
C’est l’objet d’une vérification côté régie et adtech : observer le comportement du SDK application par application, preuve à l’appui.
Sources
Chaque constat de cet article renvoie à l’un de ces documents.
- IABTransparency and Consent Framework (TCF)IAB Europe
- GoogleIntégration du TCF de l’IAB Europe pour les éditeursAide Google AdMob, intégration du TCF
- Belgique ’25La cour des marchés se prononce dans l’affaire IAB EuropeAutorité de protection des données belge, communiqué sur l’arrêt du 14 mai 2025
Questions fréquentes
- Le Consent Mode remplace-t-il une CMP ?
- Non. Le Consent Mode transporte des états de consentement vers les services de Google, il ne recueille rien. Pour servir des publicités personnalisées dans l’Espace économique européen, Google exige d’ailleurs une CMP certifiée, intégrée au TCF. Les deux couches se complètent : la CMP recueille le choix, le signal le propage.
- Un signal de consentement bien formé prouve-t-il que le choix est respecté ?
- Non. Il prouve qu’un choix a été encodé. Ce qu’un SDK en fait, et surtout ce qu’il émet avant que le signal existe ou après un refus, ne se lit pas dans le signal : cela s’observe sur l’appareil, échange par échange. Le constat reste factuel, l’appréciation juridique revient à l’éditeur et à son conseil.