Depuis le printemps 2025, la CNIL mène une campagne de contrôle qui ne se limite plus à l'apparence d'une bannière de consentement dans une application mobile : elle vérifie si les SDK intégrés arrêtent réellement de transmettre des données lorsque l'utilisateur refuse. Le 29 décembre 2022 déjà, la CNIL avait sanctionné Voodoo, éditeur français de jeux mobiles, à hauteur de 3 millions d'euros pour avoir utilisé l'identifiant technique IDFV afin de cibler publicitairement des utilisateurs ayant explicitement refusé le suivi via l'App Tracking Transparency d'Apple (CNIL, décision du 29 décembre 2022). En 2025, la CNIL a prononcé 83 sanctions pour un total de 486,8 millions d'euros, soit près de neuf fois plus qu'en 2024, avec les traceurs et cookies comme premier motif de sanction. Pour une application qui touche des utilisateurs français ou européens, la conformité mobile n'est plus un sujet juridique avec un détail technique en annexe : c'est un problème d'architecture logicielle dont la conséquence juridique peut atteindre 20 millions d'euros ou 4 % du chiffre d'affaires mondial annuel, selon le montant le plus élevé.
Points clés
- La CNIL a publié en septembre 2024 ses recommandations relatives aux applications mobiles (version modifiée le 8 avril 2025) et a lancé, dès le printemps 2025, une campagne de contrôle qui vise spécifiquement le comportement technique des SDK intégrés, pas seulement l'interface de consentement affichée à l'écran.
- Un SDK ne peut initialiser aucun traitement nécessitant un consentement avant que celui-ci soit recueilli. C'est l'exigence la plus structurante de la recommandation CNIL, et la plus fréquemment violée en pratique.
- Les règles de plateforme (App Tracking Transparency d'Apple, Privacy Manifests, Data Safety et Consent Mode v2 de Google) s'appliquent en parallèle du RGPD, jamais à sa place : obtenir l'autorisation ATT ne constitue pas un consentement RGPD valable.
- Une application qui a aussi des utilisateurs américains doit gérer une troisième couche : le CCPA/CPRA, dont les sanctions atteignent désormais 7 988 $ par violation intentionnelle ou impliquant les données d'un mineur (Californie, montants recalibrés au 1er janvier 2025).
- L'éditeur de l'application reste responsable du traitement effectué par chaque SDK tiers qu'il intègre, y compris lorsque le comportement réel du SDK diverge de sa documentation.
Ce Que la Conformité Mobile Exige Réellement
La conformité d'une application mobile en matière de vie privée désigne l'ensemble des obligations légales et techniques qui encadrent la collecte, le traitement, le stockage et la suppression des données personnelles au sein de l'app, que ce traitement soit réalisé par le code de l'éditeur ou par l'un des SDK tiers intégrés. Le périmètre est plus large que ce que suppose la plupart des équipes produit : chaque SDK de mesure d'audience, chaque SDK publicitaire, chaque permission demandée à l'exécution et chaque flux de données entre l'app et un serveur tiers entre dans ce périmètre.
Trois principes structurent la quasi-totalité des textes applicables. Le consentement et la transparence signifient que l'utilisateur doit être informé de façon compréhensible de ce qui est collecté et pourquoi, avec un moyen réel de s'y opposer. La minimisation des données signifie ne collecter que ce qui est strictement nécessaire à la finalité déclarée, jamais ce qui pourrait servir plus tard. La sécurité signifie protéger les données pendant tout leur cycle de vie, y compris à l'intérieur des SDK tiers qui s'exécutent dans l'application.
Le principe de responsabilité aggrave ces obligations pour l'éditeur : au sens du RGPD, celui qui publie l'application est responsable du traitement, y compris pour ce qui est fait par des bibliothèques logicielles qu'il n'a pas écrites lui-même. Un SDK de crash reporting qui extrait des identifiants d'appareil, un SDK publicitaire qui collecte des données comportementales avant tout consentement, un SDK de connexion sociale qui accède au carnet d'adresses sans nécessité : dans chaque cas, c'est une non-conformité de l'éditeur, pas du fournisseur du SDK. Cette responsabilité ne peut pas être externalisée par contrat, un point que la CNIL a explicitement rappelé dans ses recommandations sur les applications mobiles.
RGPD, ePrivacy, CCPA et Règles de Plateforme : Quatre Couches Qui Ne Se Confondent Pas
L'erreur la plus fréquente chez les équipes qui publient une application à la fois en Europe et aux États-Unis consiste à traiter RGPD et CCPA comme deux versions du même texte. Elles partagent une inspiration commune, mais diffèrent sur des points qui ont un effet pratique direct : base légale, mécanisme d'opposition, structure des sanctions. Les règles de plateforme forment une troisième couche, indépendante de la localisation de l'utilisateur : elles s'appliquent à toute application publiée sur l'App Store ou le Play Store, quel que soit le pays visé.
| Aspect | RGPD + ePrivacy (France et UE) | CCPA/CPRA (Californie et États américains) | Règles de plateforme (Apple et Google) |
|---|---|---|---|
| À qui cela s'applique | Toute app traitant des données de personnes situées dans l'UE/EEE, où que l'éditeur soit établi | Toute app dont l'éditeur atteint les seuils CCPA (revenu, volume de données) et qui traite des données de résidents californiens ou d'autres États à loi équivalente | Toute app publiée sur l'App Store ou le Play Store, indépendamment du pays de l'utilisateur |
| Base légale pour le suivi non essentiel | Consentement explicite exigé par l'article 5(3) de la directive ePrivacy pour tout accès au terminal | Modèle d'opt-out : le consommateur doit pouvoir refuser la vente/partage de ses données, le consentement préalable n'est pas la règle par défaut | Ne définit pas de base légale ; exige seulement une déclaration et, côté Apple, une autorisation système explicite (ATT) |
| Sanction maximale | Jusqu'à 20 millions d'euros ou 4 % du chiffre d'affaires mondial annuel, le montant le plus élevé étant retenu | Jusqu'à 7 988 $ par violation intentionnelle ou impliquant un mineur, 2 663 $ par violation non intentionnelle (montants recalibrés au 1er janvier 2025 par la CPPA) | Rejet, retrait ou suspension de l'app sur la boutique ; aucune amende financière directe |
| S'applique indépendamment de la juridiction de l'utilisateur ? | Non, seulement pour les personnes situées dans l'UE/EEE | Non, seulement pour les résidents des États concernés | Oui, pour toute app distribuée sur la boutique concernée |
Une application peut être pleinement conforme au RGPD et se retrouver malgré tout en infraction avec le CCPA, ou l'inverse, parce que les deux textes évaluent le consentement et le risque différemment. Une application qui vise à la fois des utilisateurs français et américains doit donc satisfaire simultanément le RGPD, l'ePrivacy, le CCPA/CPRA applicable et les règles de plateforme, et non une version fusionnée et simplifiée des quatre. À noter : la Commission européenne a proposé en novembre 2025, dans son paquet « Digital Omnibus », d'intégrer les règles relatives aux cookies et traceurs directement dans le RGPD via un nouvel article 88a, qui maintiendrait l'exigence de consentement pour la publicité et la personnalisation tout en exemptant une liste limitée de finalités à faible risque. Le texte est encore en cours d'examen par le Parlement européen et le Conseil au moment de la rédaction, et son adoption définitive n'est pas attendue avant 2026-2027 ; il ne change rien aux obligations actuelles tant qu'il n'est pas adopté.
Ce Que la CNIL Attend Spécifiquement des SDK Intégrés à une Application
C'est ici que la conformité mobile diverge le plus nettement de la conformité web classique, et c'est le point sur lequel la plupart des guides généralistes restent trop vagues. La recommandation CNIL relative aux applications mobiles, adoptée le 18 juillet 2024 et modifiée le 8 avril 2025, s'applique à l'ensemble de la chaîne : éditeurs, développeurs, fournisseurs de SDK, magasins d'applications et fournisseurs de système d'exploitation.
Trois obligations concrètes en découlent pour l'éditeur qui intègre un SDK tiers. Il doit d'abord obtenir du fournisseur du SDK une documentation précise permettant d'identifier les traitements réellement mis en œuvre une fois le SDK intégré, une documentation marketing générique ne suffit pas. Il doit ensuite s'assurer que le SDK respecte effectivement le consentement recueilli, c'est-à-dire qu'il bloque tout traitement ou accès aux données du terminal nécessitant un consentement jusqu'à ce que celui-ci soit valablement obtenu. Il doit enfin vérifier que le SDK permet de répondre aux demandes d'exercice des droits des personnes concernées, et non uniquement de collecter des données. Learn more about les clauses contractuelles à exiger de chaque fournisseur de SDK.
La CNIL insiste par ailleurs sur une confusion fréquente : l'obtention d'une permission système (comme l'autorisation ATT sur iOS) ne doit jamais être assimilée au recueil d'un consentement au sens du RGPD. Ce sont deux couches distinctes, qui répondent à des logiques différentes et doivent être documentées séparément. Depuis le début de la campagne de contrôle au printemps 2025, les éditeurs qui ne peuvent pas produire cette documentation SDK lors d'un contrôle s'exposent au même risque de sanction que ceux dont l'interface de consentement est manifestement défaillante.
Le Consentement en Pratique : Pourquoi le Blocage Avant Initialisation Est Le Point Décisif
Le point le plus déterminant de la conformité technique est le blocage de consentement : l'exigence architecturale selon laquelle aucun SDK non essentiel ne doit s'initialiser avant que l'état de consentement de l'utilisateur soit résolu. C'est cette étape qui distingue une application réellement conforme d'une application qui donne seulement l'impression de l'être.
Au lancement de l'app, le SDK de gestion du consentement doit s'initialiser en premier et vérifier s'il existe déjà un enregistrement de consentement valide, non expiré et correspondant à la version actuelle de la liste des fournisseurs de traceurs. En l'absence d'un tel enregistrement, l'interface de consentement doit s'afficher avant tout autre traitement, avec des options « tout accepter » et « tout refuser » présentées avec la même mise en avant visuelle, une granularité par finalité (mesure d'audience, publicité, fonctionnel) et des libellés en langage clair. Ce n'est qu'après la réponse de l'utilisateur que l'application peut initialiser les SDK non essentiels, et uniquement ceux qui correspondent aux catégories autorisées.
L'enregistrement du consentement doit être immuable et conservé à la fois localement sur l'appareil et sur un serveur distant : le stockage local évite la situation où un SDK s'initialise avant que l'état sauvegardé soit chargé, et la synchronisation distante constitue la piste d'audit que les régulateurs demandent en premier lors d'un contrôle. Chaque mise à jour de préférence doit être ajoutée comme un nouvel événement horodaté, sans écraser le précédent, avec la version de la politique de confidentialité applicable au moment du recueil. Tenir ce registre à jour manuellement, dans un tableau, cesse d'être viable au-delà de quelques milliers d'utilisateurs actifs.
Un point souvent négligé mérite d'être signalé aux équipes produit avant même de choisir un fournisseur de gestion du consentement : la capacité à prouver, lors d'un contrôle CNIL, que chaque SDK a effectivement reçu et respecté le signal de refus, pas seulement que la bannière l'a enregistré. Une solution de gestion des cookies et du consentement dotée de SDK natifs iOS et Android qui journalise chaque consentement et chaque révocation de façon exportable répond directement à cette exigence de preuve, sans que l'équipe ait à construire ce registre elle-même.
Exigences Spécifiques iOS et Android : Ce Qui S'ajoute au RGPD
iOS et Android imposent des couches d'exigence propres, qui ne remplacent ni le RGPD ni le CCPA et ne dépendent pas de la loi applicable à l'utilisateur.
Le framework App Tracking Transparency (ATT) d'Apple, en vigueur depuis iOS 14.5 en 2021, exige une invite système explicite avant tout accès à l'IDFA, l'identifiant publicitaire utilisé pour le suivi entre applications. L'ATT ne se substitue ni au consentement RGPD ni au CCPA : c'est une autorisation de plateforme distincte, qui s'ajoute en parallèle. Pour un utilisateur situé dans l'Union européenne, la séquence correcte est consentement RGPD d'abord, puis ATT, ce qui établit la base légale avant de solliciter l'autorisation de plateforme. Le taux d'acceptation de l'ATT atteint environ 51 à 53 % en France, sensiblement au-dessus de la moyenne mondiale d'environ 38 % au premier trimestre 2026, ce qui reflète en partie des habitudes de refus plus marquées sur ce marché.
Les Privacy Manifests d'Apple, obligatoires depuis le 1er mai 2024 pour tout SDK tiers intégré à une app soumise à l'App Store, sont des fichiers (PrivacyInfo.xcprivacy) qui déclarent l'usage des données et l'accès aux API sensibles de chaque SDK ; une divergence entre la pratique déclarée et le comportement réel expose l'application au rejet lors de la soumission. Côté Google, le Consent Mode v2 est obligatoire depuis le 6 mars 2024 pour toute personnalisation publicitaire ciblant du trafic en provenance de l'Espace économique européen : il communique quatre signaux de consentement (ad_storage, analytics_storage, ad_user_data, ad_personalization) qui doivent refléter le choix réel de l'utilisateur avant l'initialisation de tout SDK Google. La section Data Safety du Play Store fait l'objet, depuis avril 2025, d'un durcissement notable : l'identifiant Android (Android ID) est désormais explicitement classé comme identifiant d'appareil devant être déclaré dès qu'un SDK d'analyse y accède, et Google confronte désormais activement les déclarations Data Safety au binaire réel de l'application, avec suspension possible du compte développeur en cas d'écart.
| Exigence | iOS (Apple) | Android (Google) |
|---|---|---|
| Autorisation de suivi entre applications | Invite App Tracking Transparency avant tout accès à l'IDFA, depuis iOS 14.5 | Consent Mode v2 avec quatre signaux de consentement, obligatoire depuis mars 2024 pour le trafic EEE |
| Étiquette de confidentialité en boutique | Privacy Nutrition Label, recoupée avec le Privacy Manifest de chaque SDK | Section Data Safety, confrontée au binaire réel de l'app depuis 2025-2026 |
| Documentation des SDK tiers | Privacy Manifest obligatoire depuis le 1er mai 2024, contrôlé à la soumission | Pas d'exigence de manifeste équivalent ; la responsabilité repose sur la déclaration de l'éditeur |
| Identifiants d'appareil | IDFA soumis à l'ATT ; IDFV utilisable sans ATT mais soumis au RGPD (voir sanction Voodoo) | AAID (Advertising ID Android), considéré comme donnée personnelle par la CNIL et soumis au consentement ; Android ID classé identifiant d'appareil à déclarer depuis avril 2025 |
Minimisation des Données, Rétention et Audit des SDK
La gestion du consentement est l'exigence la plus visible, mais la minimisation des données et la définition de durées de rétention sont tout aussi importantes et bien plus souvent négligées. Chaque champ collecté, chaque permission demandée, chaque SDK intégré devrait pouvoir être justifié par une finalité précise et déclarée. Demander la date de naissance quand seule une tranche d'âge est nécessaire, ou solliciter une géolocalisation précise quand une granularité de ville suffit à la fonctionnalité, constitue une violation du principe de minimisation, pas une simple maladresse de design. Ces décisions se prennent au moment de la conception du produit, pas lors d'une revue de conformité une fois l'app déjà publiée.
Des durées de rétention doivent exister pour chaque catégorie de données, documentées de façon à pouvoir être présentées lors d'un contrôle. Les données de compte doivent être conservées pour la durée de la relation contractuelle, plus un délai post-résiliation documenté ; les événements de mesure d'audience, pour une durée liée à la finalité déclarée. Les données faisant l'objet d'un retrait de consentement doivent être supprimées, et cette suppression doit s'appliquer partout, pas seulement dans la base de l'app elle-même, mais aussi chez les plateformes d'analyse, les fournisseurs d'attribution et tout sous-traitant dont le contrat encadre ces données.
Auditer les SDK tiers par rapport à leur pratique déclarée, et vérifier par une analyse du trafic réseau, pas uniquement à partir de la documentation du fournisseur, que le SDK arrête effectivement de transmettre des données lorsque l'utilisateur refuse, est le point structurellement le plus important et le moins constamment réalisé de la conformité mobile. C'est précisément ce que la campagne de contrôle CNIL vérifie depuis le printemps 2025, et c'est la même faille technique qui a coûté 500 000 dollars à l'éditeur américain Tilting Point Media en juin 2024, sanctionné par le procureur général de Californie et la ville de Los Angeles pour des SDK publicitaires mal configurés qui continuaient de collecter et partager des données d'enfants malgré un refus enregistré côté interface. Le guide de la CNIL sur la cartographie des données détaille la méthode pour inventorier ces flux avant même d'entamer l'audit des SDK proprement dit. Learn more about qualifier chaque SDK comme responsable ou sous-traitant avant de l'auditer.
Transparence, Droits des Personnes et Contrôles Utilisateur dans les Apps
Une politique de confidentialité accessible depuis l'application, et non uniquement depuis un site web associé, reste une exigence de base trop souvent oubliée lors du passage du web au mobile. Elle doit être rédigée en langage clair, lister précisément les catégories de données collectées par l'app elle-même et par chaque SDK intégré, et être mise à jour à chaque ajout ou retrait d'un SDK, faute de quoi elle diverge du Privacy Manifest ou de la déclaration Data Safety déposée auprès de la plateforme.
L'utilisateur doit pouvoir modifier ses préférences de consentement aussi facilement qu'il les a données au départ, généralement via un centre de préférences accessible depuis les réglages de l'app, sans avoir à désinstaller puis réinstaller l'application pour repartir d'un état neutre. Les demandes d'exercice des droits (accès, rectification, effacement, opposition) doivent pouvoir être traitées dans le délai légal de 30 jours prévu par le RGPD, ce qui suppose que l'éditeur sache exactement quelles données chaque SDK détient, un exercice impossible sans l'audit décrit plus haut. La gestion des accords de traitement des données avec chaque fournisseur de SDK est la pièce contractuelle qui permet, en pratique, de répercuter une demande de suppression jusqu'au bout de la chaîne de sous-traitance.
Erreurs Courantes Qui Coûtent Cher
Charger les SDK avant la résolution du consentement reste l'erreur la plus fréquente et la plus grave. La signature de trafic est reconnaissable : une requête part vers un endpoint publicitaire ou analytique quelques instants après le lancement de l'app, avant même que l'interface de consentement ne s'affiche. Les outils de contrôle de la CNIL sont conçus pour détecter précisément ce type de séquence, et c'est le déclencheur le plus courant des investigations depuis le début de la campagne de 2025.
Confondre autorisation de plateforme et consentement RGPD est l'erreur structurelle la plus répandue chez les équipes qui ont d'abord construit leur conformité autour d'iOS. Un utilisateur qui accepte l'ATT a accordé un accès technique à l'IDFA dans le cadre du framework Apple, ce qui ne constitue pas une base légale valable au titre du RGPD ; c'est exactement la confusion qui a coûté 3 millions d'euros à Voodoo. Le consentement conditionné, c'est-à-dire un bouton unique « tout accepter » qui verrouille l'accès aux fonctionnalités principales de l'app tant que l'utilisateur n'accepte pas le suivi, est un motif de sanction récurrent : le RGPD exige que le consentement au traitement non essentiel soit libre, ce qui implique que la fonctionnalité principale reste disponible pour qui le refuse. Cette pratique s'inscrit dans ce que le laboratoire d'innovation de la CNIL (LINC) désigne comme des interfaces trompeuses, ou « dark patterns » : un bouton de refus délibérément moins visible que celui d'acceptation, ou un parcours de refus nécessitant davantage de clics, suffit à rendre le consentement recueilli juridiquement invalide, même si une case de refus existe techniquement quelque part dans l'app.
Ne pas mettre à jour le Privacy Manifest ou la section Data Safety lorsqu'un nouveau SDK est intégré devient de plus en plus risqué, à mesure qu'Apple et Google renforcent leurs vérifications automatisées de conformité entre déclaration et binaire réel. Un écart entre pratique déclarée et comportement effectif du SDK constitue à la fois une violation de la politique de boutique et une preuve potentielle en cas de contrôle par la CNIL. Pour situer l'ampleur que peuvent atteindre ces sanctions une fois qu'un dossier est instruit, la liste des amendes RGPD les plus importantes donne un ordre de grandeur utile, y compris hors contexte mobile.
FAQ
Qu'est-ce qui rend une application mobile conforme au RGPD ?
Des bases légales documentées pour chaque type de traitement, un consentement recueilli avant l'initialisation de tout SDK non essentiel, une politique de confidentialité accessible depuis l'app et alignée avec la pratique réelle, des mécanismes fonctionnels d'exercice des droits, et un contrat de traitement des données avec chaque fournisseur de SDK. Pour les utilisateurs situés dans l'Union européenne, ces exigences s'appliquent indépendamment du lieu d'établissement de l'éditeur.
Comment gérer le consentement dans une application mobile en pratique ?
Le SDK de gestion du consentement s'initialise en premier au lancement de l'app. En l'absence d'un enregistrement valide, l'interface de consentement s'affiche avant tout autre traitement, avec des options de refus et d'acceptation présentées à égalité. Seuls les SDK correspondant aux catégories autorisées par l'utilisateur s'initialisent ensuite, et l'enregistrement correspondant est stocké localement puis synchronisé avec un serveur distant, horodaté et versionné.
Les SDK sont-ils automatiquement conformes au RGPD une fois intégrés ?
Non. L'intégration d'un SDK ne transfère aucune conformité automatique : l'éditeur reste responsable du traitement effectué par ce SDK, y compris lorsque son comportement réel diverge de sa documentation. La recommandation CNIL impose explicitement d'obtenir une documentation précise du fournisseur et de vérifier, y compris par analyse du trafic réseau, que le SDK respecte effectivement le consentement recueilli.
L'autorisation App Tracking Transparency d'Apple remplace-t-elle le consentement RGPD ?
Non. L'ATT est une autorisation de plateforme qui opère en parallèle du RGPD, jamais à sa place. Un utilisateur qui accepte l'ATT a accordé un accès technique à l'IDFA dans le cadre du framework Apple, pas une base légale valable pour un traitement RGPD. Les deux couches doivent être satisfaites séparément, dans le bon ordre : consentement RGPD avant sollicitation de l'ATT.
Comment permettre aux utilisateurs de modifier leurs préférences de confidentialité dans l'app ?
Via un centre de préférences accessible depuis les réglages de l'application, offrant la même granularité par finalité que l'interface de consentement initiale, sans obliger l'utilisateur à désinstaller l'app pour revenir à un état neutre. Chaque modification doit générer un nouvel enregistrement horodaté plutôt que d'écraser le précédent, afin de constituer une piste d'audit exploitable en cas de contrôle.
À quelle fréquence faut-il revoir la politique de confidentialité d'une application ?
À chaque ajout, retrait ou mise à jour significative d'un SDK, et au minimum une fois par an même en l'absence de changement technique, pour vérifier que la politique reste alignée avec le Privacy Manifest iOS et la déclaration Data Safety Android en vigueur. Un décalage entre ces trois documents est l'un des signaux que la CNIL et les plateformes détectent le plus facilement lors d'un contrôle.
La conformité des applications mobiles, en 2026, est devenue une discipline d'ingénierie que des régulateurs testent sur le comportement technique réel, pas sur des documents de politique. Les applications qui résistent à l'examen sont celles dont le blocage de consentement fonctionne réellement, dont les flux de données de chaque SDK sont encadrés par un contrat documenté, et dont chaque changement de préférence utilisateur se propage immédiatement à tous les systèmes qui touchent des données personnelles. Maintenir cela manuellement pour le RGPD, le CCPA et les règles de chaque boutique en même temps cesse d'être tenable au-delà de quelques milliers d'utilisateurs actifs. La Solution de Consentement Cookie & SDK de Secure Privacy, avec ses SDK natifs pour iOS, Android, React Native et Flutter, sa détection automatique de la localisation du visiteur, ses journaux de consentement exportables et son support de plus de 70 langues, prend en charge la complexité technique de garder ces couches synchronisées pour que l'équipe produit se concentre sur l'application elle-même. Planifiez une démonstration pour voir comment cela s'applique à votre app.
