Politique de protection des données d'Amazon pour les vendeurs : ce que les applications tierces voient de vos acheteurs

Deux documents qui s'imposent à toute application

Une précision d'abord : si vous êtes acheteur et que vous vous demandez ce qu'Amazon fait de vos propres données, c'est l'avis de confidentialité d'Amazon.fr qu'il faut lire. Cet article s'adresse aux vendeurs qui connectent des applications à leur compte vendeur, et il expose notre lecture des règles en tant que développeur, pas un conseil juridique.

Tout développeur qui utilise l'API Selling Partner d'Amazon accepte deux politiques. La Data Protection Policy (DPP) fixe les règles de sécurité et de conservation. L'Acceptable Use Policy (AUP) fixe les règles de comportement : ce qu'un développeur peut demander et ce qu'il peut faire de ce qu'il reçoit. Les deux sont publiques et définissent le plafond de toute application qui demande l'accès à votre compte.

La DPP comporte deux niveaux. La section 1 vise « all systems that store, process, or otherwise handle data vended and retrieved from the Amazon Services API » (tous les systèmes qui traitent des données issues de l'API), donc toute application, même celle qui ne lit que votre compteur de commandes du jour. La section 2 ajoute des exigences plus strictes qui ne s'appliquent qu'à partir du moment où une application touche à des PII. C'est tout l'enjeu : une application qui ne reçoit jamais de données acheteur reste au niveau léger, et les rôles demandés vous disent à quel niveau elle se trouve.

L'AUP ajoute deux phrases qui vous concernent. « Do not request access to or retrieve Information that is not necessary for your Application's functionality. » (Ne demandez pas de données dont votre application n'a pas besoin.) Et : « Do not request or share Amazon Portal usernames or passwords from Authorized Users. » (Ne demandez pas les identifiants des utilisateurs.) Une application qui réclame votre mot de passe Seller Central, ou un rôle qu'elle ne sait pas expliquer, est hors des règles avant d'avoir stocké le moindre octet.

Pour les vendeurs français, le RGPD se superpose à tout cela, avec la minimisation des données et la limitation des finalités au centre. Savoir si un prestataire agit comme sous-traitant relève de votre propre conformité et de votre conseil ; cet article s'en tient aux règles d'Amazon.

Ce qui compte comme donnée personnelle, code postal compris

La DPP définit les données personnelles comme « information that can be used on its own or with other information to identify, contact, identify in context, or locate an Amazon Customer or Authorized User » (une information qui permet, seule ou combinée, d'identifier, de contacter ou de localiser un client Amazon). La liste qui suit est plus longue que ce que la plupart des vendeurs imaginent : « name, address, e-mail address, phone number, gift message content, survey responses, payment details, purchases, cookies, digital fingerprint (e.g., browser, user device), IP Address, geo-location, postal code, or Internet-connected device product identifier ».

Deux éléments méritent un second regard. Le code postal d'abord : isolé il paraît inoffensif, mais Amazon le classe en PII parce que, combiné à d'autres données, il permet de localiser une personne. Ensuite ce qui n'est pas dans la liste : une ligne de commande sans aucun champ acheteur. Le fait que quelqu'un ait acheté deux unités d'un SKU sur amazon.fr à 14h03 n'identifie ni ne localise personne.

Le piège du code postal dans les notifications de commande

Ce détail, nous ne l'avons découvert qu'en construisant une application. La notification ORDER_CHANGE d'Amazon, celle à laquelle les développeurs s'abonnent pour suivre les commandes, contient un champ DestinationPostalCode dans son résumé de commande. Un développeur qui écrit ce message tel quel dans une base détient désormais des PII, avec tout le poids de la section 2 : conservation limitée à 30 jours, chiffrement au repos, scans de vulnérabilités, tests d'intrusion. Celui qui jette le champ avant tout stockage reste en section 1. Demandez à une application d'alerte ou d'analyse ce qu'elle fait du code postal : la vitesse à laquelle elle comprend la question en dit long.

Les Restricted Data Tokens, la porte devant les données acheteur

Amazon ne remet pas de PII à une application simplement parce que vous l'avez autorisée. Les coordonnées des acheteurs ne sortent de l'Orders API que par ce qu'Amazon appelle des restricted operations, et la documentation de la Tokens API est explicite : « Restricted operations return customers' Personally Identifiable Information (PII). You need an RDT to call a restricted operation. » (Il faut un RDT pour appeler une opération restreinte.) Un Restricted Data Token doit être demandé pour chaque appel de ce type, et Amazon ne le délivre qu'aux applications dont les rôles approuvés couvrent les données concernées.

Dans le modèle de données de l'Orders API, trois objets portent la marque restricted : ShippingAddress, BuyerInfo (nom, adresse e-mail, données fiscales) et BuyerTaxInformation. Tout le reste revient sans aucun jeton. C'est avec cela que travaillent une alerte de commande ou un tableau de bord.

Deux nuances. Le numéro de commande n'est pas sur la liste PII d'Amazon et revient sans jeton, mais vous et Amazon pouvez le relier à un acheteur dans Seller Central ; nous le traitons donc comme une donnée pseudonyme et n'en stockons qu'un haché avec clé. Et tant qu'une commande est en attente, Amazon ne renvoie aucun prix : une application d'alerte affiche donc une estimation jusqu'à la publication du montant.

Le modèle des rôles : ce que vous approuvez en connectant une application

Les rôles sont, selon Amazon, « the mechanism by which the Selling Partner API (SP-API) determines whether a developer or application has access to an operation or resource » (le mécanisme qui décide de l'accès à une opération ou une ressource). Un développeur les demande lors de son enregistrement ; vous les revoyez sur la page d'autorisation de Seller Central au moment de connecter l'application. Ce qui n'y figure pas, l'application ne peut pas l'appeler. Nous détaillons cette page pas à pas dans notre guide pour connecter une application à Amazon Seller Central.

Quatre rôles sont marqués restricted : Direct-to-Consumer Shipping, Tax Invoicing, Tax Remittance et Professional Services. La page des rôles explique l'étiquette : « Restricted means that the role requires sensitive information, which might include personally identifiable information (PII). For these roles, you must provide additional information about your data use and security controls. » (Ces rôles portent sur des informations sensibles et imposent des précisions supplémentaires sur l'usage des données et la sécurité.) Seuls les rôles restreints débloquent les Restricted Data Tokens. Un outil d'impression d'étiquettes en a besoin, un outil de facturation aussi. Une alerte, un tableau de bord ou un repricer, non.

Le rôle nécessaire à une alerte de commande s'appelle Inventory and Order Tracking, et sa description se termine par une phrase à retenir : « Operations that require this role do not use PII required to ship an order. » (Ses opérations n'utilisent pas les PII nécessaires à l'expédition.) Il renvoie les commandes, les articles et les indicateurs de ventes, et permet l'abonnement à ORDER_CHANGE pour les commandes FBA comme FBM. Autre mécanisme utile : si un développeur ajoute un rôle plus tard, Amazon exige une nouvelle autorisation, donc une nouvelle page d'autorisation plutôt qu'une extension silencieuse.

Conservation et audits : les obligations d'une application qui détient des PII

Si une application reçoit bien des PII, la DPP est précise. Le développeur « will retain PII for no longer than 30 days after order delivery and only for the purpose of, and as long as is necessary to (i) fulfill orders, (ii) calculate and remit taxes, (iii) produce tax invoices and other legally required documents, and (iv) meet legal requirements ». Donc 30 jours après la livraison, les obligations fiscales et légales étant la seule raison de garder quoi que ce soit plus longtemps. L'AUP ferme l'autre porte : « Do not use Personally Identifiable Information about Customers for any purposes other than merchant-fulfilled shipping or to meet legal requirements. »

Les données de commande sans identité suivent une autre horloge. Un développeur ne peut les garder que le temps strictement nécessaire à la finalité que vous avez autorisée, et doit toutes les supprimer définitivement, copies actives comprises, dans les 30 jours après votre révocation ou une demande d'Amazon. Un compteur de ventes du jour que vous utilisez encore est une telle finalité ; une copie de vos commandes conservée après déconnexion n'en est pas une.

Viennent ensuite les obligations techniques. Tout développeur doit chiffrer les données en transit avec « secure protocols such as TLS 1.2 or higher », garder ses identifiants techniques « encrypted at rest, accessible only to authorized personnel, and rotated at least once every twelve (12) months » et n'accorder l'accès qu'au strict nécessaire. Celui qui détient des PII doit en plus les chiffrer au repos, réaliser un « vulnerability scanning conducted at least every 30 days » et « perform penetration testing at least every 365 days ». Amazon se réserve enfin le droit d'auditer les systèmes d'un développeur et de demander une attestation écrite de conformité. Rien de tout cela n'est visible pour vous, et c'est précisément pourquoi les rôles affichés sur la page d'autorisation comptent : ils vous disent quelles obligations le développeur a endossées, et si son application en avait besoin.

Pourquoi une alerte de commande n'a besoin de rien de tout cela

Pensez à ce dont un cha-ching sur votre téléphone a réellement besoin. Qu'une commande existe, pour la compter une fois. Quand elle a été passée, pour afficher son délai. Sur quelle place de marché et pour quel montant approximatif, pour que le chiffre affiché ait un sens. Éventuellement le SKU ou le titre, pour savoir quel produit vient de partir. Tous ces champs sortent du rôle Inventory and Order Tracking sans Restricted Data Token, et aucun ne dit qui a acheté.

Le nom de votre acheteur ne rend pas le son plus doux, et son adresse ne fait pas arriver l'alerte plus vite ; ce qui compte pour la vitesse, c'est la façon dont l'application cherche les nouvelles commandes, ce que nous avons mesuré dans à quelle vitesse une alerte de commande Amazon peut arriver. Une application de cette catégorie qui demande des données acheteur a soit mal lu la politique, soit une autre idée derrière la tête. Ni l'un ni l'autre n'est bon signe. La même logique vaut pour la plupart des tableaux de bord et même pour l'application Seller officielle, dont nous décrivons les notifications dans ce que l'application Amazon Seller notifie ou non.

Comment vérifier ce qu'une application demande

Nul besoin de lire le code d'un développeur pour juger une application. Quatre vérifications suffisent dans la plupart des cas.

1. Lisez la page d'autorisation avant de confirmer. Elle liste chaque rôle demandé, et les noms des rôles restreints sont parlants : Direct-to-Consumer Shipping, Tax Invoicing, Tax Remittance, Professional Services.
2. Rattachez chaque rôle à une fonction que vous utiliserez. L'impression d'étiquettes justifie Direct-to-Consumer Shipping, la facturation justifie Tax Invoicing. Les alertes, les analyses, le repricing et la gestion de stock ne justifient aucun rôle restreint.
3. Ouvrez la politique de confidentialité du développeur et cherchez trois réponses : quels champs sont stockés, où sont les serveurs, et combien de temps les données restent après déconnexion. Selon la DPP, la dernière réponse ne peut pas dépasser 30 jours.
4. Posez une question par e-mail : « Stockez-vous des données acheteur, et que faites-vous du code postal présent dans la notification de commande ? » Un développeur qui a lu la politique répond en deux lignes.

Si une application demande plus que ses fonctions n'exigent, ne confirmez pas : l'AUP interdit de réclamer des informations inutiles, vous n'êtes donc pas difficile. Si vous l'avez déjà connectée, révoquez-la dans Seller Central sous Applications et services, Gérer vos applications, en choisissant de désactiver l'autorisation puis en confirmant par OK. La documentation d'Amazon précise que l'application est alors désactivée mais reste visible sur cette page : la voir encore listée est donc normal. À partir de là, le développeur a 30 jours pour supprimer vos données. Et si vous vouliez surtout entendre vos ventes, notre panorama de toutes les façons d'être averti d'une vente Amazon montre lesquelles se passent totalement de données acheteur.