RGPD et application mobile : ce qu'il faut prévoir

Pour qu’une application mobile respecte le RGPD, il faut savoir précisément quelles données elle collecte et pourquoi, n’en garder que le nécessaire, informer clairement l’utilisateur et lui demander son accord pour tout ce qui ne sert pas directement au service. S’y ajoutent les exigences des stores : déclarer ses pratiques sur la fiche de l’application et permettre de supprimer son compte. Tout cela se prépare dès la conception, bien plus facilement qu’après la sortie.

Le RGPD s’applique-t-il à votre application ?

Presque toujours. Le RGPD concerne toute donnée qui permet d’identifier une personne, directement ou non. Dans une application, cela va bien au-delà du nom et de l’adresse e-mail :

• un identifiant de compte ou d’appareil ;
• la localisation, même approximative si elle est liée à une personne ;
• les photos, les contacts, les messages ;
• les données de santé, de sport ou de sommeil ;
• l’historique d’utilisation rattaché à un compte.

La CNIL rappelle d’ailleurs que les identifiants générés par le système d’exploitation, comme l’identifiant d’appareil sur iPhone, entrent dans la notion de traceur. Une application sans compte n’échappe donc pas forcément au RGPD.

La CNIL a publié des recommandations dédiées aux applications mobiles, qui s’adressent aux éditeurs, aux développeurs et aux fournisseurs de SDK. C’est la référence à garder sous la main.

Faire la liste des données dès le cahier des charges

La conformité commence par un tableau simple, à remplir pendant la rédaction du cahier des charges. Pour chaque donnée, posez quatre questions.

Donnée	Pourquoi on la collecte	Où elle est stockée	Combien de temps
Adresse e-mail	Connexion au compte	Serveur, Europe	Tant que le compte existe
Position	Afficher les magasins proches	Sur le téléphone seulement	Le temps de la recherche
Photo du ticket	Remboursement d’une note de frais	Serveur, Europe	Durée légale de conservation des justificatifs
Jeton de notification	Envoyer les rappels	Serveur	Jusqu’à désinstallation ou déconnexion

Ce tableau sert de base au registre des traitements prévu par l’article 30 du RGPD. L’exception prévue pour les petites structures est étroite : elle ne joue pas, par exemple, quand le traitement est régulier, ce qui est le cas de la plupart des applications. Mieux vaut le tenir dès le départ.

Minimiser : la donnée la plus sûre est celle qu’on ne collecte pas

Le principe de minimisation est au cœur du RGPD, et une application offre beaucoup de moyens de l’appliquer :

• La localisation approximative. iOS et Android permettent de demander une position approximative plutôt que précise. Pour afficher la météo ou les commerces d’une ville, elle suffit largement.
• Le sélecteur de photos. Les deux systèmes proposent un sélecteur qui donne accès aux seules photos choisies par l’utilisateur, sans ouvrir toute la galerie.
• Le compte facultatif. Si l’application peut fonctionner sans inscription, ne l’imposez pas. Un compte devient utile pour synchroniser plusieurs appareils ou partager des données.
• Le traitement sur le téléphone. Un calcul, une conversion ou une reconnaissance simple peuvent souvent se faire sur l’appareil, sans que rien ne parte vers un serveur.

Chaque donnée que vous ne collectez pas est une donnée que vous n’aurez ni à protéger, ni à déclarer, ni à supprimer.

Permissions et consentement : deux choses différentes

Quand une application affiche « Autoriser l’accès à votre position ? », il s’agit d’une permission technique du système. Elle ne vaut pas, à elle seule, consentement au sens du RGPD. La CNIL distingue clairement les deux dans ses recommandations.

En pratique :

• Les données nécessaires au service demandé (la position pour un itinéraire, l’appareil photo pour scanner un document) n’ont pas besoin d’un consentement séparé, mais l’utilisateur doit être informé de leur usage.
• Les données non nécessaires, comme celles qui servent au ciblage publicitaire, demandent un consentement libre, éclairé, et aussi facile à refuser ou à retirer qu’à donner.
• Sur iPhone, suivre l’utilisateur d’une application à l’autre exige en plus l’autorisation demandée par le cadre « App Tracking Transparency » d’Apple, décrit dans ses règles sur la confidentialité et l’usage des données.

Demandez chaque permission au moment où elle sert, avec une phrase qui explique pourquoi. La même logique vaut pour les notifications push : un utilisateur qui comprend la raison accepte plus volontiers.

Les SDK tiers : ce que vous intégrez, vous en répondez

Une application embarque souvent des briques fournies par d’autres : mesure d’audience, suivi des plantages, publicité, connexion avec un réseau social, cartographie. Chacune peut collecter des données, parfois dès le lancement de l’application.

Pour chaque SDK, vérifiez :

• quelles données il collecte, et s’il les réutilise pour son propre compte ;
• s’il peut être configuré pour collecter moins (désactiver l’identifiant publicitaire, anonymiser) ;
• s’il ne se lance qu’après le consentement quand il en a besoin.

Les stores vous tiennent responsable de ces briques. Apple demande de déclarer les données collectées par l’application et par les partenaires tiers dont le code y est intégré, et Google Play fait de même dans sa section Sécurité des données.

Ce que l’App Store et Google Play exigent

Au-delà du RGPD, les deux stores ont leurs propres règles, vérifiées à chaque publication.

Une politique de confidentialité. Un lien vers une page qui explique ce que fait l’application des données est demandé sur les deux stores. Elle doit correspondre à la réalité de l’application.

La déclaration des données sur la fiche. Sur l’App Store, ce sont les informations de confidentialité affichées sur la page de l’application. Sur Google Play, c’est la section Sécurité des données. Toute donnée collectée doit y figurer, même si elle ne sert qu’au fonctionnement.

La suppression de compte. Si l’application permet de créer un compte, Apple exige qu’on puisse lancer la suppression du compte depuis l’application, et pas seulement le désactiver. Google Play demande un chemin dans l’application et un lien web pour demander la suppression du compte et des données associées.

Nous revenons sur le parcours de validation dans notre article sur la publication sur l’App Store.

Sécurité, conservation et droits des utilisateurs

Protéger les données

Les échanges entre l’application et le serveur doivent être chiffrés. Les clés d’accès aux services (paiement, intelligence artificielle, base de données) restent sur le serveur, jamais dans le code de l’application, où elles peuvent être extraites. Les droits se vérifient côté serveur : un utilisateur ne doit pouvoir lire que ses propres données, quoi que l’application envoie.

Fixer des durées de conservation

Chaque donnée a une durée de vie. Un compte inactif depuis longtemps peut être supprimé après un message de prévenance, des journaux techniques n’ont pas besoin d’être gardés indéfiniment. Ces durées figurent dans la politique de confidentialité.

Répondre aux demandes

Les utilisateurs peuvent demander l’accès à leurs données, leur correction, leur suppression ou leur récupération dans un format lisible. Le RGPD prévoit une réponse dans un délai d’un mois en principe. Un bouton de suppression et un export prévus dans l’application évitent de traiter ces demandes à la main.

Réagir en cas de fuite

En cas de violation de données présentant un risque pour les personnes, le RGPD impose de la notifier à la CNIL dans les 72 heures après en avoir pris connaissance, et d’informer les personnes concernées si le risque est élevé. Avoir des journaux et savoir qui contacter fait gagner un temps précieux ce jour-là.

Questions fréquentes

Une application sans compte est-elle concernée par le RGPD ?

Souvent, oui. Dès qu’elle collecte une position, un identifiant d’appareil ou utilise un SDK de mesure d’audience ou de publicité, elle traite des données personnelles. Une application qui fonctionne entièrement sur le téléphone, sans rien envoyer, est en revanche très peu exposée.

Peut-on mesurer l’audience d’une application sans consentement ?

Oui, sous conditions. La CNIL admet une exemption pour la mesure d’audience strictement limitée aux statistiques anonymes, faite pour le seul compte de l’éditeur, sans recoupement avec d’autres données ni suivi d’une application à l’autre. Un outil qui réutilise les données pour son propre compte sort de cette exemption.

Faut-il nommer un délégué à la protection des données ?

Ce n’est obligatoire que dans certains cas : organismes publics, suivi régulier et systématique de personnes à grande échelle, ou traitement à grande échelle de données sensibles comme la santé. Pour la plupart des applications de PME, ce n’est pas requis, mais il faut quelqu’un qui connaisse le sujet.

Peut-on héberger les données hors de l’Union européenne ?

Ce n’est pas interdit, mais les transferts hors de l’Union sont encadrés et doivent être justifiés. Un hébergement en Europe simplifie la conformité et rassure les utilisateurs comme les entreprises clientes.

Nous prévoyons ces points dès la maquette, pour qu’ils ne deviennent pas un chantier après coup. Si vous préparez une application, notre page applications mobiles présente notre façon de faire, et vous pouvez nous parler de votre projet.