Le problème de la double bannière

De nombreuses applications sont en partie natives et en partie web. Un jeu affiche sa boutique, ses actualités ou ses pages d’aide dans une WebView ; une application utilitaire affiche des articles issus de son site web ; une application hybride enveloppe l’essentiel de son interface dans du contenu web. Chaque côté a son propre mécanisme de consentement : l’application native utilise un CMP ou un SDK intégré, et les pages web chargent un CMP web. Faute de liaison entre les deux, l’utilisateur est sollicité deux fois, les choix faits d’un côté sont ignorés de l’autre, et les requêtes publicitaires émises depuis la WebView partent avec les mauvais signaux.

Ce guide explique comment faire concorder consentement natif et consentement web, afin que les utilisateurs ne répondent qu’une fois et que chaque requête publicitaire porte la même décision.

Où chaque côté stocke le consentement

Natif

L’IAB TCF précise comment un CMP intégré stocke le consentement : dans NSUserDefaults sur iOS et SharedPreferences sur Android, avec des clés standard comme IABTCF_TCString, IABTCF_gdprApplies et IABTCF_PurposeConsents. Les SDK publicitaires lisent directement ces clés. L’IAB GPP définit des clés similaires avec le préfixe IABGPP_, comme IABGPP_HDR_GppString.

Web

Un CMP web stocke généralement sa décision dans des cookies first-party ou le stockage local pour le domaine du site, et l’expose via les fonctions JavaScript __tcfapi et __gpp. Les balises publicitaires de la page appellent ces fonctions, pas le stockage natif.

Le fossé

Les WebViews disposent de leur propre espace de cookies et de stockage, distinct du navigateur de l’appareil et des préférences natives de l’application. Sur iOS, une WKWebView qui utilise un data store non persistant oublie tout à sa fermeture. Rien ne circule entre les deux côtés tant que vous ne le construisez pas.

Choisissez une seule source de vérité

La première décision est de savoir quel côté détient le consentement. Pour la plupart des applications, la réponse est le CMP natif, parce que :

• Il s’exécute en premier, avant l’ouverture de toute WebView.
• Les SDK publicitaires natifs, qui génèrent généralement l’essentiel des revenus, lisent le stockage natif.
• Sur iOS, il peut être coordonné avec l’invite App Tracking Transparency.

Le web d’abord peut se justifier pour les applications hybrides dont toute l’interface est du contenu web, mais il faut alors réécrire la décision dans le stockage natif pour les SDK natifs.

Transmettre le consentement natif à la WebView

Avec le natif comme source de vérité, la WebView doit voir la même décision. Schémas courants :

1. Injecter une implémentation de __tcfapi. Avant l’exécution des scripts de la page, injectez un petit script qui définit __tcfapi (et __gpp si nécessaire) et répond aux appels avec la chaîne TC et les valeurs lues dans le stockage natif. Les balises publicitaires de la page obtiennent alors la décision native via l’API standard.
2. Masquer la bannière web. Configurez le CMP web pour qu’il reste caché lorsque la page est chargée dans votre application, par exemple d’après un paramètre de requête ou un jeton de user agent personnalisé que vous contrôlez. Sinon, l’utilisateur voit une seconde bannière.
3. Transmettre la chaîne au chargement. Certains CMP web peuvent accepter une chaîne de consentement existante à l’initialisation et l’adopter. Consultez la documentation de votre CMP web pour connaître les méthodes prises en charge.

Quel que soit le schéma retenu, assurez-vous que les valeurs injectées sont mises à jour lorsque l’utilisateur change son choix dans l’écran de réglages natif, et pas seulement au prochain lancement de l’application.

Renvoyer le consentement web vers le natif

Si les utilisateurs peuvent modifier leur consentement dans la WebView, par exemple via une page de réglages de confidentialité, l’application doit en être informée. Utilisez un pont JavaScript : un gestionnaire de messages sur iOS ou une interface JavaScript sur Android. Le côté web écoute avec __tcfapi('addEventListener', ...) et envoie la nouvelle chaîne au code natif, qui écrit les clés standard. Validez les données provenant de la WebView avant de les écrire ; n’acceptez que les messages issus de votre propre contenu.

Les publicités dans les WebViews

Les publicités affichées dans une WebView sont des publicités web. Elles lisent le consentement depuis la page, pas depuis le stockage natif, sauf si le SDK publicitaire offre un moyen de relier les deux. Le Mobile Ads SDK de Google, par exemple, propose une API pour enregistrer les WebViews afin que les publicités qu’elles contiennent puissent utiliser les signaux de l’application ; consultez la documentation actuelle de votre SDK. Dans tous les cas, vérifiez par un test que les requêtes publicitaires issues de la WebView portent la même chaîne TC ou GPP que les requêtes publicitaires natives.

Checklist de test

• Installation neuve : une seule demande de consentement, pas deux.
• Tout refuser dans le CMP natif, ouvrir une WebView, inspecter les requêtes publicitaires : la chaîne doit refléter le refus.
• Modifier le consentement dans les réglages natifs, revenir à une WebView ouverte : la page doit voir la nouvelle décision.
• Si des réglages web existent, y modifier le consentement et confirmer que les clés natives se mettent à jour.
• Tuer puis relancer l’application : les décisions persistent des deux côtés.
• Tester sur iOS et sur Android, car le stockage des WebViews se comporte différemment sur chacun.

Points clés à retenir

• Le consentement natif et celui de la WebView résident dans des stockages distincts et ne se synchronisent pas par défaut.
• Choisissez une source de vérité ; pour la plupart des applications, c’est le CMP natif.
• Exposez le consentement natif au contenu web via un __tcfapi ou __gpp injecté et masquez la bannière web.
• Utilisez un pont JavaScript pour renvoyer les changements du web vers le stockage natif.
• Vérifiez que les requêtes publicitaires issues des WebViews portent la même chaîne de consentement que les requêtes natives.