RGPD et applications mobiles : ce que vous devez savoir

Toute application qui collecte des données personnelles en Europe doit respecter le RGPD. Ce n'est pas qu'une contrainte juridique : c'est un gage de confiance pour vos utilisateurs. Voici l'essentiel, en clair. (Cet article est informatif et ne remplace pas un conseil juridique.)

Quelles données collectez-vous ?

Nom, email, localisation, comportement dans l'app… La première étape est de cartographier les données que vous collectez et de vous demander, pour chacune : en ai-je vraiment besoin ? Le principe est la minimisation.

Le consentement

L'utilisateur doit donner un consentement libre, éclairé et explicite avant toute collecte non essentielle. Fini les cases pré-cochées : le consentement doit être un choix actif.

Les droits des utilisateurs

• Accès : pouvoir consulter ses données.
• Rectification : pouvoir les corriger.
• Suppression : pouvoir supprimer son compte et ses données.
• Portabilité : pouvoir les récupérer.

Bonnes pratiques techniques

• Chiffrement des données sensibles.
• Politique de confidentialité claire et accessible.
• Suppression effective des données sur demande.

La conformité n'est pas un frein : une app qui respecte les données inspire davantage confiance, et la confiance fait revenir.

Le dossier à réunir avant la première publication

La conformité se matérialise par un petit nombre de pièces, que les magasins d'applications réclament de toute façon au moment du dépôt. La première est une politique de confidentialité accessible par une adresse web publique, en dehors de l'application : elle doit nommer le responsable de traitement, la nature des données, la finalité de chaque collecte, la durée de conservation et la façon d'exercer ses droits. La deuxième est la déclaration de collecte demandée par Apple et par Google dans la fiche du magasin, qui doit correspondre exactement à ce que fait le code : une incohérence entre les deux est un motif de rejet classique, et un motif de plainte encore plus classique.

Viennent ensuite trois documents internes que personne ne voit mais qui font foi en cas de contrôle : le registre des traitements, la liste des sous-traitants avec le contrat qui les encadre, hébergeur et outil de mesure d'audience compris, et la procédure de réponse aux demandes d'accès ou de suppression, à traiter dans le mois. Enfin, si votre application permet de créer un compte, elle doit permettre de le supprimer depuis l'application elle-même : c'est une exigence des magasins autant qu'une lecture directe du droit à l'effacement. Renvoyer l'utilisateur vers un formulaire de contact ne suffit plus.

Consentement et autorisations : deux choses différentes

La confusion la plus fréquente consiste à croire que l'autorisation demandée par le téléphone vaut consentement au sens du règlement. Ce sont deux mécanismes distincts. L'autorisation système ouvre un accès technique, à la position, à l'appareil photo, aux contacts ou à l'envoi de notifications push. Le consentement, lui, porte sur une finalité et doit être libre, spécifique, éclairé et révocable aussi simplement qu'il a été donné. Une application peut donc parfaitement avoir l'autorisation d'accéder à la position tout en n'ayant aucun droit de l'exploiter à des fins publicitaires.

Deux conséquences pratiques en découlent. D'abord, l'écran qui demande le consentement doit proposer un refus aussi visible que l'acceptation, sans case pré-cochée ni bouton grisé. Ensuite, tout ce qui n'est pas strictement nécessaire au service doit rester inactif tant que la réponse n'est pas donnée, mesure d'audience comprise. Si votre application intègre des fonctions d'intelligence artificielle, ajoutez la question de la transparence, désormais encadrée : nous la traitons dans notre article sur les obligations de transparence applicables aux contenus produits par une IA.

Ce qui déclenche réellement un problème

Dans la pratique, les difficultés ne viennent presque jamais d'un contrôle spontané. Elles viennent de trois situations. Un utilisateur demande la suppression de son compte et n'obtient pas de réponse dans le mois : la plainte qui suit est simple à déposer et simple à instruire. Une faille expose des données, et l'obligation de notification sous soixante-douze heures s'applique, avec une information des personnes concernées si le risque est élevé : les exigences techniques à poser à vos prestataires sont détaillées dans notre article sur la sécurité à exiger de ses fournisseurs. Enfin, un outil tiers ajouté après coup, régie publicitaire ou service de mesure, collecte davantage que ce que la fiche du magasin annonce.

C'est pourquoi la conformité se traite au moment du cadrage du projet et non à la veille du dépôt. Prévoir dès le départ la suppression de compte, la révocation du consentement, le chiffrement des données sensibles et la liste des sous-traitants coûte quelques heures de développement. Les reprendre après une mise en ligne oblige à toucher au modèle de données, ce qui est toujours le chantier le plus cher, et retarde d'autant la publication sur les magasins.

En résumé

Le RGPD se pense dès la conception (« privacy by design »), pas après coup. C'est notre approche pour chaque projet. Parlons de votre application.