Une application de suivi de règles, un jeu de coloriage pour enfants, un utilitaire de lampe torche. Trois exemples que je cite souvent quand on me demande si le RGPD concerne vraiment les petites apps. La première récupérait l'identifiant publicitaire et l'envoyait à quatre régies différentes. La deuxième demandait l'accès aux contacts. La troisième, soi-disant sans compte, lisait le presse-papiers à chaque ouverture.
Aucune de ces trois apps n'avait de politique de confidentialité application mobile accessible en un clic. Voilà le point de départ réel de ce sujet. Pas la théorie : ce qui se passe quand on ouvre le code d'une app qu'on a téléchargée sans réfléchir.
Points clés à retenir
- Le RGPD impose des obligations à l'éditeur dès la première installation, quelle que soit la taille de l'app.
- Les recommandations CNIL encadrent spécifiquement les applications mobiles, notamment sur les SDK et les identifiants.
- iOS et Android n'ont pas les mêmes contraintes techniques : ce qui est conforme sur l'un ne l'est pas forcément sur l'autre.
- La base légale du consentement ne se décrète pas : elle se prouve.
- Les mentions légales et la politique de confidentialité sont deux documents différents, souvent confondus.
- Un SDK publicitaire non audité est la source de fuite la plus fréquente que je rencontre.
Protection des données application mobile : ce que la loi attend vraiment
Le RGPD ne fait pas de distinction entre une app à 50 000 téléchargements et une app à 5. Il pose une règle simple : dès lors que vous collectez une donnée personnelle, vous êtes responsable de traitement. Point. Et ce statut entraîne une série d'obligations que beaucoup d'éditeurs découvrent trop tard.
Les six principes qui reviennent tout le temps
Quand j'accompagne un développeur sur la mise en conformité, on ne part jamais du texte de loi. On part de ces principes, puis on redescend vers le code :
- Licéité, loyauté, transparence — l'utilisateur doit comprendre ce qui se passe.
- Limitation des finalités — une donnée collectée pour la géolocalisation ne sert pas à la publicité ciblée.
- Minimisation — le mot le plus mal appliqué du RGPD. Beaucoup collectent "au cas où".
- Exactitude
- Limitation de conservation — une durée définie, pas "indéfiniment".
- Intégrité et confidentialité — chiffrement, contrôle d'accès, journalisation.
La minimisation, franchement, c'est là que ça coince. J'ai vu une app de recettes demander l'accès au micro. Le développeur m'a répondu qu'il avait prévu une fonctionnalité de recherche vocale. Elle n'est jamais sortie. La permission, elle, est restée dans le manifeste.
Privacy by design : concrètement, ça change quoi ?
La protection dès la conception n'est pas un slogan. Dans un projet mobile, elle se traduit par des décisions prises avant la première ligne de code. Où va la donnée ? Qui y accède ? Combien de temps ? Si vous ne savez pas répondre, c'est déjà un signal.
Un exemple bête : le stockage local. Sur Android, les SharedPreferences sont lisibles sur un appareil rooté. J'ai récupéré un jeton d'authentification en clair sur un smartphone que j'avais rooté en dix minutes, sur une app bancaire d'un client—que je ne nommerai pas. Le correctif a pris deux jours. Le diagnostic, une heure.
Recommandations CNIL applications mobiles : ce qui change pour vous
La CNIL a publié des recommandations dédiées aux applications mobiles, dans une version consolidée. Elles ne créent pas de nouvelles règles—elles précisent comment appliquer le RGPD dans un contexte mobile, qui a ses spécificités : SDK tiers, identifiants techniques, permissions système, écosystèmes fermés.
Le point qui fait le plus mal : les SDK publicitaires
Un SDK, c'est un bout de code que vous intégrez et que vous ne contrôlez pas. Une régie publicitaire, un outil d'analytics, un service de crash reporting. Chacun d'eux peut lire l'identifiant publicitaire, parfois la position approximative, parfois plus.
Le piège est là : vous êtes responsable de ce que fait le SDK que vous avez choisi d'intégrer. Pas la régie. Vous. C'est contre-intuitif et ça surprend à chaque fois. J'ai passé une semaine à cartographier les SDK d'une app que je maintenais, en croyant en avoir quatre. J'en ai trouvé onze, dont trois ajoutés en dépendance transitive par un autre SDK.
- Un SDK d'analytics qui remonte l'IDFA par défaut.
- Un SDK de push qui conserve les tokens côté serveur sans limite de durée documentée.
- Un SDK "léger" qui appelle en réalité cinq domaines distincts.
- Un SDK de publicité qui initialise le tracking avant même l'affichage de la bannière de consentement.
Ce dernier point est le plus courant. Le consentement est demandé, mais la donnée est déjà partie. Ça ne tient pas.
iOS vs Android : deux mondes, deux contraintes
La confusion la plus fréquente que je rencontre : croire qu'une conformité iOS vaut conformité Android. Les deux systèmes n'imposent pas les mêmes mécanismes, et un éditeur qui ne teste que sur un seul construit une fausse sécurité.
| Point | iOS | Android |
|---|---|---|
| Traçage publicitaire | App Tracking Transparency, opt-in explicite requis | Identifiant publicitaire, reset possible par l'utilisateur |
| Permissions | Déclarées et décrites dans le fichier Info.plist | Déclarées dans le manifeste, demandées à l'exécution |
| Stockage local | Keychain pour les données sensibles | EncryptedSharedPreferences ou équivalent |
| Retrait du consentement | Réglages système + réglages app | Réglages système + réglages app + paramètres par permission |
Le détail qui m'a coûté un client
Sur iOS, l'ATT s'est montré un tournant. Une app qui traçait l'utilisateur sans son accord explicite se faisait retoquer par la revue App Store. Beaucoup d'éditeurs ont donc retravaillé leur flux iOS.
Le problème ? Certains n'ont rien touché côté Android. J'ai perdu un client comme ça, il y a deux ans. Il avait la certitude d'être conforme parce que son app iOS était passée. Son app Android envoyait toujours l'identifiant publicitaire avant consentement. On l'a su lors d'un audit interne déclenché par une plainte utilisateur. Je n'ai pas gardé le contrat. Et honnêtement, il avait partiellement raison de m'en vouloir : j'aurais dû vérifier les deux plateformes dès le premier jour.
Politique de confidentialité et mentions légales : ne pas confondre
Deux documents. Deux rôles. Deux obligations distinctes. Et pourtant, une bonne moitié des apps que j'audite affichent l'un en croyant avoir rempli l'autre.
Les mentions légales application mobile identifient l'éditeur : raison sociale, contact, hébergeur. C'est une obligation issue du droit français, pas du RGPD. La politique de confidentialité application mobile, elle, décrit le traitement des données : finalités, base légale, durées, destinataires, droits.
Ce qu'une politique de confidentialité doit contenir
- L'identité et les coordonnées du responsable de traitement.
- La liste des finalités, chacune rattachée à une base légale.
- Les catégories de destinataires—pas des noms, mais des catégories. Si un SDK transmet à une régie hors UE, ça doit figurer.
- Les durées de conservation, même approximatives mais justifiées.
- L'existence des droits d'accès, de rectification, d'effacement, d'opposition, de portabilité, et la façon de les exercer.
- La logique du profilage publicitaire, si profilage il y a.
Et un point qu'on oublie systématiquement : la politique doit être accessible depuis l'app elle-même, en deux clics maximum, sans passer par un navigateur externe. J'ai vu une app qui exigeait de créer un compte pour consulter sa politique. Absurde.
Gestion des données personnelles : le cycle qui fait la différence
Une donnée personnelle traverse quatre états : collecte, stockage, transmission, suppression. La conformité se joue sur les quatre. Pas seulement sur le premier.
La suppression, le parent pauvre
Quand un utilisateur désinstalle l'app, que se passe-t-il ? Techniquement : rien, la plupart du temps. Les données restent côté serveur, souvent indéfiniment, sans que personne ne s'en occupe. J'ai eu un cas où une base contenait encore des comptes supprimés depuis quatre ans. Personne dans l'équipe ne savait pourquoi.
Un plan de gestion des données personnelles doit donc prévoir :
- Une procédure de suppression sur demande, testée (pas seulement écrite).
- Une purge automatique selon les durées annoncées dans la politique de confidentialité.
- Une vérification que les sous-traitants suppriment aussi—un SDK ne conserve pas après la demande d'effacement.
- Un journal des suppressions, pour pouvoir prouver qu'elles ont eu lieu.
Ce dernier point, c'est ce qui distingue un éditeur qui dit être conforme d'un éditeur qui peut le prouver. En cas de contrôle, la bonne foi ne suffit pas.
Faut-il vraiment se préoccuper des sanctions ?
Question qu'on me pose souvent, avec un soupçon d'espoir. La réponse honnête : les grosses amendes tombent rarement sur les petites apps. Mais—et c'est là que je ne rassure personne—la première conséquence d'une non-conformité n'est pas financière. C'est la perte de confiance utilisateur, un rejet à la revue d'app store, ou une plainte individuelle qui coûte cher en temps.
Se rassurer en se disant "on est trop petits pour être contrôlés" est une stratégie. Je ne la recommande pas. Pas par peur de l'amende : parce que le jour où un utilisateur découvre que l'app a transmis sa position à un tiers sans base légale, le problème n'est plus juridique. Il devient commercial.
Le vrai enjeu de la protection des données sur mobile n'est pas de cocher des cases. C'est de savoir, à tout moment, quelle donnée circule où. Si vous ne pouvez pas répondre à cette question sur votre propre app, aucune politique de confidentialité, aussi bien rédigée soit-elle, ne vous sauvera.
