Suppression de compte RGPD — Guide complet

Vue d’ensemble

Le module Suppression de compte RGPD donne à vos clients le moyen d’exercer leur droit à l’effacement (Article 17 du RGPD) directement depuis leur espace client, sans intervention manuelle de votre part. Une demande déclenche en cascade : confirmation par email avec token cryptographique, anonymisation ou suppression du compte côté boutique, désinscription automatique sur Mailchimp, Brevo et Mailjet, et écriture d’une preuve de traitement dans un journal d’audit.

Installation

1. Connectez-vous au back-office PrestaShop.
2. Allez dans Modules → Module Manager, cliquez sur Uploader un module et déposez le ZIP dfaccountdelete-1.0.2.zip.
3. Le module est installé et activé automatiquement. Cliquez sur Configurer.

L’installation crée deux tables : ps_dfad_log (journal RGPD) et ps_dfad_token (tokens de confirmation par email). Elle enregistre le module sur le hook displayCustomerAccount, qui ajoute un bloc « Supprimer mon compte » dans l’espace client.

Configuration générale

L’écran de configuration est divisé en quatre panneaux : Paramètres généraux, Mailchimp, Brevo, Mailjet. Chaque panneau se sauvegarde indépendamment.

Mode de suppression

Choisissez entre deux modes :

• Anonymiser (recommandé) : les données personnelles du client (nom, prénom, email, téléphone, adresses, date de naissance) sont remplacées par des valeurs anonymes. Les commandes restent intactes pour respecter l’obligation comptable de conservation pendant 10 ans (article L123-22 du Code de Commerce).
• Supprimer totalement si possible : le compte est entièrement effacé si aucune commande n’existe. Si des commandes existent, le module bascule automatiquement en mode anonymisation pour ne pas casser l’historique légal.

Confirmation par email obligatoire

Activée par défaut (très fortement recommandée). Le client doit cliquer sur un lien reçu par email pour valider sa demande. Cela empêche toute suppression accidentelle ou par un tiers qui aurait accédé à une session ouverte.

Durée de validité du token

En heures. 24 heures par défaut. Au-delà de cette durée, le lien dans l’email expire et la demande est annulée automatiquement.

Logs

Activés par défaut. Le module écrit dans ps_dfad_log chaque demande avec uniquement des données pseudonymisées : hash SHA-256 de l’email, hash SHA-256 de l’IP, identifiant client, mode appliqué, statut, providers contactés, user agent, identifiant boutique, horodatage. Aucune donnée personnelle n’est conservée en clair.

Email administrateur notifié

Adresse qui recevra une notification (hash de l’email seulement, jamais l’email en clair) à chaque suppression effective. Par défaut, l’email de la boutique.

Configuration des providers newsletter

Le module supporte en standard trois plateformes newsletter. Chaque provider est désactivé par défaut. Activez seulement ceux que vous utilisez.

Mailchimp

Renseignez :

• Clé API : format xxxxxxxxxxxx-us21. Le suffixe (-us21, -eu1, etc.) est le datacenter Mailchimp. Le module le détecte automatiquement.
• List ID (Audience ID) : identifiant de votre audience principale. Trouvable dans Mailchimp via Audience → Settings → Audience name and defaults.
• Suppression permanente : activée par défaut. Utilise l’endpoint POST /lists/{list_id}/members/{hash}/actions/delete-permanent qui correspond au vrai droit à l’oubli RGPD : l’email est définitivement supprimé et Mailchimp refusera tout futur opt-in avec cette adresse. Si vous préférez un simple archivage (l’email peut alors se réinscrire plus tard), désactivez cette option.

Cliquez sur Tester la connexion pour valider votre configuration. Si tout est correct, vous verrez le nom de votre audience.

Brevo (ex-Sendinblue)

Renseignez :

• Clé API v3 : format xkeysib-xxxxxx. Trouvable dans Brevo via Mon compte → SMTP & API → Clés API.
• List ID (optionnel) : si renseigné, ne retire le contact que de cette liste. Si vide, supprime le contact entièrement (recommandé pour RGPD).

Endpoint utilisé : DELETE /v3/contacts/{email} pour suppression totale, ou POST /v3/contacts/lists/{id}/contacts/remove pour retrait d’une liste.

Mailjet

Mailjet utilise une authentification Basic avec deux clés. Renseignez :

• API Key
• API Secret
• Contact List ID (optionnel) : si renseigné, désinscrit de cette liste uniquement. Si vide, supprime le contact via l’endpoint GDPR officiel de Mailjet.

Le flux de suppression Mailjet est en deux étapes : lookup de l’identifiant contact via GET /v3/REST/contact/{email}, puis DELETE /v4/contacts/{id} sur l’endpoint GDPR. Le module gère cette mécanique automatiquement.

Anonymisation ou suppression : que choisir ?

Le RGPD impose le droit à l’effacement, mais le Code de Commerce français impose la conservation des pièces comptables pendant 10 ans. Ces deux obligations sont conciliées par l’anonymisation, qui est la position recommandée par la CNIL.

Mode anonymisation

Le module remplace dans ps_customer :

• firstname → Anonymized
• lastname → Customer
• email → anon-{id_customer}-{hash}@anonymized.local
• passwd → hash aléatoire (le client ne pourra plus se connecter)
• birthday → NULL
• note, website, ip_registration_newsletter → vide
• active → 0, deleted → 1

Pour les adresses :

• Les adresses non utilisées par des commandes sont supprimées intégralement.
• Les adresses utilisées par des commandes sont anonymisées (firstname, lastname, address1, postcode, city, phone, etc. remplacés par des valeurs neutres) et marquées deleted = 1.

Mode suppression totale

Si le client n’a passé aucune commande : suppression complète des adresses puis appel à Customer::delete(). Sinon : bascule automatique en mode anonymisation. Aucune option ne permet de forcer la suppression d’un compte avec commandes — c’est volontaire pour des raisons légales.

Flux complet d’une demande

1. Le client va dans Mon Compte et clique sur le bloc « Supprimer mon compte ».
2. Il arrive sur une page de confirmation avec un encart d’avertissement, un champ « Mot de passe » et une checkbox « Je comprends que cette action est irréversible ».
3. Il saisit son mot de passe et coche la case. Le module vérifie le mot de passe via la classe PrestaShop/Core/Crypto/Hashing.
4. Si la confirmation par email est activée, le module génère un token aléatoire de 32 octets (random_bytes(32)), le convertit en hexadécimal sur 64 caractères, stocke son hash SHA-256 dans ps_dfad_token, et envoie un email contenant le token en clair dans une URL.
5. Le client reçoit l’email et clique sur le lien. Le module récupère le token depuis l’URL, calcule son SHA-256, et vérifie qu’il existe dans la table, qu’il n’est pas expiré, et qu’il n’a pas déjà été consommé.
6. Le token est marqué consommé (consumed_at = NOW()) pour éviter toute réutilisation.
7. Pour chaque provider activé (Mailchimp, Brevo, Mailjet), le module appelle l’API de suppression et enregistre le résultat (code HTTP, message) dans le journal.
8. Le module nettoie les tables PrestaShop : ps_emailsubscription, ps_newsletter, ps_cart, ps_cart_product, ps_wishlist, ps_compare, ps_customer_thread, ps_customer_message, ps_guest.
9. Selon le mode et la présence de commandes, le compte est anonymisé ou supprimé.
10. Une ligne est insérée dans ps_dfad_log avec le statut done, le mode réellement appliqué, et la liste des résultats providers.
11. Un email de notification est envoyé à l’administrateur configuré (hash de l’email uniquement).
12. Le client est déconnecté et redirigé vers une page de confirmation.

Journal de traitement RGPD

L’écran de configuration affiche les 30 dernières demandes avec :

• ID de la demande
• Hash email tronqué (12 premiers caractères du SHA-256)
• Mode appliqué (anonymize / delete)
• Statut (awaiting_confirm, done)
• Liste des providers et leur code de retour, par exemple mailchimp:OK(200) | brevo:OK(204) | mailjet:OK(200)
• Date et heure UTC

La table complète contient également : hash SHA-256 de l’IP, user agent tronqué à 250 caractères, identifiant boutique, notes internes (présence ou non de commandes).

Tester avant mise en production

Procédure recommandée avant d’activer le module sur une boutique de production :

1. Test des connexions providers : dans le BO du module, cliquez sur Tester la connexion pour chaque plateforme activée. Vous devez voir un message vert avec le nom de votre audience/compte. En cas d’erreur, le message HTTP exact remonté par l’API est affiché.
2. Test du flux complet sur un compte de test :
   • Créez un compte client avec une vraie adresse email que vous contrôlez.
   • Inscrivez-le à votre newsletter Mailchimp/Brevo/Mailjet manuellement, ou via le formulaire de votre boutique.
   • Vérifiez qu’il apparaît bien dans chaque plateforme.
   • Connectez-vous à ce compte côté boutique et lancez la procédure de suppression.
   • Confirmez via l’email reçu.
   • Vérifiez dans ps_customer que le compte est bien anonymisé.
   • Vérifiez dans chaque plateforme newsletter que l’email a disparu.
   • Vérifiez l’entrée dans ps_dfad_log.
3. Test du cas « client avec commande » : créez un compte, passez une commande de test (1€), puis lancez la suppression en mode « Supprimer totalement ». Vérifiez que le module a bien basculé en anonymisation et que la commande est intacte mais avec une adresse anonyme.

Étendre : ajouter un nouveau provider

L’architecture suit un pattern Strategy. Ajouter Sendgrid, Mailerlite, HubSpot, ActiveCampaign ou n’importe quelle autre plateforme demande uniquement la création d’une classe.

Créez classes/Provider/SendgridProvider.php :

class DfAccountDelete_SendgridProvider extends DfAccountDelete_AbstractProvider
{
    public function getKey() { return 'sendgrid'; }

    public function isEnabled()
    {
        return (bool) Configuration::get('DFAD_SG_ENABLED')
            && Configuration::get('DFAD_SG_API_KEY');
    }

    public function deleteSubscriber($email)
    {
        $headers = ['Authorization: Bearer ' . Configuration::get('DFAD_SG_API_KEY')];
        $url = 'https://api.sendgrid.com/v3/marketing/contacts?emails=' . rawurlencode($email);
        $res = $this->http('DELETE', $url, $headers);
        return ['ok' => $res['ok'], 'status' => $res['status'], 'message' => $res['message']];
    }

    public function testConnection()
    {
        $headers = ['Authorization: Bearer ' . Configuration::get('DFAD_SG_API_KEY')];
        $res = $this->http('GET', 'https://api.sendgrid.com/v3/scopes', $headers);
        return ['ok' => $res['ok'], 'status' => $res['status'], 'message' => $res['message']];
    }
}

Référencez la classe dans DfAccountDeleteService::getProviders() :

public function getProviders()
{
    return [
        new DfAccountDelete_MailchimpProvider(),
        new DfAccountDelete_BrevoProvider(),
        new DfAccountDelete_MailjetProvider(),
        new DfAccountDelete_SendgridProvider(), // nouveau
    ];
}

Et chargez la classe en haut de dfaccountdelete.php avec un require_once. Le reste (panneau de configuration BO, bouton de test, intégration au flux de suppression) est à coder de manière similaire aux providers existants.

FAQ et dépannage

Le client dit ne pas avoir reçu l’email de confirmation

Vérifiez : (1) la configuration SMTP de PrestaShop est-elle fonctionnelle (envoyez-vous d’autres emails transactionnels comme les confirmations de commande ?), (2) l’email n’est-il pas dans ses spams, (3) le délai d’expiration n’a-t-il pas été atteint. Le client peut relancer la procédure depuis son compte — le nouveau token invalide automatiquement les précédents.

Une plateforme newsletter retourne une erreur 401

La clé API est invalide ou expirée. Régénérez-la dans la plateforme concernée et mettez-la à jour dans la configuration du module. Utilisez le bouton Tester la connexion pour valider immédiatement.

L’erreur SQL « LIMIT 1 LIMIT 1 » apparaît

Vous êtes sur une version antérieure à 1.0.1. Mettez à jour vers la dernière version : ce bug a été corrigé en 1.0.1.

Le compte ne semble pas anonymisé : le nom/prénom/email d’origine sont toujours visibles

Vous êtes sur une version antérieure à 1.0.2. La validation interne PrestaShop sur Validate::isCustomerName() refusait l’ancienne valeur de lastname qui contenait le caractère # et des chiffres, ce qui faisait échouer silencieusement la mise à jour. Mettez à jour vers la 1.0.2 : l’upgrade automatique répare également les comptes mal anonymisés des versions précédentes.

Comment supprimer le journal RGPD lors de la désinstallation ?

La table ps_dfad_log est volontairement conservée à la désinstallation (preuve du traitement). Pour la supprimer manuellement après désinstallation : DROP TABLE ps_dfad_log; DROP TABLE ps_dfad_token;.

Le module est-il compatible avec mon module RGPD existant (gdpr, psgdpr) ?

Oui, les deux modules peuvent coexister. Le module officiel PrestaShop psgdpr sert principalement pour l’export des données et la gestion des consentements ; dfaccountdelete sert pour la suppression effective des comptes avec intégration newsletter. Ils ne se marchent pas sur les pieds.

Le client peut-il annuler après avoir cliqué sur le bouton ?

Oui, tant qu’il n’a pas cliqué sur le lien dans l’email de confirmation. Le token expire automatiquement après la durée configurée (24 heures par défaut). Pendant cette fenêtre, le compte reste pleinement actif. S’il ne fait rien, la demande est annulée.

Comment ajouter le bloc de suppression ailleurs que dans Mon Compte ?

Vous pouvez créer un lien direct vers {shop_url}/{lang}/module/dfaccountdelete/delete depuis n’importe quelle page (footer, page CGU, etc.). Si le visiteur n’est pas connecté, il sera redirigé vers la page de connexion avec retour sur la page de suppression après authentification.

Versions et changelog

1.0.2 — correction critique

• Fix : anonymizeCustomer() utilisait Customer::update() qui passe par Validate::isCustomerName(). Cette validation interdit les chiffres et le caractère # dans firstname/lastname, ce qui faisait échouer silencieusement l’anonymisation du record ps_customer. Remplacé par un UPDATE SQL direct qui bypasse la validation.
• L’upgrade upgrade-1.0.2.php répare rétroactivement les comptes traités par les versions précédentes qui étaient restés non-anonymisés.

1.0.1 — correction

• Fix : tableExists() utilisait Db::getValue() qui pré-pende automatiquement LIMIT 1. La requête SHOW TABLES LIKE 'xxx' LIMIT 1 est un SQL invalide en MariaDB. Remplacé par executeS().

1.0.0 — version initiale

• Compatibilité PrestaShop 8.0 à 9.x
• Mode anonymisation et mode suppression totale
• Confirmation par email avec token SHA-256
• Intégrations Mailchimp, Brevo, Mailjet
• Journal de traitement RGPD
• Interface et templates email en FR, EN, ES, DE