Sécurité et données personnelles dans l'app : RGPD, UK GDPR
Où les données d'une app doivent vivre, quelles autorisations sont vraiment nécessaires et ce qu'exigent les fiches de confidentialité selon le RGPD.
Équipe rabbitclipPublié: 7 min de lecture
En bref
La sécurité d'une app commence par collecter le moins de données possible ; une donnée jamais collectée ne peut jamais fuiter. Une application décide d'abord quelle donnée est réellement nécessaire, puis règle où et comment cette donnée est stockée, quelles autorisations elle demande, et comment tout cela est déclaré dans la fiche de confidentialité du store.
Depuis le milieu des années 2020, Apple et Google exigent tous deux une fiche de confidentialité de chaque application, App Privacy Details côté Apple, Data safety côté Google Play ; si cette fiche ne correspond pas à ce que l'application collecte réellement, le risque est un rejet en revue ou un retrait ultérieur. Le RGPD et, au Royaume-Uni, l'UK GDPR fixent chacun, dans son propre cadre juridique, quelles données peuvent être traitées et dans quel but.
Cet article couvre où les données doivent vivre, quelles autorisations sont réellement nécessaires, ce qu'exigent les fiches de confidentialité des stores, ce que demandent le RGPD et ses obligations, le chiffrement et la sécurité des sessions, et une checklist de sécurité étape par étape pour conclure.
Où les données doivent vivre : sur l'appareil ou sur le serveur
Le stockage sur l'appareil signifie qu'une information comme un nom d'utilisateur ou un jeton de session se trouve dans le coffre sécurisé propre du téléphone, Keychain côté Apple, Keystore côté Android ; cette donnée reste hors de portée même si la personne perd son téléphone, sauf si le verrouillage d'écran lui-même est cassé. Un jeton de session écrit en clair dans un fichier texte ou une zone de préférences partagées ne bénéficie d'aucune de ces protections.
Pour les données côté serveur, la vraie question est de savoir où elles sont physiquement hébergées ; si les données des résidents d'une application de gestion d'immeuble se trouvent sur un serveur basé en France, les règles de transfert du RGPD vers des pays tiers n'entrent pas en jeu, mais déplacer ces mêmes données vers un serveur situé hors de l'UE exige une base juridique séparée pour ce transfert.
Une application doit décider en amont quelles données peuvent rester sur l'appareil et lesquelles doivent absolument remonter vers un serveur ; une donnée déplacée vers un serveur sans nécessité ajoute à la fois un risque de transfert et une responsabilité de stockage.
Autorisations : laquelle est réellement nécessaire
Une autorisation ne se justifie que si elle sert une fonctionnalité réellement utilisée à ce moment ; l'accès à la localisation est nécessaire pour suivre un livreur dans une application de livraison, tandis que la même autorisation ne sert aucune fonction dans une application de lecture d'e-books. Demander une autorisation inutile abîme la confiance de la personne dès le départ et peut entraîner une demande de justification en revue du store.
L'accès à la localisation doit être traité différemment selon qu'il s'agit de «pendant l'utilisation de l'app» ou de «toujours» ; en dehors d'une application de suivi de livraison en direct, la plupart des applications n'ont pas besoin de l'option «toujours», la demander à la fois inquiète la personne et attire un examen supplémentaire en revue.
Les autorisations sensibles comme l'appareil photo, le micro ou les contacts doivent être demandées uniquement au moment où la fonctionnalité concernée est touchée ; demander toutes les autorisations à la suite au premier lancement pousse les personnes à en refuser la plupart.
Ce qu'exigent les fiches de confidentialité des stores
App Privacy Details d'Apple et Data safety de Google Play sont des formulaires de déclaration qui rendent visible, directement sur la fiche store, quelle catégorie de donnée une application collecte et à quoi elle sert. Le formulaire repose sur la déclaration du développeur lui-même, mais si cette déclaration ne correspond pas au comportement réel de l'application, Apple comme Google la traitent comme une infraction aux règles.
Quand une bibliothèque d'analytique ou de publicité tierce est ajoutée à une application, tout ce que cette bibliothèque collecte doit aussi figurer dans la déclaration ; un développeur qui ne signale que ce que collecte son propre code et omet la bibliothèque laisse la déclaration incomplète.
Ces fiches doivent être revues à chaque mise à jour de version ; si une nouvelle fonctionnalité collecte une nouvelle catégorie de donnée, la fiche doit refléter ce changement.
Ce qu'exigent le RGPD et l'UK GDPR
Le RGPD exige que le traitement des données personnelles soit justifié par un consentement explicite ou une autre base légale prévue par la loi, pour une finalité clairement énoncée ; si une application collecte des données auprès d'une personne, la finalité de leur usage doit être clairement écrite dans la politique de confidentialité. Transférer ces données vers un serveur hébergé hors de l'UE, un service cloud basé dans un pays tiers par exemple, nécessite une base juridique distincte et doit remplir des conditions fixées par le cadre du RGPD.
Au Royaume-Uni, l'UK GDPR applique des principes similaires, minimisation des données, limitation de la finalité, consentement explicite, via un régulateur différent, l'ICO ; une application qui sert des personnes à la fois en France et au Royaume-Uni a besoin d'une politique de confidentialité qui satisfasse les deux cadres, un texte générique unique peut laisser les deux incomplets.
Le droit d'une personne à demander la suppression de ses données est un droit dans les deux cadres ; une application a besoin d'une véritable voie pour honorer cette demande, suppression de compte, formulaire de demande de données, et se reposer uniquement sur l'e-mail cesse d'être tenable à mesure que la base d'utilisateurs grandit.
Chiffrement et sécurité des sessions
Chaque connexion entre une application et son serveur doit être chiffrée, HTTPS sur TLS ; un mot de passe ou une donnée de paiement envoyé sur une connexion non chiffrée peut être lu par un autre appareil sur le même réseau. Ce n'est plus une question de préférence, c'est une exigence minimale à la fois selon la règle App Transport Security d'Apple et selon la pratique de sécurité de base.
Faire expirer un jeton de session après une durée fixée et prendre en charge le verrouillage biométrique, empreinte, reconnaissance faciale, empêche des données sensibles de rester longtemps accessibles sur un téléphone perdu ou volé. Dans une application d'approvisionnement B2B, une session qui n'expire jamais met en danger les données de l'entreprise dès qu'un employé perd son téléphone.
Étape par étape : une checklist de sécurité
Voici la checklist minimale qu'une application devrait passer avant sa mise en ligne.
- Pour chaque champ de donnée collecté, se demander s'il est réellement nécessaire, et retirer ce qui ne l'est pas
- Stocker les données sensibles dans le coffre sécurisé de l'appareil (Keychain/Keystore), pas dans un fichier texte en clair
- Demander chaque autorisation seulement au moment où la fonctionnalité concernée est touchée, pas toutes d'un coup au lancement
- Faire correspondre la fiche de confidentialité du store, bibliothèques tierces incluses, au flux réel des données
- Vérifier la politique de confidentialité séparément au regard du RGPD et du cadre local du marché cible, comme l'UK GDPR
- Construire une voie in-app pour traiter les demandes de suppression, ne pas se reposer uniquement sur l'e-mail
La sécurité d'une application se construit en collectant le moins de données possible, en stockant correctement ce qui reste, et en le déclarant avec précision dans la fiche du store et la politique de confidentialité. Lors d'un appel découverte avec rabbitclip, le flux de données existant est examiné et les écarts par rapport au RGPD et au cadre local du marché cible sont identifiés ensemble.
Questions fréquentes
Que se passe-t-il si une fiche de confidentialité de store est mal remplie ?
Si la déclaration ne correspond pas au comportement réel, Apple et Google la traitent comme une infraction ; l'application peut être rejetée ou retirée plus tard.
L'accès à la localisation peut-il toujours être demandé en «toujours autoriser» ?
Seulement quand une fonctionnalité a réellement besoin d'un suivi continu, comme le suivi en direct d'un livreur ; la plupart des applications n'ont besoin que de «pendant l'utilisation».
Une seule politique de confidentialité peut-elle satisfaire à la fois le RGPD et l'UK GDPR ?
Un texte générique peut laisser les deux incomplets ; les exigences de chaque cadre doivent être vérifiées séparément.
Pourquoi l'endroit où les données sont hébergées compte-t-il ?
Le pays où les données sont hébergées détermine si les règles du RGPD sur les transferts hors UE s'appliquent ; un transfert hors UE exige une base juridique distincte.
