RGPD pour application mobile
Une application mobile collecte des données personnelles via des canaux multiples et souvent peu visibles pour l'utilisateur : SDK de mesure d'audience, bibliothèques publicitaires, rapports de crash, permissions système (géolocalisation, contacts, caméra, microphone). Chacune de ces collectes déclenche des obligations RGPD distinctes, indépendamment des transferts vers des serveurs souvent situés aux États-Unis.
Notre générateur produit une politique de confidentialité spécifiquement adaptée aux applications mobiles iOS et Android : intégrations tierces (Firebase, AppsFlyer, Crashlytics, Meta Audience Network...), identifiants publicitaires, exigences des stores Apple et Google, et consentement conforme aux recommandations de la CNIL pour les environnements mobiles.
SDK tiers et chaîne de sous-traitance
La plupart des applications mobiles embarquent plusieurs SDK (Software Development Kits) de tiers : outils d'analytics (Firebase Analytics, Amplitude, Mixpanel), de publicité (Meta Audience Network, Google AdMob), de crash reporting (Crashlytics, Sentry), de notifications push (OneSignal, Braze) ou d'authentification (Auth0, Firebase Auth). Chacun de ces SDK est potentiellement un sous-traitant au sens de l'article 28 du RGPD.
Chaque SDK intégré doit être documenté dans votre politique de confidentialité : finalité du SDK, données collectées, pays d'hébergement, base légale et lien vers la politique de confidentialité du tiers. Un SDK SDK publicitaire qui collecte des données comportementales avant le consentement de l'utilisateur constitue une violation caractérisée du RGPD.
Les transferts de données vers les États-Unis sont la règle dans l'écosystème mobile (Firebase, Meta, Google, AppsFlyer sont tous américains). Ces transferts doivent reposer sur des garanties appropriées — le Data Privacy Framework pour les entreprises certifiées, ou les clauses contractuelles types (CCT) de la Commission européenne — et être explicitement mentionnés dans votre politique.
Permissions système et identifiants publicitaires
Les permissions demandées à l'utilisateur — géolocalisation, accès aux contacts, caméra, microphone — constituent des collectes de données personnelles soumises au RGPD. Chaque permission doit être justifiée par une finalité précise et nécessaire. Demander la géolocalisation «pour améliorer l'expérience» sans usage concret constitue une collecte excessive contraire au principe de minimisation (art. 5.1.c RGPD).
Sur iOS, depuis iOS 14.5, l'accès à l'IDFA (Identifier for Advertisers) est soumis à un dialogue de consentement explicite via l'App Tracking Transparency (ATT) d'Apple. Sur Android, l'identifiant publicitaire (GAID) est accessible sans dialogue préalable mais son utilisation à des fins de ciblage publicitaire doit être encadrée par un consentement RGPD. Ces deux dispositifs doivent être coordonnés et documentés.
Exigences des stores Apple et Google
Apple App Store et Google Play imposent chacun des obligations de transparence qui s'articulent avec le RGPD. Apple exige une «nutrition label» de confidentialité (Privacy Nutrition Label) déclarant toutes les données collectées et leur utilisation. Google Play impose une «Data Safety Section» avec les mêmes exigences. Ces déclarations doivent être cohérentes avec votre politique de confidentialité — une incohérence peut entraîner le retrait de l'application des stores.
Votre politique de confidentialité doit être accessible depuis la fiche de l'application sur les stores (lien URL valide) et depuis l'intérieur de l'application. Pour les applications destinées aux mineurs, des obligations supplémentaires s'appliquent : interdiction de publicité comportementale, politique dédiée conforme aux législations spéciales protégeant les mineurs.
Générez votre document en 5 minutes
Notre générateur pré-remplit automatiquement les options adaptées à votre cas. Document personnalisé prêt à être copié-collé sur votre site.
Générer ma politique RGPD pour application mobileQuestions fréquentes
Faut-il une politique de confidentialité distincte pour l'app et le site web ?
Recommandé, car les traitements diffèrent. L'application mobile collecte des données spécifiques (identifiants publicitaires, permissions système, SDK embarqués) qui n'ont pas d'équivalent sur un site web classique. Une politique commune est possible à condition d'inclure une section dédiée à l'application mobile, mais la lisibilité s'en trouve souvent dégradée.
Le consentement RGPD remplace-t-il le dialogue ATT d'Apple ?
Non, les deux sont cumulatifs. Le dialogue ATT est une exigence contractuelle d'Apple pour accéder à l'IDFA sur iOS. Le consentement RGPD est une exigence légale pour les utilisateurs européens. Sur iOS, vous devez afficher le dialogue ATT et, si l'utilisateur est en Europe, recueillir son consentement RGPD pour la publicité comportementale. Un refus à l'un ou l'autre suffit à bloquer le ciblage.
Faut-il un DPO pour une application mobile ?
Si votre application effectue un suivi régulier et systématique d'utilisateurs à grande échelle (art. 37.1.b RGPD) — via analytics comportemental, publicité ciblée, géolocalisation continue — la désignation d'un DPO est obligatoire. Pour une application à audience limitée sans profilage intensif, elle ne l'est pas mais reste recommandée.
Comment gérer les crashlytics et les rapports de bugs du point de vue RGPD ?
Les rapports de crash (Firebase Crashlytics, Sentry, Bugsnag) peuvent contenir des données personnelles : identifiants d'utilisateur, contenu de formulaires saisis avant le crash, adresses IP. Ces outils sont des sous-traitants qui transfèrent des données aux États-Unis. Assurez-vous qu'ils sont configurés pour minimiser les données collectées (pas d'identifiants nominatifs), que leur DPA est signé, et que votre politique de confidentialité les mentionne.