Tout ce que vous voudriez savoir avant d'installer.
Un regard détaillé sur le fonctionnement de DataFirefly Account Delete RGPD, pourquoi nous l'avons conçu ainsi, et la réflexion derrière les fonctionnalités ci-dessus.
Pourquoi ce module est essentiel
Depuis 2018, le RGPD impose à toute entreprise traitant des données personnelles de citoyens européens de permettre à ses utilisateurs d'exercer leur droit à l'effacement (Article 17). PrestaShop ne propose pas cette fonctionnalité nativement : l'administrateur doit traiter chaque demande manuellement, supprimer le compte côté boutique, puis retirer l'email de chaque plateforme newsletter une par une. C'est chronophage, source d'erreurs, et risqué en cas d'audit CNIL. Ce module automatise entièrement le processus, depuis la demande du client jusqu'à la désinscription des plateformes newsletter tierces.
Deux modes : anonymisation ou suppression totale
Le module propose deux modes de fonctionnement. En mode anonymisation (recommandé), les données personnelles du client sont remplacées par des valeurs anonymes : son nom devient « Anonymized », son email un identifiant interne unique, ses adresses sont scrubées (mais conservées si elles sont liées à des commandes). Les commandes restent intactes pour respecter l'obligation comptable française de conservation pendant 10 ans, conformément à l'article L123-22 du Code de Commerce. En mode suppression, le compte est entièrement effacé si aucune commande n'existe ; sinon le module bascule automatiquement en anonymisation pour ne pas casser l'historique légal.
Confirmation par email sécurisée
Pour éviter les suppressions accidentelles ou malveillantes, le module envoie un email de confirmation contenant un lien unique avec token cryptographique. Le token est généré avec random_bytes de 32 octets puis converti en hexadécimal sur 64 caractères. Seul son hash SHA-256 est stocké en base de données, jamais le token en clair. Le lien expire après une durée configurable (24 heures par défaut). Le client doit également valider son mot de passe avant que l'email de confirmation soit envoyé : cela bloque les tentatives de suppression par un tiers ayant accès à une session ouverte.
Intégrations newsletter détaillées
Trois plateformes sont supportées en standard. Pour Mailchimp, l'endpoint utilisé est POST sur lists/{list_id}/members/{hash}/actions/delete-permanent qui supprime définitivement l'abonné et empêche tout futur réabonnement avec cet email (le vrai droit à l'oubli au sens RGPD). Une option permet de basculer sur un simple archivage si vous préférez. Pour Brevo (ex-Sendinblue), c'est DELETE sur v3/contacts/{email} qui retire le contact de toutes les listes. Si vous renseignez un List ID, le contact est seulement retiré de cette liste précise au lieu d'être supprimé totalement. Pour Mailjet, le module utilise l'endpoint GDPR officiel DELETE v4/contacts/{id} après lookup de l'identifiant contact. Chaque provider possède un bouton « Tester la connexion » dans le back-office pour valider la configuration avant mise en production.
Architecture extensible pour ajouter d'autres plateformes
Les providers newsletter suivent un pattern Strategy avec une interface PHP DataFirefly/AccountDelete/ProviderInterface. Ajouter Sendgrid, Mailerlite, HubSpot, ActiveCampaign ou n'importe quelle autre plateforme demande uniquement la création d'une classe étendant AbstractProvider avec quatre méthodes : isEnabled, getKey, deleteSubscriber et testConnection. La classe est ensuite référencée dans DataFirefly/AccountDelete/Service::getProviders. Aucune autre modification du module n'est nécessaire. La documentation README livrée avec le module détaille un exemple complet.
Journal de traitement RGPD
Toute demande est enregistrée dans la table ps_dfad_log avec uniquement des données pseudonymisées : hash SHA-256 de l'email (jamais l'email en clair), hash SHA-256 de l'IP du demandeur, identifiant interne du client, mode appliqué (anonymisation ou suppression), liste des providers contactés avec leur code de retour HTTP, user-agent tronqué, identifiant boutique, horodatage UTC. Ce journal sert de preuve du traitement en cas d'audit CNIL ou de litige avec un client. Il n'est volontairement pas supprimé à la désinstallation du module pour préserver cette preuve sur la durée.
Toutes les données nettoyées
Outre l'anonymisation du compte client lui-même, le module nettoie de nombreuses tables liées : ps_emailsubscription et ps_newsletter (désinscription native PrestaShop), ps_cart et ps_cart_product (paniers non commandés), ps_wishlist et ps_wishlist_product (liste d'envies si le module natif est actif), ps_compare et ps_compare_product (comparateur produits), ps_customer_thread et ps_customer_message (échanges SAV), ps_guest (sessions invitées non liées à des commandes). Les adresses non liées à des commandes sont supprimées intégralement, celles liées à des commandes sont anonymisées (firstname, lastname, address1, postcode, city, phone remplacés par des valeurs neutres).
Il n’y a pas encore d’avis.