16 réponses pré-attestées au formulaire Shopify de protection des données

Nous ne collectons que ce qui est nécessaire pour attribuer les conversions et enchérir au nom du marchand : un identifiant de cookie first-party (anonyme), des métadonnées d'événement (vue de page, ajout au panier, achat), l'ID de commande avec ses lignes et son total, et un hachage SHA-256 de l'e-mail du client. L'e-mail brut est haché côté bidder et n'est jamais conservé en clair côté plugin. Nous ne collectons explicitement pas : e-mail ou téléphone en clair, données de paiement, adresse postale, pièces d'identité, données biométriques, ou localisation précise.

Notre politique de confidentialité publique énumère chaque donnée personnelle que nous traitons — sa source, sa finalité et sa durée de rétention — pour les données marchands (e-mail du propriétaire, langue, jeton d'accès) et les données des clients du storefront (ID cookie, événements, e-mail haché). La fiche Shopify App Store renverra à cette politique, et la page Paramètres in-app l'affichera dès la publication de l'URL App Store.

Chaque donnée a exactement une finalité documentée, appliquée par la politique et par le code. La clé API du bidder reste côté serveur et n'atteint jamais le navigateur. La clé pixel est limitée au point d'ingestion des événements. Notre cookie first-party identifie un seul visiteur pour l'attribution propre du marchand et n'est jamais combiné entre boutiques. Les charges utiles des webhooks sont vidées de l'e-mail avant d'être persistées dans la file de réessai. Une frontière de lecture unique dans notre code est le seul chemin qui déchiffre les secrets, et chaque lecture est journalisée — rendant détectable toute violation de finalité.

Nous maintenons un modèle d'Accord de Traitement des Données (DPA) destiné aux marchands, qui couvre les obligations de l'Article 28(3)(a-h) du RGPD : traitement sur instructions du marchand, confidentialité, sécurité, sous-traitants, assistance aux demandes des personnes concernées, notification de violation, restitution ou suppression à la fin du contrat, et droits d'audit. Le modèle nomme les chemins opérationnels précis qui satisfont chaque obligation.

Deux niveaux de contrôle du consentement garantissent le respect des décisions client. Côté client : avant tout envoi, le pixel storefront consulte la valeur du consentement analytics fournie par l'API Customer Privacy de Shopify. Si le consentement est refusé ou absent, l'événement est silencieusement abandonné — et le contrôle échoue en fermeture en cas d'erreur. Côté serveur : le point d'ingestion des événements applique le contrat de consentement de manière autoritative, empêchant tout appelant non-pixel de le contourner. Le pixel est le seul chemin qui atteint légitimement ce point avec un consentement déjà vérifié.

Il s'agit du droit CCPA/CPRA de refuser la vente des données — une dimension de consentement distincte de l'analytics. Comme ArgosAd est une DSP de publicité programmatique, transmettre des événements relève de la « vente » selon la définition CPRA de la publicité comportementale inter-contextuelle. Le pixel vérifie le consentement à la vente indépendamment du consentement analytics — même si l'analytics est accordé, si la vente est refusée, l'événement est abandonné.

Notre ciblage publicitaire automatisé par ID cookie constitue techniquement un traitement automatisé, mais il n'atteint pas le seuil de « conséquences juridiques ou répercussions importantes » de l'Article 22 du RGPD / § 7222 du CPRA — ce seuil vise des décisions comme l'approbation de prêt, le tri d'embauche, ou la tarification d'assurance. Sélectionner les publicités qu'un client peut voir ne qualifie pas. Néanmoins, les contrôles de consentement ci-dessus fonctionnent comme une opposition de fait : un client qui refuse le consentement analytics ou la vente est exclu de tout traitement. Les clients peuvent également exercer leurs droits au titre des Articles 21 (Droit d'opposition) et 17 (Droit à l'effacement) du RGPD, ainsi que les opt-outs CCPA/CPRA, via le marchand — câblés sur les webhooks Shopify customers/data_request et customers/redact.

Chaque table possède une durée de rétention documentée, appliquée par un script de purge automatisé exécuté chaque semaine. Durées figées : travaux de file de réessai terminés 90 jours, journaux d'audit 365 jours, nonces d'installation 24 heures, sessions Shopify jusqu'à la désinstallation + 30 jours, configuration de boutique jusqu'à la désinstallation + 30 jours (ou 48 heures après un webhook shop/redact, selon ce qui arrive en premier), et le cookie storefront 365 jours côté navigateur. Les lignes en cours ne sont jamais purgées — uniquement les lignes terminées au-delà du seuil.

Deux couches de chiffrement. Au repos (couche applicative) : nos secrets les plus sensibles — la clé API du bidder et la clé pixel — sont chiffrés en AES-256-GCM. Le tag d'authentification GCM (16 octets) détecte toute altération, qui remonte en erreur plutôt que par un décodage silencieux. La clé de chiffrement vit dans le gestionnaire de secrets de notre hébergeur ; l'application refuse de fonctionner sans elle. Au repos (couche disque) : le déploiement exige un hébergeur Postgres managé avec chiffrement disque activé (Neon, Vercel Postgres, Supabase Pro, AWS RDS avec chiffrement de stockage, ou équivalent). Les déploiements Postgres non managés sont interdits par notre spec de déploiement. En transit : TLS 1.3 est imposé partout — navigateur ↔ plugin, plugin ↔ Shopify Admin, plugin ↔ backend bidder (en plus signé par HMAC), et plugin ↔ Postgres. Lacune connue (transparente) : le jeton de session OAuth Shopify n'est pas encore chiffré au niveau applicatif (il est stocké par une bibliothèque externe) ; il est mitigé aujourd'hui par le chiffrement disque, le contrôle d'accès et la journalisation d'audit. Le chiffrement applicatif de ce jeton est inscrit à notre feuille de route v1.1.

De deux façons. Couche applicative (les secrets comptent le plus) : nos secrets de plus haute valeur sont chiffrés au niveau de la ligne — un snapshot fuité est inutilisable sans notre clé de chiffrement. Couche disque (le reste) : les hébergeurs Postgres managés stockent les snapshots de point-in-time recovery et les sauvegardes de base chiffrés au repos. Nous n'exécutons pas nos propres sauvegardes ; la PITR automatisée de l'hébergeur managé est canonique.

URLs de base de données différentes par environnement. Le développement local exécute Postgres dans Docker sur un port hôte non standard ; la production lit son URL depuis le gestionnaire de secrets. Aucune donnée de production n'est jamais copiée vers le développement — le dev est alimenté par des fixtures synthétiques uniquement. La clé de chiffrement de production est générée fraîchement et vit uniquement dans le gestionnaire de secrets de production ; le développement utilise une clé différente. Le Shopify CLI impose naturellement que le build de développement ne s'exécute que contre une boutique Shopify de développement, jamais contre une boutique de production.

Multi-couches. Hébergeur : point-in-time recovery Postgres managé avec une rétention d'au moins 7 jours (nous recommandons 30 ou plus). Les hébergeurs managés stockent les sauvegardes dans des zones de disponibilité séparées du primaire. Application : un circuit breaker empêche les défaillances en cascade vers le bidder, et une file de réessai idempotente préserve les événements en cours pendant les indisponibilités transitoires. Opérationnel : objectifs RPO 5 min / RTO 30 min documentés, et des restaurations test trimestrielles sur une branche PITR valident le chemin de récupération. Sécurité de clé : notre clé de chiffrement est dans le gestionnaire de secrets de l'hébergeur et sauvegardée dans le gestionnaire de mots de passe de l'opérateur (chiffrée, hors-ligne). La perte de la clé est traitée comme un incident de premier ordre.

Aujourd'hui, avec un opérateur unique, notre posture d'accès est honnêtement formulée : le moindre privilège à N=1 signifie qu'une seule personne détient tout. Les contrôles compensatoires sont la MFA sur chaque compte concerné, un journal d'audit de 365 jours pour chaque lecture de secret, et une revue d'accès trimestrielle. La matrice de rôles est déjà documentée pour la croissance de l'équipe : Ingénieur, Opérateur/SRE, Support et CEO, avec l'accès en écriture au gestionnaire de secrets de production et à la base Postgres de production réservé à l'Opérateur/SRE uniquement. L'onboarding ouvre un compte à moindre privilège dès le jour zéro avec MFA imposée avant tout accès ; l'offboarding révoque dans les 4 heures et tourne tout identifiant partagé dans les 24 heures.

Politique documentée avec auto-attestation annuelle. Gestionnaires de mots de passe obligatoires pour tous les comptes concernés (1Password, Bitwarden, Dashlane, KeePass ou équivalent) — pas de réutilisation, pas de mots de passe mémorisés tapés à la main. Mots de passe générés : au moins 20 caractères, au moins 3 classes de caractères. MFA imposée sur chaque compte de l'inventaire (GitHub, Shopify Partners, hébergeur, Postgres managé, gestionnaire de secrets, e-mail opérateur, registrar de domaine, fournisseur DNS, admin bidder). Méthode préférée : clé matérielle WebAuthn / FIDO2. Repli : TOTP. Interdit : 2FA par SMS (risque de SIM-swap).

Une table d'audit dédiée enregistre chaque accès pertinent pour la sécurité : lectures de jetons d'accès marchand, émissions de jetons lors de l'installation, réception de payloads des webhooks customers/data_request et customers/redact. Chaque entrée porte acteur, boutique, ressource, action, résultat, ID de requête et horodatage. Les écritures d'audit sont en mode fire-and-forget — elles ne cassent jamais l'opération qu'elles auditent, mais leurs propres échecs remontent aux journaux d'erreur. Rétention : 365 jours. Ce que nous ne journalisons délibérément pas : chaque webhook commerce (trop bruyant pour être utile) — l'observabilité côté bidder s'en charge.

Un runbook complet de réponse aux incidents couvre les niveaux de sévérité (Sev 1, 2, 3), les sources de détection, et une réponse en six phases : détection, confinement, éradication, récupération, notification, et revue post-incident. Un Sev 1 confirmé déclenche immédiatement le compte à rebours de 72 heures de l'Article 33 du RGPD. La couverture des notifications inclut les Articles 33 (autorité de contrôle, 72h) et 34 (personnes concernées, sans délai indu) du RGPD, le CCPA § 1798.82 (procureur général de Californie + résidents concernés), Shopify Trust & Security (24h), et les marchands concernés (72h avec un modèle inclus). Le confinement comprend une rotation par chevauchement double-secret documentée pour notre clé HMAC inter-services. La rotation d'urgence de notre clé de chiffrement applicative de base de données utilise aujourd'hui une procédure manuelle ; une rotation automatisée en lecture double est documentée dans notre feuille de route v1.1.