RGPD et app mobile : obligations spécifiques à connaître

L'année dernière, j'ai audité une app de covoiturage. Elle demandait l'accès au carnet de contacts "pour inviter des amis". En regardant le code, j'ai découvert qu'elle copiait l'intégralité des contacts — noms, numéros, emails — sur les serveurs de la startup. Le fondateur ne le savait pas. Son développeur avait implémenté ça "parce que c'était dans le template".

Si vous avez une application mobile, les obligations de conformité RGPD sont les mêmes que pour un site web. Mais les pièges sont radicalement différents. Permissions, SDK tiers, push notifications, analytics — voici ce que je retrouve systématiquement quand j'audite des apps mobiles.

Le RGPD s'applique à votre app mobile, mais pas comme sur le web

Le réflexe de la plupart des fondateurs, c'est de penser RGPD = cookies = bandeau de consentement. Sur un site web, c'est le point de départ. Sur une app mobile native, il n'y a généralement pas de cookies.

Pas de cookies ne veut pas dire pas de collecte de données.

Sur mobile, la collecte passe par d'autres canaux : les permissions système (localisation, contacts, micro), les SDK tiers intégrés dans votre app (analytics, crash reporting, pub), et les identifiants publicitaires (IDFA sur iOS, GAID sur Android). Chacun de ces canaux constitue un traitement de données personnelles au sens du RGPD.

J'ai audité une startup qui avait un site web impeccable côté conformité. Bandeau cookies propre, politique de confidentialité détaillée, consentement granulaire. Leur app mobile ? Les mêmes traceurs étaient actifs par défaut. Zéro consentement demandé. Zéro information dans la politique de confidentialité de l'app. Le fondateur pensait que la conformité du site couvrait l'ensemble.

Elle ne couvre rien du tout. L'app mobile est un traitement distinct, avec ses propres vecteurs de collecte et ses propres risques. Si vous n'êtes pas au clair sur les 6 obligations RGPD de base, commencez par là avant de lire la suite.

Les permissions mobiles : le piège le plus visible

Chaque permission que votre app demande donne accès à des données personnelles. Localisation = donnée personnelle. Contacts = données personnelles. Appareil photo, micro, stockage = accès potentiel à des données personnelles.

Le RGPD impose le principe de minimisation : ne collecter que les données strictement nécessaires à la finalité déclarée. Si votre app de recettes demande l'accès à la localisation, vous avez un problème.

Revenons à mon app de covoiturage. L'accès aux contacts était justifié par la fonctionnalité "inviter un ami". Sauf que la fonctionnalité n'avait besoin que du numéro de téléphone saisi manuellement par l'utilisateur — pas d'un dump complet du carnet d'adresses. L'implémentation allait bien au-delà de la finalité. C'est un manquement caractérisé au principe de minimisation.

Ce que je vérifie en audit pour chaque permission

• La permission est-elle nécessaire à une fonctionnalité réelle ? Une app de livraison a besoin de la localisation. Une app de notes, non.
• L'implémentation respecte-t-elle la finalité ? Demander la localisation pour afficher un point sur une carte, OK. Stocker l'historique complet des déplacements, c'est un autre traitement — avec sa propre base légale.
• La permission est-elle documentée dans le registre des traitements ? Si elle n'apparaît pas dans votre registre, elle n'existe pas aux yeux de la CNIL.

Cas concret : j'ai audité une app de livraison qui stockait 6 mois d'historique de géolocalisation. Pas pour la livraison en cours — ça, ça se justifie. Pour "des analyses futures". Aucune base légale, aucune durée de conservation définie, aucune mention dans la politique de confidentialité. Le fondateur a découvert ça pendant l'audit.

SDK tiers : ce que votre app collecte sans que vous le sachiez

C'est le point qui surprend le plus les fondateurs.

Quand votre développeur — ou votre outil no-code — construit une app mobile, il utilise un framework : React Native, Flutter, Swift, Kotlin. La plupart des templates de départ intègrent des SDK tiers par défaut. Firebase Analytics pour les stats, Crashlytics pour les rapports de crash, parfois le Facebook SDK pour l'attribution marketing.

Ces SDK collectent des données dès qu'ils sont intégrés. Avant même que vous écriviez une ligne de code métier.

Le cas le plus fréquent dans mes audits : une app React Native dont le boilerplate initial intégrait Firebase Analytics et Crashlytics. L'app envoyait des données de comportement utilisateur — pages vues, durée de session, type d'appareil, version d'OS — aux serveurs Google, hébergés aux États-Unis. Le fondateur n'avait jamais configuré ces outils. Il ne savait même pas qu'ils étaient actifs.

Côté RGPD, ça donne :

• Transfert de données hors UE non encadré
• Traitements non déclarés dans le registre
• Absence de consentement pour le tracking
• Politique de confidentialité muette sur Google et Firebase

Quatre manquements. Un seul SDK. Intégré par défaut.

Et vous êtes responsable. Le RGPD ne fait pas de distinction : en tant qu'éditeur de l'app, vous êtes responsable de traitement pour toutes les données collectées, y compris par les bibliothèques tierces que vous avez intégrées — même sans le vouloir. La CNIL a sanctionné à plusieurs reprises des éditeurs d'apps pour des collectes effectuées par des SDK qu'ils n'avaient pas configurés eux-mêmes.

Push notifications et analytics : deux traitements que tout le monde oublie

Les push notifications, tout le monde en envoie. Peu de fondateurs réalisent que c'est un traitement de données personnelles.

Si vos push sont identiques pour tous vos utilisateurs — mise à jour de l'app, maintenance prévue — le sujet est simple. Mais dès que vous ciblez — "les utilisateurs qui n'ont pas ouvert l'app depuis 7 jours", "ceux qui ont abandonné un panier" — vous faites du profilage comportemental. C'est un traitement qui nécessite une base légale, une information claire à l'utilisateur, et une ligne dans votre registre.

Un fondateur m'a dit : "Les push, c'est juste des notifs, c'est pas des données." Si. Le token push est lié à un utilisateur identifié. Le ciblage comportemental repose sur l'analyse de ses actions dans l'app. C'est du traitement de données personnelles, point.

Pour les analytics, même raisonnement. Mesurer le comportement de vos utilisateurs dans l'app — et vous le faites probablement, ne serait-ce que via Firebase — c'est un traitement. Si votre outil d'analytics transmet des données à un serveur hors UE sans base légale, vous ajoutez un problème de transfert international.

Apple et Google : le deuxième régulateur

Depuis iOS 14.5, Apple impose l'App Tracking Transparency (ATT). Si votre app collecte des données à des fins de suivi publicitaire, vous devez afficher un popup de consentement natif. L'utilisateur refuse ? Vous n'avez plus accès à l'IDFA. Et Apple vérifie — si vous contournez, votre app est rejetée du store.

Google a suivi avec la Data Safety Section sur le Play Store. Vous devez déclarer toutes les données collectées par votre app, y compris par les SDK tiers. Oublier un SDK = rejet lors de la review.

Les stores deviennent un second régulateur. Parfois plus strict que la CNIL. La CNIL met des mois à sanctionner. Apple rejette votre app en 48 heures.

Pour un fondateur, c'est une bonne nouvelle déguisée. Si vous êtes conforme aux exigences d'Apple et Google, vous êtes déjà aux deux tiers du chemin côté RGPD mobile. L'inverse n'est pas vrai.

Checklist conformité RGPD pour votre app mobile

Voici les 8 points que je vérifie systématiquement quand j'audite une app mobile. Si vous ne savez pas répondre à l'un d'entre eux, il y a un trou dans votre conformité.

1. Inventaire des permissions — Listez chaque permission demandée par votre app. Pour chacune : pourquoi elle est nécessaire, quelle fonctionnalité l'utilise, si l'implémentation respecte la finalité déclarée.

2. Inventaire des SDK tiers — Listez chaque SDK intégré. Pour chacun : quelles données il collecte, où elles sont envoyées (UE ou hors UE), si un DPA est signé avec l'éditeur.

3. Base légale par traitement — Chaque collecte (permission, SDK, analytics, push) doit avoir une base légale documentée : consentement, intérêt légitime ou exécution du contrat.

4. Consentement pour le tracking — Si votre app utilise des identifiants publicitaires ou des SDK de tracking, le consentement doit être recueilli avant l'activation. Pas après.

5. Politique de confidentialité dans l'app — Pas seulement sur votre site web. L'app doit avoir un lien vers une politique de confidentialité à jour, qui mentionne spécifiquement les traitements liés au mobile.

6. Conformité stores — App Tracking Transparency (iOS), Data Safety Section (Android). Ce que vous déclarez doit correspondre à ce que vos SDK font réellement.

7. Push notifications documentées — Si vous envoyez des push ciblées, c'est un traitement qui doit figurer dans votre registre avec sa base légale.

8. Durées de conservation — Les données collectées sur mobile (historique de localisation, logs de comportement, tokens push) doivent avoir des durées de conservation définies et appliquées.

Pour les actions prioritaires au-delà du mobile, j'ai écrit un guide des 5 actions RGPD urgentes pour les fondateurs pressés.

Ce que ça change concrètement

Le RGPD sur mobile, ce n'est pas un RGPD différent. Ce sont les mêmes obligations, avec des vecteurs de collecte que le fondateur ne voit pas.

Sur un site web, vous voyez vos cookies. Sur une app mobile, vos SDK collectent des données sans que vous ayez touché un seul réglage. Votre développeur ajoute Firebase pour un crash report, et vous vous retrouvez avec un transfert de données hors UE non documenté.

Une fois l'inventaire fait, la mise en conformité n'est pas si lourde. C'est l'inventaire qui est la partie difficile — et c'est exactement ce qu'un audit RGPD technique produit : la liste exhaustive de ce que votre app collecte réellement, vérifiée dans le code source.

Si vous avez un doute sur ce que votre app collecte, ne demandez pas à votre développeur — il ne le sait probablement pas lui-même. Faites analyser le code.