Comment protéger les données personnelles des utilisateurs d'une appli mobile

Un développeur m'a envoyé un mail l'an dernier, paniqué. Sa petite appli de suivi sportif avait été épinglée par un utilisateur qui avait découvert que l'écran de consentement ne proposait qu'un seul bouton : "Tout accepter". Pas de refus possible. Pas de choix par finalité. Le type avait copié la bannière d'un modèle trouvé en ligne, sans se poser plus de questions. Résultat : une plainte, un audit interne, et trois mois de refonte pour rattraper ce qui aurait pris trois jours à faire correctement au départ.

Ce genre d'histoire, j'en ai vu défiler une dizaine. Des apps qui collectent tout, tout le temps, "au cas où", sans jamais se demander si c'était nécessaire. Et le vrai problème, ce n'est pas la loi. C'est ce qu'on en fait. Protéger les données personnelles des utilisateurs d'une appli mobile, ce n'est pas cocher une case sur un formulaire : c'est une décision de conception, prise au moment où vous dessinez le premier écran.

Ce qui suit, c'est comment je m'y prends aujourd'hui, après m'être planté, et ce que j'ai fini par retenir.

Pourquoi les données personnelles d'une appli mobile sont un terrain plus glissant qu'un site web

Sur un site, vous avez une adresse IP, des cookies, un parcours. Sur une appli, vous avez un identifiant publicitaire qui suit la personne de jeu en jeu, un accès au carnet de contacts si elle l'autorise, la géolocalisation en arrière-plan, le Bluetooth, la bibliothèque photo, parfois le micro. Chaque autorisation ouvre une porte. Et la plupart des développeurs que je croise ne savent même pas combien de portes ils ont ouvertes.

Je l'ai appris à mes dépens. Sur une appli de covoiturage que j'accompagnais en 2023, on avait intégré un SDK analytics "pour mesurer les conversions". Sauf que ce SDK collectait aussi les identifiants des réseaux Wi-Fi à proximité. Personne ne l'avait lu dans sa doc. On l'a découvert en préparant le registre des traitements. Vingt lignes de code retirées, mais une vingtaine de tests à refaire derrière.

Ce que la CNIL regarde vraiment dans une appli

Depuis la publication de ses recommandations sur les applications mobiles, la CNIL a resserré sa grille. Il y a quelques années, un éditeur pouvait à peu près tout collecter tant que la politique de confidentialité le mentionnait quelque part. Aujourd'hui, la question posée est plus dure : ce que vous collectez sert-il réellement à faire fonctionner l'appli ? Si la réponse est non, il faut pouvoir l'expliquer au moment où quelqu'un enclenche un contrôle.

Concrètement, les points sur lesquels j'ai vu le plus de retours négatifs :

• le consentement noyé dans une seule case, sans granularité par finalité ;
• des durées de conservation jamais définies, donc infinies par défaut ;
• des SDK publicitaires qui remontent les données avant même que l'utilisateur ait vu l'écran de consentement ;
• et cette manie de tout garder "pour améliorer l'expérience", sans jamais pouvoir détailler ce que ça veut dire.

Rien de tout cela n'est exotique. C'est l'état par défaut d'une appli sur deux.

Mettre son appli en conformité : la méthode que j'applique

Personne ne m'a jamais demandé "comment respecter le RGPD" ; tout le monde me demande "par où commencer". Et honnêtement, la première fois que j'ai ouvert un registre des traitements, j'étais perdu. Je vais vous éviter ça.

Commencez par la cartographie, pas par la politique

Avant d'écrire une seule ligne de texte dans votre politique de confidentialité, listez tout ce que votre appli collecte. Vraiment tout. Pour chacune des données, notez :

1. d'où elle vient (l'utilisateur, l'appareil, un SDK tiers) ;
2. à quoi elle sert, en une phrase claire ;
3. combien de temps vous la gardez ;
4. qui la reçoit en dehors de vous.

Cette liste, c'est votre cartographie. Elle prend une demi-journée. Elle vous servira ensuite pour le registre officiel, et surtout pour repérer les collectes que vous ne justifiez pas. Un indicateur de vitesse de connexion conservé 24 mois ? Vous n'en avez pas besoin. Virez.

Le consentement granulaire, ou la vraie difficulté

Un consentement, pour être valable, doit être libre, spécifique, éclairé et univoque. "Libre", ça veut dire qu'on peut refuser sans que l'appli se ferme. "Spécifique", ça veut dire une case par finalité, pas une case unique.

Concrètement, voilà comment je structure l'écran aujourd'hui :

Finalité	Base légale	Consentement requis ?
Faire fonctionner l'appli (compte, synchro)	Exécution du contrat	Non
Analytics anonymes pour corriger les bugs	Intérêt légitime	Non (mais information obligatoire)
Analytics produit nominatifs	Consentement	Oui
Publicité personnalisée	Consentement	Oui
Notifications marketing	Consentement	Oui

Deux règles simples que j'applique. Le bouton "Refuser" a strictement la même taille et la même couleur que "Accepter" : pas de gris clair planqué dans un coin. Et on ne charge aucun SDK publicitaire avant que la personne ait cliqué. Le préchargement avant consentement, c'est la faute la plus courante — et la plus facile à tracer.

Les SDK tiers : le maillon que tout le monde oublie

Ce qui m'a le plus surpris en auditant mes propres applis, c'est la quantité de données qui fuitent par des bibliothèques que je n'avais pas écrites. Un module de crash reporting. Un SDK d'attribution. Une régie publicitaire. Chacun de ces bouts de code est un sous-traitant au sens du RGPD, et chacun doit figurer dans votre politique de confidentialité, avec le rôle précis qu'il joue.

Je liste désormais chaque SDK dans un tableau interne : nom, éditeur, données collectées, finalité, pays d'hébergement, lien vers sa propre politique. Un SDK qui refuse de documenter ça est un SDK que je retire. Point. J'ai perdu un partenaire publicitaire comme ça le printemps dernier. Sa doc indiquait "may collect device signals" sans plus de détail. Aucun regret.

Le filtre des plateformes : iOS, Android et leurs propres règles

Ce qui complique la vie, c'est que le RGPD n'est pas le seul texte en jeu. Apple et Google imposent leurs propres mécanismes de consentement, et les deux ne se recouvrent pas parfaitement.

Côté iOS, l'App Tracking Transparency

Depuis quelques années, iOS exige une double étape : votre propre écran de consentement, puis la boîte de dialogue système d'Apple. Si l'utilisateur refuse la seconde, vous n'avez aucun identifiant de tracking à disposition, point. Vous pouvez toujours faire de l'analytics agrégé sans identifiant, mais toute personnalisation devient impossible.

Côté Android, la gestion des identifiants publicitaires

Google a suivi avec ses propres contrôles sur l'identifiant publicitaire. Vous pouvez demander à l'utilisateur de le réinitialiser, mais l'accès dépend d'un paramètre système qui doit être respecté. Sur une appli que j'ai reprise en 2024, le développeur précédent avait codé un contournement pour "garantir" la mesure d'audience. On l'a arraché avant la mise à jour. Le risque ne valait pas deux points de conversion.

Ma règle : tester l'appli avec tous les consentements refusés. Si elle fonctionne, même en mode dégradé, vous êtes dans les clous. Si elle plante, vous avez un problème de conception, pas de conformité.

Politique de confidentialité et mentions légales : ce qu'il faut y mettre pour de vrai

Je vais être direct. La plupart des politiques de confidentialité que je lis sont illisibles, copiées d'un modèle trouvé en ligne, et contiennent des clauses qui ne correspondent à rien dans l'appli. Ce n'est pas seulement un problème juridique : c'est un problème de confiance. Un utilisateur qui tombe sur une politique de quinze pages de jargon ferme l'appli.

Ce que je mets dans la mienne aujourd'hui :

• une phrase de résumé en tête, en langage normal, qui dit qui collecte quoi et pourquoi ;
• un tableau des données, une ligne par type, avec durée de conservation et destinataire ;
• la liste nominative des SDK et sous-traitants, avec lien vers leur propre politique ;
• les modalités concrètes pour exercer ses droits (accès, effacement, portabilité) — avec une adresse mail qui répond vraiment, pas une adresse morte ;
• et une date de dernière mise à jour qui n'a pas trois ans.

Les mentions légales, elles, restent plus techniques : éditeur, hébergeur, contact. Mais je conseille toujours de faire pointer les deux documents depuis un lien visible en bas de chaque écran principal, pas enterré dans les paramètres au septième niveau.

Faut-il encore déclarer une collecte de données à la CNIL ?

La déclaration préalable, telle qu'elle existait avant le RGPD, n'existe plus pour la plupart des traitements. Ce qui la remplace, c'est le registre interne : vous documentez chaque traitement, sa finalité, sa base légale, sa durée. Ce registre n'est pas envoyé à la CNIL, mais il doit être prêt à être présenté en cas de contrôle. Pour certains traitements sensibles, notamment ceux qui impliquent un profilage à grande échelle ou des données de santé, une analyse d'impact est exigée en amont.

Ce que la CNIL attend, en pratique, c'est que vous puissiez expliquer vos choix. Pas de remplir un formulaire.

Les erreurs que je vois encore, et qui coûtent cher

J'ai compilé mentalement les cinq erreurs qui reviennent chez presque tous les éditeurs que je rencontre.

1. Copier une politique de confidentialité générique sans vérifier qu'elle décrit l'appli réelle.
2. Considérer le consentement comme acquis une fois pour toutes, alors qu'il doit pouvoir être retiré aussi facilement qu'il a été donné.
3. Laisser un SDK tiers envoyer des données avant l'affichage du bandeau.
4. Ne jamais définir de durée de conservation, par flemme ou par peur de jeter.
5. Traiter la conformité comme un projet ponctuel, alors que chaque nouvelle fonctionnalité peut rouvrir le sujet.

Sur une appli à cinq mille utilisateurs actifs, la remise à plat complète m'a pris trois semaines. Sur une autre, plus simple, quatre jours. Le coût n'est jamais délirant ; c'est l'absence de méthode qui coûte cher.

Ce qui reste, une fois qu'on a tout coché

À la fin, la conformité n'est qu'un plancher. Le vrai sujet, c'est ce que vous décidez de ne pas collecter. Chaque donnée que vous n'avez pas collectée est une donnée que vous ne risquez pas de perdre, de fuiter, de revendre par accident. Il y a une forme de soulagement à concevoir une appli qui n'a pas besoin de savoir où l'utilisateur habite pour fonctionner.

La prochaine fois que vous ouvrez votre écran de consentement, posez-vous une seule question : si un utilisateur refusait absolument tout, votre appli tiendrait-elle debout ? Si la réponse est non, ce n'est pas la loi qu'il faut revoir. C'est la conception.