L’essentiel
Une application mobile qui traite des données personnelles reste pleinement soumise au RGPD, exactement comme un site web. Mais le contexte mobile ajoute des risques spécifiques : SDK publicitaires et d’analytics tiers qui collectent des données à l’insu de l’éditeur, permissions matérielles trop larges, tracking publicitaire encadré par l’App Tracking Transparency d’Apple, et labels de confidentialité désormais affichés directement sur la fiche de l’App Store et du Google Play Store. Ignorer ces spécificités expose autant à une sanction RGPD qu’à un rejet de l’application par les stores eux-mêmes.
Le RGPD s’applique à l’app, pas seulement au backend
Une erreur fréquente consiste à ne penser la conformité RGPD qu’au niveau du serveur (base de données, formulaires web), en oubliant que l’application elle-même collecte et traite des données dès son installation : identifiant publicitaire, données de localisation, journaux de crash, comportement de navigation dans l’app. Chaque traitement doit reposer sur une base légale claire, être documenté, et rester limité à ce qui est réellement nécessaire au fonctionnement de l’application (principe de minimisation).
Pour le volet purement technique de la protection de ces données (chiffrement, stockage, gestion des accès), voir notre page sécurité des applications mobiles : sécurité et conformité RGPD sont complémentaires, la première protège les données que la seconde encadre juridiquement.
Les SDK tiers, premier risque RGPD sous-estimé
La plupart des applications intègrent des kits de développement tiers pour l’analytics, la publicité, les notifications push ou les paiements. Chacun de ces SDK peut collecter et transmettre des données à ses propres serveurs, souvent hors Union européenne, sans que l’éditeur de l’application en ait une visibilité complète.
Points de contrôle avant d’intégrer un SDK tiers : vérifier sa politique de confidentialité et sa localisation de traitement, s’assurer qu’un accord de sous-traitance (DPA) existe si des données personnelles transitent par lui, auditer périodiquement les SDK réellement actifs dans l’application (des kits oubliés après un test restent parfois actifs en production), et documenter chaque SDK dans le registre des traitements comme n’importe quel autre sous-traitant.
Consentement et tracking : ce que changent iOS et Android
| Aspect | iOS (App Tracking Transparency) | Android |
|---|---|---|
| Cadre du tracking publicitaire | Consentement explicite obligatoire via la pop-up ATT avant tout tracking inter-app | Pas d’équivalent système unique, dépend du SDK et de la politique Google Play |
| Identifiant publicitaire | IDFA inaccessible sans consentement ATT | Identifiant publicitaire réinitialisable par l’utilisateur |
| Sanction en cas de non-respect | Rejet ou retrait de l’application par Apple | Rejet ou retrait de l’application par Google, en plus des sanctions RGPD |
| Article RGPD concerné | Article 6 (base légale) et considérant sur le consentement | Identique : le RGPD s’applique indépendamment de l’OS |
Le consentement demandé par une pop-up native (ATT ou bannière RGPD interne) ne suffit pas à lui seul : il doit être libre, spécifique, éclairé et univoque, ce qui exclut les formulations orientées (“Accepter pour continuer” sans alternative réelle) déjà sanctionnées par la CNIL sur le web et transposables sans ambiguïté au contexte mobile.
Permissions : le principe du moindre privilège
Demander l’accès à la caméra, au micro, à la géolocalisation précise ou au carnet de contacts sans justification directe avec une fonctionnalité utilisée immédiatement est à la fois un risque RGPD (traitement disproportionné) et un signal négatif pour les utilisateurs, qui désinstallent plus volontiers une application perçue comme intrusive. La bonne pratique consiste à demander chaque permission au moment précis où elle devient nécessaire (lazy permissions), avec une explication claire de son usage, plutôt qu’un bloc de demandes à l’ouverture de l’application.
Les labels de confidentialité des stores : la transparence devient publique
Depuis leur généralisation, l’Apple Privacy Nutrition Label et la section “Sécurité des données” de Google Play affichent directement sur la fiche de l’application un résumé des données collectées et de leur usage, visible par tout utilisateur avant même l’installation. Ces déclarations engagent juridiquement l’éditeur : une inexactitude entre le label déclaré et le comportement réel de l’application constitue à la fois une violation des conditions du store et un indice de non-conformité RGPD documenté publiquement.
Droits des personnes dans un contexte mobile
Le droit d’accès, de rectification et d’effacement s’applique à une application mobile comme à tout autre traitement, avec une contrainte pratique supplémentaire : les données peuvent exister à la fois sur le serveur et localement sur l’appareil (cache, base de données locale chiffrée, fichiers temporaires). Une suppression de compte doit donc déclencher l’effacement effectif des deux couches, pas seulement de l’enregistrement côté serveur.
FAQ
Un chiffrement fort suffit-il à garantir la conformité RGPD d’une application mobile ?
Non. Le chiffrement protège les données contre un accès non autorisé, mais la conformité RGPD couvre un périmètre plus large : base légale de collecte, durée de conservation, information des utilisateurs, gestion des droits d’accès et de suppression, encadrement contractuel des sous-traitants (SDK tiers inclus). Le chiffrement est une brique nécessaire, pas suffisante.
Faut-il un délégué à la protection des données (DPO) pour une application mobile ?
Cela dépend du volume et de la nature des données traitées, pas du support (mobile ou web) : le RGPD impose un DPO dans des cas précis (traitement à grande échelle de données sensibles, suivi régulier et systématique à grande échelle des personnes). Une PME avec une application standard n’y est généralement pas tenue, mais gagne à désigner un référent RGPD interne.
Les SDK publicitaires gratuits sont-ils un risque RGPD particulier ?
Souvent oui, car leur modèle économique repose justement sur la collecte et la valorisation de données. Chaque SDK publicitaire intégré doit faire l’objet d’une vérification de sa politique de traitement des données et, si nécessaire, d’un accord de sous-traitance, exactement comme n’importe quel prestataire qui traite des données pour le compte de l’éditeur de l’application.
Neodigit : la conformité RGPD intégrée à l’architecture mobile
Chez Neodigit, la conformité RGPD se pense dès le choix des SDK tiers et l’architecture de stockage, pas en correctif après un audit. Notre approche de la sécurité applicative intègre systématiquement le chiffrement des données locales, la minimisation des permissions demandées et une documentation claire des traitements, pour des applications conformes sans complexité inutile ajoutée après coup.
Une application existante à mettre en conformité ou un nouveau projet à concevoir dans les règles ? Parlons-en.