RGPD et App Tracking Transparency (ATT) : comment obtenir le consentement utilisateur dans une app mobile

Depuis 2021, impossible d’ignorer le sujet : le consentement utilisateur est devenu obligatoire dans les apps mobiles, que ce soit pour des raisons légales (RGPD en Europe) ou techniques (App Tracking Transparency imposé par Apple). Et pourtant, encore aujourd’hui, une majorité d’applications collectent des données sans respecter les règles, souvent par méconnaissance ou complexité technique.

Or, ne pas respecter ces règles, ce n’est pas seulement un risque juridique : c’est aussi un risque business majeur :

• Données analytics faussées (car non consenties)

• Risque de blocage sur les stores (notamment par Apple)

• Sanctions potentielles de la CNIL ou d’autres autorités

• Perte de confiance des utilisateurs

Mais alors, comment faire ?
Comment être 100 % conforme tout en conservant des données de qualité ? Comment afficher le bon prompt au bon moment ? Et surtout, comment empêcher les SDK comme Firebase, Adjust ou AppsFlyer de collecter quoi que ce soit sans consentement explicite ?

Dans cet article, je te propose une méthode claire, concrète et applicable, même si tu n’es pas juriste :

• Tu comprendras ce que disent vraiment le RGPD et ATT

• Tu verras quand et comment demander le consentement, sans ruiner l’expérience utilisateur

• Tu découvriras comment bloquer les SDKs avant consentement, même dans une app React Native

• Et tu apprendras à gérer les changements de choix, stocker les statuts et rester clean face à la loi

🎯 Que tu sois dev mobile, PM ou fondateur, ce guide est là pour te permettre de concilier tracking utile et respect de la vie privée. Et en bonus, je te donnerai un template gratuit de bandeau de consentement mobile, prêt à implémenter.

Comprendre les obligations légales

Avant de parler d’implémentation technique, il est essentiel de comprendre ce que la loi impose. Beaucoup d’équipes se contentent d’afficher un bandeau de consentement… sans savoir ce qu’elles doivent bloquer, ni pourquoi. Résultat : du tracking illégal, des SDK actifs avant consentement, et des données potentiellement inutilisables.

Voici les deux grands cadres à connaître pour toute app mobile en 2025 : le RGPD (Règlement Général sur la Protection des Données) et l’App Tracking Transparency d’Apple.

🇪🇺 Le RGPD : obtenir un consentement libre, éclairé, spécifique et documenté

Le RGPD s’applique dès lors que vous traquez un utilisateur situé dans l’Union Européenne, quel que soit le pays d’hébergement de votre app. Il impose plusieurs principes :

• Consentement préalable obligatoire : vous devez obtenir un accord avant de collecter toute donnée non essentielle (analytics, attribution, retargeting…).

• Le consentement doit être libre (pas imposé), éclairé (l’utilisateur comprend ce qu’il accepte), spécifique (par finalité) et documenté (pouvoir prouver qu’il a été donné).

• Vous devez pouvoir bloquer tous les outils non essentiels (SDKs) tant que le consentement n’est pas donné.

• L’utilisateur doit pouvoir retirer son consentement à tout moment.

💡 En pratique, cela signifie que l’init du SDK Firebase Analytics ou AppsFlyer ne doit pas se produire tant que l’utilisateur n’a pas accepté. Ce n’est pas une simple question de wording ou de case à cocher.

⚠️ La CNIL a déjà condamné plusieurs entreprises pour non-respect de ces règles dans leurs apps mobiles. La collecte par défaut, même sans identifier l’utilisateur directement, n’est pas légale sans accord explicite.

🍏 L’ATT (App Tracking Transparency) : le consentement d’Apple pour l’accès à l’IDFA

Depuis iOS 14.5, toute app qui souhaite accéder à l’IDFA (identifiant publicitaire d’Apple) doit afficher le prompt ATT natif proposé par le système.

Les obligations :

• Vous ne pouvez plus accéder à l’IDFA sans avoir affiché (et reçu un “autoriser”) sur le prompt ATT

• Le prompt ATT doit être clairement expliqué avant affichage via un écran personnalisé (pré-prompt)

• Les outils de tracking comme Adjust ou AppsFlyer n’obtiendront aucun identifiant publicitaire si l’utilisateur refuse

• Vous devez adapter votre stratégie analytics pour fonctionner même sans IDFA (par exemple : tracking via user_id ou device_id interne)

💡 ATT ne remplace pas le RGPD. Vous devez afficher les deux demandes de consentement si vous collectez des données dans l’UE. ATT concerne l’IDFA uniquement, le RGPD englobe toutes les données personnelles.

🎯 Différence : consentement publicitaire vs analytique

Il est aussi important de distinguer les types de données que vous collectez :

• Le tracking analytique (Firebase, Mixpanel, Amplitude…) peut être exempté de consentement si vous anonymisez totalement les données et ne les utilisez pas pour autre chose.

• Le tracking publicitaire et d’attribution (Adjust, AppsFlyer, Meta SDK, etc.) nécessite toujours un consentement préalable, car il repose sur des identifiants persistants, souvent non anonymes.

🎯 Conseil : séparez clairement les finalités dans votre UX de consentement, avec une case pour “Mesure d’audience” et une autre pour “Publicité personnalisée”.

Quand et comment demander le consentement

Maintenant que vous connaissez vos obligations légales, reste à répondre à la question cruciale :

Quand faut-il demander le consentement, et comment le présenter pour qu’il soit clair, légal… et efficace ?

Cette étape est trop souvent bâclée, avec des bandeaux mal placés, incompréhensibles ou affichés au mauvais moment. Et pourtant, une UX de consentement bien pensée permet à la fois de respecter la loi et de maximiser le taux d’acceptation.

⏱️ Quand afficher la demande de consentement ?

Il n’existe pas un seul bon moment, mais plusieurs options en fonction de votre UX. Ce qui compte, c’est de l’afficher avant le premier envoi de données, pas après.

Option 1 : Dès le premier lancement de l’app

• ✅ Avantage : vous êtes 100 % conforme dès la première seconde

• ❌ Inconvénient : froid, intrusif, taux d’acceptation parfois faible

Option 2 : Après l’onboarding

• ✅ Avantage : l’utilisateur comprend mieux la valeur de l’app → accepte plus facilement

• ❌ Risque juridique si des SDKs sont lancés entre-temps

Option 3 : Sur action déclencheuse (ex : analytics, clic pub, partage)

• ✅ UX personnalisée, déclenchée uniquement si nécessaire

• ❌ Plus complexe techniquement, demande une logique de gestion par finalité

🎯 Recommandation : si vous utilisez des SDKs comme Firebase Analytics, Adjust ou AppsFlyer, ne les initialisez pas au lancement de l’app. Attendez que l’utilisateur ait accepté via votre système de consentement.

🧰 CMP mobile ou système maison : que choisir ?

Deux options s’offrent à vous pour gérer le consentement :

1. Intégrer une Consent Management Platform (CMP) mobile

Il existe aujourd’hui plusieurs CMP adaptées aux apps :

• OneTrust Mobile

• Didomi

• Axeptio Mobile SDK

• Sourcepoint SDK

✅ Avantages :

• Conformes par design (RGPD + CCPA)

• UI/UX prêtes à l’emploi

• Gestion du multi-fonction (analytics / pub / essentiel)

• Stockage du consentement automatique

• Intégration possible avec TCF (pour la pub programmatique)

❌ Inconvénients :

• Coût parfois élevé

• Intégration technique à maîtriser

• UX parfois trop rigide

2. Créer un système de consentement custom

Vous créez votre propre bandeau de consentement avec vos textes, vos cases à cocher, votre logique de stockage.

✅ Avantages :

• Contrôle total sur l’UX et l’apparence

• Comportement parfaitement adapté à votre app

• Aucune dépendance à un tiers

❌ Inconvénients :

• Vous êtes responsable de la conformité juridique

• Doit gérer la compatibilité iOS/Android + l’affichage d’ATT

• Implémentation plus longue

🎯 Conseil : si vous avez une équipe produit/tech solide, un système custom bien fait est souvent plus léger et plus agréable. Sinon, une CMP reste le moyen le plus rapide d’être conforme.

🧩 Exemples de bonnes pratiques UX mobile

• Pré-prompt ATT : avant le prompt Apple, affichez un écran expliquant pourquoi vous demandez l’accès (ex : “Cela nous permet d’améliorer les publicités que vous voyez. Vous pouvez refuser.”)

• Consentement par catégorie : proposez des choix clairs :

  • Essentiel

  • Analytics

  • Publicité personnalisée

• Explication courte et actionnable : utilisez un langage humain, pas juridique :

  “Nous utilisons des outils pour mieux comprendre ce que vous aimez dans notre app, et pour personnaliser nos publicités. Vous pouvez choisir ce que vous acceptez.”

• Lien vers votre politique de confidentialité : obligatoire et toujours visible

Bloquer les SDKs avant consentement

C’est le nerf de la guerre. Beaucoup d’équipes affichent un bandeau de consentement… mais laissent tout de même les SDK comme Firebase, Adjust ou AppsFlyer s’exécuter dès le démarrage de l’app. Résultat : données collectées avant consentement = non conformité au RGPD, et parfois non-respect des guidelines Apple.

Voici comment bloquer proprement vos SDKs analytics et attribution tant que l’utilisateur n’a pas donné son accord.

🚫 Pourquoi il ne suffit pas “d’ignorer les events”

Certains pensent qu’il suffit de ne pas envoyer certains événements ou de les filtrer côté dashboard. Faux.

Dès qu’un SDK est initialisé, il :

• Envoie des requêtes réseau automatiquement (ex : device ID, session, app version…)

• Crée des identifiants persistants ou utilise ceux du téléphone (ex : GAID, IDFA)

• Peut transmettre des données à des serveurs aux États-Unis ou en dehors de l’UE

💡 Résultat : le simple fait de “charger le SDK” déclenche déjà des traitements de données. Il faut donc empêcher son initialisation tant que le consentement n’est pas obtenu.

🧱 Méthode générale pour bloquer l’initialisation d’un SDK

Étapes :

1. Stocker le choix de l’utilisateur (par exemple dans AsyncStorage, SharedPreferences, ou une base locale)

2. Au launch de l’app, vérifier si l’utilisateur a donné son accord

3. Si oui → initialiser le SDK

4. Si non → ne rien faire

Exemple avec Adjust (React Native ou Android natif) :

if (userHasConsented) { const config = new AdjustConfig(appToken, AdjustEnvironment.Production); Adjust.create(config); }

Exemple avec Firebase :

• Firebase Analytics peut être désactivé par défaut avec :

await analytics().setAnalyticsCollectionEnabled(false);

• Puis activé uniquement après acceptation :

if (userHasConsented) { await analytics().setAnalyticsCollectionEnabled(true); }

🎯 Conseil : pensez aussi à bloquer les événements personnalisés (ex : logEvent()) si le consentement n’a pas été donné.

🔧 Spécificités selon les plateformes

🔷 React Native :

• Vérifiez que votre logique de consentement est bien exécutée avant tout import de module analytics

• Utilisez des loaders conditionnels ou require() à la volée après consentement

🔷 Android natif :

• Placez vos initialisations SDK après un check de consentement stocké dans SharedPreferences

• Évitez les initialisations dans le fichier Application si elles ne sont pas contrôlables

🔷 iOS natif :

• Utilisez NSUserDefaults pour stocker le consentement

• Retardez les initialisations Firebase/Adjust dans applicationDidFinishLaunching

• Intégrez correctement le prompt ATT via ATTrackingManager.requestTrackingAuthorization(...) uniquement si nécessaire

🎯 En résumé :

Tant que l’utilisateur n’a pas donné son accord clair, aucun SDK ne doit être initialisé, ni aucun événement envoyé. C’est la seule manière d’être réellement conforme, et de pouvoir défendre votre app en cas de contrôle.

Gérer les changements de consentement

Obtenir le consentement une fois ne suffit pas. Le RGPD impose que l’utilisateur puisse modifier son choix à tout moment, facilement et sans subir de pression. De votre côté, cela implique de gérer dynamiquement ce consentement dans votre code, et de synchroniser les SDKs en conséquence.

Voici comment mettre en place une gestion propre, conforme et évolutive du consentement dans votre app mobile.

🔒 1. Où et comment stocker le consentement utilisateur

Le choix de l’utilisateur doit être :

• Persistant (conservé entre les sessions)

• Modifiable à tout moment

• Exploitable rapidement par les SDKs

Où le stocker ?

• Sur le device : via AsyncStorage (React Native), SharedPreferences (Android), NSUserDefaults (iOS)

• Sur votre back-end : lié à un user_id ou device_id si l’utilisateur est authentifié

• Via une CMP : les CMPs stockent souvent le consentement automatiquement et exposent une API

💡 Recommandation : stockez localement pour le démarrage rapide, et répliquez côté back-end pour l’audit (preuve du consentement).

Comment structurer le consentement ?

Créez un objet structuré :

{ "analytics": true, "ads": false, "timestamp": "2025-04-25T13:00:00Z", "source": "initial_prompt" }

🎯 L’objectif est de pouvoir rejouer l’historique, tracer les changements et adapter dynamiquement les comportements de votre app.

🔄 2. Mettre à jour dynamiquement les SDKs après un changement

Une fois que le consentement change, il faut répercuter ce changement immédiatement dans les outils actifs. Voici comment faire selon les cas :

Firebase :

await analytics().setAnalyticsCollectionEnabled(userConsents.analytics);

Adjust :

• Il n’existe pas de méthode “disable” une fois lancé → vous devez redémarrer sans initialisation à la prochaine session.

• Sinon, vous pouvez :

  • arrêter d’envoyer les événements personnalisés

  • désactiver temporairement le tracking via config SDK (selon la version)

AppsFlyer :

appsFlyer.setSharingFilterForAllPartners(); appsFlyer.stop(true); // stoppe tout tracking (optionnel)

💡 Attention : tous les SDKs n’offrent pas une désactivation dynamique. Si besoin, redémarrez l’app avec les nouveaux paramètres appliqués.

🧠 3. Donner accès à une interface de modification du consentement

Vous avez l’obligation RGPD de permettre à l’utilisateur de changer son choix facilement.

Bonnes pratiques :

• Lien “Gérer mes préférences” dans les paramètres de l’app

• Possibilité de réafficher le bandeau ou les catégories

• Option de suppression complète du compte ET des données trackées

• Mise à jour immédiate des comportements dans l’app après le changement

🎯 Ajoutez un événement analytics consent_updated pour suivre les changements (sans stocker d’information sensible, évidemment).

En résumé :

Le consentement n’est pas un moment unique, c’est un état qui peut évoluer. Votre app doit savoir l’enregistrer, le respecter et l’adapter à la volée.

Bonnes pratiques UX et conformité

Respecter le RGPD et ATT, ce n’est pas juste un sujet légal. C’est aussi un sujet d’expérience utilisateur. Une demande de consentement bien conçue peut à la fois :

• respecter les réglementations,

• inspirer confiance,

• et augmenter votre taux d’acceptation.

À l’inverse, une UX brouillonne, manipulatrice ou floue peut ruiner la relation utilisateur… voire vous exposer à des sanctions. Voici les meilleures pratiques pour allier clarté, conformité et conversion.

🚫 Éviter les dark patterns

Les dark patterns sont des pratiques d’interface qui poussent l’utilisateur à accepter sans réfléchir, ou rendent le refus volontairement difficile. Ils sont illégaux dans le cadre du RGPD, et de plus en plus visés par les régulateurs.

Exemples à proscrire :

• Le bouton “Tout accepter” très visible, et “Tout refuser” en gris minuscule

• Des cases pré-cochées (interdites)

• Des formulations ambiguës comme “Poursuivre équivaut à consentir”

• La disparition du choix après un clic “Refuser”

💡 Le principe à suivre : donner un vrai choix, dans une interface claire, équilibrée et lisible. L’utilisateur doit comprendre, choisir, et revenir sur son choix facilement.

✅ Proposer des choix par finalité (et pas juste tout ou rien)

Une bonne UX de consentement donne à l’utilisateur le contrôle sur les types de données collectées.

Modèle recommandé :

• Essentiel (toujours activé – fonctionnement de l’app)

• Analytics (comprendre l’usage de l’app)

• Publicité personnalisée (améliorer les recommandations et campagnes)

Cela permet de :

• Respecter la granularité demandée par le RGPD

• Maximiser le taux d’acceptation partielle (souvent suffisant pour vos besoins analytics)

• Montrer que vous traitez les données avec sérieux et respect

🎯 Conseil : conservez les choix de l’utilisateur dans un objet simple (consents.analytics = true) et appliquez-les dynamiquement dans l’app.

🧾 Utiliser un wording clair, court, non juridique

Trop d’apps présentent leur bandeau de consentement comme un mini code civil. Mauvaise idée. Vous devez expliquer en langage humain, simple, bienveillant ce que vous allez faire avec les données.

Exemples de bons wordings :

“Nous utilisons des outils pour mieux comprendre ce que vous aimez dans notre app. Vous pouvez refuser si vous préférez ne pas être suivi.”

“Ces données nous aident à améliorer votre expérience et à vous proposer des contenus utiles. Vous êtes libre de les activer ou non.”

Évitez :

• Les phrases passives : “Des données sont susceptibles d’être collectées…”

• Le jargon légal (finalité, traitement, base légale, etc.)

• Les formulations biaisées du type “améliorer votre confort” (trop flou)

🎯 Objectif : que l’utilisateur comprenne ce qu’il accepte sans avoir à googler des termes juridiques.

🔗 Ajouter un lien clair vers la politique de confidentialité

C’est une obligation légale, mais aussi un gage de sérieux. Le lien doit :

• Être visible directement dans l’interface de consentement

• Pointer vers une page mobile-friendly, à jour, lisible

• Détailler les outils utilisés (Firebase, Adjust, AppsFlyer…), la durée de conservation, les droits utilisateurs

💡 Bonus : créez une version synthétique (3 bullet points) au-dessus du lien pour résumer les points clés de manière accessible.

Conclusion : Le respect du RGPD et d’ATT, un levier de confiance (et de performance)

On pourrait croire que le RGPD et ATT sont des freins au tracking. En réalité, ils sont une opportunité de remettre de l’ordre dans vos pratiques, de clarifier vos intentions, et de bâtir une relation de confiance durable avec vos utilisateurs.

Aujourd’hui, la collecte de données sans consentement n’est plus une option :

• Apple bloque les apps non conformes à ATT

• La CNIL multiplie les contrôles et les sanctions

• Les utilisateurs deviennent de plus en plus attentifs (et méfiants)

En respectant les règles dès l’installation de votre app, vous :

• Protégez votre business d’un risque légal

• Améliorez la qualité et la fiabilité de vos données

• Créez un meilleur onboarding, plus éthique et plus transparent

Et vous montrez que votre entreprise a compris que la privacy est un droit, pas un frein.

✅ Ce que vous pouvez faire dès maintenant

• Auditez tous les SDKs utilisés dans votre app

• Créez un écran de consentement clair, avant tout tracking

• Retardez l’initialisation des SDKs tant que le consentement n’est pas donné

• Ajoutez un bouton “Gérer mes préférences” dans les paramètres

• Documentez tout pour prouver votre conformité (très utile en cas de contrôle)

👋 Besoin d’un accompagnement RGPD / ATT ?

Je peux vous aider à :

• Faire l’audit complet de votre app mobile (tracking + consentement)

• Mettre en place un système de gestion du consentement compatible RGPD + ATT

• Rendre vos SDKs totalement conformes (Firebase, Adjust, AppsFlyer, etc.)

• Créer un plan de taggage légalement solide et business-friendly