Guide de gestion du consentement pour les applications mobiles
Vue d'ensemble
Ce document fournit des directives complètes pour la mise en œuvre de la gestion du consentement dans les applications mobiles, garantissant ainsi la conformité aux réglementations en matière de protection des données, notamment le RGPD, la LGPD et les exigences du Transparency & Consent Framework (TCF) de l'IAB. Il traite de la gestion appropriée du consentement des utilisateurs pour les services tiers, notamment les réseaux publicitaires, les plateformes d'analyse et autres services de suivi.
Exigences d'implémentation
1. N'initialisez pas les services tiers sans vérification du consentement
Étapes de mise en œuvre :
- Vérifiez si l'utilisateur a pris une décision de consentement
- Vérifier le consentement pour le fournisseur/service spécifique
- Initialisez le service uniquement si les deux conditions sont remplies
- Si aucun consentement n'a été accordé pour un fournisseur ou un objectif donné, vous devrez :
- Ignorer l'initialisation de ce service (par exemple, Google AdMob) ;
- Utilisez des alternatives respectueuses de la vie privée, si elles sont disponibles ;
- Limitez les fonctionnalités disponibles en fonction de votre stratégie de revenus. Par exemple, pour une application entièrement gratuite dont la seule source de revenus est l'affichage de publicités, vous pouvez afficher un message informatif indiquant que l'application ne fonctionnera pas ou ne sera disponible que partiellement, sauf consentement à des fins marketing.
2. Vérification du consentement en deux phases
Mettez toujours en œuvre les deux contrôles requis par l'article 7(1) du RGPD et les spécifications IAB TCF :
Phase 1 : L’utilisateur a-t-il pris une décision ?
- Vérifiez si l'utilisateur a interagi avec la couche de consentement
- Si aucune décision n'a été prise, ne traitez pas les données personnelles
Phase 2 : L’utilisateur consent-il à un objectif spécifique ?
- Vérifiez si le consentement a été accordé pour le service tiers spécifique
- Chaque fournisseur/service nécessite une vérification du consentement individuel
Scénarios de flux de travail utilisateur
Scénario 1 : Flux de travail utilisateur normal
Flux : l'utilisateur ouvre l'application → le SDK affiche la couche de consentement (si nécessaire) → l'utilisateur fait son choix → l'application continue avec les services appropriés
Important : la navigation par bouton de retour ou les gestes sont désactivés sur nos SDK mobiles, de sorte que l'utilisateur ne peut pas ignorer la couche de consentement sans consentement approprié.
Étapes de mise en œuvre :
- Démarrage de l'application : Initialisez la plateforme de gestion du consentement. Pour cela, utilisez la méthode checkAndOpen(). Consultez les exemples dans notre documentation d'aide (iOS, Android)
- Vérification du consentement : l'étape précédente déterminera automatiquement si le consentement est nécessaire ou non, afin que l'utilisateur puisse prendre une décision éclairée en matière de consentement.
- Initialisation du service : initialiser les services en fonction des choix de consentement de l'utilisateur
Exemple de mise en œuvre :
// This hypothetical example assumes you have implemented:
// - OneSignal (s1448)
// - Google Ads/AdMob (s1)
// - Google Analytics (s26)
class yourGreatApp {
void function onAppLaunch() {
if shouldInitializeService("s148") {
OneSignal.initialize("your-token")
}
if shouldInitializeService("s1") {
AdMobService.initialize()
}
if shouldInitializeService("s26") {
FirebaseAnalytics.initializeApp("your-token")
}
}
boolean private function shouldInitializeService(string: purposeId):
// Phase 1: Check if user has made any decision
consentStatus = CMPManager.getUserStatus()
if consentStatus.status = "choiceDoesntExist"
return false // Consent Layer was not yet displayed to this client
return CMPManager.shared.getStatusForPurpose(id: purposeId) == "granted"
}
}Scénario 2 : Pas de connexion Internet
Flux : l'utilisateur ouvre l'application sans Internet → CMP ne peut pas charger la couche de consentement → l'application doit être gérée correctement
Observations critiques :
- Notre SDK mobile ne peut pas récupérer la configuration des serveurs
- Les décisions de consentement antérieures peuvent toujours être valables (conformément à l'article 7(3) du RGPD sur le retrait du consentement)
- L'application doit fonctionner en mode dégradé sans traiter de données personnelles au cas où aucun consentement n'aurait encore été donné
Stratégie de mise en œuvre :
- Vérifiez les éventuelles données de consentement persistantes des sessions précédentes (vous utiliserez
getUserStatus()comme dans l'exemple précédent pour cela) - Si un consentement préalable existe, procéder normalement
- Si aucun consentement persistant et pas d'internet :
-
- Bloquer tous les services tiers non essentiels
- Afficher un message convivial expliquant la situation
- Configurez l'écouteur de connectivité pour réessayer lorsque la connexion est rétablie et affichez la couche de consentement lorsque cela se produit
- Autoriser les fonctionnalités de base de l'application qui ne nécessitent pas de traitement de données personnelles
Considérations relatives à l’expérience utilisateur :
- Afficher un message clair sur les fonctionnalités limitées
- Implémenter l'option de nouvelle tentative lorsque la connexion est disponible
- Expliquez qu'aucune donnée personnelle ne sera partagée tant que les choix de confidentialité n'auront pas été faits
- Offrir la possibilité de continuer en mode limité
Scénario 3 : Aucun consentement nécessaire
Situation : l'utilisateur est en dehors de l'UE et la CMP est configurée pour s'afficher uniquement dans l'UE → Aucune couche de consentement affichée
Stratégie de mise en œuvre :
- Initialiser la configuration CMP normalement
- Autoriser CMP à déterminer si la couche de consentement doit être affichée à l'aide
checkAndOpen() - Si le consentement n'est pas requis, le statut de l'utilisateur renverra « choiceExists » et les fournisseurs et les finalités seront définis sur « accordés ».
- Initialiser tous les services normalement
Réagir aux changements de consentement
Les changements de consentement peuvent survenir dans plusieurs scénarios :
- L'utilisateur ouvre les paramètres de consentement et modifie ses préférences
- Le consentement expire et doit être renouvelé (ce paramètre se trouve sous Mentions légales sur votre tableau de bord CMP)
- Modifications des exigences légales qui obligent à se souvenir du consentement
- L'utilisateur demande la suppression des données
La checkAndOpen() La méthode réagira à toutes ces situations. Implémentez un écouteur qui suivra les modifications de consentement. Vous pouvez utiliser didReceiveConsent rappel pour cela (iOS et Android). Si, à tout moment, un fournisseur ou un objectif donné est rejeté, agissez immédiatement et bloquez les services en conséquence.
Liste de contrôle des tests
Essais fonctionnels
Test de débit normal :
- L'application démarre correctement et affiche la couche de consentement lorsque cela est nécessaire
- Les choix de consentement des utilisateurs sont correctement enregistrés et respectés
- Les services ne s'initialisent qu'avec le consentement approprié
- L'application fonctionne correctement après les décisions de consentement
Test de flux de rejet :
- Le rejet des utilisateurs bloque correctement les services tiers
- L'application reste fonctionnelle ou entre en mode dégradé en fonction de votre stratégie de revenus
Tests hors ligne :
- L'application gère correctement l'absence de connexion Internet
- Les données de consentement mises en cache sont utilisées de manière appropriée
- Le mode respectueux de la vie privée s'active en cas de besoin
- La restauration de la connexion déclenche une logique de nouvelle tentative appropriée
Test de délai d'attente :
- Le délai d'expiration de la couche de consentement déclenche une solution de secours appropriée
- L'application ne se bloque pas et ne plante pas pendant le délai d'attente
- Le mode de secours bloque correctement le traitement des données
- L'utilisateur reçoit une communication claire sur son statut
Test de conformité
Vérification du traitement des données :
- Aucune donnée de suivi n'est envoyée avant que l'utilisateur ne prenne sa décision de consentement
- Les identifiants des fournisseurs sont correctement mappés aux services réels
- Le blocage des services individuels fonctionne comme prévu
- Granularité du consentement correctement mise en œuvre
Vérification des exigences légales :
- Le retrait du consentement arrête immédiatement le traitement des données
- Les droits des personnes concernées peuvent être exercés via l'application
- Une piste d'audit appropriée est maintenue pour les décisions de consentement
- Base juridique documentée pour tout traitement de données
Dépannage
Problèmes courants et solutions
Problème : les services s'initialisent même lorsque le consentement est refusé
Causes profondes:
- Vérification du consentement manquante avant l'initialisation du service
- Mappage d'ID de fournisseur incorrect
Solutions:
- Ajouter une vérification de consentement explicite avant l'initialisation de TOUS les services tiers
- Vérifiez que les identifiants des fournisseurs correspondent à ceux de la liste globale des fournisseurs
- Mettre en œuvre une synchronisation appropriée entre le consentement et l'initialisation du service
- Effacer les instances de service lorsque le consentement est révoqué
Problème : la couche de consentement n'apparaît jamais
Causes possibles:
- Configuration CMP incorrecte (ID, domaine, etc. incorrects)
- Problèmes de connectivité réseau
- L'utilisateur se trouve en dehors de la région géographique cible
- Problèmes d'intégration d'applications
Étapes de débogage :
- Vérifier que la configuration CMP correspond aux paramètres du compte
- Tester la connectivité réseau et l'accessibilité du serveur CMP
- Vérifiez les journaux de la console pour les messages d'erreur
- Tester avec la couche de consentement à ouverture forcée pour vérifier l'intégration
- Confirmer les paramètres de ciblage géographique dans le tableau de bord CMP
Liste de contrôle des priorités de mise en œuvre
Haute priorité (doit être terminé avant le lancement) :
- Vérification du consentement implémentée avant l'initialisation de TOUS les services tiers
- Gestion appropriée des erreurs pour les problèmes de délai d'attente, de réseau et de configuration
- Les fonctionnalités de base de l'application sont préservées lorsque le consentement ne peut être déterminé
- Tous les identifiants de fournisseurs vérifiés et correctement mappés aux services réels
Améliorations continues :
- Suivez les analyses sur votre tableau de bord CMP pour connaître les taux de réussite du consentement
- Tests A/B pour l'optimisation de la couche de consentement
- Intégration avec des cadres de conformité supplémentaires
- Éducation améliorée des utilisateurs sur les choix de confidentialité
N'oubliez pas : face à l'incertitude quant aux exigences en matière de consentement, privilégiez toujours l'approche la plus respectueuse de la vie privée. Mieux vaut être trop prudent que de violer la vie privée des utilisateurs ou les exigences réglementaires.
