Consentement et traçabilité du partage de données dans un réseau de franchise et de marketplace

Un client achète des chaussures de running dans un magasin de sport « local ». Ce magasin est un franchisé. La transaction passe en réalité par une plateforme de marketplace (imaginez une annonce traitée via un compte vendeur tiers). Les points de fidélité s'inscrivent dans un programme co-brandé par le franchiseur et une banque. Quatre entités détiennent désormais un morceau des données de ce client : le franchisé, le franchiseur, la marketplace et le partenaire fidélité. Quand le client écrit plus tard « merci de supprimer mes données », laquelle des quatre le fait réellement ? En pratique : souvent aucune, parce que chacune suppose qu'une autre est responsable de la demande.

C'est ce trou d'accountability que cette leçon doit vous aider à repérer.

Pourquoi les structures de franchise et de marketplace cassent la traçabilité du consentement

Le consentement, au sens de la protection des données, est une base légale valide pour collecter ou utiliser des données personnelles : la personne a clairement accepté un usage précis. Il coexiste avec d'autres bases légales comme la « nécessité contractuelle » ou l'« intérêt légitime ».

Le problème : le consentement est recueilli une fois, à un seul point de contact, alors que les données personnelles circulent ensuite à travers plusieurs entités juridiques indépendantes.

• Le franchisé est en général une entreprise juridiquement distincte, souvent le « responsable de traitement » de première ligne pour la collecte en magasin (le responsable de traitement est l'entité qui décide *pourquoi* et *comment* les données sont utilisées, selon la terminologie du RGPD européen).
• Le franchiseur fournit la marque, les systèmes IT et le programme de fidélité, et peut aussi agir comme responsable de traitement, ou comme « responsable conjoint » aux côtés du franchisé.
• La marketplace (Amazon, Walmart Marketplace, MercadoLibre, Cdiscount) est encore un responsable de traitement distinct, avec sa propre politique de confidentialité que le client n'a probablement jamais lue attentivement.
• Le partenaire fidélité (une banque, un pétrolier, une compagnie aérienne) reçoit souvent un flux de données dans le cadre d'un accord totalement séparé.

Chaque transfert peut être légitime. La défaillance survient quand le périmètre du consentement ne voyage pas *avec* les données. Un client qui a accepté de « recevoir des offres du Magasin X » n'a pas nécessairement accepté que « son historique d'achats soit partagé avec le moteur de fidélité de la Banque Y ».

Les repères réglementaires à connaître

États-Unis : pas de loi fédérale unique sur la vie privée. À la place, une mosaïque :

• La Section 5 du FTC Act permet à la Federal Trade Commission (FTC) d'agir contre les pratiques de données « déloyales ou trompeuses », y compris les promesses de confidentialité non tenues.
• Les lois des États mènent le jeu : le California Consumer Privacy Act (CCPA), modifié par le California Privacy Rights Act (CPRA), donne aux consommateurs le droit de savoir, de supprimer et de s'opposer à la « vente » ou au « partage » de leurs données personnelles. Le Colorado, la Virginie, le Connecticut et d'autres ont des lois similaires en 2026, chacune avec des seuils et des définitions légèrement différents.

Europe : le Règlement général sur la protection des données (RGPD), appliqué par les autorités nationales de protection des données (la CNIL en France, la DPC en Irlande). Concepts clés :

• Responsable de traitement vs. sous-traitant : un sous-traitant agit uniquement sur instruction d'un responsable de traitement (par exemple un éditeur de plateforme de fidélité) ; un responsable de traitement décide des finalités et des moyens. Les réseaux de franchise ont fréquemment des répartitions responsable/sous-traitant floues, ce que les régulateurs ont sanctionné.
• Limitation des finalités : des données collectées pour une finalité déclarée ne peuvent pas être silencieusement réutilisées pour une autre.
• Data Processing Agreements (DPA) : contrats obligatoires entre responsables de traitement et sous-traitants, précisant ce qui peut être fait avec les données.

Le Digital Markets Act (DMA) européen et les obligations propres aux marketplaces prévues par le Digital Services Act (DSA) poussent également désormais les grandes marketplaces à plus de transparence sur les pratiques de données des vendeurs, ce qui compte quand un franchisé vend via une grande plateforme.

Où se situe réellement l'accountability : trois schémas de défaillance

1. Le schéma du « blanchiment de consentement ». Un franchisé collecte un email en caisse pour envoyer un ticket. Le CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète → du franchiseur (système de gestion de la relation client) inscrit plus tard cet email dans un programme de fidélité national avec un consentement marketing que personne n'a explicitement donné. Sous le RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète →, c'est une violation de la limitation des finalités ; sous le CCPA/CPRA, cela peut relever d'un « partage » non divulgué.

2. Le schéma du « bouclier marketplace ». Un franchisé vend via une marketplace et suppose que la politique de confidentialité de la marketplace couvre tout. Ce n'est généralement pas le cas. Les marketplaces restreignent typiquement les données (nom, adresse, historique de commandes) qu'elles transmettent aux vendeurs tiers, précisément pour empêcher ces vendeurs de constituer leurs propres bases clients non autorisées. Un franchisé qui aspire ou exporte les données de commande de la marketplace vers son propre CRM de fidélité sans base légale valide s'expose, et surtout le franchiseur aussi s'il a donné cette instruction.

3. Le schéma du « responsable conjoint silencieux ». Franchiseur et franchisé décident conjointement des mécaniques du programme de fidélité (marque du contrôle conjoint au sens de l'article 26 du RGPD), mais seule la politique de confidentialité du franchiseur est visible du client. En cas de violation de données, les régulateurs peuvent, et l'ont fait, tenir les deux responsables, alors même que le client n'a jamais vu qu'une seule marque.

Une piste d'audit concrète : ce qu'il faut vraiment vérifier

Pour une revue de gouvernance d'une chaîne franchise/marketplace/fidélité, suivez les données comme une piste forensique :

1. Cartographiez les points de contact. Listez chaque entité qui touche les données : système de caisse, CRM du franchiseur, flux de commandes de la marketplace, partenaire fidélité, tout pixel ad-tech présent sur la page de paiement.
2. Rattachez chaque point de contact à une preuve de consentement. Le consentement a-t-il été recueilli à ce point précis, pour cette finalité précise ? Une case générique « j'accepte les conditions » satisfait rarement l'exigence du RGPD d'un consentement spécifique, éclairé et libre.
3. Vérifiez les contrats, pas seulement les politiques. Existe-t-il un Data Processing Agreement entre franchiseur et franchisé ? Entre franchiseur et partenaire fidélité ? L'absence de DPA est un constat d'audit fréquent.
4. Testez le parcours de suppression/opposition de bout en bout. Soumettez une vraie demande (dans un environnement de test ou un compte test) et mesurez le temps de propagation aux quatre systèmes. Le RGPD exige généralement une réponse sous un mois ; le CCPA/CPRA exige généralement une action sous 45 jours (prolongeable une fois). Si la base du partenaire fidélité contient encore l'enregistrement au-delà, vous avez un écart de conformité bien réel, pas théorique.
5. Vérifiez les durées de conservation. Les données gardées « au cas où » au-delà de leur finalité déclarée sont une cible classique des régulateurs : la CNIL et l'ICO britannique ont tous deux sanctionné des distributeurs pour conservation excessive.

Un script de contrôle interne simple (pseudocode, purement illustratif) :

for each customer_id flagged "deletion_requested":
    check franchisee_pos_db.status(customer_id)
    check franchisor_crm.status(customer_id)
    check loyalty_partner_feed.status(customer_id)
    check marketplace_export_cache.status(customer_id)
    flag if any status != "deleted"

C'est le type de piste qu'un auditeur interne ou un enquêteur d'autorité de protection des données reconstituera après une violation, en cartographiant non seulement *quelles* données ont circulé, mais *qui a autorisé* chaque transfert.

Mini-cas travaillé : attribuer l'accountability

Supposons que l'éditeur du système de caisse d'un franchisé subisse une violation exposant 50 000 enregistrements de membres du programme de fidélité, dont un historique d'achats synchronisé depuis la marketplace. Qui est responsable ?

• Le franchisé est probablement responsable de traitement pour les données qu'il a collectées en magasin, tenu à ses propres obligations de sécurité.
• Le franchiseur est probablement responsable conjoint du dispositif de fidélité qu'il a conçu et imposé, surtout s'il a imposé l'éditeur du système de caisse.
• L'éditeur du système de caisse est un sous-traitant, contractuellement responsable envers les responsables de traitement mais rarement la cible réglementaire principale.
• La marketplace n'est responsable que si la violation découle de données qu'elle a diffusées indûment, au-delà de ses propres conditions.

Les régulateurs regardent généralement *qui a décidé de la finalité et des moyens* du traitement, pas qui hébergeait le serveur. C'est pourquoi la due diligence sur les contrats de franchise (qui possède la base fidélité, qui peut être poursuivi) compte autant que la revue technique de sécurité.

Pour une introduction lisible à ces distinctions responsable/sous-traitant, les orientations de l'ICO britannique sur les responsables et sous-traitants sont une ressource gratuite solide, et transposable assez bien à la façon de raisonner des régulateurs européens.

Points clés

• Un consentement recueilli à un point de contact (magasin, application, annonce sur marketplace) ne voyage pas automatiquement avec les données vers tous les partenaires en aval ; la limitation des finalités sous le RGPD et les règles de divulgation sous le CCPA/CPRA exigent toutes deux que l'usage *spécifique* soit autorisé.
• Les réseaux de franchise et de marketplace manquent régulièrement de Data Processing Agreements clairs entre franchiseur, franchisé, marketplace et partenaire fidélité ; auditer l'existence et le périmètre de ces contrats est un premier contrôle peu coûteux.
• L'accountability suit *qui décide de la finalité et des moyens* (responsable de traitement), pas seulement qui détient le serveur (sous-traitant) ; le contrôle conjoint entre franchiseur et franchisé est fréquent et souvent non documenté.
• Un audit concret consiste à tracer une vraie demande de suppression ou d'opposition de bout en bout dans tous les systèmes, et à la chronométrer face aux délais légaux (environ un mois sous le RGPD, 45 jours sous le CCPA/CPRA, selon les règles en vigueur en 2026).
• Les restrictions de partage de données des marketplaces existent précisément pour empêcher les vendeurs de constituer des bases clients non autorisées ; l'export par les franchisés des données de commande de la marketplace vers leur propre CRM est un schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → récurrent à haut risque, à vérifier en premier.