Droit à l’oubli RGPD article 17 sur PrestaShop : suppression de compte sans casser la trace fiscale en 2026

L’article 17 RGPD : une obligation simple à formuler, complexe à exécuter

« Le client peut demander la suppression de ses données ». La phrase est lapidaire dans l’article 17 du RGPD. Sa mise en œuvre sur une boutique PrestaShop ou WooCommerce qui a 5 ans d’existence est tout sauf simple. Parce qu’une « suppression de compte » bien faite doit naviguer entre quatre exigences contradictoires :

• Le droit à l’oubli du client (RGPD article 17).
• L’obligation de conservation comptable de 10 ans (code de commerce L.123-22).
• La traçabilité fiscale des ventes (CGI, FEC).
• Le droit de réponse à un litige éventuel (Code de la consommation, garanties légales jusqu’à 2 ans après l’achat).

L’enjeu pratique : un module qui supprime tout brutalement met l’entreprise en infraction comptable. Un module qui ne supprime rien met l’entreprise en infraction RGPD (sanction jusqu’à 4 % du CA mondial). La bonne pratique, c’est la pseudonymisation sélective — supprimer ce qui n’est pas nécessaire à une obligation légale, conserver le reste sous une forme non rattachable à une personne identifiée.

Ce que l’article 17 RGPD dit exactement

L’article 17.1 énumère six motifs qui justifient la demande de suppression :

1. Les données ne sont plus nécessaires à la finalité pour laquelle elles ont été collectées.
2. La personne retire son consentement et il n’existe pas d’autre fondement juridique.
3. La personne s’oppose au traitement et il n’existe pas de motif légitime impérieux.
4. Les données ont fait l’objet d’un traitement illicite.
5. Les données doivent être effacées pour respecter une obligation légale.
6. Les données ont été collectées dans le cadre de l’offre de services à un enfant.

Mais l’article 17.3 prévoit cinq exceptions qui s’appliquent fréquemment au e-commerce :

1. Exercice de la liberté d’expression et d’information.
2. Respect d’une obligation légale (par exemple : conservation comptable).
3. Motif d’intérêt public dans le domaine de la santé publique.
4. Fins archivistiques, recherche scientifique ou historique, statistiques.
5. Constatation, exercice ou défense de droits en justice.

L’exception (b) — obligation légale — est celle qui s’applique aux données comptables. Mais elle ne couvre pas toutes les données d’un compte client : seulement celles strictement nécessaires à la tenue de la comptabilité et au respect de la durée de conservation (10 ans).

Cartographier les données d’un compte client

Sur une boutique PrestaShop avec 5 ans d’historique, un compte client contient typiquement :

Catégorie de donnée	Exemples	Suppression article 17	Conservation légale
Identification	nom, prénom, email, téléphone	Pseudonymiser	10 ans (compta)
Adresses	livraison, facturation	Conserver adresse de facturation, supprimer livraison ancienne	10 ans pour facturation
Commandes	numéro, date, montants, items	Conserver	10 ans (compta) + 2 ans (garantie légale)
Paiements	tokens Stripe/PayPal, derniers chiffres	Supprimer si plus utilisés	Pas obligation, mais utile pour litige
Mots de passe	hash bcrypt	Supprimer immédiatement	Aucune
Préférences	newsletter, marketing, cookies	Supprimer	Aucune (sauf preuve de consentement utile 3 ans)
Historique de navigation	logs visites, paniers abandonnés	Supprimer	Aucune
Avis et commentaires	avis produits, messages SAV	Anonymiser (« Client anonyme »)	Variable selon affichage public
Programme fidélité	points, statuts	Supprimer	Aucune
Wishlist	produits favoris	Supprimer	Aucune

La règle de tri : est-ce que cette donnée est nécessaire à la trace comptable ou à un éventuel litige ? Si oui, on conserve sous forme pseudonymisée. Si non, on supprime.

Pseudonymisation : le mécanisme central

Pseudonymiser, ce n’est pas anonymiser. La différence est juridique et technique :

• Anonymisation : suppression irréversible du lien entre la donnée et la personne. La donnée ne peut plus jamais être rattachée. L’anonymisation sort la donnée du périmètre RGPD.
• Pseudonymisation : remplacement des identifiants directs par un pseudonyme, mais le lien reste théoriquement reconstructible (par exemple via une table de correspondance chiffrée). La donnée reste dans le périmètre RGPD, mais le traitement est considéré comme moins risqué.

Pour le e-commerce, on vise généralement une pseudonymisation forte qui s’apparente à de l’anonymisation pratique :

• customer.firstname → "Client"
• customer.lastname → "#" + id_customer (ex. "#42851")
• customer.email → "deleted-" + id_customer + "@invalid" (préfixe spécial, domaine invalide)
• customer.phone → NULL
• customer.passwd → bytes aléatoires (compte effectivement inutilisable)
• customer.note → NULL
• address.firstname, address.lastname sur adresses anciennes → pseudonyme
• address.firstname, address.lastname sur l’adresse de facturation des commandes existantes → conserver (nécessaire à la facture)

La clé est dans la nuance : on garde la facture telle qu’elle a été émise (obligation comptable), mais on supprime tout ce qui ne sert plus.

Architecture d’un module de suppression conforme

Un module sérieux pour PrestaShop comme DfAccountDelete implémente cinq couches :

Couche 1 — Identification de la demande

Trois canaux possibles :

• Bouton dans l’espace client — « Supprimer mon compte » accessible depuis « Mes informations ». UX du self-service.
• Formulaire de demande — pour les anciens clients qui ne peuvent plus se connecter. Vérification d’identité par email avec lien de confirmation.
• Demande au DPO/contact RGPD — par email ou courrier, traitée manuellement avec retranscription dans le système.

Couche 2 — Vérification d’identité

Avant suppression, on vérifie que la personne est bien titulaire du compte. Pour les clients connectés : le fait d’être connecté + saisie du mot de passe ou validation par email (magic link bis). Pour les clients non connectés : envoi d’un email de confirmation avec un lien de validation single-use à durée limitée (1 heure typiquement). Pour les demandes par courrier : copie d’une pièce d’identité conservée 1 an puis détruite.

Couche 3 — Délai de réflexion

Optionnel mais recommandé : un délai de 7 à 30 jours entre la demande et l’exécution effective. L’utilisateur reçoit un email « votre demande sera traitée le [date], cliquez ici pour annuler ». Cela évite les suppressions accidentelles et les regrets. C’est une bonne pratique CNIL.

Couche 4 — Exécution de la pseudonymisation

Le module exécute en transaction MySQL atomique :

1. Pseudonymise ps_customer (nom, email, téléphone, etc.).
2. Pseudonymise les ps_address non rattachées à des commandes finalisées.
3. Supprime ps_cart abandonnés, ps_compare, ps_wishlist.
4. Supprime les entrées de programme fidélité, alertes prix, alertes stock.
5. Anonymise les avis publics (« Client anonyme ») ou les supprime selon la politique.
6. Supprime les logs de session, tokens magic link, paniers sauvegardés.
7. Supprime les abonnements newsletter (et propage à Mailchimp, Brevo via API si connecté).
8. Marque le compte comme supprimé (active=0, deleted=1, deleted_at = now).
9. Conserve intactes les commandes, factures, avoirs (ps_orders, ps_order_invoice, ps_order_slip).

Couche 5 — Audit log et notification

Une entrée dans un journal d’audit RGPD :

• Date de la demande, date de l’exécution.
• Email d’origine (avant pseudonymisation).
• ID client.
• Méthode de vérification d’identité.
• Liste des tables touchées et nombre de lignes affectées.

Ce log est conservé 3 ans (durée recommandée par la CNIL pour démontrer la conformité). Il sert en cas d’inspection CNIL ou de demande de la personne (« avez-vous vraiment supprimé mes données ? »).

Un email de confirmation est envoyé à l’adresse d’origine, avec mention que les données ont été supprimées sauf celles nécessaires à la comptabilité (transparence article 12 RGPD).

Le pont avec le FEC : ce qu’il faut absolument préserver

Comme expliqué dans notre article sur le FEC et l’export comptable, certaines données sont nécessaires à la production d’un FEC conforme :

• Identification du client sur la facture émise (nom + adresse de facturation au moment de l’émission). Mais on n’a pas besoin que ce nom soit toujours retrouvable depuis la base clients vivante — il est dans la facture PDF archivée et dans ps_orders.
• Montants HT, TVA, port, total TTC — données comptables pures, à conserver intactes.
• Date de la commande, de la facture, du paiement — idem.
• Méthode de paiement (Stripe, PayPal, virement) — utile pour le rapprochement bancaire.

Le pattern pratique : on pseudonymise ps_customer, mais on laisse ps_orders.firstname, ps_orders.lastname, ps_orders.email tels qu’ils étaient au moment de la commande. C’est ce qui apparaît sur la facture émise. La facture est l’enregistrement comptable, immuable. Le compte client est un agrégat vivant, qu’on peut anonymiser.

Sur PrestaShop, cette logique est facilitée par le fait que la facture est gérée par ps_order_invoice avec ses propres champs (le nom n’est pas seulement référencé par id_customer, il est aussi figé dans la commande). Sur WooCommerce, c’est plus délicat : les orders WC stockent l’customer ID et reconstruisent les infos à l’affichage. Il faut donc figer le nom et l’adresse de facturation sur l’order au moment de la pseudonymisation, sinon la facture régénérée affiche « Client anonyme ».

Les avis et commentaires : un cas à part

Un avis produit affiché publiquement avec le nom du client est une donnée personnelle (article 4 RGPD). Sa suppression à la demande pose deux problèmes :

• Le contenu de l’avis a une valeur pour les autres clients (information consommateur).
• L’historique des avis sert à la moyenne de notation.

La résolution juridique standard : anonymiser le nom (« Client anonyme » ou « C.A. »), conserver le contenu de l’avis et la note. C’est un traitement statistique au sens de l’article 17.3.d. Si le client demande explicitement la suppression complète de l’avis (« je ne veux plus que ce texte existe »), alors on supprime entièrement, mais on peut ré-évaluer la moyenne sans la donnée perdue.

Cette nuance doit être présentée à l’utilisateur dans le formulaire : « Voulez-vous supprimer vos avis ou les rendre anonymes ? ».

Cas particuliers difficiles

Compte client avec un litige en cours

Si une commande est en litige (retour bloqué, contestation, action en garantie), la suppression des données du client compromet la défense de l’entreprise. Article 17.3.e couvre ce cas : on peut refuser la suppression jusqu’à résolution du litige, en informant le client de cette raison. La conservation se fait sous statut « en litige », avec accès restreint.

Compte B2B avec multi-utilisateurs

Sur un compte B2B avec plusieurs utilisateurs, la suppression du compte d’un utilisateur ne doit pas supprimer la société. On supprime l’utilisateur (qui a un droit individuel), on conserve les commandes au nom de la société (qui n’a pas de droit à l’oubli, étant une personne morale).

Newsletter sans compte (anonyme)

Un email inscrit à la newsletter sans compte client : la suppression est immédiate, sans pseudonymisation. Pas d’obligation comptable rattachée. Une exception : si le consentement marketing est tracé pour preuve, on peut conserver l’historique du consentement (date, IP, opt-in) pendant 3 ans après désinscription. Au-delà, suppression complète.

Abonnés à un service récurrent (abonnement)

Pour les boutiques en abonnement, la suppression du compte exige d’abord l’arrêt de l’abonnement (impossible de débiter une carte d’un compte qui n’existe plus). Le module doit séquencer : annulation des abonnements → attente d’un cycle pour confirmation → pseudonymisation. Skipper la séquence cause des débits orphelins et des contentieux clients.

Le délai de réponse imposé par le RGPD

Article 12.3 RGPD : la réponse à une demande doit intervenir sous 1 mois, prolongeable à 2 ou 3 mois pour les demandes complexes (avec notification de la prolongation au demandeur). En pratique pour le e-commerce :

• Demande simple via le bouton « supprimer mon compte » : exécution immédiate (selon délai de réflexion optionnel) — bien en deçà du délai légal.
• Demande par email/courrier qui exige une vérification d’identité : 1 à 2 semaines de traitement, en deçà du mois.
• Demande dans un contexte complexe (litige, abonnement actif, multi-comptes) : 1 mois avec information du demandeur du statut.

Le non-respect du délai expose à des sanctions CNIL. Un module automatisé qui répond sous 24-48 h couvre largement le risque.

Coût et ROI

Le ROI d’un module de suppression de compte conforme se mesure différemment d’un module de conversion :

• Coût du module : 39 € licence pour PrestaShop.
• Coût évité d’une sanction CNIL : variable, mais les sanctions e-commerce 2023-2025 vont de 5 000 € pour PME à plusieurs millions pour les grandes enseignes. Le ratio coût/risque est extrêmement favorable.
• Coût évité de retraitement manuel : sur une boutique de 50 000 clients, traiter 5 à 10 demandes/mois manuellement représente 2 à 4 h/mois de travail interne — environ 1 200 €/an.
• Bénéfice de confiance : afficher un bouton « supprimer mon compte » bien visible est devenu un signal de confiance fort en 2026, mesurable en taux de création de compte (+3 à 6 % observé).

FAQ

Faut-il vraiment garder les commandes 10 ans après suppression du compte ?

Oui, c’est l’obligation comptable (code de commerce L.123-22). Le RGPD ne dispense pas du droit fiscal. La résolution : les commandes restent en base sous forme pseudonymisée (le nom du client n’est plus rattaché à un compte vivant mais figure encore sur la facture émise, comme c’est nécessaire). À l’issue des 10 ans, suppression complète possible.

Que faire si Mailchimp ou Brevo continue d’envoyer la newsletter ?

Le RGPD article 19 impose la propagation de la suppression aux destinataires des données. Si vous avez synchronisé votre base avec Mailchimp/Brevo/Klaviyo, le module doit appeler leur API pour supprimer le contact (et pas seulement le désabonner). C’est un point à valider à l’installation : tous les connecteurs marketing doivent recevoir le signal de suppression.

Comment gérer la suppression chez les sous-traitants (Stripe, PayPal) ?

Stripe et PayPal conservent les tokens de paiement et l’historique des transactions selon leur politique (généralement 10 ans pour conformité fiscale + lutte anti-blanchiment). Vous ne pouvez pas forcer leur suppression — c’est leur obligation légale, distincte de la vôtre. La mention dans votre politique de confidentialité doit indiquer que les sous-traitants de paiement conservent les données selon leur propre durée légale.

Peut-on supprimer un compte sans en informer le client ?

Si c’est le client qui a demandé la suppression : on l’informe de l’exécution. Si c’est l’entreprise qui supprime à son initiative (inactivité prolongée, par exemple) : on doit avoir prévu cette politique dans les CGV/politique de confidentialité, et idéalement notifier 30 jours avant suppression pour permettre l’opposition. La suppression sans notification est risquée.

Combien de temps après une demande d’oubli un client peut-il revenir vers nous ?

Le droit à l’oubli n’est pas un droit à l’inversion. Une fois les données supprimées (ou pseudonymisées), le client qui revient crée un nouveau compte ex nihilo. L’historique reste dans l’audit log RGPD (qui sert à prouver qu’on a exécuté la demande), mais ne peut pas être réutilisé pour reconstituer le compte initial.

En synthèse

La suppression de compte conforme à l’article 17 RGPD est un exercice d’équilibrisme entre quatre obligations légales contradictoires. La résolution passe par la pseudonymisation sélective : on supprime ou anonymise tout ce qui n’est pas couvert par une obligation de conservation, on conserve intactement la trace comptable nécessaire au FEC et au contrôle fiscal.

Le module DfAccountDelete pour PrestaShop implémente cette logique avec les cinq couches d’un workflow conforme : identification, vérification d’identité, délai de réflexion optionnel, pseudonymisation atomique, audit log. Il s’intègre avec l’export FEC pour ne pas casser la chaîne comptable et avec les principaux outils marketing (Mailchimp, Brevo, Klaviyo) pour propager la suppression.

Le bon réflexe en 2026 : afficher un bouton « supprimer mon compte » bien visible dans l’espace client (signal de confiance, conformité explicite), documenter le workflow dans la politique de confidentialité (transparence article 12), conserver l’audit log 3 ans pour démontrer la conformité en cas d’inspection CNIL.

Pour les boutiques qui souhaitent un audit complet de leur conformité RGPD, notre audit PrestaShop couvre les six points critiques : cookies et consentement, base de traitement des données clients, durées de conservation paramétrées, droit à l’accès et à la portabilité, droit à l’oubli, registre des traitements article 30.