Confidentialité et consentement pour les apps mobiles e-commerce : RGPD, CCPA, suivi, notifications push et choix du client

La confidentialité dans une app d'achat est bien plus que de la paperasse juridique. Elle touche la confiance des clients, la portée de votre marketing, l'attribution et l'approbation sur l'App Store. Si vous vous trompez, vous pouvez abîmer la confiance à l'installation, perturber la mesure et risquer un refus. Si vous faites les choses bien, les clients disposent de choix plus clairs et vos équipes travaillent sur des données plus fiables.

Ce guide donne aux équipes produit et marketing les distinctions dont elles ont besoin avant de lire les guides détaillés sur le suivi, le consentement aux notifications push, la conception du centre de confidentialité, la rétention et les fournisseurs. Il couvre les règles européennes et californiennes, les cas où l'autorisation de suivi d'Apple s'applique, le fonctionnement du consentement aux notifications push, et ce qu'il faut à un centre de confidentialité pour être utilisable.

Périmètre, et ce que ceci n'est pas. Ceci est une vue d'ensemble stratégique pour les équipes produit et marketing. Ce n'est pas un avis juridique et cela ne remplace ni un avocat ni un délégué à la protection des données. Les règles évoluent souvent et varient selon la juridiction. Ce qui s'applique à votre app dépend de vos propres flux de données, de vos marchés et de votre mise en œuvre. Traitez tout ce qui suit comme des questions à trancher avec un conseil juridique, vérifiez les exigences en vigueur à la source, et faites relire votre configuration précise avant de vous y fier. Cet avertissement couvre tout l'article.

Le principe à transmettre à vos équipes

Un écran de consentement n'est pas une politique de confidentialité, et une autorisation système n'est pas automatiquement un consentement au sens juridique. Ce sont quatre choses distinctes. Beaucoup d'erreurs de conformité dans les apps de commerce commencent quand une équipe les confond.

• Une politique de confidentialité est un document d'information. Elle explique ce que vous faites. À elle seule, elle ne constitue en général pas un consentement, même si elle fait souvent partie d'une information obligatoire ou d'une obligation de transparence.
• Un écran de consentement est l'endroit où le client fait un choix réel et éclairé sur les usages facultatifs de ses données.
• Une autorisation système (l'invite de suivi d'iOS, l'invite de notifications d'Android) est le contrôle du système d'exploitation. L'accorder n'équivaut pas à donner un consentement au sens des règles européennes, et cela ne remplace pas les choix que vous proposez dans l'app.
• Un droit du client sur ses données (accès, effacement, opposition à la vente ou au partage) est une procédure que vous devez honorer, distincte de tout interrupteur de consentement.

Quand une équipe intègre que ces éléments sont distincts, la plupart des décisions de conception deviennent plus simples. La suite de ce guide parcourt les couches dans l'ordre.

Les cinq couches de données d'une app d'achat

Chaque activité porte des obligations différentes. Ne traitez pas « les données de l'app » comme un bloc unique. Séparez les activités, car chacune peut avoir une base légale et une promesse client différentes.

Les données nécessaires au service, l'analytique facultative, le suivi publicitaire, l'autorisation marketing et les droits des personnes sont des sujets distincts. Quand vous vous appuyez sur le consentement pour des usages facultatifs, les articles 5 à 7 du RGPD exigent qu'il soit démontrable, clairement distinct, intelligible et facile à retirer. Ils imposent aussi la limitation des finalités, la minimisation des données et une conservation limitée à la durée nécessaire. Le CEPD rappelle que retirer son consentement doit être aussi simple que de le donner.

Le RGPD n'est pas la seule règle en Europe

Ne réduisez pas « la confidentialité européenne » au seul RGPD. Les règles sur le marketing électronique et sur l'accès au terminal coexistent avec le RGPD, et elles peuvent exiger un consentement là où le RGPD seul ne l'exigerait peut-être pas. Au Royaume-Uni, le règlement PECR encadre le marketing électronique et toute technologie qui stocke des informations sur le terminal de l'utilisateur ou y accède. Les recommandations de l'ICO indiquent explicitement que cela inclut les apps mobiles. Quand les deux régimes s'appliquent, vous devez satisfaire les deux.

L'effet pratique pour une app d'achat :

• Les messages marketing (e-mail, SMS et souvent le marketing dans l'app) peuvent déclencher les règles de consentement ePrivacy en plus du RGPD, d'après les recommandations de l'ICO sur PECR.
• Stocker ou lire des données sur le terminal, y compris les identifiants de SDK et les technologies similaires dans une app, relève des recommandations de l'ICO sur les technologies de stockage et d'accès, et pas du seul RGPD.

Ne dites pas « le RGPD exige un consentement pour l'analytique et la publicité » comme règle générale. Dites que le consentement doit être démontrable, spécifique à une finalité et facile à retirer là où vous vous appuyez dessus, au titre du RGPD ou des règles ePrivacy applicables. Tranchez la base de chaque activité avec un conseil juridique et votre cartographie des données.

Ce que doit montrer le premier écran de choix

Le premier écran de confidentialité doit aider le client à faire un vrai choix, pas le pousser à travers un document juridique. Expliquez les usages facultatifs simplement.

Une première couche complète contient :

• Le nom de la marque (le responsable de traitement).
• Une explication courte de ce qui est nécessaire au fonctionnement de l'app.
• Des explications distinctes et en langage clair pour chaque finalité facultative : analytique et amélioration de l'app ; publicité personnalisée et mesure ; communications marketing.
• Une phrase claire indiquant que les achats et les fonctions principales continuent de fonctionner si les choix facultatifs sont refusés.
• Des actions d'égale visibilité, par exemple N'utiliser que les données nécessaires, Autoriser les données facultatives et Gérer mes choix. Ne rendez pas le bouton d'acceptation voyant et le refus discret sous forme de lien.
• Un accès à la politique de confidentialité et aux informations détaillées sur les fournisseurs.
• Une mention indiquant que les choix se modifient plus tard dans Profil ou Réglages.

Pour les utilisateurs de l'EEE, du Royaume-Uni et de Suisse, quand la publicité ou la mesure Google entrent en jeu, la politique de consentement de l'utilisateur de l'UE de Google attend une information claire, une action affirmative, une mention de la personnalisation publicitaire dès la première couche, l'indication que des tiers (dont Google) reçoivent des données, et un lien vers les informations de Google sur l'usage responsable des données. En clair : n'enterrez pas « publicité personnalisée » derrière une formule aimable du type « améliorer votre expérience ».

Un exemple de première couche pensé pour le client :

Vos choix de confidentialité Nous utilisons les données nécessaires à votre compte, votre panier, le paiement et le suivi de vos commandes. Avec votre autorisation, nous utilisons aussi votre activité dans l'app et les informations de votre appareil pour comprendre ce qui fonctionne, mesurer la publicité et vous montrer des offres plus pertinentes. Vous pouvez modifier ces choix à tout moment dans Profil > Confidentialité et marketing. N'utiliser que les données nécessaires | Autoriser les données facultatives | Gérer mes choix

L'écran de détail derrière « Gérer mes choix » doit ensuite séparer les options par finalité (analytique, publicité, marketing), et non par étiquettes vagues du type « partenaires marketing ».

Quand et comment demander l'autorisation ATT

App Tracking Transparency est une exigence de plateforme d'Apple, pas un substitut aux choix européens ou californiens. Apple impose l'invite ATT quand une app relie ses données aux données des apps, sites et propriétés hors ligne d'autres entreprises, à des fins de publicité ciblée ou de mesure publicitaire. D'après les recommandations d'Apple sur la vie privée, cela s'applique même quand l'identifiant est un e-mail ou un numéro de téléphone haché, et pas l'identifiant publicitaire.

La bonne approche est étroite et honnête :

1. Ne demandez que si l'app effectue réellement le suivi tel qu'Apple le définit.
2. Expliquez d'abord l'intérêt dans une pré-invite courte, à l'intérieur de l'app.
3. Affichez ensuite l'invite ATT système d'Apple.
4. Ne conditionnez jamais les achats, le contenu, les offres ou les récompenses à l'acceptation du suivi.
5. Revérifiez le statut de l'autorisation aux lancements suivants, et arrêtez le suivi s'il n'est plus autorisé.

Apple autorise une pré-invite transparente, mais interdit la manipulation, le retrait de fonctionnalités et la rémunération des personnes en échange de l'autorisation de suivi. Par exemple :

Aidez-nous à mesurer notre publicité Si vous autorisez le suivi, nous pouvons mesurer quelles publicités amènent des clients dans l'app et rendre notre publicité moins répétitive. Votre expérience d'achat fonctionne dans les deux cas. Continuer | Pas maintenant

Le texte de finalité système doit dire ce que font les données, et non promettre vaguement « une meilleure expérience ». Par exemple : « Nous utilisons l'identifiant de votre appareil pour mesurer la performance publicitaire et personnaliser la publicité sur les apps et sites d'autres entreprises. » Ne l'affichez que si c'est vrai. Si votre app fait de l'analytique de première partie, au sein de la même marque et sans suivi inter-entreprises, ATT peut ne pas s'appliquer du tout, mais cette qualification relève de votre cartographie des données et de votre revue juridique. Pour la décision complète, la rédaction du texte de finalité et ce qu'il advient de votre mesure publicitaire en cas de refus, voir App Tracking Transparency : quand une app e-commerce a besoin d'ATT et comment le demander.

Séparez le consentement aux notifications du consentement marketing

L'autorisation de notifications push se gaspille facilement. Une app de commerce ne doit pas confondre « nous vous tenons au courant de votre commande » et « nous vous faisons du marketing ». Sur Android 13 et versions ultérieures, les nouvelles apps ont besoin de l'autorisation d'exécution POST_NOTIFICATIONS, et Android recommande de la demander en contexte, avec une explication claire. Apple exige lui aussi l'autorisation de l'utilisateur pour les notifications susceptibles de le déranger.

Quatre choses distinctes sont en jeu, et c'est en les confondant que les marques se mettent en difficulté :

1. Les messages de commande, de livraison, de sécurité et de compte.
2. Les messages de retour en stock, de baisse de prix, de fidélité et de promotion.
3. Le réglage de notifications de l'appareil, au niveau système.
4. La préférence marketing de la marque à l'intérieur de l'app.

Les App Store Review Guidelines d'Apple exigent un consentement explicite dans l'app pour les notifications push promotionnelles, ainsi qu'un moyen de se désinscrire dans l'app. Les notifications push ne peuvent pas non plus être obligatoires pour que l'app fonctionne. Demandez donc en contexte, puis proposez des catégories :

Soyez prévenu quand ça compte Activez les notifications pour les changements de livraison, le retour en stock de vos articles enregistrés et les offres que vous choisissez. Vous pouvez modifier les catégories ou tout désactiver à tout moment. Activer les notifications | Pas maintenant

Les catégories peuvent être : commandes et livraisons ; retours en stock et baisses de prix ; fidélité et récompenses ; nouveautés et soldes. La règle qui compte : ne laissez jamais entendre qu'accepter les informations de livraison vaut consentement au marketing promotionnel. Pour le détail complet des deux décisions distinctes derrière le consentement aux notifications push et la conception du centre de préférences, voir consentement aux notifications push : autorisation, consentement marketing et conception du centre de préférences. Pour bien exploiter les notifications push une fois le consentement obtenu, voir notifications push : le canal de rétention que les marques Shopify n'ont pas encore construit. Les notifications push ont leur propre voix. Ce n'est pas un e-mail moins cher.

Le centre de confidentialité dans le Profil

Le centre de confidentialité doit être un écran de l'app, pas un lien enfoui dans une page juridique. Le client a besoin d'un chemin évident pour modifier ses choix, et ces contrôles doivent produire un effet réel. Une structure possible :

Profil
  Confidentialité et marketing
    - Vos choix de confidentialité
        - N'utiliser que les données nécessaires / Retirer le consentement facultatif
        - Analytique et amélioration de l'app
        - Publicité personnalisée et mesure
    - Préférences marketing
        - Notifications push : commandes / retours en stock / fidélité / offres
        - Préférences e-mail
        - Préférences SMS
    - Autorisations de l'appareil
        - Suivi : statut + « Ouvrir les réglages de l'appareil »
        - Notifications : statut + « Ouvrir les réglages de l'appareil »
    - Vos choix de confidentialité en Californie
        - Ne pas vendre ni partager mes informations personnelles
        - Limiter l'utilisation de mes informations personnelles sensibles  (uniquement si vous traitez des données personnelles sensibles)
    - Télécharger mes données / demander l'accès
    - Supprimer le compte / demander l'effacement de mes données personnelles
    - Politique de confidentialité
    - Nos prestataires et sous-traitants ultérieurs

Deux remarques de conception sur cette arborescence. Premièrement, « Supprimer le compte » et « demander l'effacement de mes données personnelles » sont liés, mais ce n'est pas toujours la même procédure. Nommez chaque action pour ce qu'elle fait, plutôt que de laisser croire qu'un bouton efface tout. Deuxièmement, une demande de droits n'est pas un simple clic : l'accès et l'effacement peuvent exiger une vérification d'identité et restent soumis à des exceptions légales, par exemple les registres de commandes et les données fiscales que vous êtes tenu de conserver. Concevez le parcours pour vérifier le demandeur et pour expliquer ce qui peut être effacé et ce qui ne peut pas l'être, plutôt que de promettre un effacement total et immédiat.

L'action « retirer le consentement facultatif » doit elle aussi faire plus que déplacer un interrupteur à l'écran. Pour être réelle, elle doit arrêter la collecte et la transmission par les SDK facultatifs, stopper les audiences de publicité personnalisée et le marketing à venir lorsque cela s'applique, mettre à jour l'état du consentement dans les systèmes connectés, empêcher l'envoi des événements facultatifs en file d'attente, conserver une trace d'audit minimale du changement, et afficher une confirmation avec une date d'effet.

La mise en œuvre compte plus que l'intention. Pour Google Analytics pour Firebase, le mode de consentement prend en charge des états par défaut et des mises à jour pour analytics_storage, ad_storage, ad_user_data et ad_personalization. L'état retenu persiste jusqu'à sa modification. Un mécanisme de retrait doit mettre à jour l'état du SDK, pas seulement repeindre l'interface. Pour la conception complète de l'écran, voir comment concevoir un centre de confidentialité d'app mobile réellement utilisable.

Pourquoi la Californie mérite son propre traitement CCPA et CPRA

Pour les entreprises soumises à la CCPA et à la CPRA, le modèle californien diffère du modèle européen. Ne réutilisez pas un écran européen de consentement préalable en considérant le sujet réglé. Les consommateurs californiens ont le droit de savoir, de faire effacer, de faire rectifier, de limiter certains usages de données sensibles et de s'opposer à la vente ou au partage de leurs informations personnelles. Le « partage » peut inclure la publicité comportementale entre contextes. D'après les recommandations du procureur général de Californie sur la CCPA, une entreprise concernée doit informer au moment de la collecte ou avant, décrire les catégories de données et les finalités, et fournir une voie d'opposition ainsi qu'un lien vers la politique de confidentialité lorsque des données sont vendues ou partagées.

La conséquence importante en conception : l'Europe fonctionne largement sur un modèle d'accord préalable pour les usages facultatifs, tandis que la Californie fonctionne largement sur un modèle d'opposition. Utilisez des contrôles clairs et nommés :

Vos choix de confidentialité Ne pas vendre ni partager mes informations personnelles Limiter l'utilisation de mes informations personnelles sensibles

N'affichez « Limiter l'utilisation de mes informations personnelles sensibles » que si l'entreprise traite réellement des données personnelles sensibles d'une façon qui déclenche ce droit. Ce n'est pas une entrée de menu universelle, et l'ajouter quand elle ne s'applique pas est une autre façon d'induire en erreur.

Global Privacy Control et les signaux d'opposition

La Californie exige plus qu'un bouton dans l'app. Les entreprises concernées qui vendent ou partagent des données doivent respecter les signaux valides de préférence d'opposition, comme Global Privacy Control (GPC). Les exemples d'application de la loi en Californie reprochent à des commerçants de ne pas avoir respecté GPC. Un accord de 2026 a également porté sur le traitement de GPC appareil par appareil pour les personnes connectées.

GPC est avant tout un signal de navigateur : sa transposition à une app native demande donc de la prudence.

• L'app doit proposer ses propres contrôles de confidentialité clairs (l'action « Ne pas vendre ni partager » ci-dessus).
• Le site doit respecter les signaux de préférence d'opposition du navigateur qui lui sont applicables, comme GPC.
• Quand la personne est authentifiée sur le web et dans l'app, votre conseil juridique doit déterminer comment une opposition reconnue s'applique à l'ensemble de cette relation client, plutôt que de traiter chaque appareil isolément.

L'agence californienne de protection de la vie privée insiste également : les choix de confidentialité doivent être clairs et équilibrés, et non des interfaces trompeuses conçues pour décourager l'opposition. Refuser doit être aussi simple qu'accepter, en Californie comme ailleurs.

Le registre des consentements et la cartographie des données

Un enregistrement de consentement doit refléter une décision réelle, pas un champ vague du type consent = true. Vous devez savoir ce qui a été montré et ce que le client a choisi. Ne stockez que ce qui est nécessaire pour démontrer et appliquer ce choix :

• L'identifiant interne du client, de l'appareil ou l'identifiant pseudonymisé
• La région et la langue au moment de la décision
• La date et l'heure
• La version de l'app et la version de l'écran de consentement
• Les finalités exactes affichées, et l'ensemble des fournisseurs et SDK affichés
• Le choix pour chaque finalité
• La façon dont le choix a été recueilli
• L'historique des retraits et des modifications
• L'état de propagation vers les systèmes connectés, lorsque cela s'applique

Ne mettez pas dans le registre des consentements l'historique comportemental brut, des enregistrements d'écran complets ou des identifiants inutiles. Tenez à côté une cartographie des données qui consigne, pour chaque type de donnée, la finalité, la base légale, le système, le destinataire, la région, la règle de conservation, la voie d'effacement et le responsable. Servez-vous de cette cartographie pour vos notices de confidentialité, les étiquettes App Store, les déclarations CCPA, les demandes d'effacement et les listes de sous-traitants ultérieurs.

Point de contrôle AIPD. Quand votre cartographie fait apparaître un traitement à risque plus élevé, par exemple une surveillance systématique, des données sensibles ou du profilage à grande échelle, demandez à votre délégué à la protection des données ou à votre conseil juridique si une analyse d'impact relative à la protection des données est requise avant de construire. C'est la cartographie qui vous dit si vous avez franchi cette ligne.

Il n'existe pas de durée de conservation universelle

Aucune règle ne dit « conservez les données X années ». Les données ne doivent pas être conservées plus longtemps que nécessaire au regard de la finalité annoncée : chaque type de donnée appelle donc sa propre durée. Un calendrier défendable peut ressembler à ceci :

Écartez les deux facilités opposées. « On garde tout au cas où » se heurte à la limitation de la conservation. « On supprime tout immédiatement » peut se heurter à des obligations fiscales, de lutte contre la fraude, de garantie ou de suppression de contacts. Pour le modèle complet de calendrier, le fonctionnement de l'effacement dans les sauvegardes et chez les tiers, et la procédure de demandes de droits, voir conservation et effacement des données d'app mobile : quoi garder, pourquoi et combien de temps.

Sous-traitants ultérieurs, SDK et notices de confidentialité

Une liste de sous-traitants ultérieurs n'est pas un mur de logos. Pour chaque société qui traite des données personnelles sur vos instructions ou sur celles de votre prestataire, vous devez pouvoir indiquer le nom de l'entité juridique, le service et la finalité du traitement, les catégories de données concernées, si elle agit comme sous-traitant, sous-traitant ultérieur ou responsable indépendant, les lieux de traitement, le mécanisme de transfert international lorsque cela s'applique, un lien vers son accord de sous-traitance ou sa documentation de confidentialité, la date d'ajout et le statut, et la façon dont les clients sont informés des changements.

Un socle technique typique d'app de commerce comprend l'hébergement cloud et l'infrastructure de base de données, un CDN, un fournisseur d'authentification, la surveillance des erreurs et le rapport de plantages, l'analytique produit, l'infrastructure d'envoi des notifications push, une plateforme de support client, un fournisseur d'e-mail et de SMS, un entrepôt de données, des SDK d'attribution et de publicité, les intégrations Shopify et paiement, et les services Apple et Google. N'étiquetez pas automatiquement chaque fournisseur comme sous-traitant ultérieur : une plateforme publicitaire, un prestataire de paiement ou l'opérateur d'un store peut agir dans un rôle juridique différent selon le flux et le contrat, et cette analyse des rôles doit être exacte.

Un point propre à la plateforme : Apple exige que les apps déclarent, dans les informations de confidentialité de l'App Store, les données collectées par les SDK tiers, et qu'elles expliquent dans la politique de confidentialité le partage avec des tiers, la conservation et l'effacement, ainsi que le retrait du consentement. Ces étiquettes de confidentialité App Store font partie de votre fiche, et s'y tromper crée un risque de refus et de confiance, au même titre qu'une fiche mal remplie. Si vous travaillez sur votre fiche, voir comment remplir la fiche de votre app sans vous faire refuser. Pour la checklist fournisseurs complète, l'analyse des rôles, les transferts et les déclarations de SDK, voir registres des rôles fournisseurs, sous-traitants ultérieurs et notices de confidentialité des SDK pour les apps de commerce.

Les signaux de consentement pour l'analytique et la publicité

Si vous faites de l'analytique ou de la publicité auprès d'utilisateurs de l'EEE, le choix de consentement doit atteindre les systèmes qui traitent les données. Un client peut refuser la publicité personnalisée dans la première couche, mais si les SDK et les régies ne reçoivent jamais ce choix, vous continuez de collecter et de transmettre des données comme s'il avait dit oui.

Pour Google Analytics pour Firebase et les produits publicitaires de Google, le mode de consentement est le mécanisme qui transporte le choix : des états par défaut fixés avant la collecte, et des mises à jour au moment où le client décide, sur analytics_storage, ad_storage, ad_user_data et ad_personalization. Une plateforme de gestion du consentement (CMP) peut orchestrer tout cela, mais le principe tient quel que soit l'outil : l'état choisi par votre client doit être l'état dans lequel se trouvent vos SDK. Pour comprendre le comportement réel du mode de consentement (y compris pourquoi un « refusé » n'arrête pas toujours les données vers Google), la place d'une CMP et pourquoi le choix doit aussi atteindre vos SDK non Google, voir Google Consent Mode et CMP pour les apps mobiles.

Ce que votre équipe doit produire

La confidentialité d'une app, ce n'est pas un écran. Avant le lancement, une marque Shopify devrait disposer de tout ceci :

1. Une cartographie des données : type de donnée, finalité, base légale, système, destinataire, région, conservation, voie d'effacement, responsable.
2. Un registre des rôles fournisseurs : chaque fournisseur nommé, avec son rôle juridique réel (sous-traitant, sous-traitant ultérieur ou responsable indépendant) et son mécanisme de transfert.
3. Une conception du consentement : un choix de première couche et un écran de détail par finalité, où refuser est aussi simple qu'accepter.
4. Un test de propagation : la preuve qu'un refus ou un retrait modifie réellement l'état des SDK, et pas seulement l'interface.
5. Une procédure de droits : accès, effacement, rectification et opposition, avec vérification d'identité et exceptions documentées.
6. Un calendrier de conservation : par type de donnée, pas un chiffre unique.
7. Les déclarations des stores : des étiquettes de confidentialité App Store et Play qui correspondent à la cartographie, plus les sections de politique de confidentialité qu'Apple et Google exigent.

S'il manque l'un de ces éléments, il devient plus difficile de faire confiance aux autres. Cette liste est aussi le moyen le plus rapide de voir où une app existante est exposée.

Comment NAPPS aide

NAPPS construit les écrans de confidentialité décrits plus haut pour les marques Shopify et Shopify Plus : un choix de consentement en première couche, un centre de confidentialité dans le Profil, des invites ATT et notifications demandées en contexte, et des préférences de notifications push par catégorie. Les apps sont publiées sous vos comptes Apple et Google, avec vos étiquettes de confidentialité App Store et Play.

La propagation du consentement est standard, ce n'est pas une option supplémentaire. Quand un client refuse ou retire un choix, NAPPS met à jour l'état du consentement dans les intégrations que vous avez activées et configurées : le choix par finalité est enregistré, les API de consentement des SDK concernés sont mises à jour avant la collecte, et la transmission des événements facultatifs à venir s'arrête. Ce n'est pas un avantage du natif sur la webview (une app fondée sur une webview peut respecter le consentement, et une app native peut échouer à le faire). C'est une exigence de base que nous intégrons, car une app qui ignorerait ces choix s'exposerait à un refus sur l'App Store et sur Play. Ce qui varie d'une marque à l'autre, ce sont les intégrations activées, pas le respect des choix. Ce que NAPPS ne fait pas, c'est prendre les décisions juridiques à votre place : vos bases légales, votre calendrier de conservation, les rôles de vos fournisseurs et votre analyse par juridiction vous appartiennent, à fixer avec un conseil juridique, et l'app est construite pour les honorer.

Pour une vue plus large de tout ce qu'il faut à une app au lancement, voir comment transformer une boutique Shopify en app mobile (2026), et pour les catégories réglementées, où la validation par les stores est un obstacle à part entière, pouvez-vous vendre du CBD, du cannabis ou des vapes via une app mobile ?.

Pour aller plus loin sur la confidentialité, le consentement et les autorisations

Chaque sujet ci-dessous a son guide détaillé :

• App Tracking Transparency : quand une app e-commerce a besoin d'ATT et comment le demander : savoir si votre app effectue le suivi tel qu'Apple le définit, comment bien demander, et comment continuer à mesurer en cas de refus.
• Consentement aux notifications push : autorisation, consentement marketing et conception du centre de préférences : les deux décisions distinctes derrière les notifications push, comment séparer les messages de service du marketing, et comment concevoir un centre de préférences que les clients gardent activé.
• Comment concevoir un centre de confidentialité d'app mobile réellement utilisable : la spécification opérationnelle de construction : associer les finalités aux contrôles, fixer l'état avant le démarrage des SDK, ce que « désactivé » signifie vraiment, et les cas de test qui le prouvent.
• Conservation et effacement des données d'app mobile : quoi garder, pourquoi et combien de temps : construire un calendrier de conservation défendable par finalité, et comment l'effacement fonctionne réellement dans les sauvegardes et chez les tiers.
• Registres des rôles fournisseurs, sous-traitants ultérieurs et notices de confidentialité des SDK pour les apps de commerce : déterminer le rôle juridique réel de chaque fournisseur, et gérer les déclarations de SDK, les transferts et les étiquettes des stores.
• Google Consent Mode et CMP pour les apps mobiles : ce que fait réellement Consent Mode, la différence entre comportement de base et avancé, et pourquoi le choix doit atteindre tous les SDK, pas seulement ceux de Google.

Directement à la source

Ces règles évoluent : consultez les versions en vigueur.

• Europe : le texte du RGPD (articles 5 à 7), les recommandations du CEPD et, au Royaume-Uni, l'ICO sur PECR et sur les technologies de stockage et d'accès.
• Apple : les App Store Review Guidelines, App Tracking Transparency et les pages User Privacy and Data Use.
• Google et Android : les recommandations sur l'autorisation de notifications, la politique de consentement de l'utilisateur de l'UE et le mode de consentement pour les apps.
• Californie : les pages CCPA du procureur général, les exemples d'application de la loi et l'agence californienne de protection de la vie privée.

En résumé

La confidentialité dans une app de shopping comporte cinq parties distinctes : les données nécessaires au service, l'analytique facultative, le suivi publicitaire, l'autorisation marketing et les droits des clients. Gardez-les séparées. Donnez au client un vrai choix sur les usages facultatifs, rendez le refus aussi simple que l'acceptation, et assurez-vous que le choix atteint vos SDK. Là où vous vous appuyez sur le consentement au titre du RGPD ou des règles ePrivacy applicables, il doit être démontrable, spécifique à une finalité et facile à retirer. La Californie ajoute l'opposition à la vente et au partage, ainsi que le devoir de respecter des signaux comme GPC. Apple et Google ajoutent leur propre mécanique d'autorisations.

Si vous préparez une app Shopify et voulez que les surfaces de confidentialité soient intégrées dès le départ plutôt que rajoutées après coup, réservez un appel de 20 minutes avec l'équipe NAPPS et nous vous montrerons comment les écrans de consentement, le centre de confidentialité et les invites d'autorisation s'assemblent dans une app native, avec le consentement appliqué aux intégrations que vous avez activées, pour que vous puissiez emmener cela dans vos discussions juridiques et plateforme avant de construire.