Consentement application mobile : auditer vos SDK (amende Fnac)

Votre bandeau de consentement fonctionne, vous l’avez testé. Mais avez-vous vérifié ce que votre application envoie juste après qu’un utilisateur a cliqué sur « Refuser » ? C’est exactement la question qui vient de coûter 7 millions d’euros à la Fnac : la CNIL a sanctionné un traceur présent dans son application mobile qui continuait d’envoyer l’activité des utilisateurs à un tiers, refus ou pas. C’est tout l’enjeu du consentement application mobile : il ne se joue pas dans l’écran de choix, il se joue dans les requêtes réseau de vos SDK.

Ce guide prend le sujet côté tracking : ce qui a été reproché exactement, quels SDK exigent un accord préalable, et surtout une méthode d’audit que vous pouvez dérouler en une demi-journée avec un proxy, puis rejouer à chaque version de l’app. Avec les réglages des SDK les plus courants et une checklist de recette.

Comme toujours sur ces sujets : rien ici n’est un avis juridique. Je vous renvoie aux textes de la CNIL, à lire avec la personne qui porte la conformité chez vous.

Ce que la CNIL reproche à la Fnac, en clair

Les faits, tels que la CNIL les a publiés (communiqué de la sanction) : la formation restreinte a prononcé le 22 octobre 2026 (délibération SAN-2026-015) une amende de 7 millions d’euros, soit 6 millions pour Fnac Darty Participations et Services et 1 million pour Fnac Direct. La décision a été rendue publique le 29 octobre. Tout part d’une plainte de l’association noyb, suivie d’un contrôle de l’application en mars 2024.

Le traceur en cause envoyait, par des appels d’API vers un domaine tiers, un identifiant attribué par la Fnac et l’activité de l’utilisateur, notamment les produits consultés. Finalité : afficher des recommandations personnalisées (accessoires, services, produits similaires) et entraîner l’algorithme de recommandation. La CNIL ne nomme pas le fournisseur, et je ne vais pas jouer aux devinettes.

Un traceur de recommandation n’est pas « strictement nécessaire »

Le fondement est l’article 82 de la loi Informatique et Libertés, le même que pour les cookies d’un site. Deux exemptions seulement : le traceur sert à la transmission de la communication, ou il est strictement nécessaire à un service expressément demandé par l’utilisateur. La CNIL a estimé que la recommandation de produits ne rentre dans aucune des deux. L’utilisateur a demandé une app pour acheter, pas un moteur qui apprend de sa navigation.

C’est le point à retenir pour vos propres arbitrages : « ça améliore l’expérience » n’est pas une exemption. Personnalisation, ciblage commercial, entraînement d’un modèle : consentement préalable.

Le vrai manquement : le refus n’est pas respecté

Selon la CNIL, les sociétés n’ont pas pris en compte le choix de l’utilisateur de ne pas consentir. Autrement dit, ce n’est pas l’absence de bandeau qui est sanctionnée, c’est un bandeau dont le « non » ne coupait pas le flux. En plus de l’amende, la CNIL a prononcé une injonction de mise en conformité sous un mois, avec une astreinte de 10 000 euros par jour de retard.

D’expérience, c’est aussi le défaut que je rencontre le plus souvent en recette d’app : le bandeau est branché sur deux ou trois SDK, et un quatrième, ajouté plus tard par une autre équipe, n’a jamais été relié à la plateforme de consentement.

Consentement application mobile : quels SDK exigent un accord préalable

La CNIL a publié en septembre 2024 une recommandation dédiée aux applications mobiles, mise à jour le 8 avril 2025 (page de la CNIL). Elle vise toute la chaîne : éditeurs, développeurs, fournisseurs de SDK, systèmes d’exploitation et magasins d’applications. Le principe ne change pas : tout traitement non nécessaire au fonctionnement de l’app demande un consentement, et le refus doit être aussi simple que l’acceptation. La CNIL avait annoncé une campagne de contrôles dédiée aux applications à partir du printemps 2025.

Analytics, attribution, publicité, recommandation

Ce qui reste exempté, et pourquoi la mesure d’audience d’app l’est rarement

L’exemption de mesure d’audience existe, mais elle est étroite : statistiques anonymes, strictement limitées à l’éditeur, sans croisement ni transmission à des tiers. Un SDK analytics qui partage ses données avec une régie, active des signaux publicitaires ou suit l’utilisateur d’une app à l’autre en sort immédiatement. Et attention à un raccourci fréquent : la permission système (localisation, notifications, ATT sur iOS) n’est pas un consentement RGPD. La recommandation CNIL rappelle qu’accepter la géolocalisation pour un service ne vaut pas accord pour la publicité personnalisée.

Auditer les SDK de votre app en une demi-journée

Le seul audit qui compte, c’est le réseau. Une liste de SDK dans un tableur vous dit ce qui devrait se passer ; une capture des requêtes vous dit ce qui se passe.

Inventaire : SDK déclarés et SDK embarqués

Commencez par la liste des dépendances du projet (Gradle côté Android, CocoaPods ou Swift Package Manager côté iOS). Puis cherchez ce qui n’y figure pas en clair : un SDK de régie peut embarquer ses propres sous-SDK, et une librairie de paiement ou de chat peut appeler un service d’analytics. Pour chaque SDK, notez sa finalité, son domaine d’appel et la façon dont il est (ou n’est pas) relié à votre plateforme de consentement.

Le test réseau sur refus avec un proxy

Installez un proxy d’interception sur votre poste (Charles, Proxyman ou mitmproxy), faites passer le trafic du téléphone de test par ce proxy et installez son certificat. Puis déroulez ce scénario, que je considère comme le minimum :

1. désinstallez l’app, puis réinstallez-la, pour repartir d’un état vierge ;
2. lancez la capture avant d’ouvrir l’app : les appels faits au démarrage, avant tout choix, sont les plus révélateurs ;
3. au bandeau, cliquez sur « Refuser tout » ;
4. naviguez sur trois fiches produit, ajoutez un article au panier, faites une recherche ;
5. tuez l’app, relancez-la, refaites un parcours court : certains SDK ne relisent le consentement qu’au démarrage suivant, ou l’oublient.

Résultat attendu : zéro appel vers les domaines tiers soumis à consentement, que ce soit avant le choix ou après le refus. Recommencez ensuite avec « Accepter tout » : vous devez voir les appels apparaître. Si rien ne change entre les deux, votre bandeau est décoratif.

Une limite à connaître : certaines apps refusent les certificats de proxy (certificate pinning). Dans ce cas, faites l’audit sur un build de recette où le pinning est désactivé, plutôt que de conclure trop vite à l’absence d’appels.

Lire les requêtes : identifiants, événements, domaines tiers

Filtrez la capture par domaine et regardez trois choses dans chaque requête vers un tiers : un identifiant persistant (identifiant client, identifiant publicitaire, identifiant d’installation), un nom d’événement ou d’écran, et un contenu métier (référence produit, catégorie, montant de panier). Un appel vers un tiers qui contient un identifiant client et des références produits après un refus, c’est précisément le schéma sanctionné chez la Fnac.

Les réglages de consentement des SDK courants

Les noms de méthodes ci-dessous viennent de la documentation des éditeurs, consultée en novembre 2026. Ils évoluent avec les versions majeures des SDK : vérifiez toujours dans la documentation de votre version.

Firebase et GA4 : le consent mode pour les apps

Google applique aux apps le même consent mode que sur le web, avec quatre types : analytics_storage, ad_storage, ad_user_data et ad_personalization (documentation Google). Le principe en deux temps :

• un état par défaut refusé, déclaré avant même le premier lancement : clés GOOGLE_ANALYTICS_DEFAULT_ALLOW_ANALYTICS_STORAGE (et ses équivalentes pour les trois autres types) à false dans l’Info.plist sur iOS, meta-data google_analytics_default_allow_* dans le manifeste sur Android ;
• une mise à jour au choix de l’utilisateur avec setConsent, qui ne modifie que les types passés et persiste d’un lancement à l’autre.

Si vous préférez couper toute collection tant que l’utilisateur n’a pas choisi, Firebase propose aussi de désactiver la collecte au démarrage puis de la réactiver avec setAnalyticsCollectionEnabled. Pour vérifier, activez les logs détaillés : Firebase affiche l’état de chaque type de consentement dans la console de debug. Si vous suivez déjà les conversions d’app dans GA4, je détaille leur lecture dans les rapports dans mon guide sur les conversions app dans les rapports cross-canal GA4 ; et le comportement de GA4 en cas de refus est le même que côté web, décrit dans Consent Mode v2 dans GA4.

Adjust et les MMP : rien avant le choix

Pour un MMP, la règle la plus robuste est simple : n’initialisez pas le SDK tant que l’utilisateur n’a pas fait son choix, et ne l’initialisez pas du tout en cas de refus si votre usage ne relève d’aucune exemption. Adjust fournit aussi des méthodes dédiées (documentation Adjust) : trackThirdPartySharing pour encadrer le partage avec les partenaires (à appeler avant l’initialisation), trackMeasurementConsent pour transmettre le consentement à la mesure, et gdprForgetMe pour les demandes d’effacement. AppsFlyer et les autres MMP ont des équivalents : cherchez « start » ou « init » différé dans leur documentation.

Meta SDK et SDK publicitaires : couper l’initialisation automatique

Le SDK Meta s’initialise et journalise des événements tout seul par défaut. Meta documente comment le retarder (documentation Meta) : sur Android, une meta-data com.facebook.sdk.AutoInitEnabled à false dans le manifeste, et le flag AutoLogAppEventsEnabled à false ; après consentement, FacebookSdk.setAutoInitEnabled(true) puis FacebookSdk.fullyInitialize(). Même logique pour les SDK de régies : cherchez systématiquement l’option d’initialisation manuelle.

Le cas server-side : un proxy ne vous exonère pas

Faire passer vos flux par un serveur sGTM ou un proxy maison change le domaine appelé, pas l’obligation. Si votre serveur relaie ensuite l’activité de l’utilisateur vers une régie ou un moteur de recommandation, c’est toujours un traceur soumis au consentement, et c’est même plus difficile à auditer depuis le téléphone, puisque tout part vers votre domaine. Si vous avez une architecture de tracking server-side pour application mobile, le contrôle se fait aussi côté serveur : chaque événement doit porter l’état de consentement, et chaque tag sortant doit le respecter.

Checklist de recette à rejouer à chaque version

La dernière ligne compte plus qu’elle n’en a l’air : la CNIL demande à la Fnac de démontrer que son nouvel outil recueille le consentement. Une capture datée par version, c’est votre meilleure preuve.

FAQ

Qu’est-ce que la CNIL reproche exactement à la Fnac ?

Un traceur de son application mobile transmettait à un tiers un identifiant et l’activité de l’utilisateur, notamment les produits consultés, pour des recommandations personnalisées, sans tenir compte de son refus. Amende de 7 millions d’euros et injonction sous astreinte.

Les SDK d’analytics d’une app exigent-ils tous un consentement ?

Presque toujours. L’exemption de mesure d’audience est étroite (statistiques anonymes, réservées à l’éditeur, sans transmission à des tiers) et la plupart des SDK du marché en sortent dès qu’un signal publicitaire est activé.

La permission ATT sur iOS suffit-elle ?

Non. L’App Tracking Transparency est une permission d’Apple sur l’identifiant publicitaire ; elle ne remplace pas le consentement exigé par l’article 82 pour les autres traceurs.

Comment prouver que mon app respecte le refus ?

Avec une capture réseau réalisée après un refus, sur une installation vierge, archivée avec le numéro de version de l’app. À refaire à chaque version qui ajoute ou met à jour un SDK.

Ce qu’il faut retenir

L’amende Fnac ne sanctionne pas un bandeau absent, elle sanctionne un refus ignoré. Pour le consentement de votre application mobile, la seule vérification qui vaille se fait dans le réseau : installation vierge, refus, parcours, capture. Planifiez cet audit cette semaine sur votre version en production, branchez-le ensuite dans votre recette de release, et commencez par les SDK de personnalisation et de publicité : c’est là que se trouve le risque, et souvent les surprises.