Application mobile et RGPD : les règles CNIL 2026

L’essentiel. La CNIL a adopté une recommandation dédiée aux applications mobiles (délibération n° 2024-061 du 18 juillet 2024, remplacée par la délibération n° 2025-024 du 27 mars 2025), puis a contrôlé 10 applications mobiles ou fournisseurs de code embarqué au cours de la campagne 2025. Le constat principal tient en une phrase : un manque de transparence, y compris lors du recueil du consentement à la géolocalisation. Le point de droit que presque tout le monde manque : une permission technique iOS ou Android ne vaut pas consentement au sens de l’article 82 de la loi Informatique et Libertés. Il faut les deux — et démontrer les deux.

Une application mobile n’est pas un site web avec une icône. Elle accède au micro, aux photos, au carnet de contacts, à la localisation en continu ; elle embarque en moyenne plusieurs kits de développement tiers dont l’éditeur ne maîtrise ni le paramétrage par défaut ni les destinataires réels des données. C’est précisément cet écart entre ce que l’éditeur croit collecter et ce que son application collecte effectivement que la CNIL est venue examiner en 2025. Voici le cadre applicable, ce que la CNIL a réellement reproché, et la méthode pour y répondre.

La recommandation CNIL : statut, date exacte et contenu

Beaucoup d’articles se trompent sur les références. Rétablissons-les.

La recommandation relative aux applications mobiles a été adoptée par la délibération n° 2024-061 du 18 juillet 2024, diffusée publiquement le 24 septembre 2024 à l’issue d’une consultation publique lancée en juillet 2023. Elle a ensuite été abrogée et remplacée par la délibération n° 2025-024 du 27 mars 2025, mise en ligne sur cnil.fr le 8 avril 2025 et publiée au JORF n° 0087 du 11 avril 2025 (texte n° 86, NOR : CNIL2510874X).

Le détail est révélateur : la CNIL n’a pas « modifié » sa recommandation, elle a abrogé la précédente pour la remplacer intégralement. La raison est purement documentaire et elle le dit elle-même — le fonds des décisions de la CNIL sur Légifrance ne permet pas, à ce stade, de présenter une version consolidée combinant une décision initiale et une décision modificative. Retenez donc la délibération n° 2025-024 comme unique référence en vigueur.

Les trois modifications d’avril 2025

La CNIL qualifie ces changements de « non substantiels ». Ils sont pourtant opérationnellement utiles :

1. Partie 4.2 — qualification des acteurs. L’exemple relatif à la lecture d’une donnée de localisation par un SDK pour le seul compte de l’éditeur, et son schéma, sont rectifiés pour lever une incohérence.
2. Partie 6.2.3 — recueil du consentement. Le tableau d’articulation entre fenêtre de consentement (CMP) et permission technique est remplacé par une infographie, « dans un objectif de clarté ».
3. Partie 6.3.1 — sélection du SDK. C’est la modification la plus importante : lorsque le fournisseur d’un SDK intégré réalise des traitements pour son propre compte, cela doit être prévu contractuellement avec l’éditeur au moment de l’intégration. Motif retenu par la CNIL : éditeur et fournisseur de SDK sont alors responsables conjoints de la collecte, et l’éditeur doit avoir « une vision claire et contractualisée » des traitements opérés par le prestataire qu’il choisit.

Ce qui relève de l’obligation, de la recommandation ou de la bonne pratique

Une recommandation CNIL n’est pas un règlement. Elle est adoptée sur le fondement de l’article 8-I-2°b de la loi n° 78-17 du 6 janvier 1978 et n’a pas de valeur contraignante en elle-même. La CNIL a d’ailleurs pris soin, dans la version finale, de mieux distinguer les trois niveaux. En pratique :

Niveau	Exemple tiré de la recommandation
Obligation (art. 82 LIL, RGPD)	Recueillir le consentement avant toute lecture ou écriture non exemptée dans le terminal ; choisir la permission adaptée au regard du principe de minimisation
Recommandation CNIL	Choisir, pour chaque permission, la version la moins intrusive que l’OS propose et qui réponde au besoin
Bonne pratique	Recueillir les consentements de manière contextuelle, au fil des actions de l’utilisateur, plutôt que par un unique écran d’accueil

Le point mérite d’être posé clairement : le non-respect d’une recommandation n’est pas sanctionnable en soi. Mais la recommandation décrit l’état de la doctrine que la CNIL appliquera lors d’un contrôle, et un écart assumé suppose de pouvoir en justifier. C’est le même mécanisme que celui des lignes directrices cookies.

Cinq acteurs, cinq régimes de responsabilité

La recommandation vise expressément cinq catégories. Cette cartographie n’est pas cosmétique : elle détermine qui doit recueillir le consentement, qui doit informer, et qui répond de quoi.

Acteur	Rôle	Qualification la plus fréquente
Éditeur	Met l’application à disposition, en détermine les finalités	Responsable de traitement pour les traitements de l’application ; responsable conjoint avec le fournisseur de SDK pour les opérations de lecture/écriture
Développeur	Écrit le code, intègre les SDK	Sous-traitant de l’éditeur (art. 28) lorsqu’il agit sur instruction
Fournisseur de SDK	Fournit des briques prêtes à l’emploi (mesure d’audience, ciblage)	Sous-traitant s’il agit pour le seul compte de l’éditeur ; responsable conjoint (art. 26) dès qu’il traite pour son propre compte
Fournisseur d’OS	iOS, Android : conçoit le système de permissions	Responsable de traitement pour ses propres traitements ; débiteur de bonnes pratiques sur la conception des permissions
Magasin d’applications	Distribue les applications	Responsable de traitement pour les données de téléchargement et de compte

La ligne à retenir est celle du SDK. Un éditeur n’est pas responsable des traitements que le tiers effectue pour son propre compte sur les données issues de l’application — mais la collecte réalisée à travers l’application, elle, doit être prévue contractuellement entre l’éditeur et ce tiers. Autrement dit : vous ne répondez pas de ce que la régie fait de la donnée dans son propre écosystème, mais vous répondez du fait qu’elle la collecte depuis votre application sans cadre écrit. La co-responsabilité se joue exactement à cet endroit.

Le vrai fondement juridique : l’article 82, pas seulement le RGPD

C’est l’erreur d’analyse la plus coûteuse. Les traceurs embarqués dans une application ne relèvent pas du RGPD seul, mais de l’article 82 de la loi n° 78-17 du 6 janvier 1978, qui transpose l’article 5(3) de la directive ePrivacy. Son économie est simple :

« Ces accès ou inscriptions ne peuvent avoir lieu qu’à condition que l’abonné ou la personne utilisatrice ait exprimé, après avoir reçu cette information, son consentement qui peut résulter de paramètres appropriés de son dispositif de connexion ou de tout autre dispositif placé sous son contrôle. »

Deux exemptions seulement : l’opération a « pour finalité exclusive de permettre ou faciliter la communication par voie électronique », ou elle est « strictement nécessaire à la fourniture d’un service de communication en ligne à la demande expresse de l’utilisateur ».

Le champ couvre bien les identifiants mobiles

La CNIL est explicite : la notion de traceur recouvre les cookies HTTP, le résultat du calcul d’une empreinte unique du terminal (fingerprinting), les pixels invisibles, et tout autre identifiant généré par un logiciel ou un système d’exploitation — la CNIL cite nommément l’IDFV (Identifier for Vendors d’Apple). Les identifiants publicitaires de terminal (IDFA côté Apple, AAID côté Google) relèvent de la même catégorie générique. Et ces opérations sont visées « quel que soit le type de terminal utilisé : ordinateur, smartphone, tablette numérique ou console de jeux vidéo ».

Deux conséquences pratiques que l’on sous-estime systématiquement :

• L’acceptation des conditions générales d’utilisation ne vaut pas consentement. La CNIL l’écrit noir sur blanc. Un écran d’onboarding qui fait accepter les CGU et la politique de confidentialité en un bouton ne couvre rien.
• Le guichet unique ne s’applique pas. Dans la délibération n° SAN-2025-005 du 1er septembre 2025 (SHEIN, 150 millions d’euros — décision qui porte sur un site web, pas sur une application), la CNIL rappelle que le mécanisme de coopération du RGPD « n’a pas vocation à s’appliquer dans la mesure où les opérations liées à l’utilisation de traceurs relève non pas du RGPD mais de la directive ePrivacy, transposée à l’article 82 ». Sa compétence se fonde alors sur l’article 3 de la loi Informatique et Libertés. Traduction pour un éditeur d’application établi à Dublin, Chypre ou Singapour et dont l’application est distribuée en France : la CNIL peut vous contrôler et vous sanctionner directement, sans passer par une autorité chef de file.

Permission technique et consentement : deux mécanismes distincts

C’est le cœur de la recommandation, et la confusion la plus répandue dans les équipes produit.

Une permission iOS ou Android est un dispositif du système d’exploitation qui autorise ou bloque l’accès technique à une ressource protégée : capteurs (localisation, micro, objectif photo, accéléromètre) ou mémoire (photos, fichiers, carnet de contacts, historiques). La CNIL le formule ainsi : ces permissions « visent uniquement à donner ou bloquer l’accès technique à certaines ressources protégées, sans tenir compte des objectifs (ou finalités) pour lesquels les applications le demandent ».

Et elle en tire la conséquence : « ces permissions “techniques” ne sont pas conçues pour collecter le consentement des utilisateurs, au sens du RGPD et de la loi Informatique et Libertés ».

Pourquoi les deux ne se recouvrent pas

Les deux mécanismes se croisent sans se superposer, dans les deux sens :

• Permission sans consentement requis. Une application de navigation a besoin de la localisation pour calculer un itinéraire : la donnée est strictement nécessaire au service demandé, aucun consentement n’est exigé au titre de l’article 82. L’OS impose pourtant une permission.
• Consentement requis mais permission insuffisante. Une permission ne constitue un consentement valable « que dans des cas limités, par exemple si la permission concerne un seul traitement, une seule finalité et un seul destinataire des données ». Autant dire jamais, dès lors qu’un SDK publicitaire est dans la boucle.

La conclusion opérationnelle de la CNIL est sans ambiguïté : « dans la plupart des cas, il est nécessaire d’utiliser une plateforme de gestion du consentement en complément de la demande de permission ».

Comment les articuler concrètement

La CNIL pose quatre règles d’articulation, et elles sont plus souples qu’on ne le croit :

1. L’ordre est libre. « Le consentement peut être obtenu indifféremment avant ou après la demande de permission. » Vous choisissez le parcours.
2. L’articulation ne doit pas créer de confusion. Deux fenêtres qui se ressemblent et se succèdent en trois secondes, dont l’une porte sur l’accès à la localisation et l’autre sur le ciblage publicitaire, produisent mécaniquement un consentement non éclairé — et rejoignent la logique des dark patterns.
3. Les deux conditions sont cumulatives. Il faut pouvoir accéder techniquement à la donnée (permission) et démontrer un consentement conforme (CMP). L’un ne dispense pas de l’autre.
4. Ne pas afficher la seconde demande si la première est refusée. La CNIL « invite à ne pas afficher la seconde demande pour éviter de solliciter inutilement les utilisateurs ». C’est du bon sens ergonomique devenu doctrine.

Et une bonne pratique, qui est aussi la meilleure façon de faire remonter les taux d’acceptation : recueillir le consentement de manière contextuelle en fonction des actions entreprises, plutôt que par un unique écran initial. Demander l’accès aux photos au moment où l’utilisateur veut publier une photo convertit mieux qu’un mur de six demandes au premier lancement. Les mêmes mécaniques que celles décrites dans mon analyse des taux de consentement s’appliquent au mobile.

Le SDK : premier point de contrôle

La CNIL a annoncé, pour sa campagne 2025, que les vérifications porteraient « essentiellement sur les questions abordées dans la recommandation, notamment le paramétrage des SDK ainsi que les accès aux données du téléphone via la gestion des permissions ». Le mot important est paramétrage.

La quasi-totalité des SDK d’analytics et de publicité démarrent leur collecte à l’initialisation de l’application, avant tout écran de consentement, parce que c’est leur configuration par défaut. Un éditeur qui intègre un SDK sans modifier ce comportement dépose et lit des identifiants avant consentement : le manquement à l’article 82 est constitué dès le premier lancement, indépendamment de la qualité de sa CMP.

Ce qu’il faut vérifier avant d’intégrer un SDK, puis à chaque montée de version :

• Le SDK dispose-t-il d’un mode différé permettant de bloquer toute collecte tant que le signal de consentement n’est pas transmis ? Est-il activé ?
• Quelles données lit-il exactement au démarrage (identifiants de terminal, adresse IP, liste des applications installées, données de localisation) ?
• Le fournisseur traite-t-il pour son propre compte ? Si oui, la qualification est celle de responsable conjoint et un accord au sens de l’article 26 du RGPD est requis — pas un simple contrat de sous-traitance.
• Les données sortent-elles de l’Union européenne ? Le sujet des transferts hors UE est structurellement présent dans l’écosystème publicitaire mobile.
• Le comportement réel correspond-il à la documentation ? Un audit réseau du trafic sortant de l’application, sur un terminal de test, répond en une demi-journée à une question que les fiches produit laissent ouverte.

Ce dernier point est le seul qui compte devant la CNIL. Ses agents ont contrôlé VOODOO en téléchargeant les applications et en les exécutant sur un iPhone : ils regardent ce que l’application fait, pas ce que le contrat prévoit.

Géolocalisation : le sujet qui a fait tomber la campagne 2025

Le 7 juillet 2026, la CNIL a publié une fiche dédiée à la géolocalisation dans les applications mobiles, dans le prolongement direct de sa recommandation. Le contexte est explicite : plusieurs enquêtes de presse ont révélé « l’existence de bases de données regroupant des millions d’identifiants publicitaires associés à des historiques de localisation, collectés via des applications très utilisées du quotidien », revendues par des courtiers spécialisés.

La doctrine posée est nette :

• Consentement obligatoire dès que la géolocalisation n’est pas strictement nécessaire au service : usage publicitaire, revente à des fins marketing, enrichissement de profils.
• Pas de consentement lorsqu’elle est strictement nécessaire (navigation, calcul d’itinéraire) — mais la permission technique reste demandée par l’OS.
• L’autorisation technique ne vaut pas consentement : « l’autorisation technique donnée par le système d’exploitation ne vaut pas, à elle seule, consentement pour les usages des données de localisation ». La CNIL le répète ici parce que c’est exactement là que ses contrôles ont trouvé les manquements.

Et une mise en garde souvent ignorée : le consentement ne dispense pas des autres principes. Même consentie, la collecte ne peut pas être plus précise que nécessaire, ni conserver des historiques de déplacements sur une longue durée à des fins de ciblage ou de revente. Quatre leviers concrets, tous issus de la fiche CNIL :

Levier	Application concrète
Niveau de précision	Une application météo fonctionne avec une localisation approximative (ville, quartier) — proposer la saisie manuelle d’un code postal est une bonne pratique
Traitement local	Calculer le magasin le plus proche sur le terminal plutôt que d’envoyer la position à un serveur
Collecte en arrière-plan	La géolocalisation continue se justifie pendant un trajet, pas quand l’application est fermée
Durée de conservation	Conserver plusieurs années l’historique détaillé des déplacements pour une application météo est « difficilement justifiable »

La sensibilité du sujet vient de la réidentification. Quelques points de localisation suffisent souvent à reconnaître un individu dès lors qu’ils révèlent son domicile, son lieu de travail ou ses habitudes. Une base présentée comme « anonyme » parce qu’elle ne contient qu’un identifiant technique n’est, dans la très grande majorité des cas, que pseudonymisée — avec toutes les conséquences que cela emporte, comme je l’ai détaillé sur la distinction pseudonymisation / anonymisation.

Ce que la CNIL a effectivement contrôlé — et trouvé

Les chiffres viennent du rapport annuel 2025 de la CNIL, publié le 18 mai 2026 :

« Dans le prolongement de sa recommandation sur les applications mobiles, la CNIL a contrôlé 10 applications mobiles ou fournisseurs de code embarqué dans ces applications. Les vérifications ont essentiellement porté sur les accès aux données contenues sur le téléphone et la gestion des autorisations. Les constats ont notamment mis en évidence un manque de transparence dans les informations fournies aux personnes, y compris lors de la collecte du consentement pour l’usage de la géolocalisation. »

Le grief n’est donc pas d’abord l’absence de consentement : c’est l’information. Les articles 12, 13 et 14 du RGPD, appliqués à un écran de 6 pouces, sur lequel il faut expliquer quelles données sont collectées, pour quoi, par qui et pour combien de temps, au bon moment du parcours. C’est un problème de conception d’interface autant que de rédaction juridique.

Trois précisions de rigueur :

• Aucune mise en demeure ni sanction publique n’a été rattachée à cette campagne à ce jour. Ne lisez pas les 10 contrôles comme une vague répressive.
• Les quatre thématiques prioritaires de 2025 ont représenté environ 30 % des 323 contrôles de l’année. L’année 2025 s’est soldée par 259 décisions, 83 sanctions et environ 487 millions d’euros d’amendes.
• Les applications mobiles ne figurent plus parmi les thématiques prioritaires annoncées pour 2026 (recrutement, répertoire électoral unique, fédérations sportives, plus l’action européenne coordonnée sur l’information et la transparence). Mais la CNIL indique que ces contrôles « se poursuivront dans les prochaines années », environ 80 % de ses contrôles restent hors thématiques prioritaires, et elle consacrera en 2026 la moitié de ses contrôles et actions répressives à la sécurité des données, en visant notamment les acteurs traitant massivement des données de localisation.

Autrement dit : la pression ne retombe pas, elle change de porte d’entrée. Vous trouverez le suivi des décisions récentes dans mon analyse des sanctions CNIL 2026.

Le précédent VOODOO : 3 millions d’euros pour un identifiant « technique »

La décision de référence en matière d’identifiants mobiles reste la délibération n° SAN-2022-026 du 29 décembre 2022, par laquelle la formation restreinte a prononcé une amende de 3 000 000 euros contre la société VOODOO, éditeur de jeux mobiles, sur le fondement de l’article 82 de la loi Informatique et Libertés — assortie d’une injonction de mise en conformité sous trois mois sous astreinte de 20 000 euros par jour de retard.

Le mécanisme sanctionné mérite d’être compris précisément, car il se rejoue tous les jours dans les stacks publicitaires. Lorsque l’utilisateur refusait le suivi publicitaire — donc l’accès à l’IDFA via le dispositif App Tracking Transparency d’Apple — VOODOO lisait l’IDFV, un identifiant en principe technique, et traitait des informations relatives aux habitudes de navigation à des fins publicitaires. La substitution d’un identifiant présenté comme technique à un identifiant publicitaire refusé constitue un accès à des informations stockées dans le terminal sans consentement.

Deux enseignements durables :

• La qualification d’un identifiant ne dépend pas de son nom, mais de son usage. Un identifiant « technique » exploité à des fins publicitaires bascule dans le champ de l’article 82.
• Le refus doit être respecté sur toute la chaîne. Un refus au niveau de l’OS que l’application contourne par un autre identifiant est un manquement caractérisé, quelle que soit la conformité apparente de l’écran de consentement.

À ce jour, la CNIL n’a pas rendu publique de sanction visant spécifiquement un SDK tiers intégré dans une application mobile. Compte tenu de ce qu’elle a annoncé contrôler, ce n’est probablement qu’une question de calendrier.

Consentement multi-terminaux : la nouveauté de janvier 2026

Dernière évolution à intégrer si votre application coexiste avec un site web et un espace client : la délibération n° 2025-131 du 18 décembre 2025, publiée le 16 janvier 2026, adopte une recommandation sur le consentement multi-terminaux, qui modifie et complète la recommandation « cookies et autres traceurs » de 2020 (délibération n° 2020-092 du 17 septembre 2020). Une version consolidée des deux textes a été mise en ligne en janvier 2026.

Le périmètre est celui des univers logués : lorsque l’utilisateur est authentifié à un compte, ses choix peuvent être appliqués à l’ensemble de ses appareils — « son téléphone, sa tablette, son ordinateur ou sa télévision connectée, ainsi que le navigateur ou l’application utilisés ». Trois exigences en découlent :

• Symétrie de portée. Si l’on peut consentir en une fois pour tous les appareils, on doit pouvoir refuser et retirer son consentement avec la même simplicité et la même portée.
• Information dès le premier niveau de la fenêtre de consentement, précisant que les choix s’appliquent à tous les appareils.
• Message temporaire recommandé lors d’une connexion depuis un nouveau terminal, et méthode explicite de résolution des conflits entre choix locaux et choix enregistrés dans le compte (priorité au dernier choix exprimé, ou priorité aux préférences du compte — les deux sont admises).

Sur la durée de vie des choix, la CNIL retient une bonne pratique — pas une obligation : « la durée de conservation des choix devra être appréciée au cas par cas (au regard de la nature du site web ou de l’application concernée et des spécificités de son audience). Généralement, une conservation des choix pendant une durée de 6 mois constitue une bonne pratique. » Cette durée vaut pour le consentement comme pour le refus : reproposer une fenêtre de consentement à chaque ouverture de l’application, après un refus, est le contre-exemple parfait.

Plan d’action en 12 étapes

Étape	Action
1	Inventorier tous les SDK embarqués, version par version, y compris ceux hérités d’une intégration ancienne
2	Auditer le trafic réseau réel de l’application au premier lancement, avant toute interaction, sur iOS et Android
3	Pour chaque SDK, trancher la qualification : sous-traitant ou responsable conjoint ?
4	Contractualiser : DPA article 28 pour les sous-traitants, accord article 26 pour les responsables conjoints
5	Activer le mode différé de chaque SDK : aucune lecture ni écriture avant transmission du signal de consentement
6	Cartographier les permissions demandées et supprimer celles qui ne servent plus à aucune fonctionnalité
7	Choisir, pour chaque permission, la version la moins intrusive proposée par l’OS (localisation approximative, photos sélectionnées)
8	Déployer une CMP compatible mobile et définir l’ordre permission / consentement, sans afficher la seconde demande si la première est refusée
9	Passer au recueil contextuel : demander au moment de l’action, pas au premier lancement
10	Réécrire l’information : mentions des articles 13 et 14 accessibles dans l’application, au bon moment, en langage clair
11	Journaliser la preuve du consentement : horodatage, version de l’application, texte exact affiché, captures écran horodatées du rendu sur terminal mobile
12	Inscrire chaque finalité au registre des traitements et évaluer la nécessité d’une AIPD — la géolocalisation à grande échelle y conduit souvent

C’est typiquement le genre de chaîne — inventaire des SDK, qualification des acteurs, contrats, registre, preuve — que Legiscope permet de tenir à jour sans reconstruire un tableur à chaque version de l’application.

Cinq erreurs fréquentes

1. Faire accepter les CGU au premier lancement et considérer le consentement acquis. La CNIL exclut expressément cette modalité.
2. Traiter la permission ATT d’Apple comme un consentement RGPD. Elle porte sur l’accès à un identifiant, pas sur les finalités ni sur les destinataires. Elle ne dispense d’aucune CMP dès qu’il y a plusieurs finalités ou plusieurs tiers.
3. Reprendre la CMP du site web telle quelle. Les traceurs, les identifiants et les destinataires ne sont pas les mêmes ; la CNIL recommande que le choix soit effectué sur chacun des sites ou applications concernés.
4. Oublier les SDK dormants. Un kit d’attribution intégré pour une campagne de 2023 et jamais retiré continue d’émettre. Il figurera au rapport de contrôle.
5. Confondre absence de nom et anonymat. Un identifiant publicitaire associé à un historique de localisation reste une donnée personnelle, et son partage avec des courtiers suppose un consentement spécifique.

Ce qu’il faut retenir

• La référence en vigueur est la délibération n° 2025-024 du 27 mars 2025, qui abroge et remplace la délibération n° 2024-061 du 18 juillet 2024. Publication au JORF n° 0087 du 11 avril 2025.
• Une permission technique iOS ou Android ne vaut pas consentement. Elle n’en tient pas lieu, sauf cas limité d’un traitement unique, d’une finalité unique et d’un destinataire unique. Dans la plupart des cas, une CMP est nécessaire en complément.
• Le fondement juridique est l’article 82 de la loi Informatique et Libertés, pas seulement le RGPD. Conséquence directe : pas de guichet unique, la CNIL est compétente sur le fondement de l’article 3 de la loi, même pour un éditeur établi hors de France.
• Le SDK est le premier point de contrôle. Son paramétrage par défaut déclenche presque toujours la collecte avant consentement ; depuis avril 2025, la CNIL exige en outre de contractualiser la collecte lorsque le fournisseur traite pour son propre compte (responsabilité conjointe, article 26).
• La campagne 2025 a porté sur 10 applications ou fournisseurs de code embarqué, et le grief principal retenu est un manque de transparence, y compris sur le consentement à la géolocalisation. Aucune mise en demeure ni sanction publique n’y a été rattachée à ce jour.
• VOODOO (SAN-2022-026, 3 M€, article 82) reste la décision de référence : lire l’IDFV à des fins publicitaires après un refus de suivi caractérise un accès sans consentement.
• Les applications mobiles ne sont plus une thématique prioritaire en 2026, mais la CNIL annonce que ces contrôles se poursuivront, 80 % de ses contrôles restent hors thématiques, et la moitié de son activité répressive 2026 visera la sécurité des données, dont les données de localisation.
• Conserver les choix six mois est une bonne pratique, pas une obligation — et elle vaut aussi bien pour le refus que pour l’acceptation.

FAQ

La permission iOS ou Android suffit-elle à recueillir le consentement ?

Non, sauf cas très limité. La CNIL indique que les permissions sont des dispositifs « techniques » qui donnent ou bloquent l’accès à une ressource sans tenir compte des finalités poursuivies, et qu’elles ne sont pas conçues pour recueillir un consentement au sens du RGPD et de l’article 82 de la loi Informatique et Libertés. Une permission ne suffit que si elle concerne un seul traitement, une seule finalité et un seul destinataire — hypothèse rare dès qu’un SDK publicitaire est intégré. Dans les autres cas, une plateforme de gestion du consentement est nécessaire en complément.

Faut-il un consentement pour la géolocalisation dans une application ?

Cela dépend de la nécessité au regard du service demandé. Une application de navigation qui a besoin de la position pour calculer un itinéraire n’a pas à recueillir de consentement au titre de l’article 82 : la donnée est strictement nécessaire. En revanche, dès que la localisation sert à personnaliser des publicités, à alimenter des profils marketing ou à être partagée avec des partenaires, le consentement est obligatoire. Et même consenti, le traitement reste soumis à la minimisation : pas de précision supérieure au besoin, pas d’historique conservé au-delà de l’utile.

Un éditeur d’application établi hors de France peut-il être sanctionné par la CNIL ?

Oui, directement. Les opérations de lecture et d’écriture dans un terminal relèvent de la directive ePrivacy transposée à l’article 82 de la loi Informatique et Libertés, et non du RGPD. Le mécanisme du guichet unique, qui suppose une autorité chef de file, ne s’applique donc pas à ce contentieux. La CNIL fonde sa compétence sur l’article 3 de la loi Informatique et Libertés. C’est le raisonnement qu’elle a suivi dans la délibération n° SAN-2025-005 du 1er septembre 2025 à l’encontre d’une société établie hors de France.

Quelle différence de traitement entre un SDK sous-traitant et un SDK responsable conjoint ?

Le SDK est sous-traitant lorsqu’il n’agit que pour le compte de l’éditeur, sur ses instructions : un contrat au sens de l’article 28 du RGPD suffit. Dès qu’il traite les données pour son propre compte — ce qui est le cas de la plupart des SDK publicitaires et de mesure d’audience —, éditeur et fournisseur sont responsables conjoints de la collecte réalisée à travers l’application, ce qui impose un accord au sens de l’article 26 du RGPD répartissant les obligations, notamment en matière d’information et d’exercice des droits. Depuis la version modifiée d’avril 2025, la CNIL demande expressément que cette collecte soit prévue contractuellement lors de l’intégration du SDK.

Combien de temps peut-on conserver le choix de l’utilisateur avant de le redemander ?

La CNIL considère qu’une conservation des choix pendant six mois constitue généralement une bonne pratique, à apprécier au cas par cas selon la nature de l’application et les spécificités de son audience. Il ne s’agit pas d’un plafond réglementaire. Le point important est la symétrie : cette durée s’applique au refus comme à l’acceptation. Réafficher la fenêtre de consentement à chaque ouverture de l’application après un refus revient à exercer une pression sur l’utilisateur et fragilise le caractère libre du consentement obtenu par lassitude.

---

Recevez nos analyses conformité chaque semaine. RGPD, traceurs, applications mobiles, AI Act : une lecture par semaine pour suivre la réglementation sans y passer vos soirées. Inscrivez-vous à la newsletter.

---