RGPD et application mobile : ce que la CNIL contrôle depuis 2025
La CNIL a fait des applications mobiles l'une de ses trois priorités de contrôle pour 2025, et ce qu'elle regarde n'est pas ce que la plupart des devis prévoient. Si vous faites développer une application, deux décisions vous engagent plus que toutes les autres : la liste des permissions qu'elle demande, et les bibliothèques tierces qu'elle embarque. Voici comment nous les traitons, et ce que nous ne savons pas faire.
Le texte qui s'applique à un téléphone n'est pas seulement le RGPD
C'est le point que les articles français sur le sujet passent presque tous. Lire ou écrire une information dans le téléphone de quelqu'un relève en France de l'article 82 de la loi du 6 janvier 1978, celui qu'on connaît pour les cookies. Or son texte ne parle pas de navigateur. Il parle d'« équipement terminal », et un smartphone en est un.
L'article impose d'informer l'utilisateur de la finalité de l'accès et des moyens de s'y opposer, et de recueillir son consentement avant l'opération. Deux cas seulement en sortent : quand l'accès a pour finalité exclusive de permettre ou faciliter la communication électronique, et quand il est strictement nécessaire à la fourniture d'un service à la demande expresse de l'utilisateur (article 82 de la loi n° 78-17, Légifrance).
La conséquence est directe, et elle change des budgets. Un identifiant publicitaire lu sur le téléphone, une bibliothèque de mesure d'audience qui écrit son propre identifiant, un outil de suivi marketing : rien de tout cela n'est strictement nécessaire au service demandé. Il faut donc un consentement, pas un intérêt légitime mentionné dans une politique de confidentialité. Nous voyons encore des projets où cette ligne a été franchie sans que personne ne la voie, parce qu'elle est invisible dans l'application.
Que contrôle la CNIL sur une application mobile ?
Deux choses, nommément. Le paramétrage des bibliothèques tierces intégrées à l'application, et les accès aux données du téléphone par la gestion des permissions. La campagne a commencé au début du printemps 2025 et vise les éditeurs d'applications comme les fournisseurs de ces bibliothèques. Ce sont les deux sujets les moins écrits dans un cahier des charges.
Le cadre de référence est la recommandation de la CNIL relative aux applications mobiles, adoptée le 18 juillet 2024 par la délibération n° 2024-061 et republiée dans une version modifiée le 8 avril 2025. Elle distingue cinq rôles dans la chaîne : l'éditeur de l'application, son développeur, le fournisseur du kit de développement tiers, le fournisseur du système d'exploitation et celui du magasin d'applications (recommandation relative aux applications mobiles, CNIL). Si vous êtes l'éditeur, une bonne partie de ces obligations vous revient même quand le code a été écrit par quelqu'un d'autre.
La CNIL justifie la priorité par un ordre de grandeur qu'elle publie : « Les Français téléchargent désormais une trentaine d'applications mobiles par an » (les contrôles de la CNIL en 2025). Ce que nous en retenons pour un dirigeant : le sujet n'est plus théorique, et il concerne les applications d'entreprise autant que les applications grand public.
Les permissions se décident au cadrage, pas au développement
La CNIL conseille de retenir, pour chaque permission, la version la moins intrusive qui réponde au besoin, et de recueillir les consentements de manière contextuelle en fonction des actions entreprises plutôt que sur un écran unique (permissions dans les applications mobiles, CNIL). Autrement dit, cela se joue dans les maquettes. Un document juridique rédigé à la livraison n'y change rien.
Daiky, notre application Flutter qui rend lisible la composition d'un cosmétique, en est un bon exemple parce que sa permission centrale est évidente : la caméra, pour scanner un code-barres ou photographier une étiquette quand le produit n'est pas référencé. Elle se demande au moment où l'utilisateur appuie sur le bouton de scan. À ce moment-là, la raison est comprise sans explication, et c'est tout l'intérêt du moment contextuel. Sur un écran d'accueil, la même demande aurait l'air d'une fouille.
Voici la partie qui coûte plus cher que prévu, et nous la chiffrons désormais séparément. Une permission peut être refusée, et l'application doit continuer de fonctionner. Cela veut dire deux parcours à dessiner, deux à développer et deux à tester, pour chaque permission sensible. C'est le poste que nous sous-évaluions, et il n'a rien de juridique : c'est du travail d'interface. Une application qui affiche un écran blanc quand on refuse la géolocalisation n'est pas conforme, elle est seulement cassée.
Qui est responsable des données qu'une bibliothèque tierce collecte ?
Vous, en tant qu'éditeur, et c'est la réponse qui surprend le plus en réunion. Une bibliothèque d'analyse d'audience, de publicité ou de rapport de plantage collecte sous votre responsabilité, avec les finalités que son paramétrage par défaut lui donne. Ce paramétrage par défaut est précisément ce que la CNIL est venue regarder.
Sur un projet Flutter ou React Native, la difficulté est que l'arbre de dépendances descend plus loin que ce que l'équipe a choisi. Une bibliothèque en entraîne trois, dont une envoie des mesures quelque part. Nous tenons donc un inventaire écrit des bibliothèques embarquées et de leur finalité, et nous le tenons pendant le développement. Le reconstituer après coup, sur un projet en production, prend plusieurs jours et rend un résultat dont personne n'est sûr.
Le choix des services tiers est aussi un choix de destinataires, et il se fait parfois sans y penser. Sur AquaPro Manager, notre plateforme pour les professionnels de la piscine, les fiches clients et les bassins s'affichent sur des cartes OpenStreetMap. Retenir un fournisseur de cartes plutôt qu'un autre décide de qui reçoit une requête chaque fois qu'un technicien ouvre une fiche. La connexion se fait par code à usage unique, ce qui suppose de conserver un numéro de téléphone : une donnée personnelle de plus, pour une commodité d'usage réelle.
Vient enfin l'endroit où les données sont traitées, et celui-là ne se rattrape pas. Un service d'identification géré peut être traité exclusivement aux États-Unis, sans paramètre pour le changer, quand la base de données du même fournisseur se place à Paris. Nous avons documenté ce cas précis, sources à l'appui, dans notre article sur ce que Firebase couvre et où il s'arrête. Nous ne pouvons pas répondre oui à une entreprise qui exige que toutes les données personnelles de ses utilisateurs soient traitées dans l'Union, et nous le disons avant le devis.
Quand les données touchent à la santé, le périmètre se décide d'abord
Deux de nos applications sont concernées. MamaSafe Food indique à une femme enceinte si un aliment est sûr, à partir d'un scan photo et des recommandations de l'ANSES, de Santé publique France et du CNGOF. Daiky analyse ce qu'une personne s'applique sur la peau. Dans les deux cas, ce que l'utilisateur scanne en dit long sur lui, et le simple fait d'ouvrir l'application à un moment donné en dit déjà quelque chose.
La décision prise sur MamaSafe Food mérite d'être citée telle quelle : les photos ne sont pas conservées sans consentement. C'est une décision d'architecture. Elle se prend avant le premier écran, parce qu'ensuite elle coûte une reprise de données. La durée de conservation de l'historique relève du même moment, et elle est autant une question de produit que de conformité : quelqu'un doit l'écrire quelque part avant que le premier écran ne soit dessiné.
Notre recommandation tient en une phrase : ne collectez pas une donnée parce qu'elle pourrait servir un jour. C'est ce raisonnement qui remplit les bases, puis les déclarations, puis les discussions avec un juriste. Et nous déconseillons franchement d'ajouter une bibliothèque de mesure d'audience en début de projet « pour avoir les chiffres » quand personne n'a encore dit lesquels. Une donnée collectée se retire toujours plus mal qu'elle ne s'ajoute.
Questions fréquentes
Une application mobile a-t-elle besoin d'une bannière de consentement ?
La permission du système Android ou iOS suffit-elle comme consentement ?
Qui est responsable des données collectées par un SDK tiers ?
Les données de mon application peuvent-elles rester en Europe ?
La décision qui vous revient n'est pas juridique. Elle est de savoir à quel moment du projet ces questions se posent, et vous n'avez qu'une occasion de la prendre : au cadrage, quand les écrans ne sont pas encore dessinés. Après, chaque correction se paie en reprise de données, en écrans à refaire et en déclarations à modifier sur les deux boutiques. C'est pour cela que nous mettons la liste des permissions, l'inventaire des bibliothèques tierces et l'emplacement des données dans la proposition commerciale, là où le client peut encore en discuter le prix.
Le pendant web de cette discussion est traité dans notre checklist RGPD pour le développement web, et la façon dont nous conduisons un projet mobile de bout en bout est décrite sur la page de notre service de développement d'application mobile.
