Audit RGPD PrestaShop : 88 points de contrôle pour boutiques

Table des matières :

Ce qu’un audit RGPD PrestaShop doit réellement couvrir

Un audit RGPD PrestaShop sérieux ne se limite pas à vérifier un bandeau cookies. Il doit couvrir l’ensemble du cycle de vie de la donnée personnelle dans une boutique : collecte (front), enrichissement (back-office), diffusion (emails, exports, API), stockage (MySQL + fichiers), logs applicatifs, et transferts vers des sous-traitants (paiement, transport, CRM, analytics). Sur PrestaShop, la difficulté n’est pas tant le core que l’addition de modules et de scripts tiers qui introduisent des traitements « hors radar ».

Pour être exploitable, l’audit doit aussi livrer des preuves et pas seulement des constats : inventaire des traitements et des sous-traitants, liste des modules/scripts avec finalités, écarts mesurés (ex. requêtes réseau avant consentement), puis un plan d’actions priorisé (risque × effort), avec responsables et échéances. C’est ce qui permet de tenir l’exigence d’accountability (capacité à démontrer la conformité).

Contexte de versions : les points ci-dessous s’appliquent principalement à PrestaShop 8.1–8.2 et PrestaShop 9.x (stack Symfony 6.4 côté back-office) avec PHP 8.1+ (cf. compatibilités discutées dans l’écosystème PrestaShop 9.1). Les écarts entre versions concernent surtout le back-office modernisé, certaines routes Admin et la manière dont des modules s’adossent au container Symfony. Dans tous les cas, la donnée client reste majoritairement dans MySQL (tables ps_customer, ps_address, ps_orders, etc.) et dans des logs plus ou moins maîtrisés (web server, PHP, application, WAF, CDN).

Côté exigences RGPD, deux rappels structurants : privacy by design/by default (article 25) et sécurité adaptée au risque (article 32). En pratique, cela implique (a) de réduire au strict nécessaire ce que vous collectez et exposez par défaut, et (b) de prouver des mesures de sécurité cohérentes avec les risques (accès Admin, exfiltration via exports, fuite via logs, etc.). Le RGPD encadre explicitement la sécurité :

« Le responsable du traitement et le sous-traitant mettent en œuvre des mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque… » (RGPD, article 32 — Règlement (UE) 2016/679) : Règlement (UE) 2016/679

Cartographier les données personnelles dans PrestaShop (core + modules)

La première étape opérationnelle, c’est une cartographie des traitements (registre (article 30)) orientée technique : quelles données, où, pourquoi, combien de temps, qui y accède, et quels flux sortants. Sur PrestaShop, la cartographie doit couvrir le core, mais aussi les modules (paiement, transport, avis, chat, anti-fraude, marketing automation), les webhooks, les exports CSV et les flux vers ERP/CRM (dans beaucoup d’architectures, l’e-commerce alimente Odoo ou inversement).

Une bonne cartographie « RGPD-ready » mélange 3 vues complémentaires :

Vue fonctionnelle : parcours (compte, panier, commande, SAV) + finalités (exécution du contrat, obligation légale, intérêt légitime, consentement).
Vue technique : DB, fichiers, logs, cache, queues, endpoints (webhooks/API), scripts tiers.
Vue prestataires : qui reçoit quoi (paiement, transport, emailing, retargeting, anti-fraude), et à quel titre (responsable conjoint ? sous-traitant ?).

Mini-scénario (typique en France) : une boutique PrestaShop expédie via un transporteur, encaisse via un PSP, et automatise le marketing via un outil d’emailing. Dans ce cas, l’audit doit tracer exactement quels champs partent : adresse et téléphone vers le transporteur, email vers l’emailing, identifiants de commande et montant vers le PSP, et (souvent oublié) l’IP et les identifiants cookies vers des tags marketing. Ce sont ces flux « invisibles » (scripts, pixels, logs) qui créent les non-conformités les plus fréquentes.

Côté base de données, vous devez identifier au minimum :

tables « identité » : ps_customer (email, hash de mot de passe), ps_address, ps_gender, ps_country ;
tables « transaction » : ps_orders, ps_order_payment, ps_order_invoice, ps_order_detail, ps_cart ;
tables « relation » : ps_customer_thread / ps_customer_message (SAV), ps_cart_rule (bons), ps_guest ;
tables « technique » souvent sous-estimées : ps_connections, ps_connections_source, ps_log (et selon modules : tables d’audit, de scoring, d’analytics).

Au-delà de MySQL, n’oubliez pas les zones “fichiers” qui finissent par contenir de la donnée personnelle : PDF de factures, pièces jointes SAV, exports CSV déposés sur le serveur, répertoires d’import/export de connecteurs, sauvegardes, ou encore stockage objet (S3/OVH Object Storage) utilisé par des modules.

Exemples de requêtes à préparer pour un inventaire rapide (à exécuter sur une copie, avec sauvegarde préalable) :

-- Où trouve-t-on l’email ?
SELECT TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND COLUMN_NAME LIKE '%email%';

-- Repérer des colonnes potentiellement sensibles
SELECT TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND COLUMN_NAME REGEXP '(ip|token|cookie|phone|mobile|dni|ssn|birth|passport)';

Enfin, la cartographie doit inclure les flux HTTP : scripts tiers (Tag Manager, pixels), endpoints API, et back-office exposé. Un test rapide et très parlant consiste à capturer :

les requêtes sortantes avant consentement (traceurs),
les requêtes sortantes au checkout (tags marketing souvent trop intrusifs),
les appels Admin (endpoints, upload, exports),
les webhooks entrants/sortants (PSP, transport, ERP).

Une boutique « conforme sur le papier » mais avec des accès Admin faibles ou un back-office accessible sans durcissement, c’est un risque RGPD direct (confidentialité). Pour l’angle sécurité applicative et journalisation, vous pouvez recouper avec : Sécurité PrestaShop : protéger API backoffice, WAF et journalisation SIEM.

Checklist : 88 points de contrôle RGPD pour boutiques PrestaShop

L’objectif de cette checklist n’est pas de remplacer un juriste/DPO, mais de fournir un référentiel vérifiable par une équipe technique. Chaque point doit produire une preuve (screenshot paramétrage, extrait de config, log d’accès, requête SQL, export du CMP, contrat DPA, etc.). Sans preuve, vous êtes dans l’opinion.

Méthode recommandée : scorez chaque item OK / KO / N.A., associez un niveau de risque (faible/moyen/élevé) et un coût (S/M/L). Priorisez ensuite les KO à risque élevé (souvent : cookies non conformes, absence de purge, fuites via logs, transferts hors UE non cadrés, back-office trop exposé). C’est exactement la logique « accountability » : démontrer la maîtrise, pas seulement déclarer l’intention.

Un format simple qui marche bien en atelier technique (et qui évite les débats abstraits) :

Champ	Exemple
Statut	KO
Risque	Élevé (impact confidentialité + exposition web)
Effort	M (1–3 jours)
Preuve attendue	Capture DevTools + export CMP + diff Tag Manager
Correctif	Bloquer tags avant consentement + règles GTM + QA
Owner	Lead dev / Marketing / DPO
Échéance	J+14

Référence consentement : le RGPD définit le consentement comme :

« toute manifestation de volonté, libre, spécifique, éclairée et univoque… » (RGPD, article 4(11) — Règlement (UE) 2016/679) : Guides RGPD (Règlement 2016/679)

Référence cookies (France) : les recommandations de la CNIL rappellent notamment l’importance du blocage préalable des traceurs non nécessaires et de la symétrie acceptation/refus. Point clé côté PrestaShop : la conformité dépend surtout du CMP et du déclenchement effectif des tags (pas du texte du bandeau). Page de référence : Cookies et autres traceurs — CNIL

A. Gouvernance & documentation (1–11)

Registre des traitements à jour (finalités, bases légales, durées, destinataires, transferts).
Identification claire responsable de traitement vs sous-traitants (paiement, transport, hébergeur, emailing).
DPA (Data Processing Agreement) signé avec l’hébergeur et chaque prestataire traitant des données.
Inventaire des modules et scripts tiers avec finalité, données manipulées, endpoints.
Politique de confidentialité versionnée (date, historique, traçabilité des changements).
Procédure interne DSAR (accès/rectification/effacement/portabilité/opposition) avec SLA.
Procédure de gestion d’incident + notification (articles 33 et 34) avec matrice de criticité.
DPIA déclenché si profilage à risque / scoring / anti-fraude intrusif / données sensibles.
Journal des accès Admin et actions sensibles conservé et consultable.
RACI/ownership : qui valide cookies, qui déploie, qui purge, qui répond aux demandes.
Preuves d’information des utilisateurs (mentions checkout, création compte, formulaires).

Astuce preuve utile : une page « inventaire modules & tags » exportée mensuellement (liste des modules installés + scripts injectés dans le thème/BO + Tag Manager) réduit énormément le temps d’audit, et rend visibles les ajouts « marketing » non tracés.

B. Collecte front (formulaires, champs, validation) (12–22)

Minimisation : aucun champ non nécessaire n’est « obligatoire » (ex. date de naissance).
Libellés de champs et messages d’aide explicitent la finalité (ex. téléphone = livraison).
Cases opt-in marketing non pré-cochées (email/SMS) et séparées des CGV.
Double opt-in si requis par votre politique (recommandé pour preuve en B2C email).
Preuve de consentement marketing stockée (timestamp, source, version texte).
Limitation des champs libres (commentaires) pour éviter collecte de données sensibles.
Protection anti-bot (rate limit / captcha) sans sur-collecte (éviter fingerprinting agressif).
Uploads (SAV, retours) : filtrage MIME/extension + antivirus côté serveur.
Journaux applicatifs : pas de dump $_POST en clair en production.
Erreurs/stack traces désactivées en prod (éviter fuite PII), cf. Gestion d’erreur PHP.
TLS strict (HTTPS partout, HSTS) et aucune page checkout servie en HTTP.

Point souvent négligé : les champs “commentaire de commande” et “message au transporteur” sont des aimants à données sensibles (« code porte », « indisponible car hospitalisé », etc.). La minimisation peut passer par un message d’avertissement + limitation de longueur + modération/filtrage.

C. Comptes, commandes, emails transactionnels (23–33)

Politique mot de passe robuste + rotation tokens reset (durée courte, usage unique).
MFA admin activable (module/SSO) et comptes inutilisés désactivés.
Segmentation des rôles back-office (permissions minimales par profil).
Exports clients/commandes restreints et tracés (qui exporte quoi, quand).
Emails transactionnels : pas de données inutiles (ex. éviter adresse complète dans sujet).
Factures/avoirs : protection contre indexation (robots + headers) si accessibles via URL.
Logs de paiement : ne jamais stocker PAN/CVV (PCI DSS), limiter les références.
SAV (ps_customer_thread) : purge/archivage défini, accès restreint.
Module d’avis : conformité sur les champs (pas de téléphone/adresse en clair).
Newsletter : mécanisme de désinscription effectif et immédiat.
Comptes invités : suppression / conversion contrôlée, durée de conservation définie.

Ajout opérationnel : vérifiez aussi les gabarits d’emails (thème + modules). Un module peut injecter des variables (adresse, téléphone) dans des emails ou PDF envoyés à des tiers (SAV, logistique). L’audit doit inclure un échantillon d’emails transactionnels réels (commande, reset, retour, SAV) pour contrôler la minimisation.

D. Cookies, traceurs et mesure d’audience (34–44)

CMP bloque réellement les tags avant consentement (audit réseau dans DevTools).
Refus aussi simple que l’acceptation (symétrie UI, pas de dark patterns).
Preuve de consentement (ID, date, catégories) stockée et exportable.
Durée de vie cookies conforme à la politique interne (pas de 13 mois par défaut sans raison).
Catégorisation : nécessaires / préférences / stats / marketing (pas de catégories floues).
Consentement granulaire par finalité (retargeting ≠ analytics).
Tag Manager : déclencheurs conditionnés au consentement (pas de “all pages”).
Masquage IP/anonymisation si outil analytics le permet.
Pas de fingerprinting sans base légale solide et documentation.
Pages panier/checkout : limiter au strict nécessaire (éviter scripts marketing).
Politique cookies cohérente avec la réalité (liste des cookies à jour).

Contrôle concret recommandé (rapide et reproductible) : faites 3 parcours et comparez les requêtes réseau :

1) arrivée sur home sans action (avant consentement),
2) acceptation « tout »,
3) refus « tout » + passage panier/checkout.

Si vous observez des appels vers des domaines marketing au point (1) ou (3), vous avez une non-conformité mesurable et une remédiation claire (blocage/conditionnement). Pour cadrer l’interprétation du consentement au niveau européen, les Guidelines 05/2020 on consent de l’EDPB sont une référence utile : Guidelines EDPB 05/2020

E. Sécurité applicative & infrastructure (45–55)

Back-office protégé (IP allowlist/VPN/SSO) ou au minimum durci (URL admin non triviale + WAF).
WAF en amont + règles anti-bot sur endpoints sensibles (login, contact, recherche).
Mises à jour PrestaShop et modules (inventaire CVE, fenêtre de patching).
Headers sécurité : CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
Séparation environnements (dev/staging/prod) avec données anonymisées hors prod.
Sauvegardes chiffrées, testées, avec rotation et accès restreint.
Chiffrement au repos si possible (disque/volume) + secrets hors repo (Vault/ENV).
Logs : suppression/masquage des PII (emails, tokens, IP si non nécessaire).
Accès DB : comptes dédiés, droits minimaux, pas de root applicatif.
Monitoring et détection (SIEM/alerting) sur événements Admin et anomalies.
Revue des endpoints API modules (auth, scopes, rate limiting), cf. Sécurité PrestaShop : API backoffice, WAF et journalisation SIEM.

Point “RGPD” très concret côté sécurité : contrôlez les canaux d’export (CSV, modules connecteurs, endpoints API). Une fuite ne vient pas toujours d’un hack sophistiqué : un compte Admin trop permissif + export non tracé suffit. D’où l’importance du point 26 (traces d’exports) et du point 9 (journal des accès).

F. Sous-traitants, transferts, intégrations (56–66)

Liste exhaustive des sous-traitants avec finalité et données envoyées.
Contrats : clauses de confidentialité + mesures de sécurité documentées.
Hébergement : localisation (UE/hors UE) et garanties si transfert.
Analytics / CDN / anti-fraude : vérifier transferts et identifiants persistants.
Webhooks : signatures/HMAC et rotation des secrets.
ERP/CRM : synchronisation minimale (n’envoyer que ce qui est nécessaire).
Mapping champs vers ERP (ex. Odoo) documenté ; éviter duplications inutiles.
Journalisation des flux sortants (sans PII en clair) pour auditabilité.
Gestion des erreurs d’intégration : pas de retry infini avec payload PII.
Accès prestataires (agence, support) : comptes nominatifs, durée limitée.
Revue périodique des clés API (rotation, révocation), y compris modules transport/paiement.

Conseil pragmatique : pour chaque prestataire, ajoutez une colonne “preuve technique du flux” (capture d’un webhook, extrait de log masqué, screenshot paramétrage module). Ça évite les inventaires « déclaratifs » qui ne résistent pas à un contrôle.

G. Conservation, purge, anonymisation (67–77)

Durées de conservation définies par catégorie (prospects, clients, commandes, SAV).
Purge automatique des paniers abandonnés au-delà d’un seuil (si pas de finalité).
Purge des ps_connections* et logs web (IP) avec rotation.
Anonymisation des données hors obligations légales (ex. après délai comptable).
Droit d’effacement : suppression logique vs physique documentée (et impacts).
Factures : conservation légale respectée, mais accès restreint.
Archivage : stockage séparé, chiffré, et accès en lecture seule.
Sauvegardes : politique d’effacement (les backups ne doivent pas conserver éternellement).
Données en fichiers (exports, PDF, pièces jointes) : purge planifiée.
Nettoyage DB industrialisé (cron) et contrôlé, cf. Base de données PrestaShop : routine de maintenance et nettoyage automatisé.
Tests : vérifier que la purge n’impacte pas les contraintes métiers (SAV, compta, retours).

Exemple de politique de rétention (à adapter et valider juridiquement selon votre contexte, notamment en France) :

Donnée	Finalité	Durée cible	Action
Paniers sans commande	Relance / intérêt légitime (si applicable)	30–90 jours	Suppression ou anonymisation
Logs de connexion (`ps_connections*`)	Sécurité / détection	6–12 mois	Rotation + purge
Threads SAV	Suivi client / preuve	1–3 ans	Archivage ou purge
Données marketing (opt-in)	Prospection	tant que consentement valide	purge à désinscription + revue périodique

Le point critique n’est pas la table MySQL : ce sont les copies (exports, backups, environnements de test) et les données “orphelines” (fichiers, logs applicatifs) qui contournent la purge.

H. Droits des personnes, transparence et incidents (78–88)

Export des données (portabilité) réalisable et complet (client + commandes + adresses).
Droit d’accès : produire un dossier lisible sans exposer données d’autres clients.
Droit de rectification : propagation vers sous-traitants (ERP/CRM) si synchronisés.
Droit d’effacement : vérifier suppression dans modules (avis, chat, anti-fraude).
Opposition marketing : stop effectif sur tous canaux (email/SMS/push) et dans les exports.
Paramètres compte : téléchargement / suppression sans intervention manuelle excessive.
Journal des demandes DSAR (date, type, statut) conservé (sans sur-collecte).
Breach playbook : collecte des preuves (logs) + qualification (données, volume, impact).
Notification CNIL/autorité : capacité à produire ce qui est exigé par art. 33.
Notification personnes concernées (art. 34) si risque élevé : modèles prêts.
Tests réguliers : exercices de simulation incident + revue post-mortem.

Ajout utile : testez réellement un DSAR « bout en bout » sur un compte de test (création, commande, SAV, newsletter), puis demande d’accès/effacement. Vous découvrirez vite les trous : modules qui conservent des données, exports incomplets, ou impossibilité de purger des pièces jointes.

Remédiations techniques typiques (sans casser le core)

Le piège classique sur PrestaShop : « corriger » en modifiant le core, puis perdre la conformité au prochain upgrade. La règle de base : module dédié, override minimal, hooks, et mise en place de tests/régression. Sur PrestaShop 8/9, privilégiez les points d’extension (hooks front, services Symfony côté Admin quand disponibles) plutôt que des patchs directs.

Sur les cookies, ne validez rien sans audit réseau. Ouvrez DevTools → Network, filtrez sur collect, pixel, gtm, analytics, et vérifiez que rien ne part avant consentement (sauf strictement nécessaire). Très souvent, le problème n’est pas le CMP, mais un tag injecté dans le thème, un module marketing qui force le chargement, ou un script ajouté via le back-office.

Une remédiation fréquente (et propre) consiste à :

centraliser l’injection des tags (éviter les scripts « en dur » dans le thème),
conditionner chaque tag à un signal de consentement,
désactiver/supprimer les modules redondants (deux trackers = deux fuites potentielles).

Pour la perf et l’impact JS, croisez aussi avec : DevTools : méthodes professionnelles pour mesurer et optimiser les performances web.

Sur la purge/anonymisation, vous aurez rarement un « bouton magique » fiable. L’approche propre est d’implémenter une politique de rétention via cron, avec journal des actions (sans PII) et dry-run. Exemple : supprimer les paniers de plus de X jours sans commande, purger les tables de connexions, et anonymiser des champs non nécessaires après la fenêtre légale. Ne négligez pas l’impact index/IO (des purges massives non planifiées peuvent bloquer la prod).

Un bon pattern d’exécution (évite les catastrophes en production) :

dry-run → comptage des lignes impactées + estimation temps,
exécution par batch (LIMIT / tranches temporelles),
fenêtre de maintenance,
métriques post-run (taille tables, temps requêtes, erreurs).

Si vous devez optimiser des DELETE/UPDATE de masse, des bons index changent tout (voir : Index MySQL : optimiser WHERE, JOIN et ORDER BY avec EXPLAIN).

Industrialiser la conformité : preuves, monitoring, CI/CD et audits récurrents

Un audit RGPD PrestaShop n’est pas un livrable « one shot » : c’est un contrôle continu parce que les modules, tags et intégrations bougent en permanence. La bonne pratique, c’est de versionner vos éléments de conformité comme du code : configuration CMP exportée, liste de sous-traitants, mapping de données, et procédures d’incident. L’objectif est simple : réduire le MTTR (temps de remédiation) et augmenter la traçabilité.

Concrètement, vous pouvez mettre en place un cycle léger mais efficace :

À chaque release : vérification “cookies avant consentement” + contrôle des scripts ajoutés + revue des permissions Admin.
Mensuel : export inventaire modules + scan des endpoints exposés (Admin/API) + revue des comptes Admin.
Trimestriel : test DSAR complet + exercice incident (table-top) + revue des sous-traitants (nouvelles intégrations).
Annuel : audit plus large (sécurité + conformité) et mise à jour de la documentation.

Pour la partie code, couplez revue de sécurité et qualité : analyse statique (niveau PHP), règles de non-journalisation de PII, et audit des dépendances. Si vous maintenez des modules custom, industrialisez la dette technique (typage, refactor, tests) afin d’éviter les « quick fixes » qui réintroduisent des fuites (ex. logs verbeux, dumps). Sur ce sujet, les approches outillées sont détaillées ici : PHPStan et Rector : industrialiser la qualité du code PHP et, côté profiling/perf applicative Symfony, Scout Monitoring Symfony : détection N+1 Doctrine et memory bloat.

Enfin, alignez conformité et sécurité avec un référentiel externe vérifiable. OWASP fournit des contrôles utiles (auth, session, logging, data protection) pour cadrer vos exigences techniques : OWASP ASVS. Sur un cycle de 30–60 jours réaliste : (1) geler et inventorier modules/tags, (2) corriger cookies + sécurité back-office (WAF, accès), (3) implémenter purge/anonymisation + procédures DSAR, (4) formaliser preuves et récurrence (audit trimestriel). Pour élargir le volet durcissement global PrestaShop, recoupez avec : Sécurité PrestaShop 2026 : risques majeurs et protections professionnelles.