EDPB : comptes e‑commerce et base légale RGPD

Christophe BARDY - GRACES community
9/12/2025
Propulsé par Virginie
Cet article est réservé aux membres GRACES.community

EDPB : base légale pour imposer la création de comptes sur les sites e‑commerce


Le Comité européen de la protection des données (EDPB) a publié des « Recommendations 2/2025 on the legal basis for requiring the creation of user accounts on e‑commerce websites ». Ce document, mis en consultation publique, précise dans quels cas un marchand en ligne peut légalement exiger la création d’un compte client au regard du RGPD, et quand il doit proposer une alternative au compte obligatoire. Pour des compliance officers francophones expérimentés, l’enjeu est double : sécuriser la base légale du traitement et concevoir des parcours clients conformes tout en maîtrisant les risques opérationnels et réputationnels.


Pourquoi ces recommandations sont structurantes

De nombreuses plateformes conditionnent l’achat à l’ouverture d’un compte, accumulant au passage des données personnelles et des historiques. L’EDPB encadre désormais : (i) le recours au contrat (article 6(1)(b) RGPD) n’est légitime que si le compte est objectivement nécessaire à la fourniture du service acheté ; (ii) l’intérêt légitime (article 6(1)(f)) suppose un test de mise en balance rigoureux et ne peut contourner l’exigence de nécessité ; (iii) lorsque ni le contrat ni l’intérêt légitime ne s’appliquent, le consentement (article 6(1)(a)) doit être libre, spécifique, éclairé et non conditionné à l’achat si le compte n’est pas nécessaire.


Champ et définitions utiles

Les recommandations visent les sites e‑commerce B2C/B2B qui proposent la vente de biens ou services en ligne et qui envisagent d’imposer la création d’un compte au moment de l’achat, de la livraison, du suivi commande, ou du service après-vente. Elles couvrent aussi les fonctionnalités associées au compte (historique, préférences, fidélité) et les pratiques de profilage liées au compte.


Base légale : articulations clés

1) Contrat (art. 6(1)(b) RGPD)

La création de compte ne peut être imposée au titre du contrat que si elle est objectivement nécessaire à l’exécution de la prestation achetée. Nécessaire ne signifie pas « utile » ni « optimisante ». Exemples : nécessaire = accès continu à un service numérique sous abonnement nécessitant authentification, coffre-fort documentaire contractuel, fonctionnalités indispensables au service acquis. Non nécessaire = confort d’achats ultérieurs, marketing personnalisé, programme de fidélité, historique facultatif, suivi colis consultable via lien unique sans authentification.

Conséquence : si le compte n’est pas strictement requis, le marchand doit permettre l’achat en mode « invité » et traiter les données nécessaires à l’exécution (identité, adresse livraison/facturation, paiement, preuve d’achat, service client) sans conditionner à un compte.

2) Intérêt légitime (art. 6(1)(f))

Peut couvrir certaines finalités annexes (lutte anti‑fraude, sécurité du paiement, prévention des abus, limitation des litiges), sous réserve : test de nécessité, proportionnalité, et mise en balance documentée. L’intérêt légitime ne saurait justifier l’imposition d’un compte si des alternatives moins intrusives existent (p. ex. vérification anti‑fraude transactionnelle ponctuelle). Des garanties (minimisation, durées, séparation des données, pseudonymisation) sont attendues.

3) Consentement (art. 6(1)(a))

Si le compte n’est pas nécessaire à l’exécution du contrat et que l’éditeur souhaite néanmoins créer un espace offrant des avantages non essentiels (fidélité, wishlists, recommandations), il doit proposer un consentement libre et granulaire. Pas de « consentement forcé » : l’achat doit rester accessible sans compte. Le retrait du consentement entraîne la fermeture du compte et l’effacement ou l’anonymisation des données non nécessaires à des obligations légales (facturation, garantie, contentieux).


Transparence, information et UX conforme

L’EDPB exige une information claire, en langage simple, avant la collecte : finalités distinctes, bases légales correspondantes, caractère obligatoire ou facultatif du compte, conséquences du refus, durées de conservation, partage avec des tiers (transporteurs, PSP), profilage et décisions automatisées le cas échéant. Les dark patterns sont proscrits : pas de design qui pousse subrepticement à créer un compte ou à refuser l’achat invité.


Données minimales et conservation

Principe de minimisation : seules les données strictement nécessaires à l’achat invité doivent être collectées quand le compte n’est pas requis. Les durées de conservation doivent être alignées : données transactionnelles conservées selon obligations légales et défense de droits ; données de compte conservées pendant la relation, puis supprimées ou anonymisées après inactivité ou clôture, avec politiques claires et mécanismes d’effacement automatisés.


Fonctionnalités liées au compte : qualification

Historique d’achats, préférences, adresses, favoris, alertes stock/prix : ce sont des commodités, rarement nécessaires à l’exécution d’un contrat d’achat unitaire. Leur imposition via un compte obligatoire requiert une base légale adéquate (souvent consentement), ou une alternative sans compte. Pour la fidélité, la base contractuelle peut s’appliquer au « contrat de programme » distinct si l’utilisateur y adhère librement.


Profilage et personnalisation

Le profilage marketing basé sur le compte requiert une base légale adaptée (intérêt légitime avec opposition simple et efficace, ou consentement selon les cas et les législations ePrivacy pour cookies/traceurs). La personnalisation « forte » ou le scoring automatisé avec effets significatifs nécessite une attention particulière aux articles 21, 22 RGPD et aux avis EDPB/EDPS pertinents. La séparation des bases légales par finalité et la gestion de préférences granulaires dans le compte sont des attentes clés.


Sécurité et anti‑fraude : quand un compte est‑il justifié ?

La sécurité peut justifier certaines mesures d’authentification, mais n’emporte pas automatiquement l’obligation de compte. L’EDPB privilégie des contrôles transactionnels contextuels, limitées aux opérations à risque, plutôt qu’une imposition généralisée. Si un compte est requis pour des services continus (ex. contenu SaaS avec accès permanent), la sécurité renforce la nécessité contractuelle déjà avérée.


Droits des personnes et gouvernance

Les parcours doivent permettre : achat invité, accès/suppression rectifiés, export des données du compte, clôture en un clic, paramètres privacy by default, et preuve du consentement. Les DPO doivent aligner ROPA, analyses de nécessité/proportionnalité, DPIA lorsque des risques élevés sont identifiés (profilage étendu, large échelle, collecte sensible).


Articulation avec ePrivacy et cookies

L’imposition du compte ne doit pas être un détour pour imposer des traceurs non essentiels. Les obligations ePrivacy s’appliquent pour les cookies de mesure marketing ou profilage : consentement préalable, indépendant du compte, avec options claires et symétriques.


Impacts pour les modèles marketplaces et BNPL

Les marketplaces gèrent des flux multi‑vendeurs : l’EDPB attend que l’achat invité demeure possible si le compte n’est pas indispensable au suivi/gestion contractuelle. Les dispositifs BNPL/financement peuvent requérir des évaluations d’éligibilité et des obligations KYC/LCB‑FT portées par des entités financières : ces exigences ne doivent pas être confondues avec une obligation de compte marchand si une alternative processuelle est possible.


Exemples pratiques et lignes rouges

- Vente d’un bien physique standard : le compte ne peut pas être exigé si le suivi/livraison peut être fourni via des canaux sans authentification persistante (lien suivi, email/SMS).

- Service numérique à accès continu (SaaS, bibliothèque d’ebooks achetés) : un compte peut être nécessaire pour fournir l’accès promis ; base : contrat.

- Programme de fidélité : jamais imposable pour acheter ; base : contrat de fidélité distinct et/ou consentement pour traitements marketing.

- Anti‑fraude : préférence pour contrôles transactionnels ciblés plutôt qu’un compte obligatoire généralisé.


Documentation requise pour la conformité

Les organisations doivent consigner : l’analyse de nécessité (matrice fonctionnalités vs. finalités vs. base légale), le test de mise en balance (si intérêt légitime), les notices d’information, les preuves de consentement, les durées de conservation, les paramètres default privacy, et les décisions de design évitant les dark patterns.


Interactions avec autorités de contrôle

Les autorités (CNIL, autres membres de l’EDPB) examineront particulièrement les parcours imposant un compte pour des achats ponctuels. Les audits porteront sur le respect des bases légales, des choix utilisateurs, et des preuves de conformité.


Conclusion

Les Recommendations 2/2025 de l’EDPB offrent un cadre clair : un compte client ne peut être imposé que lorsqu’il est strictement nécessaire à l’exécution du service acheté. Sinon, achat invité, granularité des bases légales et consentement libre s’imposent, avec une documentation robuste et un design éthique.


Quelques pistes pour l’intégration opérationnelle dans votre dispositif :

- Cartographiez les finalités du « compte » et rattachez chacune à une base légale documentée, en distinguant l’essentiel du facultatif.

- Concevez et testez un parcours « achat invité » complet : information, suivi, SAV, preuve d’achat, sans authentification persistante.

- Implémentez un gestionnaire de préférences granulaire (marketing, fidélité, personnalisation) avec journal des consentements et parcours de retrait simple.

- Mettez à jour ROPA, politiques de conservation et tests de mise en balance ; déclenchez une DPIA si profilage à grande échelle.

- Réalisez un audit UX anti‑dark patterns et alignez cookies/traceurs avec ePrivacy indépendamment du compte.

Envie de lire la suite de l’article ?
Il vous reste 50% de l’article à lire
Inscrivez-vous sur GRACES.community pour profitez de toute l’actualité compliance
directement depuis votre espace Membre !
M'inscrire

Plus de 200 sociétés ont trouvé leur compliance officer avec GRACES.community,

et si c’était vous ?