E-commerce
1 juillet 2026
« Pourquoi le transporteur a mon adresse ? » « Vendez-vous mes données à Meta ? » « Quelle app Shopify reçoit mon email ? » Trois tickets où le partage données partenaires manque de réponse support claire, pas seulement de politique juridique.
Le support partage données partenaires e-commerce couvre transporteurs, processeurs paiement, outils marketing et apps tierces nécessaires à la commande. Distinct des préférences compte (#849) et de la privacy générale (#154) : ici, le client veut savoir qui reçoit quoi et pourquoi.
Ce guide #851 déploie policy PARTDATA-SUP, flow PD-1 à PD-8 et matrice PARTDATA-MAP. Paire SAV du futur bot partenaires (#852).
Sommaire
Pourquoi le partage partenaires génère-t-il des tickets support ?
Une commande e-commerce active une chaîne de sous-traitants : livraison, paiement, emailing, analytics. Le client lit « partenaires » dans la politique confidentialité et imagine une revente de données. L'agent renvoie le PDF RGPD sans nommer les acteurs concrets ni distinguer donnée obligatoire commande et partage marketing optionnel.
Cinq frictions typiques partage partenaires
Transporteur : « Pourquoi Chronopost a mon téléphone ? »
Paiement : crainte que Stripe ou Shop Pay revende les données
Marketing : pixel Meta, Klaviyo, peur publicité ciblée abusive
Apps Shopify : client ne sait pas quelle intégration reçoit l'email
Revente : « Vendez-vous mes données ? » sans lecture fine du DPA
Le RGPD impose information claire sur destinataires et finalités (CNIL, information personnes concernées 2026). Le support traduit cette obligation en langage ticket.
Exemple DTC
Maison déco DTC, 14 tickets partdata_/mois. Après PARTDATA-MAP : partdata_clarity_resolution_rate 91 %, escalades DPO inutiles -38 %.
PARTDATA #851 vs Privacy #154, PRIVPREF #849, CONNDATA #675 et bot #852
Six contenus privacy, six angles clients distincts.
Matrice rapide
#851 PARTDATA : qui reçoit données commande, transporteur, apps, marketing partenaires
Privacy #154 : expliquer politique et droits RGPD transverse
PRIVPREF #849 : toggles marketing cookies dans compte client
CONNDATA #675 : données capteurs produit connecté distinct partenaires commande
ACCTDEL #823 : effacement compte distinct qui reçoit mes données
Bot #852 : informer partenaires sans jargon juridique tier 1
#851 = qui a mon adresse et pourquoi ? #849 = comment couper le marketing dans mon compte.
Promesse #851
Policy PARTDATA-SUP, arbre PARTDATA-GATE, 8 macros, registre partenaires agent-ready, KPI partdata_clarity_resolution_rate.
Quelles typologies partdata_* classifier ?
Classifier oriente réponse : transporteur obligatoire ≠ pixel marketing ≠ handoff DPO.
Huit typologies PARTDATA-MAP
partdata_carrier_tracking : transporteur, suivi colis, adresse livraison
partdata_payment_processor : Stripe, Shop Pay, PayPal, données carte
partdata_marketing_partner : Klaviyo, Meta, Google Ads, audiences
partdata_app_third_party : apps Shopify, ERP, avis, fidélité
partdata_who_receives : liste complète destinataires demandée
partdata_opt_out_partner : veut limiter partage hors commande
partdata_international_transfer : données hors UE, USA, cloud
partdata_sell_data_fear : crainte revente ou « vente » données
Policy PARTDATA-SUP : règles agents et escalade
La policy PARTDATA-SUP fixe transparence opérationnelle sans promettre zéro sous-traitant légal.
Six règles PARTDATA-SUP
Registre partenaires à jour : macro PARTDATA-LIST avant improvisation
Distinguer obligatoire vs opt-in : PARTDATA-OBLIGATORY livraison paiement facture
Pas de liste carte complète : expliquer processeur, jamais PAN
Opt-out marketing d'abord : renvoyer PRIVPREF #849 si demande couper pubs
Transfert hors UE documenté : PARTDATA-TRANSFER avec garanties SCC
DSAR formel → DPO : export effacement distinct ticket explicatif
Matrice finalité (agent)
Exécution commande : transporteur, entrepôt, paiement, SAV logistique
Marketing opt-in : emailing promo, retargeting, SMS promo
Mesure opt-in : analytics, A/B test, heatmaps consentis
Jamais revendu : PARTDATA-NOSELL si partdata_sell_data_fear
Flow PD-1 à PD-8 : résolution standard
Huit étapes séquentielles, SLA P3 privacy < 24 h, escalate DPO si DSAR formel.
Flow PD-1 à PD-8
PD-1 Triage : lire question, tag partdata_*, transporteur ou marketing ?
PD-2 Lookup : registre partenaires actifs, apps installées, stack livraison
PD-3 Educate : PARTDATA-OBLIGATORY si confusion livraison
PD-4 Classify : partdata_* via PARTDATA-MAP
PD-5 Execute : macro ciblée, lien politique #154, handoff #849 si opt-out
PD-6 Confirm : macro PARTDATA-DONE périmètre exact
PD-7 Test : client comprend qui reçoit quoi et pourquoi
PD-8 Close : KPI partdata_clarity_resolution_rate
Huit macros PARTDATA-* prêtes à coller
Macros pédagogiques, noms partenaires réels, pas de copier-coller juridique.
Bibliothèque PARTDATA-*
PARTDATA-CARRIER : « Pour livrer votre commande, nous transmettons nom, adresse et téléphone à {{carrier}}. Donnée limitée à la livraison. »
PARTDATA-PAYMENT : « Le paiement est traité par {{processor}}. Nous ne stockons pas votre numéro de carte complet. »
PARTDATA-MARKETING : « Emails promo et audiences pub passent par {{tool}} si vous avez consenti. Désactivation : préférences compte #849. »
PARTDATA-APPS : « L'app {{app}} reçoit {{fields}} pour {{purpose}}. Liste complète : section Partenaires politique confidentialité. »
PARTDATA-LIST : « Partenaires actifs : livraison {{carrier}}, paiement {{processor}}, marketing {{tools}}. Détail finalités : lien politique. »
PARTDATA-OPTOUT : « Pour limiter le marketing, modifiez vos préférences compte. La livraison et la facturation restent obligatoires. »
PARTDATA-TRANSFER : « Certains outils hébergent des données aux USA avec clauses contractuelles types approuvées UE. »
PARTDATA-NOSELL : « Nous ne vendons pas vos données personnelles. Nous partageons avec des prestataires sous contrat pour exécuter le service. »
Arbre PARTDATA-GATE et registre partenaires agent-ready
Arbre décision avant escalade DPO ou réponse floue « consultez la politique ».
PARTDATA-GATE
Question transporteur ou suivi ? → CARRIER + OBLIGATORY
Question paiement ou carte ? → PAYMENT, jamais détails PAN
Veut couper pubs ? → OPTOUT + handoff PRIVPREF #849
Crainte revente ? → NOSELL + LIST si besoin
Demande export ou effacement formel ? → DPO, pas macro seule
Registre interne minimum
Tableau helpdesk : partenaire, finalité, champs partagés, base légale, pays hébergement, lien DPA. Mise à jour trimestrielle avec revue apps Shopify. Former agents : partenaire ≠ revente automatique.
KPI, QA et handoff vers bot #852
Mesurer PARTDATA détecte réponses juridiques opaques et sous-information transporteur.
Quatre KPI PARTDATA
partdata_clarity_resolution_rate : client comprend destinataires / total
partdata_wrong_silo_rate : % tickets routés PRIVPREF #849 à tort
partdata_dpo_escalate_rate : % DSAR formels correctement escaladés
partdata_repeat_7d : même question partenaires sous 7 jours
Handoff bot #852
Exporter PARTDATA-MAP vers intents bot_partdata_carrier, bot_partdata_marketing, bot_partdata_nosell. Guardrail PARTDATA-DSAR-BOT : router DPO si export effacement ou opposition formelle détectée.
Cas limites : marketplace, guest checkout, retargeting tiers
Trois cas hors flow standard.
Marketplace ou dropshipping
Fournisseur tiers expédie. CARRIER + APPS avec nom fournisseur réel. Ne pas promettre zéro partage si logistique externalisée.
Guest checkout
Client sans compte demande opt-out marketing. OPTOUT + lien désinscription email + cookies. Lien guest checkout (#819) si confusion compte.
Retargeting Meta Google
MARKETING + lien préférences #849. Expliquer que le pixel ne s'active qu'avec consentement bannière cookies si applicable.
Formation agents : 20 minutes PARTDATA
Module : registre partenaires, obligatoire vs opt-in, NOSELL avant panique, DSAR ≠ question simple.
Exercices
Ticket A : transporteur a mon adresse → CARRIER pas DPO
Ticket B : stop pubs Meta → OPTOUT + handoff #849
Ticket C : export toutes mes données → escalate DPO, pas LIST seul
Comment Qstomy structure PARTDATA dans votre stack
Qstomy route partdata_*, injecte registre partenaires dans la réponse agent et handoff DPO si DSAR formel.
Trois briques
Routing : intent partner_sharing vs privacy_prefs vs dsar_request
Knowledge : registre partenaires synchronisé macros PARTDATA-*
Bot #852 : expliquer transporteur et apps tier 1 sans jargon
Scénario : marque beauté, 11 tickets/mois « vendez-vous mes données ». Bot #852 répond NOSELL + LIST, agents traitent apps Shopify et transferts USA. partdata_clarity_resolution_rate passe de 71 % à 89 % en 6 semaines.
FAQ et checklist déploiement PARTDATA
FAQ
Le transporteur = vente de données ?
Non. Transmission contractuelle pour livrer. Macro CARRIER + finalité livraison.
Différence #849 ?
#851 = qui reçoit mes données et pourquoi. #849 = comment modifier mes toggles compte.
Client demande effacement ?
Handoff DPO ou procédure ACCTDEL #823. PARTDATA explique, ne exécute pas l'effacement seul.
Checklist 7 jours
J1 : PARTDATA-SUP + PARTDATA-MAP + registre partenaires
J2 : 8 macros helpdesk avec noms réels
J3 : aligner politique #154 section Partenaires
J4 : formation 20 min agents
J5 : tags partdata_* + KPI
J6 : test handoff #849 vs DPO
J7 : brief bot #852 DSAR-GATE
Maillage
Enzo
1 juillet 2026
