Registres des rôles fournisseurs, sous-traitants ultérieurs et notices de confidentialité des SDK pour les apps de commerce

Un sous-traitant ultérieur est un sous-traitant engagé par un autre sous-traitant : les fournisseurs que vous nommez directement (hébergeur cloud, fournisseur d'analytique, constructeur d'app) sont en général vos sous-traitants, pas des sous-traitants ultérieurs. C'est pourquoi une app de commerce a besoin d'un registre des rôles fournisseurs couvrant tout le socle technique, plus les listes de sous-traitants ultérieurs des chaînes qu'il contient. Cette distinction détermine les contrats, les autorisations et les informations à donner.

Ce guide sépare les quatre documents, explique comment évaluer le rôle réel d'un fournisseur, et couvre les déclarations de SDK, les transferts et les étiquettes des stores. Il complète confidentialité et consentement pour les apps mobiles e-commerce.

Réponse courte. Construisez un registre des rôles fournisseurs pour tout le socle technique. Consignez pour chaque fournisseur son flux de données, sa finalité, son rôle juridique, sa localisation, son contrat et sa voie d'effacement. Tenez ou obtenez les listes de sous-traitants ultérieurs pour les chaînes de sous-traitance qu'il contient. Servez-vous du registre pour créer votre notice de confidentialité, vos étiquettes App Store et Play, et votre écran de consentement. Ne recopiez pas le registre dans chacun d'eux.

Périmètre, et ce que ceci n'est pas. Ceci est un guide pratique, pas un avis juridique. Le rôle juridique d'un fournisseur et le bon mécanisme de transfert dépendent de vos flux de données et de vos contrats précis, et ils évoluent. Menez l'analyse avec un conseil juridique et vérifiez à la source les exigences en vigueur des plateformes et des régulateurs avant de vous y fier.

Quatre documents, quatre publics

Gardez-les comme des documents distincts, car ils s'adressent à des lecteurs et à des finalités différentes :

Le registre est la source de vérité interne. Les trois autres en découlent, mais chacun a son public et ses règles. Parmi les erreurs courantes : publier le registre interne comme notice de confidentialité, ou l'appeler liste de sous-traitants ultérieurs.

La question du rôle passe en premier, et c'est la réalité qui tranche

Avant d'inscrire un fournisseur, déterminez son rôle juridique. L'étiquette change vos obligations. Traitez ces exemples de commerce comme des points de départ d'évaluation, pas comme des classements acquis :

Deux points comptent plus que le tableau. Premièrement, c'est la réalité qui détermine le rôle, pas l'étiquette du contrat. Un accord de sous-traitance ne fait pas d'une société votre sous-traitant si elle décide de façon indépendante pourquoi et comment utiliser les données, ou si elle les réutilise à ses propres fins. Demandez qui décide pourquoi et comment les données sont traitées. Les SDK de publicité et de mesure méritent une attention particulière, car le constructeur d'app, la marque, le fournisseur d'analytique et la régie peuvent avoir des rôles différents selon les flux.

Deuxièmement, une relation de responsabilité conjointe porte sa propre obligation. Selon l'article 26 du RGPD, les responsables conjoints doivent répartir leurs responsabilités de façon transparente au moyen d'un accord, dont l'essence doit être mise à la disposition des personnes concernées. Dire « la plateforme et nous sommes responsables conjoints » ouvre donc une obligation, cela ne coche pas une case. Bien attribuer ces rôles, c'est aussi ce qui rend l'effacement acheminable, comme l'explique notre guide de cartographie des données.

Champs recommandés du registre des rôles fournisseurs

Gardez le registre interne, et assez détaillé pour servir au conseil juridique, aux demandes d'effacement et à un régulateur. Ce sont des champs opérationnels, pas un format public imposé :

• Nom de l'entité juridique (l'entité contractante réelle).
• Service et finalité du traitement.
• Catégories de données concernées.
• Rôle : responsable de traitement, sous-traitant, sous-traitant ultérieur, responsable conjoint ou responsable indépendant.
• Entité contractante, lieux d'hébergement et lieux d'accès à distance (le lieu de traitement seul suffit rarement).
• Destinataires ultérieurs avec lesquels le fournisseur partage les données, et l'analyse de transfert correspondante.
• Référence du contrat (l'accord de sous-traitance ou un autre accord), conservée en interne, car un accord de sous-traitance est en général un contrat commercial confidentiel, pas un document à publier.
• Date d'ajout, statut et responsable.

Placez le processus d'information des changements dans le document qui correspond à son public. Les notifications au titre de l'article 28 vont aux responsables de traitement d'un sous-traitant. Les notices de confidentialité vont aux consommateurs. N'ajoutez pas ce processus à chaque ligne de fournisseur.

Le socle technique fournisseurs typique d'une app de commerce

Les socles techniques des apps de commerce sont souvent plus longs qu'on ne l'imagine, et les rôles varient. Des données personnelles peuvent atteindre :

• L'hébergement cloud et l'infrastructure de base de données
• Le réseau de diffusion de contenu (CDN)
• Le fournisseur d'authentification
• La surveillance des erreurs et le rapport de plantages
• L'analytique produit
• L'infrastructure d'envoi des notifications push
• La plateforme de support client
• Le fournisseur d'e-mail et de SMS
• L'entrepôt de données
• Les SDK d'attribution et de publicité
• Les intégrations Shopify et paiement
• Les services Apple et Google

Certains sont clairement vos sous-traitants. D'autres, en particulier les entrées publicité, paiement et stores, peuvent agir dans un rôle différent pour une partie ou pour la totalité de leur activité. Parcourez la liste fournisseur par fournisseur et attribuez le rôle de façon délibérée.

Ce qu'est une liste de sous-traitants ultérieurs

Une liste de sous-traitants ultérieurs indique aux responsables de traitement d'un sous-traitant quels prestataires ce sous-traitant emploie. Si vous êtes la marque, les listes qui vous concernent sont celles que vos sous-traitants publient ou vous remettent, et qui couvrent leurs propres prestataires. Ne tenez votre propre liste que lorsque vous agissez comme sous-traitant pour quelqu'un d'autre.

Le mécanisme sous-jacent est contractuel, ce n'est pas une fonctionnalité destinée aux consommateurs. Selon l'article 28 du RGPD, lorsqu'un responsable de traitement a donné à un sous-traitant une autorisation générale de recruter des sous-traitants ultérieurs, le sous-traitant doit informer le responsable des ajouts ou remplacements envisagés et lui laisser la possibilité de s'y opposer. C'est une obligation d'un sous-traitant envers son responsable de traitement. Ce n'est pas un droit des consommateurs, et une page publique du type « nous avons mis à jour nos fournisseurs » ne l'accomplit pas. Gardez les deux séparés : l'information et l'opposition de l'article 28 remontent la chaîne de sous-traitance ; la transparence envers le consommateur passe par votre notice de confidentialité.

Ce que la notice de confidentialité expose (et ce qu'elle n'expose pas)

La notice de confidentialité est un document destiné au consommateur : elle expose ce dont les clients ont besoin, pas tout le registre interne. Une notice de confidentialité présente en général les finalités, les catégories de données, les destinataires ou catégories de destinataires, les droits du client, et les transferts lorsque cela est requis. Notez « destinataires ou catégories de destinataires » : vous n'êtes souvent pas tenu de nommer dans la notice publique chaque entité juridique de votre registre, et vous ne publiez en général pas d'accords de sous-traitance confidentiels. Décidez délibérément ce que la notice nomme et ce qu'elle regroupe par catégories, et gardez-la cohérente avec le registre qui la sous-tend. Les contrôles côté client vers lesquels cette notice renvoie sont présentés dans la section consacrée au centre de confidentialité dans notre guide sur la confidentialité et le consentement.

Transferts internationaux

Traitez les transferts comme un test juridique, pas comme une carte. « Les données sont hébergées à l'étranger » n'est pas une analyse. Pour les données personnelles de l'EEE ou du Royaume-Uni, demandez-vous si l'arrangement constitue un transfert international restreint et, si oui, quel mécanisme en vigueur s'applique. Ce peut être une décision d'adéquation, les clauses contractuelles types, l'accord ou l'avenant de transfert international du Royaume-Uni, ou un cadre certifié comme le cadre de protection des données UE-États-Unis. Depuis Schrems II, un mécanisme seul peut ne pas suffire. Une analyse d'impact du transfert peut aussi être nécessaire.

Ce qui tranche, c'est le flux réel, pas seulement l'emplacement d'un serveur : les entités contractantes, l'accès de support à distance depuis d'autres pays, les transferts ultérieurs, et l'identité de l'exportateur et de l'importateur. Consignez l'analyse fournisseur par fournisseur, et ne présentez pas le mécanisme d'un fournisseur précis comme figé, car les fournisseurs changent d'entités, de régions et de cadres. Confirmez la situation en vigueur avec un conseil juridique.

Accords de sous-traitance et contrats

Le rôle que vous avez attribué détermine le contrat dont vous avez besoin. Quand un fournisseur est votre sous-traitant, le RGPD exige un accord de sous-traitance comportant les clauses de l'article 28 (traitement sur vos seules instructions, confidentialité, sécurité, règles sur les sous-traitants ultérieurs, effacement ou restitution en fin de contrat, et assistance en cas d'audit). Quand un fournisseur est responsable conjoint, il vous faut un accord au titre de l'article 26 qui répartit les responsabilités et dont l'essence est accessible aux personnes concernées. Quand un fournisseur est responsable indépendant, vous ne lui donnez pas d'instructions : un accord de sous-traitance est alors le mauvais instrument, et vous devez plutôt comprendre ses propres conditions. Faire correspondre le contrat au rôle fait partie du travail d'attribution du rôle.

Auditez les déclarations de SDK, ne vous fiez pas à une liste de fonctionnalités

Les SDK tiers peuvent collecter des données dont vous répondez. « Nous n'avons activé que ces fonctionnalités » ne vous dit pas ce qu'il faut déclarer. Un SDK intégré peut démarrer tout seul, collecter des diagnostics, demander des autorisations ou changer de comportement lors d'une mise à jour, même quand sa fonctionnalité visible est désactivée. Auditez ce que fait l'app construite : la version et la configuration du SDK, les autorisations et les API, les appels réseau et les points de terminaison, et la documentation du fournisseur.

Consignez le détail propre à chaque SDK dans le registre, car c'est ce dont se nourrissent les formulaires des stores et l'écran de consentement :

• Nom du SDK, fournisseur, et version
• Responsable de votre côté
• Démarrage automatique et comportement par défaut (s'initialise-t-il avant le consentement ?)
• Autorisations et accès aux API qu'il demande
• Données envoyées hors de l'appareil, et vers quels points de terminaison
• Dépendance au consentement (attend-il un signal de consentement ?)
• Indicateur de fonctionnalité ou configuration qui le pilote
• Correspondance avec les déclarations Apple et Play pour les données qu'il traite

Sur les manifestes de confidentialité d'Apple en particulier : ce n'est pas une règle simple du type « chaque SDK a besoin d'un manifeste ». Apple exige des manifestes de confidentialité couvrant l'usage par l'app de certaines API à raison d'utilisation requise ainsi que sa collecte de données, avec des exigences spécifiques pour un ensemble de SDK tiers d'usage courant. Les manifestes ne remplacent pas des réponses exactes aux questions de confidentialité de l'App Store. Comme l'ajout d'un SDK peut modifier vos déclarations et, lorsqu'il effectue du suivi inter-entreprises, déclencher une invite ATT, l'inventaire des SDK et la conception du consentement forment une seule et même discussion, traitée dans App Tracking Transparency : quand une app e-commerce a besoin d'ATT et comment le demander.

Apple et Google exigent des correspondances de déclaration distinctes

Ne partez pas du principe qu'un seul registre remplit automatiquement les deux stores, car Apple et Google utilisent des définitions et des taxonomies nettement différentes. Le registre alimente les étiquettes des stores, mais une étape de correspondance, avec un responsable et une validation, s'intercale entre les deux :

• Les informations de confidentialité de l'App Store d'Apple demandent les types de données, la finalité d'usage, si les données sont reliées à l'identité de l'utilisateur, et si elles servent au suivi tel qu'Apple le définit.
• La section Sécurité des données de Google Play interroge sur la collecte et le partage selon ses propres définitions, sur les finalités, sur le caractère obligatoire ou facultatif de la collecte, et sur des déclarations de sécurité et d'effacement valables pour toute l'app. Google précise que sa taxonomie peut différer nettement de celle d'un autre store, et que la déclaration est globale au package de l'app : si une version ou une région distribuée collecte ou partage des données, cela entre en général dans la déclaration.

Donnez un responsable nommé à cette correspondance des déclarations. Testez-la face à l'app construite et gardez-la alignée avec la fiche, à l'aide de comment remplir la fiche de votre app sans vous faire refuser.

Tenez à jour, dans le bon document

Chaque document demande de l'entretien. Mettez à jour le registre des rôles fournisseurs quand vous ajoutez, retirez ou changez un fournisseur, puis mettez à jour les sorties concernées. Quand vous agissez comme sous-traitant, honorez l'obligation d'information et d'opposition de l'article 28 envers vos responsables de traitement. Quand vos pratiques visibles par le consommateur changent, mettez à jour la notice de confidentialité et donnez l'information exigée par la loi applicable. Il n'existe pas de droit universel du consommateur à être alerté d'un changement de sous-traitant ultérieur.

Une checklist fournisseurs

Avant de publier, vérifiez :

1. Un registre des rôles fournisseurs couvrant tout le socle technique, y compris les fournisseurs présents dans les SDK.
2. Un rôle évalué pour chacun, face au flux et au contrat réels, la réalité tranchant à la place de l'étiquette.
3. Des listes de sous-traitants ultérieurs obtenues de vos sous-traitants, et tenues par vous uniquement là où vous agissez comme sous-traitant.
4. Le bon contrat par rôle : accord de sous-traitance au titre de l'article 28 pour les sous-traitants, accord au titre de l'article 26 pour les responsables conjoints, et compréhension des conditions des responsables indépendants.
5. Une analyse de transfert par fournisseur pour les données de l'EEE et du Royaume-Uni, avec un mécanisme et une évaluation là où l'arrangement est un transfert restreint.
6. Un audit des SDK de l'app construite, avec les champs de registre propres aux SDK renseignés.
7. Une correspondance des déclarations pour Apple et Google, avec un responsable et une validation.
8. Une notice de confidentialité qui expose les destinataires ou leurs catégories, les droits et les transferts, en cohérence avec le registre.
9. Un processus de changement qui met à jour le bon document pour le bon public.

Comment NAPPS aide

NAPPS est un fournisseur parmi d'autres dans ce tableau. Il peut documenter son propre rôle et ses services, mais il ne peut pas prendre vos décisions juridiques.

Commencez par son rôle, à titre indicatif : si vous êtes le responsable de traitement et que vous nommez directement NAPPS pour traiter les données clients de votre app, NAPPS serait normalement votre sous-traitant. Il n'est sous-traitant ultérieur qu'à l'intérieur d'une chaîne de sous-traitance, lorsqu'un autre sous-traitant l'engage. Savoir lequel des deux cas est le vôtre relève de votre évaluation et du contrat, pas d'une étiquette générale. Deux choses à demander à NAPPS et à vérifier face à ses documents publics en vigueur plutôt qu'à prendre pour acquis : un accord de sous-traitance, et sa propre liste de sous-traitants ultérieurs pour l'infrastructure qui fait tourner l'app, laquelle couvre l'infrastructure de NAPPS et non vos fournisseurs d'analytique, de publicité, de support et autres. Et la discipline sur les SDK décrite plus haut vaut ici aussi : ce que vous déclarez découle de ce que fait réellement l'app construite, y compris ce qui démarre tout seul, et pas seulement des fonctionnalités que vous avez activées. Ce que NAPPS ne fait pas, c'est décider du rôle d'un fournisseur, choisir des mécanismes de transfert ou rédiger votre notice de confidentialité. Pour voir comment le registre se relie à l'effacement, voir notre guide sur la conservation et l’effacement ; pour la vue d'ensemble du lancement, comment transformer une boutique Shopify en app mobile (2026).

Directement à la source

Ces documents évoluent : consultez les versions en vigueur.

• Europe : le texte du RGPD (sous-traitants et accords de sous-traitance à l'article 28, responsables conjoints à l'article 26, transferts au chapitre V) et les recommandations du CEPD sur les clauses contractuelles types et les analyses de transfert.
• Apple : les exigences des App privacy details et les règles sur les manifestes de confidentialité et les API à raison d'utilisation requise pour les apps et les SDK tiers répertoriés.
• Google : les exigences de la section Sécurité des données de Play.

En résumé

Construisez un registre des rôles fournisseurs pour tout le socle technique. Évaluez chaque fournisseur d'après ce qu'il fait réellement, pas d'après le nom que lui donne son contrat. Gardez séparées les listes de sous-traitants ultérieurs, la notice de confidentialité et la correspondance des déclarations pour les stores. Analysez ensuite les transferts, faites correspondre les contrats aux rôles, auditez les SDK de l'app construite, et mettez à jour le bon document quand quelque chose change. Il vous reste alors une carte des fournisseurs exploitable, et non un mur de logos.

Si vous préparez une app Shopify et voulez que les déclarations de SDK, les étiquettes de confidentialité des stores et la documentation fournisseurs soient traitées proprement dès le départ, réservez un appel de 20 minutes avec l'équipe NAPPS et nous vous montrerons comment tout cela s'assemble dans une app native avant que vous ne construisiez.