Formation PrestaShop

RGPD PrestaShop : Mettre en conformité votre boutique

Sur les 150 boutiques PrestaShop qu’on a auditées chez CYBERIAL ces trois dernières années, 78 % avaient au moins un écart majeur sur le RGPD. Et pas des détails, des écarts qui aujourd’hui, avec les sanctions 2025, exposent réellement le marchand.

Si vous cherchez notre simulateur d’audit RGPD gratuit –> Cliquez ici

Le plus embêtant c’est que la plupart du temps le marchand ne le sait pas. Il a installé un bandeau cookies, il pense que c’est réglé, il dort tranquille ! Le problème c’est que ce n’est pas réglé.

Et le paradoxe c’est que ces mêmes boutiques font pourtant un boulot soigné sur leur catalogue, leurs photos, leur SEO. Mais sur le RGPD, on dirait qu’elles ont coché une case quelque part en 2018 et qu’elles n’y sont jamais revenues.

Je vais essayer de changer ça avec ce guide.

Ce que vous allez trouver ici :

D’abord une partie éducation qui explique pourquoi tout ça existe et pourquoi c’est dans votre intérêt, pas juste une contrainte administrative de plus.
Ensuite un audit concret à faire vous-même, en 5 chapitres et 88 points de contrôle, directement inspiré de la méthode utilisée par les cabinets DPO professionnels, que j’ai adaptée point par point à PrestaShop.
Et pour finir un simulateur interactif qui vous permet de scorer votre RGPD et repartir avec 10 priorités.

Le guide fait 20 000 mots environ. Ça se lit en une heure, ça s’applique sur un trimestre, et ça change le niveau de risque de votre activité.

Partie 1 : Comprendre le RGPD avant de l’appliquer

Avant de plonger dans les 88 points techniques, il faut qu’on soit d’accord sur ce qu’on fait, et surtout pourquoi. Parce que sans ça, l’audit devient de la checklist à remplir bêtement, et on perd la logique.

Si vous avez déjà cette culture, vous pouvez sauter directement à la partie 2 : Audit RGPD de votre boutique PrestaShop. Mais je vous recommande quand même la section « Pourquoi c’est dans votre intérêt » plus bas, c’est l’angle que la plupart des marchands oublie de creuser.

Ce que protège le RGPD en France et dans le monde

Avant de parler de cases à cocher et de bandeaux cookies, il faut qu’on se mette d’accord sur une chose. Qu’est-ce qu’on protège, exactement, quand on parle de données personnelles ?

Prenons un exemple simple. Un de vos clients, appelons-le Thomas, commande une paire de chaussures sur votre boutique en mars. Il laisse son nom, son email, son adresse, son numéro de téléphone, ses informations de paiement (qui transitent chez Stripe ou PayPal, donc vous ne les stockez pas vraiment). Votre serveur enregistre aussi son adresse IP, son user agent et les pages qu’il a visitées avant de commander. Classique !

Maintenant imaginez que demain, pour une raison X ou Y, une faille dans un module non mis à jour, un mot de passe admin faible, un collaborateur qui a quitté la boîte sans qu’on révoque ses accès, ou simplement une base exportée à un partenaire qui n’avait pas signé de DPA, ces données quittent votre boutique.

Regardez ce qu’il se passe ensuite. Ce n’est pas une hypothèse, c’est le fonctionnement d’internet.

Jour 1 à 30. La base est récupérée par des agrégateurs qu’on appelle des courtiers en données. Des sociétés comme Acxiom, Oracle Data Cloud, LiveRamp. Leur métier c’est de prendre des bases de différentes sources et de les croiser pour enrichir chaque profil. À partir de l’email de Thomas, en croisant avec d’autres bases qu’ils ont déjà, ils vont déduire son âge approximatif, son pouvoir d’achat, sa zone géographique fine, ses centres d’intérêt, parfois ses déplacements (via les données Bluetooth et Wi-Fi des applis mobiles qui reçoivent de la pub), sa composition familiale, son niveau d’études probable. Et ce qui n’était qu’un email devient un profil !

Jour 30 à 90. Ce profil enrichi est revendu à des plateformes publicitaires ou à des annonceurs directement. Thomas devient une cible dans des « audiences personnalisées » sur Meta, Google, TikTok, Criteo. Quand vous voyez une pub ciblée qui semble vous connaître bien, c’est à ça que vous avez affaire.

Au-delà de 90 jours. Ces profils servent à d’autres choses que la pub commerciale classique. Ils servent à du ciblage politique en période électorale. Cambridge Analytica a démontré ce que ça produit, avec 87 millions de profils Facebook aspirés en 2014. Ils servent à du phishing sur-mesure, les emails de phishing « votre colis est en attente de livraison » qui connaissent votre nom, votre ville et même parfois le transporteur que vous utilisez, viennent de là. Ils servent à de la tarification discriminante, oui, les prix affichés en ligne peuvent varier selon votre profil. Ils servent, potentiellement, à des logiques d’assurance ou de crédit qui n’ont pas lieu d’avoir votre profil marchand comme variable.

Ce qu’il faut comprendre, c’est ça. Les données que votre boutique collecte ne valent pas grand-chose prises isolément. Elles prennent toute leur valeur quand elles sont agrégées, croisées, revendues, et c’est exactement là qu’elles vous échappent. Votre client vous a fait confiance pour lui vendre des chaussures. Pas pour nourrir une chaîne industrielle de ciblage commercial et politique qu’il ne contrôle absolument pas.

Le RGPD, au fond, c’est la barrière qui empêche ce voyage de s’enclencher sans que la personne ait explicitement dit oui. Et quand on dit « explicitement », on veut vraiment dire explicitement, pas une case pré-cochée, pas un bandeau avec juste un bouton « OK », pas « en continuant votre navigation vous acceptez »…

C’est cette logique qu’il faut avoir en tête avant d’attaquer le reste du guide. Tout ce qui va suivre, les 88 points, les formulations à copier, les paramétrages techniques, c’est de l’opérationnel. Mais derrière chaque point il y a ça : le choix politique de dire que la personne est propriétaire de ses données, et que vous en êtes le dépositaire pour une finalité précise.

Pourquoi l’Europe a choisi un cadre strict

Quelques repères historiques parce que c’est utile :

6 janvier 1978. La France est le premier pays au monde à se doter d’une loi sur les données personnelles. La loi Informatique et Libertés, qui crée la CNIL dans la foulée. Ça fait réfléchir quand on réalise que c’est la même année que la création de Apple, on est loin de l’informatique personnelle généralisée, mais en France on avait déjà senti le coup venir. Pourquoi ? Parce qu’en 1974 le gouvernement avait essayé de mettre en place le projet SAFARI (Système automatisé pour les fichiers administratifs et le répertoire des individus), un fichier centralisé qui aurait interconnecté toutes les administrations françaises via le numéro de sécurité sociale. Levée de boucliers immédiate dans la presse et l’opinion. Le projet est abandonné. La loi Informatique et Libertés est le résultat direct de cette alerte.
24 octobre 1995. La directive européenne 95/46/CE harmonise l’approche à l’échelle de l’Union. C’est le grand-père du RGPD.
25 mai 2018. Le RGPD entre en application. Règlement 2016/679 pour les curieux. Passage d’une logique de « directive à transposer » à une logique de « règlement directement applicable », c’est ce qui explique que tout le monde ait parlé de la même chose partout en Europe en même temps.

Bon. Pourquoi cette chronologie est utile ?

Parce qu’elle raconte une cohérence européenne sur un sujet où les États-Unis ont fait le choix inverse. Aux US, depuis le début, le principe est l’opt-out : vous pouvez collecter et utiliser les données d’une personne jusqu’à ce qu’elle vous dise explicitement non. En Europe, c’est l’opt-in : vous ne pouvez rien faire tant que la personne n’a pas explicitement dit oui (avec quelques exceptions encadrées : exécution d’un contrat, obligation légale, intérêt légitime documenté).

Derrière cette différence binaire il y a deux visions du monde. Aux US, la donnée appartient à celui qui la collecte. En Europe, la donnée appartient à la personne concernée. L’entreprise n’en est que dépositaire, pour une finalité précise, pour une durée précise, avec des obligations précises, et rien d’autre ! C’est à cette logique qu’il faut revenir chaque fois qu’un problème RGPD vous semble tordu.

La question à vous poser n’est pas « est-ce que j’ai le droit ». C’est « est-ce que j’ai vraiment besoin de cette donnée pour ce que je fais ». Si la réponse est non, ne la collectez pas. Si la réponse est oui, encadrez-la, documentez-la, limitez sa durée.

Mon conseil : quand vous êtes face à une décision de collecte (ajouter un champ dans un formulaire, ajouter un tracker, ajouter un outil dans votre stack), passez la question par ce filtre avant de passer par le filtre juridique. C’est plus rapide et c’est souvent ça qui résout le problème.

Les 6 principes du RGPD en langage PrestaShop

L’article 5 du RGPD pose six principes. Vous les retrouverez partout dans le guide, donc autant les avoir en tête avec leur traduction concrète côté boutique.

Licéité, loyauté, transparence. Pour chaque traitement, une base légale identifiable. Pour la commande, c’est l’exécution d’un contrat (article 6.1.b). Pour la newsletter, c’est le consentement (article 6.1.a). Pour la conservation des factures pendant 10 ans, c’est l’obligation légale (article 6.1.c, Code de commerce). Pour un scoring client anti-fraude, c’est l’intérêt légitime (article 6.1.f). Si vous ne pouvez pas nommer la base légale d’un traitement que vous faites, c’est un problème.
Limitation des finalités. L’email collecté pour confirmer une commande ne peut pas être utilisé pour une campagne marketing sans consentement distinct. C’est le piège classique sur PS : la case « J’accepte les CGV » au checkout ne couvre pas la newsletter. Il faut deux cases séparées, avec deux finalités distinctes.
Minimisation. Ne collectez pas ce dont vous n’avez pas besoin. Si votre formulaire de création de compte demande la date de naissance alors que vous vendez des chaussures, justifiez-la ou retirez-la. Ce qu’on voit chez nos clients : des formulaires qui demandent civilité obligatoire, téléphone obligatoire, « comment nous avez-vous connu » obligatoire. La plupart du temps, aucun de ces champs n’a de justification opérationnelle.
Exactitude. Le client doit pouvoir corriger ses données. C’est un des droits que PrestaShop gère correctement en natif via la rubrique « Mes informations » de l’espace client. On en reparle au point suivant.
Limitation de la conservation. Vous ne gardez pas les données indéfiniment. Les durées varient selon le type de donnée. Les factures 10 ans (obligation comptable). La relation client active 3 ans après la dernière commande. Un compte resté inactif 2 ans doit être archivé puis supprimé. Une base de prospects non-clients, 3 ans après le dernier contact actif. On fait le détail dans le chapitre 2 de l’audit.
Intégrité et confidentialité. HTTPS partout, back-office protégé, mots de passe hashés, sauvegardes testées. Le chapitre 5 entier y est consacré (33 points).

Il y a aussi un septième principe, parfois appelé accountability ou responsabilité : vous devez pouvoir prouver que vous êtes conforme. C’est un principe qui structure tout le reste. Horodatage des consentements, registre des traitements, DPA signés avec vos sous-traitants, logs exportables. C’est là que le module natif ps_gdpr atteint ses limites, il documente certaines actions mais il n’est pas conçu comme une preuve exhaustive.

Les 8 droits du client et ce que ça veut dire dans PrestaShop

Le RGPD donne 8 droits aux personnes. Vous devez être capable d’y répondre dans un délai d’un mois (prorogeable à deux mois si la demande est complexe). Regardons concrètement ce que chaque droit veut dire côté back-office PrestaShop.

Droit d’accès (article 15). Le client vous écrit pour demander une copie de toutes les données que vous détenez à son sujet. PS natif : le module ps_gdpr export un PDF ou un CSV récapitulatif depuis l’espace client. Couvre le besoin.
Droit de rectification (article 16). Le client veut corriger une donnée erronée, une adresse, un nom mal orthographié. PS natif : la rubrique « Mes informations » permet au client de le faire lui-même. Couvert.
Droit à l’effacement (article 17), aussi appelé droit à l’oubli. Le client demande la suppression de ses données. PS natif : demande initiée via ps_gdpr, validation côté marchand, suppression des données hors facturation. Attention, les factures comptables ne sont pas supprimées, vous avez une obligation de conservation de 10 ans au Code de commerce qui prime sur le droit à l’effacement. Mais vous devez pouvoir expliquer ce qui reste et pourquoi.
Droit à la limitation du traitement (article 18). Moins connu. Le client demande que vous gardiez la donnée mais que vous arrêtiez de l’utiliser activement. Typiquement pendant qu’une contestation est en cours. PS natif ne le gère pas spécifiquement. À traiter manuellement.
Droit d’opposition (article 21). Le client refuse un traitement, typiquement du marketing. Sur PS, la désinscription newsletter est le cas classique, et c’est un point où ps_emailsubscription fait un travail moyen : l’opposition fonctionne, mais elle n’est pas proprement horodatée et la preuve peut manquer.
Droit à la portabilité (article 20). Le client récupère ses données dans un format réutilisable (CSV, JSON) pour les transférer ailleurs. PS natif : export CSV via ps_gdpr. Couvert.
Droit de retrait du consentement (article 7.3). À tout moment, aussi simplement qu’il l’a donné. En pratique ça veut dire : un bouton « Se désinscrire » en un clic dans chaque email, un lien « Gérer mes cookies » en pied de page. PS le gère partiellement, chaque consentement a son mécanisme, mais il n’y a pas de centre unifié. Une CMP externe comble ce manque.
Droit de ne pas faire l’objet d’une décision automatisée (article 22). C’est le droit le plus récent en pratique. Il concerne tout ce qui est scoring client, recommandation personnalisée avancée, chatbot qui prend des décisions (par exemple un chatbot qui refuserait automatiquement un remboursement). Depuis la position CNIL de février 2021 : un chatbot seul ne peut pas prendre une décision significative concernant un client, il faut toujours un humain dans la boucle pour les décisions qui ont des conséquences réelles. PS ne gère pas ce droit en natif, ça dépend de votre organisation et des outils que vous ajoutez.

Le module ps_gdpr que PrestaShop gratuit maintenant, couvre correctement 4 de ces droits sur 8. C’est bien, mais c’est pas suffisant. Un visuel pour résumer :

Les trois droits non couverts ou partiellement couverts sont ceux qui demandent de l’organisation, une politique claire sur le chatbot, un centre unifié de retrait des consentements, une procédure pour les demandes de limitation. On en reparle dans le chapitre 2.

Pourquoi c’est dans votre intérêt (pas juste une contrainte)

Là je vais enfoncer une porte non ouvert parce que personne n’en parle.

La conformité RGPD n’est pas une fatalité administrative qu’il faut subir. C’est un levier qui améliore concrètement votre activité sur plusieurs plans. Je le dis après 150 audits, ce n’est pas une posture, c’est une observation.

Argument commercial direct. Les acheteurs soucieux de leur vie privée sont de plus en plus nombreux. La génération Z particulièrement. Ils vérifient vos mentions avant d’acheter. Une politique de confidentialité claire, lisible, récente, est un facteur de confiance comme l’est un cadenas HTTPS ou un logo Avis vérifiés. Et en B2B c’est encore plus marqué, les services achats et les DSI auditent leurs fournisseurs sur ce point dans les appels d’offres sérieux. J’ai vu plusieurs marchands perdre un appel d’offres B2B pour des mentions manquantes.
Hygiène technique. La démarche RGPD vous oblige à cartographier vos données, vos sous-traitants, vos flux. Ce nettoyage met à jour des outils que vous payez par inertie, des bases de prospects obsolètes qui polluent votre délivrabilité, des scripts tiers qui ralentissent votre boutique. Un de nos clients a récupéré 900 ms de TTFB en retirant trois trackers obsolètes lors d’un audit RGPD. 900 millisecondes, ça se voit dans les Core Web Vitals, ça se voit dans le taux de rebond et ça se voit dans les conversions.
Filtre sur vos outils. Un outil qui ne vous propose pas de DPA (Data Processing Agreement), qui ne documente pas ses sous-traitants, qui n’a pas de politique de suppression lisible : ce n’est pas juste un problème RGPD. C’est un signal qu’il gère mal vos données en général. Les outils sérieux ont une page de confidentialité accessible publiquement. Les autres, méfiance, si leur doc RGPD est bâclée, le reste l’est probablement aussi.
Marketing qui fonctionne mieux. Une base de personnes qui ont vraiment opt-in et confirmé en double opt-in ouvre vos emails trois à quatre fois plus qu’une base acquise au forceps ou achetée. Les taux de réclamation spam chutent. La délivrabilité Gmail et Outlook remonte. Vos campagnes coûtent moins cher par conversion. La conformité RGPD sur la newsletter c’est littéralement du ROI.
Protection contre les risques réels. Les amendes CNIL font les titres : Shein 150 millions d’euros, Google 325 millions le même jour, le 1er septembre 2025. Mais pour un marchand PrestaShop moyen, les vrais coûts d’une non-conformité sont ailleurs. Fuite de données qui détruit la confiance clientèle, panier moyen en baisse pendant 6 à 18 mois. Procès CIPA en Californie si vous vendez aux US avec indemnités entre 10 000 et 200 000 dollars, et ça se règle souvent à l’amiable pour éviter la procédure. Mise en demeure CNIL qui bloque deux mois d’activité marketing (publicité, newsletter, etc.) le temps de se mettre en règle.

Ah si, autre chose. La conformité RGPD n’est pas un état permanent. Vos outils changent, vos sous-traitants évoluent, la réglementation s’adapte. Ce qui était conforme en 2022 peut ne plus l’être en 2026. Donc une fois que vous êtes au niveau, il faut tenir !

Pourquoi les boutiques PrestaShop sont plus en retard que les WordPress ?

Je pose ça ici parce que c’est un constat honnête avec les 150+ clients que nous accompagnons dans cette agence PrestaShop et plus de 300 autres entreprises avec notre agence WordPress HARSENE. Les boutiques PS sont statistiquement moins en règle sur le RGPD que les sites WordPress de taille équivalente. Voyons pourquoi.

Écosystème CMP. WordPress a un écosystème mature de plugins de consentement. Complianz, CookieYes, RGPD Cookie Consent, Axeptio, tous bien intégrés, bien documentés, bien mis à jour. Sur PrestaShop, le catalogue Addons est plus éclaté. Beaucoup de modules historiques datent d’avant les lignes directrices CNIL 2020 et n’ont jamais été correctement refondus. Les modules de qualité existent (Advanced Cookie Banner, idnovate Loi Cookies) mais il faut les chercher et les paramétrer. Au passage, tous ces modules de CMP ont des performances éclatées au sol et pénalisent les Web Core Vitals de votre PrestaShop.
Module natif trompeur. PrestaShop poussait son ancien module « Official GDPR compliance » dans le catalogue officiel. Le nom laisse penser qu’il couvre tout le sujet. En réalité il couvre quatre droits (accès, rectification, effacement, portabilité), plutôt bien, et c’est tout. Il ne gère pas le consentement cookies, ne bloque pas les cookies avant consentement, ne fait pas la catégorisation des trackers, ne connaît pas Consent Mode v2, ne scanne pas vos modules tiers. Beaucoup de marchands l’achètent, voient le nom officiel, et pensent que c’est réglé. Ça ne l’est pas.
Thèmes moins alignés. Les thèmes WordPress modernes intègrent souvent un bandeau cookies par défaut, ou s’intègrent nativement avec les plugins CMP populaires. Sur PrestaShop, un thème ne prévoit en général rien, le marchand doit bricoler l’intégration du module CMP dans le thème, et c’est à ce moment-là que les bugs apparaissent (bandeau qui n’apparaît pas sur certaines pages, scripts qui se chargent quand même, etc.).
Communauté moins prolixe sur le sujet. Cherchez « RGPD WordPress » sur Google : des centaines d’articles grand public, récents, bien maintenus. Cherchez « RGPD PrestaShop » : une poignée d’articles, souvent mal mis à jour, qui se recopient entre eux. C’est un des trous de contenu que cet article vient combler, il n’y avait tout simplement pas de guide francophone complet sur le sujet jusqu’à ce que nous publions cet article.
Agences plus rares à en faire un argument. Peu d’agences PrestaShop ont positionné la conformité RGPD comme un argument dans leur offre. La plupart des agences interviennent en correction sur demande, pas en préventif.

Conclusion. Ce n’est pas la faute du marchand s’il est en retard. C’est un écosystème qui n’a pas produit les bons outils pédagogiques au bon moment, couplé à un module officiel trompeur et à une communauté moins bavarde sur le sujet. L’article que vous lisez essaie de rattraper ce retard.

Ce qui change en 2026

Cinq évolutions récentes à avoir en tête avant d’attaquer l’audit. Ce n’est pas pour faire peur, c’est pour que vous sachiez dans quel contexte vous êtes.

Sanctions CNIL record en 2025. Un total de 487 millions d’euros d’amendes prononcées en 2025. La sanction Shein porte sur des cookies publicitaires déposés avant interaction avec le bandeau, 12 millions de visiteurs par mois en France. Le message est clair : même les géants non européens sont dans le viseur de la CNIL, donc les TPE/PME françaises le sont à plus forte raison. Personne n’est trop petit pour être contrôlé.
Consent Mode v2 obligatoire pour les annonceurs Google Ads. Depuis le 6 mars 2024. Sans Consent Mode v2 correctement implémenté sur votre boutique, la conversion Google Ads n’est plus correctement enregistrée et la diffusion de vos campagnes se limite. On voit régulièrement des boutiques qui ont un écart de 60 % entre le chiffre d’affaires remonté dans Analytics et le chiffre d’affaires réel dans le back-office. 10 à 15 % d’écart c’est normal et ça se rattrape avec des ajustements de tracking. 60 %, c’est un bug critique qui coûte directement en budget Ads.
Chatbots IA et GenAI dans le viseur. Position CNIL publiée le 22 juillet 2025 : 13 fiches pratiques sur l’IA et le RGPD. Cas documenté de mise en demeure en septembre 2024 d’un e-commerce français qui avait intégré l’API ChatGPT dans son chatbot sans le mentionner dans sa politique de confidentialité. Mise en conformité sous deux mois imposée. Et plus largement, le trafic chatbot IA sur les sites français a augmenté de 340 % en 2024, c’est un angle mort de plus en plus scruté.
Shopping agents IA qui arrivent en 2026. OpenAI Agent, Perplexity Comet, Google AI Mode avec « buy buttons », ChatGPT avec sa fonction « Buy it ». Morgan Stanley projette que 50 % des acheteurs utiliseront un agent IA pour leurs achats en ligne d’ici 2030. L’EU AI Act entre en application en août 2026, avec des amendes pouvant atteindre 7 % du chiffre d’affaires global.
CCPA/CPRA 2026 pour les marchands qui vendent aux US. Depuis le 1er janvier 2026, les lois américaines en vigueur dans l’Indiana, le Kentucky, le Rhode Island (en plus de la Californie historique) imposent un opt-out signal GPC (Global Privacy Control) obligatoire. Les class actions au titre du CIPA (California Invasion of Privacy Act) par des cabinets comme Swigart Law Group ciblent les boutiques qui utilisent Meta Pixel ou session replay sans consentement valide. Indemnités entre 10 000 et 200 000 dollars par cas. Si vous vendez aux US, c’est à intégrer dès maintenant.

Bon. Le contexte est posé. Le pourquoi est clair. Maintenant passons au comment.

Pour structurer l’audit je me suis appuyé sur la méthode utilisée par les cabinets DPO professionnels, structurés autour de 88 points de contrôle répartis en 5 chapitres. J’ai repris cette grille point par point et je l’ai adaptée à la réalité PrestaShop. Voici ce que ça donne.

Partie 2, L’audit en 5 chapitres, point par point

On entre dans le concret. 88 points de contrôle, structurés en 5 chapitres (plus un chapitre bonus IA qu’on a rajouté pour 2026). La méthode reprend la notation classique des audits DPO : pour chaque point, vous répondez Oui (3 points), Partiel (1 point), Non (0 point) ou Non applicable.

Avant d’attaquer, deux choses :

Le simulateur. Si vous voulez scorer votre boutique et repartir avec vos 10 priorités en fin de parcours, vous avez un simulateur en ligne qui reprend exactement la même grille. Vous pouvez le faire en parallèle de la lecture, ou après. C’est gratuit et vos réponses sont sauvegardées dans votre navigateur si vous voulez y revenir plus tard.
Les 88 points de contrôle. Pour chaque point, vous aurez : l’énoncé, ce que ça veut dire concrètement dans votre back-office PrestaShop, un exemple à copier-coller quand c’est pertinent (texte juridique, mention, paramétrage), et la référence jurisprudentielle ou CNIL quand elle existe. Les exemples copier-coller sont à adapter à votre boutique (remplacer le nom, l’adresse, les données spécifiques).

Allons-y.

Chapitre 1, Cookies et traceurs (21 points)

C’est le chapitre le plus volumineux et c’est le plus scruté par la CNIL en 2025. La quasi-totalité des sanctions cookies récentes portent sur des points de ce chapitre. Si vous ne deviez faire qu’un seul chapitre de l’audit, c’est celui-ci.

Il se divise en trois sous-sections : le bandeau d’information (ce que vos visiteurs voient), le paramétrage du bandeau (comment il se comporte techniquement), la politique des cookies (le document qui documente le tout).

Sous-section A, Bandeau d’information (7 points)

Point 1.1, Existence d’un bandeau d’information

Énoncé : un bandeau apparaît dès la première visite pour informer l’utilisateur que des cookies sont déposés et utilisés, avant même qu’il ait interagi avec le site.

Dans votre back-office PrestaShop : par défaut, PS ne met pas de bandeau. Si vous n’avez rien installé, vous n’en avez pas. Allez dans Modules → Modules installés, filtrez par catégorie « Juridique » ou cherchez des mots-clés comme « cookie », « consent », « RGPD ». Si rien n’apparaît, c’est que votre boutique est en non-conformité sur ce point fondamental.

Référence : article 82 de la loi Informatique et Libertés, lignes directrices CNIL 2020-091 du 17 septembre 2020, contraignantes depuis le 1er avril 2021.

Point 1.2, Mention des finalités des différents types de cookies

Énoncé : le bandeau décrit les catégories de cookies utilisées avec une phrase d’explication par catégorie : techniques, préférences, mesure d’audience, partage réseaux sociaux, publicitaires, non classés.

Dans votre back-office PrestaShop : sur votre bandeau actuel, vérifiez la mention de chaque catégorie. Beaucoup de bandeaux se contentent de « ce site utilise des cookies » sans détailler. Ce n’est pas conforme. Voici une mention type complète à adapter :

À copier-coller · Mention des finalités (bandeau)

Notre site [NOM DE VOTRE BOUTIQUE] et nos partenaires utilisent des cookies ou technologies similaires afin d’assurer son bon fonctionnement (cookies techniques), de mémoriser vos préférences (cookies de préférence), de mesurer l’audience (cookies statistiques), de vous proposer des contenus de réseaux sociaux (cookies de partage) et de vous présenter des publicités personnalisées (cookies publicitaires). Le dépôt de certains cookies nécessite votre consentement préalable.

Référence : recommandation CNIL octobre 2020.

Point 1.3, Durée de conservation du choix affichée sur le bandeau

Énoncé : le bandeau indique combien de temps votre choix (consentement ou refus) sera mémorisé. La CNIL recommande 6 ou 12 mois comme bonne pratique.

Dans votre back-office PrestaShop : sur votre bandeau, vérifiez qu’il y a une phrase explicite indiquant la durée. Si votre module ne l’affiche pas par défaut, configurez-le dans les paramètres ou ajoutez la phrase dans les textes libres.

À copier-coller · Durée du choix

Nous conservons votre choix pendant 6 mois. Vous pouvez changer d’avis à tout moment en cliquant sur « Gérer mes cookies » en bas de chaque page de notre site.

Référence : CNIL recommande explicitement 6 mois comme bonne pratique dans ses lignes directrices 2020.

Point 1.4, Boutons « Accepter » et « Refuser » de même niveau

Énoncé : les deux boutons sont strictement symétriques en taille, couleur, emplacement et visibilité. Aucun des deux ne doit être plus saillant que l’autre.

Dans votre back-office PrestaShop : c’est le point où 70 % des boutiques PS auditées échouent. Le bandeau a souvent un « Accepter » très visible (gros bouton coloré) et un « Refuser » caché ou dégradé (« continuer sans accepter » en tout petit texte gris).

La règle : deux boutons strictement identiques. Même taille, même couleur de fond ou même traitement visuel, même position, même hiérarchie. Le visiteur ne doit pas être visuellement orienté vers une réponse plutôt que l’autre.

Référence : décision CNIL Shein, 1er septembre 2025, 150 M€, cookies publicitaires déposés avant interaction avec le bandeau et dissymétrie des boutons font partie des griefs retenus.

Point 1.5, Possibilité de personnalisation du choix

Énoncé : un bouton « Paramétrer » ou « Personnaliser » donne accès au détail par catégorie. L’utilisateur doit pouvoir accepter ou refuser chaque catégorie indépendamment.

Dans votre back-office PrestaShop : troisième bouton visible sur le bandeau (après « Tout accepter » et « Tout refuser »), ou lien clair vers un panneau de réglages.

À copier-coller · Libellés de boutons

[Tout accepter] [Tout refuser] [Personnaliser mes choix]

Évitez « Continuer sans accepter » qui est moins clair, préférez « Tout refuser » qui est le pendant exact de « Tout accepter ».

Point 1.6, Lien hypertexte vers la politique des cookies

Énoncé : sur le bandeau, un lien « En savoir plus » ou « Politique des cookies » renvoie vers une page CMS dédiée.

Dans votre back-office PrestaShop : créez une page CMS dédiée aux cookies dans Apparence → Pages. Cette page peut être distincte de votre politique de confidentialité générale, ou fusionnée avec elle selon votre préférence. Le lien depuis le bandeau doit y renvoyer.

Point 1.7, Identification du responsable de traitement

Énoncé : sur le bandeau ou la politique qu’il renvoie, l’entité juridique responsable doit être identifiable.

Dans votre back-office PrestaShop : le marchand (votre société) est le responsable de traitement. L’hébergeur est sous-traitant. Ne confondez pas. Dans la politique de cookies, le bloc d’identification doit mentionner votre société explicitement.

À copier-coller · Identification du responsable

Le site [URL DE VOTRE BOUTIQUE] est édité par : [DÉNOMINATION SOCIALE], [FORME JURIDIQUE] au capital de [MONTANT] € Siège social : [ADRESSE COMPLÈTE] SIRET : [NUMÉRO SIRET], RCS : [VILLE + NUMÉRO] Responsable de traitement : [NOM DU DIRIGEANT] Contact RGPD : [EMAIL, ex : rgpd@votre-boutique.fr]

Sous-section B, Paramétrage du bandeau (6 points)

Point 1.8, Fermeture du bandeau sans dépôt

Énoncé : si l’utilisateur ferme le bandeau (croix, clic à l’extérieur, échap) sans faire de choix explicite, aucun cookie non essentiel n’est déposé.

Dans votre back-office PrestaShop : test à faire en navigation privée avec DevTools ouvert. Chargez votre boutique, ouvrez DevTools → Application → Cookies (sur Chrome) ou Stockage (sur Firefox). Observez les cookies présents. Fermez le bandeau sans cliquer sur Accepter ou Refuser. Les cookies non essentiels ne doivent pas apparaître.

Référence : Conseil d’État, 19 juin 2020, la simple poursuite de la navigation ne peut pas être interprétée comme un consentement.

Point 1.9, Durée de conservation du choix effective

Énoncé : le bandeau ne réapparaît pas avant l’expiration de la durée annoncée (6 ou 12 mois si vous avez suivi le point 1.3).

Dans votre back-office PrestaShop : test à faire en vrai avec patience, ou en manipulant la date du cookie dans DevTools. Sur une boutique bien configurée, un utilisateur qui a fait son choix ne revoit pas le bandeau pendant 6 mois. Si votre bandeau réapparaît à chaque session ou après quelques jours, c’est un bug à corriger.

Point 1.10, Retrait du consentement accessible en permanence

Énoncé : un moyen de revenir sur son choix est visible en permanence sur toutes les pages du site.

Dans votre back-office PrestaShop : un lien « Gérer mes cookies » dans le footer, ou une icône persistante en bas à gauche qui rouvre le panneau de préférences. Le retrait doit être aussi simple que le consentement, pas enterré dans la politique de confidentialité.

À copier-coller · Lien footer

Gérer mes cookies · Politique de confidentialité · Mentions légales · CGV

Référence : RGPD article 7.3, « il doit être aussi simple de retirer que de donner son consentement».

Point 1.11, Informations spécifiques sur les cookies accessibles

Énoncé : la liste complète des cookies avec leurs finalités, durées et tiers est accessible en un clic depuis le bandeau (généralement via le bouton « Personnaliser »).

Dans votre back-office PrestaShop : dans le panneau de personnalisation, chaque catégorie doit être dépliable pour afficher le détail des cookies qu’elle contient. Les bonnes CMP (Axeptio, Sirdata, Cookiebot) le font nativement.

Point 1.12, Système de gestion du consentement installé

Énoncé : une CMP (Consent Management Platform) est installée et active sur la boutique.

Dans votre back-office PrestaShop : c’est le cœur de votre dispositif cookies. Voici les options les plus courantes sur PrestaShop, avec mes recommandations terrain :

Mon conseil : pour une boutique sous 500 k€ de CA, Axeptio ou Cookiebot sont le meilleur rapport qualité/prix, avec une intégration propre sur PrestaShop. Pour une boutique mid-market (500 k€ à 5 M€), Sirdata, OneTrust ou Didomi sont plus robustes sur les fonctions avancées (multi-domaines, TCF v2.2, reporting). Tarteaucitron est gratuit et fonctionnel mais demande de la configuration technique manuelle et les performances Web Core Vitals prennent un coup !

Point 1.12 bis, Enregistrement horodaté du choix

Énoncé : le consentement est tracé techniquement avec horodatage, identifiant de session, version du bandeau. La preuve doit être exportable en cas de contrôle.

Dans votre back-office PrestaShop : demandez à votre CMP d’exporter un log récent et vérifiez qu’il contient au minimum la date et heure, un identifiant utilisateur (hashé ou pseudonymisé), et la version du bandeau acceptée. C’est généralement disponible dans la console de votre outil de CMP.

Référence : RGPD article 7.1, charge de la preuve du consentement sur le responsable de traitement.

Point 1.13, Aucun cookie non essentiel avant consentement

Énoncé : c’est LE point critique de tout le chapitre. Avant que le visiteur ait cliqué sur « Accepter », aucun cookie non essentiel n’est déposé.

Dans votre back-office PrestaShop : le test se fait en 30 secondes. Ouvrez votre boutique en mode navigation privée. Ouvrez DevTools (F12) → onglet Application (Chrome) ou Stockage (Firefox) → Cookies → sélectionnez votre domaine. Vous voyez la liste des cookies déposés avant que vous ayez interagi avec le bandeau.

Les seuls cookies autorisés à ce stade sont les cookies strictement nécessaires : session PHP (PHPSESSID), panier PrestaShop, langue, devise, jeton CSRF. Si vous voyez à ce stade des cookies commençant par _ga, _ga_*, _fbp, _clck, _clsk, MUID, _hjSessionUser, ou des cookies de Criteo, Taboola, Outbrain : non conforme.

Mon conseil : faites ce test avant même de commencer l’audit complet. Si vous échouez sur ce point, vous savez déjà que votre priorité absolue est de reconfigurer votre CMP pour bloquer les trackers avant consentement. C’est le point le plus sanctionné par la CNIL.

Référence : décision CNIL Shein, 1er septembre 2025, 150 M€, cookies publicitaires déposés avant interaction avec le bandeau est le grief principal retenu.

Sous-section C, Politique des cookies (8 points)

Point 1.14, Définition des cookies et explications

Énoncé : la politique des cookies commence par une définition accessible, sans jargon juridique.

Dans votre back-office PrestaShop : page CMS dédiée, introduction pour un lecteur non technique.

À copier-coller · Introduction politique cookies

Un cookie est un petit fichier texte que notre site dépose sur votre terminal (ordinateur, tablette, smartphone) lorsque vous le visitez. Ces fichiers nous permettent, selon leur type, de vous reconnaître d’une visite à l’autre, de mémoriser vos préférences, de mesurer l’audience de nos pages, ou de vous proposer des contenus adaptés. Certains de ces cookies sont indispensables au fonctionnement de notre boutique (par exemple pour garder votre panier en mémoire). D’autres nécessitent votre accord préalable avant d’être déposés. Cette page vous explique quels cookies nous utilisons, dans quel but, pour combien de temps, et comment revenir sur votre choix à tout moment.

Point 1.15, Détail des données collectées via cookies

Énoncé : pour chaque cookie listé, les données qu’il collecte sont explicitées (adresse IP, user agent, pages visitées, historique de navigation, identifiant unique, etc.).

Dans votre back-office PrestaShop : à traiter dans le tableau de détail des cookies (voir point 1.16 et 1.17).

Point 1.16, Finalité précise de chaque cookie

Énoncé : pour chaque cookie individuel (pas juste par catégorie), la finalité est indiquée.

Dans votre back-office PrestaShop : tableau détaillé dans la politique des cookies. Généralement fourni par votre CMP via un bout de code embed.

Mon conseil : ne mettez dans ce tableau que les cookies que vous déposez vraiment. Ne copiez pas un modèle générique qui mentionne des cookies que vous n’utilisez pas, ça crée une incohérence et la CNIL le remarque en cas de contrôle. Faites le test DevTools du point 1.13 pour lister ce qui est vraiment déposé sur votre boutique. Vous pouvez aussi utiliser le scanner de votre CMP.

Point 1.17, Durée de conservation de chaque cookie

Énoncé : la durée de vie de chaque cookie est indiquée dans le tableau. Attention, ce n’est pas la durée du choix (6 mois au point 1.3), c’est la durée de vie du cookie lui-même.

Dans votre back-office PrestaShop : les valeurs typiques : session (jusqu’à fermeture du navigateur), 24h, 30 jours, 90 jours, 6 mois, 13 mois (max CNIL pour les cookies analytiques), 1 an, 2 ans.

Point 1.18, Tiers destinataires identifiés

Énoncé : pour chaque cookie tiers, le responsable est identifié (nom juridique, pays) et, s’il s’agit d’un transfert hors UE, le mécanisme de transfert est mentionné.

Dans votre back-office PrestaShop : colonne « Tiers » du tableau + mention des transferts dans la politique. Voici les mentions types pour les grands tiers :

À copier-coller · Tiers et transferts hors UE

Google Analytics et Google Ads sont fournis par Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, États-Unis. Les données peuvent être transférées aux États-Unis dans le cadre du Data Privacy Framework (décision d’adéquation UE du 10 juillet 2023) et de clauses contractuelles types. Meta Pixel est fourni par Meta Platforms Ireland Limited, 4 Grand Canal Square, Dublin 2, Irlande, avec des transferts possibles vers Meta Platforms Inc. aux États-Unis dans le cadre du Data Privacy Framework. Microsoft Clarity est fourni par Microsoft Corporation, One Microsoft Way, Redmond, WA 98052, États-Unis, dans le cadre du Data Privacy Framework.

Point 1.19, Modalités de gestion du consentement expliquées

Énoncé : paragraphe qui explique comment l’utilisateur peut revenir sur son choix et où.

Dans votre back-office PrestaShop : après le tableau des cookies.

À copier-coller · Gestion du consentement

Vous pouvez revenir sur votre choix à tout moment en cliquant sur le lien « Gérer mes cookies » situé en bas de chaque page. Le panneau qui s’ouvre vous permet d’accepter ou de refuser chaque catégorie de cookie indépendamment. Votre nouveau choix remplace le précédent et est conservé pendant 6 mois. Le refus des cookies non essentiels n’empêche pas l’accès à notre boutique ni la passation de commandes, mais certaines fonctionnalités (recommandations personnalisées, mesure d’audience, publicité adaptée à vos intérêts) seront dégradées.

Point 1.20, Paramétrage navigateur expliqué

Énoncé : la politique indique comment bloquer les cookies au niveau du navigateur, avec des liens vers les paramétrages des principaux navigateurs.

Dans votre back-office PrestaShop : paragraphe dédié dans la politique.

À copier-coller · Paramétrage navigateur

Vous pouvez également paramétrer votre navigateur pour bloquer tout ou partie des cookies, indépendamment de notre bandeau : • Google Chrome : Paramètres → Confidentialité et sécurité → Cookies et autres données des sites (support.google.com/chrome/answer/95647) • Mozilla Firefox : Paramètres → Vie privée et sécurité → Cookies et données de sites (support.mozilla.org/fr/kb/proteger-vie-privee-donnees-sites) • Safari : Préférences → Confidentialité → Cookies et données de sites web (support.apple.com/fr-fr/guide/safari/sfri11471) • Microsoft Edge : Paramètres → Cookies et autorisations de site (support.microsoft.com/fr-fr/microsoft-edge)

Point 1.21, Conséquences d’un refus indiquées

Énoncé : la politique explique les conséquences d’un refus sans pour autant rendre le refus artificiellement dissuasif.

Dans votre back-office PrestaShop : phrase factuelle qui décrit ce qui fonctionnera moins bien sans les cookies. Pas de message alarmiste type « votre expérience sera fortement dégradée », juste du factuel.

À copier-coller · Conséquences du refus

Le refus des cookies non essentiels vous permet de naviguer librement sur notre site et de passer commande sans restriction. Les fonctionnalités suivantes seront cependant dégradées : les recommandations produits ne seront plus personnalisées selon votre historique, les publicités affichées sur d’autres sites ne seront plus adaptées à vos centres d’intérêt, et nous ne pourrons plus mesurer précisément comment améliorer votre expérience sur nos pages.

Récapitulatif chapitre 1. Si vous avez bien suivi les 21 points ci-dessus, vous avez un bandeau clair, symétrique et conforme, qui ne dépose rien avant consentement, qui est relié à une politique de cookies complète et précise, et qui permet à vos visiteurs de revenir sur leur choix à tout moment. C’est le chapitre le plus lourd à mettre en place mais c’est celui qui vous protège le plus des sanctions CNIL.

Passage au chapitre 2, politique de confidentialité.

Chapitre 2, Politique de confidentialité (16 points)

Deuxième chapitre. Celui où la page PrestaShop est là, par défaut, depuis le premier jour, et où 90 fois sur 100 personne ne l’a jamais ouverte depuis.

Allez vérifier. Dans Conception → Pages, vous allez trouver une page intitulée « Politique de confidentialité ». Ouvrez-la. Si c’est un texte générique qui commence par « Cette politique a pour objet de vous informer… » avec du remplissage juridique copié-collé d’un modèle de 2018, bienvenue au club. Vous êtes dans la situation de la majorité des boutiques PrestaShop qu’on audite.

Pourquoi ça compte ? Parce que c’est ce document qui fait foi en cas de contrôle CNIL. Pas votre bandeau cookies (on l’a fait au chapitre 1). Pas vos CGV (autre sujet). Votre politique de confidentialité. C’est elle qu’un inspecteur télécharge en premier. C’est elle qu’un client averti va vérifier avant d’acheter. C’est elle qui, si elle est incomplète ou obsolète, vous met en porte-à-faux immédiat.

Bon. Les 16 points qu’elle doit couvrir. On y va.

Sous-section A, Accessibilité et clarté (3 points)

Point 2.1, Information accessible sans recherche active

Énoncé : le visiteur n’a pas à chercher activement la politique de confidentialité. Elle est directement accessible depuis toutes les pages du site.

Dans votre back-office PrestaShop : footer, lien visible, sur toutes les pages (accueil, catégories, fiches produit, checkout, compte client). Simple à vérifier, il suffit d’ouvrir trois pages de types différents et de regarder en bas.

Si le lien manque sur certaines pages (arrive sur des thèmes anciens qui ont une gestion du footer un peu baroque), direction Conception → Positions → displayFooter pour le remettre. Ou, plus rapide, passer par le module de gestion du pied de page de votre thème si vous en avez un.

Point 2.2, Accès direct en un clic

Énoncé : un seul clic depuis le footer et l’utilisateur arrive sur la politique complète. Pas de PDF à télécharger, pas de page intermédiaire type « choisissez votre document », pas de pop-up.

Dans votre back-office PrestaShop : c’est presque toujours le cas par défaut, pas de souci.

Le seul piège que j’ai vu plusieurs fois : la politique hébergée en PDF sur le serveur, et linkée depuis le footer. Ne faites pas ça. Hébergez-la en page CMS HTML. Elle sera indexable par Google (utile pour votre SEO), lisible par les lecteurs d’écran (utile pour l’accessibilité), et un visiteur qui veut juste vérifier un point précis pourra la parcourir sans télécharger un truc.

Point 2.3, Écrite en termes clairs et simples

Énoncé : la politique est rédigée en langage accessible. Pas de jargon juridique inutile, pas de copier-coller d’un modèle générique sans adaptation.

Dans votre back-office PrestaShop : écrivez comme vous écririez un email à un client curieux qui aurait demandé des explications. Les formulations pompeuses du style « le responsable de traitement des données à caractère personnel nominatives collectées dans le cadre du présent site internet » sont à réécrire en « nous » ou en utilisant directement le nom de la société.

Mon conseil sur la structure : des sous-titres en question marchent très bien. « Qui collecte mes données ? », « Combien de temps sont-elles conservées ? », « À qui sont-elles transmises ? », « Comment puis-je les supprimer ? ». Ça oriente le lecteur vers sa vraie question au lieu de lui imposer de lire un roman.

Référence : article 12 du RGPD, qui est explicite sur ce point d’ailleurs. Concision, transparence, compréhension aisée, en termes clairs et simples. C’est écrit noir sur blanc.

Sous-section B, Contenu obligatoire (9 points)

Point 2.4, Identité et coordonnées du responsable de traitement

Énoncé : l’identité complète de votre société est indiquée, en cohérence avec vos mentions légales.

Dans votre back-office PrestaShop : c’est le bloc d’ouverture de la politique. Reprenez le même modèle que sur vos mentions légales, pas de nouvelle version. La cohérence des deux pages est vérifiée en cas de contrôle, ce serait bête d’avoir un SIRET sur l’une et une coquille sur l’autre.

Voici le modèle à adapter :

À copier-coller · Bloc responsable de traitement

Le responsable du traitement des données personnelles collectées sur [URL DE VOTRE BOUTIQUE] est : [DÉNOMINATION SOCIALE], [FORME JURIDIQUE, ex : SAS, SARL, EURL] au capital social de [MONTANT] euros Siège social : [ADRESSE COMPLÈTE] Immatriculée au RCS de [VILLE] sous le numéro [NUMÉRO SIRET] Numéro de TVA intracommunautaire : [NUMÉRO TVA] Représentée par [NOM ET PRÉNOM DU DIRIGEANT], en qualité de [FONCTION] Pour toute question relative à la protection de vos données personnelles, vous pouvez nous contacter : Par email : [rgpd@votre-boutique.fr] Par courrier : [ADRESSE POSTALE]

Référence : article 13 du RGPD, informations à fournir lors de la collecte auprès de la personne concernée.

Point 2.5, Détail des données à caractère personnel collectées

Énoncé : la politique liste de façon exhaustive les données collectées par la boutique.

Dans votre back-office PrestaShop : là il faut être concret. Pas « toutes les données nécessaires à la fourniture du service » qui ne veut rien dire. Une liste, catégorie par catégorie.

Voici la liste type pour une boutique PrestaShop classique. À adapter en retirant ce que vous ne collectez pas (si vous ne faites pas de jeux-concours, retirez), en ajoutant ce qui serait spécifique à votre activité (tailles de vêtements, préférences alimentaires, données de santé le cas échéant).

À copier-coller · Liste des données collectées

Nous collectons les catégories de données suivantes : Données d’identification : civilité, nom, prénom, date de naissance (si renseignée), date de création de votre compte client. Données de contact : adresse email, numéro de téléphone (si renseigné), adresse postale (livraison et facturation). Données de commande : historique de vos commandes, produits achetés, montants, dates, mode de livraison choisi, mode de paiement choisi (mais pas le numéro de carte bancaire, qui est géré directement par notre prestataire de paiement). Données de navigation : adresse IP, type de navigateur (user agent), pages consultées sur notre site, date et heure de visite, site de provenance (referrer). Données de relation : échanges avec notre service client (emails, tickets), avis que vous laissez sur nos produits, participations à nos jeux-concours éventuels. Données dérivées : préférences produits déduites de votre navigation et de vos commandes, segment marketing dans lequel vous êtes classé (client régulier, nouveau client, client inactif, etc.). Nous ne collectons aucune donnée dite sensible au sens de l’article 9 du RGPD (origine raciale, opinions politiques, convictions religieuses, données de santé, orientation sexuelle, etc.).

Mon conseil : le dernier paragraphe sur les données sensibles n’est pertinent que si c’est vraiment vrai. Si vous vendez des produits de santé ou de bien-être et que vous collectez des informations sur l’état de santé du client (par exemple pour une boutique de compléments alimentaires avec un questionnaire de personnalisation), vous avez des données de santé et il faut le déclarer, avec une base légale spécifique (consentement explicite article 9.2.a). Dans ce cas, faites appel à un juriste spécialisé, c’est un cas qui sort du cadre de ce guide.

Point 2.6, Caractère obligatoire ou facultatif

Énoncé : pour chaque champ collecté, précisez s’il est obligatoire (pour exécuter le contrat) ou facultatif. Les astérisques sur vos formulaires PrestaShop doivent être cohérents avec ce que dit la politique.

Dans votre back-office PrestaShop : le test de cohérence se fait en 2 minutes. Ouvrez votre formulaire de création de compte, regardez quels champs ont un astérisque rouge. Ouvrez votre politique de confidentialité, regardez ce qu’elle dit. Les deux doivent se correspondre parfaitement.

Ce qu’on voit chez nos clients : un formulaire où le téléphone est obligatoire (astérisque rouge), et une politique qui dit « les champs téléphone et date de naissance sont facultatifs ». Contradiction. En contrôle CNIL, c’est la politique qui fait foi, donc le formulaire est à remettre en cohérence.

Les obligatoires d’une commande classique, c’est : nom, prénom, email, adresse de livraison, mode de paiement. Les facultatifs : téléphone, date de naissance, civilité, société, numéro de TVA (sauf B2B où il est souvent obligatoire).

À copier-coller · Obligatoire vs facultatif

Lors de la création de votre compte ou du passage d’une commande, certains champs sont obligatoires car ils sont nécessaires à l’exécution du contrat de vente (livraison, facturation, relation client). Il s’agit de votre nom, prénom, adresse email, adresse de livraison et adresse de facturation. Ces champs sont signalés par un astérisque rouge sur nos formulaires. Les autres champs (téléphone, date de naissance, société) sont facultatifs. Vous pouvez laisser votre commande se finaliser sans les renseigner. Le téléphone n’est collecté que pour faciliter la livraison en cas d’absence et n’est pas utilisé à des fins marketing sans votre consentement distinct.

Point 2.7, Finalités de chaque traitement

Énoncé : pour chaque finalité distincte de traitement (gestion des commandes, livraison, fidélisation, newsletter, etc.), la politique les liste explicitement avec les données concernées.

Dans votre back-office PrestaShop : la meilleure forme c’est un tableau. Voici les finalités types d’une boutique PrestaShop, à reprendre et adapter.

À copier-coller · Tableau des finalités de traitement

Mon conseil : si vous ne faites pas une de ces finalités (par exemple vous n’avez pas d’avis clients automatiques), retirez la ligne. La politique doit refléter ce que vous faites réellement, pas une liste exhaustive de ce qu’une boutique pourrait théoriquement faire.

Point 2.8, Bases légales de chaque finalité

Énoncé : pour chaque finalité, une base légale parmi les six prévues par l’article 6 du RGPD. Consentement, exécution d’un contrat, obligation légale, intérêt légitime, mission d’intérêt public, sauvegarde des intérêts vitaux.

Dans votre back-office PrestaShop : vous l’avez déjà en colonne 3 du tableau du point 2.7.

Un rappel rapide sur les 4 bases utiles en e-commerce, parce que c’est un des points où beaucoup de marchands sèchent.

Exécution d’un contrat (article 6.1.b). Pour tout ce qui est nécessaire pour vendre, livrer, facturer, assurer le SAV. C’est votre base par défaut pour la commande. Si une donnée est nécessaire à l’exécution de la vente, vous n’avez pas besoin de consentement.

Consentement (article 6.1.a). Pour la newsletter, pour les cookies non essentiels, pour le profilage publicitaire. Recueilli via case à cocher décochée, spécifique, éclairé. C’est la base la plus fragile parce qu’elle peut être retirée à tout moment.

Obligation légale (article 6.1.c). Pour les factures comptables (10 ans, Code de commerce), les données fiscales. Vous ne pouvez pas supprimer ces données même si le client vous le demande, la loi prime.

Intérêt légitime (article 6.1.f). Pour la lutte contre la fraude, la sécurité informatique, les avis clients automatiques après commande, les relances de panier abandonné dans une certaine mesure.

Attention sur l’intérêt légitime : il doit être documenté. Concrètement, une petite note interne qui explique pourquoi votre intérêt justifie le traitement et pourquoi il n’atteint pas excessivement aux droits de la personne. Et il peut toujours être contesté par opposition de la personne (article 21 du RGPD). On en reparle plus bas.

Référence : article 6 du RGPD.

Point 2.9, Existence de prises de décision automatisée (y compris profilage)

Énoncé : si vous utilisez un système qui prend des décisions sur un client sans intervention humaine significative (scoring client anti-fraude, recommandations personnalisées avancées, chatbot qui refuse automatiquement un remboursement, algorithmes de pricing personnalisé), vous devez le mentionner.

Dans votre back-office PrestaShop : pertinent pour vous si vous utilisez Signifyd, Stripe Radar ou équivalent pour le scoring anti-fraude, ou si vous avez un chatbot IA qui prend des décisions sur les demandes client sans validation humaine. Voici le modèle de mention.

À copier-coller · Prise de décision automatisée

Nous utilisons un système automatique de détection de la fraude pour sécuriser les paiements sur notre boutique. Ce système analyse votre commande (montant, adresse de livraison, adresse IP, historique) et peut la marquer comme suspecte. Dans ce cas, la commande est revue manuellement par un membre de notre équipe avant d’être acceptée ou refusée. Aucune décision n’est prise sans intervention humaine. Nous utilisons également un système de recommandations de produits basé sur votre historique de navigation et vos achats précédents. Ces recommandations n’ont aucune incidence sur le prix que vous voyez (nos prix sont identiques pour tous les visiteurs) ni sur votre accès au service. [SI APPLICABLE] Notre chatbot de support client utilise [NOM DE L’OUTIL IA] pour répondre aux questions courantes. Pour toute demande sensible (remboursement, annulation, réclamation), vous êtes automatiquement redirigé vers un membre de notre équipe humaine. Vous avez le droit de demander une intervention humaine à tout moment, de contester une décision automatisée qui vous concernerait, et d’exprimer votre point de vue à son sujet.

Référence : article 22 du RGPD, et position CNIL du 19 février 2021 sur les chatbots. Par défaut, une décision significative ne peut pas être prise par un algorithme seul, sauf exceptions limitées.

Point 2.10, Destinataires des données

Énoncé : liste explicite des sous-traitants e-commerce qui traitent vos données, avec leur rôle juridique précis.

Dans votre back-office PrestaShop : attention à une subtilité juridique qu’on voit mal appliquée 8 fois sur 10.

Il y a deux types de destinataires, et il faut les distinguer.

Les sous-traitants au sens de l’article 28. Eux traitent vos données sur vos instructions. Votre hébergeur, votre outil emailing, votre outil de chatbot. Vous signez un DPA (Data Processing Agreement) avec eux, et ils sont responsables envers vous.

Les responsables de traitement indépendants. Eux ont leur propre relation juridique avec le client et leur propre politique. Stripe et PayPal sont dans cette catégorie, et c’est souvent mal compris. Quand votre client paye par Stripe, Stripe devient responsable de traitement sur les données bancaires, pas votre sous-traitant. Ce qui veut dire que Stripe applique sa propre politique, pas la vôtre.

Dans votre politique, il faut donc mentionner les deux, mais en précisant leur rôle. Voici le modèle.

À copier-coller · Destinataires et rôle juridique

Vos données sont susceptibles d’être transmises aux destinataires suivants : Hébergeur (sous-traitant) : [NOM HÉBERGEUR, ex : o2switch / OVH / Ionos / Hostinger], qui héberge notre boutique sur des serveurs situés en [PAYS]. Prestataire de paiement (responsable de traitement indépendant) : Stripe Payments Europe Ltd (Irlande) et/ou PayPal (Europe) S.à r.l. et Cie, S.C.A. (Luxembourg). Ces prestataires traitent vos données bancaires sous leur propre responsabilité, selon leurs propres politiques de confidentialité. Nous ne conservons aucun numéro de carte bancaire complet. Outil emailing (sous-traitant) : [NOM OUTIL, ex : Brevo SA (France) / Mailchimp (Intuit Inc., États-Unis) / Klaviyo Inc. (États-Unis)], pour l’envoi de nos communications marketing si vous y avez consenti. Transporteur (sous-traitant) : [NOM TRANSPORTEUR, ex : La Poste / Chronopost / Mondial Relay / Colissimo / DHL / UPS], pour la livraison de vos commandes. Outil de mesure d’audience (sous-traitant si cookies acceptés) : Google LLC (États-Unis) pour Google Analytics, si vous avez consenti aux cookies statistiques. Outil de chatbot (sous-traitant si chatbot présent) : [NOM OUTIL IA, ex : OpenAI / Anthropic / Zendesk], pour notre assistance client automatisée. Service comptable (sous-traitant) : notre cabinet d’expertise comptable pour le traitement des factures. Autorités publiques : en cas de demande légale ou réquisition judiciaire, nous sommes tenus de transmettre certaines données aux autorités compétentes. Nous ne vendons, ne louons et ne cédons vos données à aucun tiers commercial.

Mon conseil : vérifiez que pour chaque sous-traitant listé, vous avez bien signé le DPA (Data Processing Agreement) ou « accord de sous-traitance ». C’est une obligation stricte de l’article 28 du RGPD. Un outil sérieux vous le propose en ligne dans votre espace client (Brevo, Stripe, Cloudflare, o2switch, OVH le font tous). Un outil qui ne vous le propose pas est un drapeau rouge.

Point 2.11, Existence ou non de transferts hors UE

Énoncé : la politique identifie explicitement les transferts de données en dehors de l’Union européenne, avec leur cadre juridique (Data Privacy Framework, clauses contractuelles types, règles d’entreprise contraignantes).

Dans votre back-office PrestaShop : pour chaque sous-traitant US de votre liste précédente (Google, Meta, Microsoft, Intuit/Mailchimp, OpenAI, Klaviyo, Zendesk, AWS si utilisé, Stripe dans certains cas), une mention explicite.

À copier-coller · Transferts hors UE

Certains de nos sous-traitants sont situés en dehors de l’Union européenne, principalement aux États-Unis. Ces transferts sont encadrés par les mécanismes juridiques suivants : Data Privacy Framework (DPF), décision d’adéquation de la Commission européenne du 10 juillet 2023, applicable aux entreprises américaines qui se sont certifiées à ce framework. Concerne notamment : Google LLC, Meta Platforms, Microsoft Corporation, Intuit Inc. (Mailchimp), Stripe Inc. Clauses contractuelles types (CCT ou SCC), validées par la Commission européenne, qui s’appliquent aux transferts vers des sous-traitants non certifiés DPF. Nous nous assurons que chacun de nos sous-traitants transférant des données en dehors de l’UE présente des garanties appropriées de protection. Vous pouvez obtenir une copie de ces garanties sur demande à l’adresse [rgpd@votre-boutique.fr].

Référence : Data Privacy Framework adopté le 10 juillet 2023, confirmé par le Tribunal de l’UE le 3 septembre 2025 (affaire T-553/23). Reste fragile juridiquement (Schrems III en cours), donc la mention des clauses contractuelles types en backup reste pertinente.

Point 2.12, Durées de conservation

Énoncé : pour chaque type de donnée, la durée de conservation est précisée, en cohérence avec les recommandations CNIL et les obligations légales.

Dans votre back-office PrestaShop : c’est un des points les plus techniques. Voici les durées de référence pour une boutique PrestaShop, reprises du référentiel CNIL pour le secteur commerce (septembre 2025) et du Code de commerce.

À copier-coller · Durées de conservation

Type de donnée | Durée de conservation —————————————– | —————————————– Données de facturation et comptables | 10 ans (obligation légale, Code de commerce) Données de commande | 3 ans après la dernière commande (relation client active) Compte client inactif | 2 ans sans connexion (archivé puis supprimé) Données de prospection (non clients) | 3 ans après le dernier contact actif Numéro de carte bancaire | Non conservé (géré par notre prestataire de paiement) Cryptogramme CVV | Jamais conservé Cookies, selon la catégorie | Voir notre politique de cookies (6 mois à 2 ans selon le cookie) Consentement du cookie lui-même | 6 mois (durée du choix mémorisé) Avis clients | 5 ans après publication Données de navigation (logs techniques) | 12 mois maximum Correspondance SAV et tickets | 3 ans après la fin de l’échange Données de chatbot IA | 30 jours (purge automatique) Données fiscales (TVA intracommunautaire) | 10 ans (obligation légale)

Mon conseil : il faut que les durées annoncées dans votre politique correspondent à ce que vous faites vraiment dans votre back-office. Si vous dites « 2 ans pour les comptes inactifs » mais que vous n’avez aucun mécanisme de purge automatique et que des comptes de 2019 sont encore actifs en 2026, vous êtes en décalage. Le plus simple : mettez en place une tâche planifiée trimestrielle qui archive puis supprime les comptes inactifs selon vos règles.

Référence : référentiel CNIL « gestion commerciale » mis à jour en septembre 2025, décision CNIL contre PAP de 2022 (sanction pour conservation excessive de profils clients).

Sous-section C, Droits et recours (4 points)

Point 2.13, Droits de la personne concernée

Énoncé : la politique liste les 8 droits RGPD de la personne concernée (accès, rectification, effacement, limitation, portabilité, opposition, retrait du consentement, refus de décision automatisée).

Dans votre back-office PrestaShop : modèle à reprendre tel quel, adapté à votre boutique.

À copier-coller · Bloc des 8 droits

Conformément au Règlement général sur la protection des données (RGPD) et à la loi Informatique et Libertés, vous disposez des droits suivants sur vos données personnelles : Droit d’accès (article 15) : obtenir la confirmation que nous traitons vos données et en recevoir une copie. Droit de rectification (article 16) : faire corriger des données inexactes ou compléter des données incomplètes. Droit à l’effacement (article 17), aussi appelé droit à l’oubli : demander la suppression de vos données, sauf lorsqu’une obligation légale nous impose de les conserver (notamment les factures pendant 10 ans). Droit à la limitation du traitement (article 18) : demander que nous suspendions temporairement l’utilisation de vos données, par exemple pendant le temps de résoudre une contestation. Droit à la portabilité (article 20) : récupérer vos données dans un format structuré et lisible pour les transférer à un autre prestataire. Droit d’opposition (article 21) : vous opposer à un traitement fondé sur notre intérêt légitime (typiquement pour les traitements marketing). Droit de retrait du consentement (article 7.3) : revenir à tout moment sur un consentement donné (cookies, newsletter), aussi simplement que vous l’avez donné. Droit de ne pas faire l’objet d’une décision automatisée (article 22) : refuser qu’une décision significative vous concernant soit prise uniquement sur la base d’un traitement automatisé. Vous pouvez exercer ces droits à tout moment en nous contactant par les moyens indiqués ci-dessous. Nous vous répondrons dans un délai d’un mois, pouvant être prolongé de deux mois pour les demandes complexes.

Point 2.14, Modalités d’exercice des droits

Énoncé : au moins deux moyens d’exercer ses droits sont proposés. Typiquement, une adresse email dédiée et une adresse postale, ou une adresse email et un formulaire web dédié.

Dans votre back-office PrestaShop : bloc à placer juste après la liste des droits.

À copier-coller · Comment exercer vos droits

Pour exercer vos droits ou pour toute question relative à la protection de vos données personnelles, vous pouvez nous contacter de deux manières : Par email : [rgpd@votre-boutique.fr] Par courrier postal : [DÉNOMINATION SOCIALE], [ADRESSE COMPLÈTE DU SIÈGE] Afin de traiter votre demande rapidement, merci de préciser votre nom complet, votre adresse email associée à votre compte (le cas échéant) et la nature précise de votre demande. Pour des raisons de sécurité, nous pouvons vous demander de justifier de votre identité. Nous nous engageons à vous répondre dans un délai d’un mois à compter de la réception de votre demande. Ce délai peut être prolongé de deux mois supplémentaires pour les demandes complexes ou nombreuses, avec une information de notre part dans ce sens. Si vous avez un compte client sur notre boutique, vous pouvez également exercer certains de vos droits directement depuis votre espace « Mes informations personnelles » (consultation, rectification, export de vos données, demande d’effacement).

Référence : RGPD article 12.3, délai de réponse d’un mois prolongeable à trois.

Point 2.15, Coordonnées du DPO si désigné

Énoncé : si un Délégué à la Protection des Données (DPO) est désigné, ses coordonnées sont dans la politique. Sinon, un référent RGPD interne est indiqué.

Dans votre back-office PrestaShop : pour la plupart des boutiques TPE/PME (moins de 250 employés, pas d’activité massive de surveillance ou de traitement de données sensibles), le DPO n’est pas obligatoire. Si c’est votre cas, indiquez un référent.

À copier-coller · DPO ou référent RGPD

[VERSION AVEC DPO DÉSIGNÉ] Notre Délégué à la Protection des Données (DPO) peut être contacté à l’adresse suivante : Email : [dpo@votre-boutique.fr] Courrier : [NOM DU DPO], [DÉNOMINATION SOCIÉTÉ], [ADRESSE COMPLÈTE]. [VERSION SANS DPO, AVEC RÉFÉRENT RGPD] Nous n’avons pas désigné de Délégué à la Protection des Données (DPO) car notre activité ne l’impose pas réglementairement. Un référent RGPD interne est cependant désigné au sein de notre équipe pour gérer toutes les questions relatives à la protection de vos données. Vous pouvez le contacter à l’adresse [rgpd@votre-boutique.fr].

Point 2.16, Droit d’introduire une réclamation auprès de la CNIL

Énoncé : la politique mentionne explicitement le droit de saisir la CNIL en cas de désaccord ou de non-réponse de votre part.

Dans votre back-office PrestaShop : phrase standard à la fin de la section sur les droits.

À copier-coller · Droit de réclamation CNIL

Si vous estimez, après nous avoir contactés, que vos droits ne sont pas respectés, vous avez le droit d’introduire une réclamation auprès de la Commission nationale de l’informatique et des libertés (CNIL) : Sur le site de la CNIL : www.cnil.fr (rubrique « Exercer vos droits ») Par courrier : CNIL, 3 Place de Fontenoy, TSA 80715, 75334 PARIS CEDEX 07 Par téléphone : 01 53 73 22 22

Récapitulatif chapitre 2. Une politique de confidentialité conforme couvre les 16 points ci-dessus. C’est un document qui doit être vivant, remis à jour chaque fois que vous ajoutez un nouvel outil (nouveau sous-traitant, nouveau chatbot, nouvelle fonctionnalité de profilage). Ne la rédigez pas une fois pour toutes. Mettez-la en version datée en pied de page (« Dernière mise à jour : [date] ») et tenez un historique des versions majeures.

Chapitre 3, Mentions sur les formulaires de collecte (5 points)

Chapitre court, 5 points. Mais chapitre sous-estimé.

Ce qu’il dit : sous chaque formulaire de votre boutique qui collecte des données, une mention d’information doit rappeler l’essentiel. Pas dans la politique de confidentialité cachée trois clics plus loin, sous le formulaire. En dessous.

Vous allez me dire : « Mais si j’ai bien fait ma politique de confidentialité au chapitre 2, pourquoi je dois remettre des mentions sous chaque formulaire ? ». Bonne question. La réponse courte : parce que l’information doit être donnée au moment de la collecte, pas au moment où le visiteur aurait l’idée d’aller chercher la politique. C’est l’esprit de l’article 13 du RGPD. La personne doit savoir ce que vous faites de ses données au moment où elle appuie sur le bouton « Envoyer ».

Sur PrestaShop c’est probablement le chapitre où l’écart est le plus flagrant. Les formulaires fonctionnent techniquement (sinon la boutique ne tournerait pas), mais 9 fois sur 10, la mention d’information n’est pas là. Ou alors elle est là, mais elle est générique, pas adaptée au formulaire.

Les 5 points, c’est parti.

Point 3.1, Mention d’information sous chaque formulaire

Énoncé : chaque formulaire qui collecte des données personnelles a une mention d’information RGPD directement en dessous (pas dans une page séparée, pas en survol, pas dans un pop-up).

Dans votre back-office PrestaShop : faites le tour de tous les formulaires de votre boutique. Voici la liste type :

Formulaire de création de compte client
Formulaire de commande (checkout invité + checkout compte)
Formulaire de contact
Formulaire de newsletter (module ps_emailsubscription natif)
Formulaire « me prévenir quand disponible » sur les fiches produit
Formulaire d’avis client
Formulaires des modules de devis, demande de catalogue, configurateur

Pour chacun, une mention d’information en dessous. La mention peut être courte et factuelle. Elle n’a pas à reprendre toute la politique, juste les informations clés avec un lien vers la politique complète.

Point 3.2, Finalités du traitement

Énoncé : la mention indique clairement ce qui sera fait des données collectées par ce formulaire spécifique.

Dans votre back-office PrestaShop : pour chaque formulaire, la finalité est différente. Un formulaire de contact sert à répondre à la question. Un formulaire de création de compte sert à tenir votre compte client. Un formulaire newsletter sert à vous envoyer des emails marketing. Ne faites pas de copier-coller d’une mention générique sur tous vos formulaires.

Point 3.3, Destinataires des données

Énoncé : qui reçoit les données saisies dans le formulaire.

Dans votre back-office PrestaShop : généralement, vous (l’éditeur de la boutique) et parfois un sous-traitant (votre outil emailing si c’est un formulaire newsletter, votre outil CRM si c’est un formulaire de contact).

Point 3.4, Durée de conservation

Énoncé : combien de temps les données seront conservées. Cohérent avec le tableau du point 2.12.

Dans votre back-office PrestaShop : la mention renvoie à la bonne durée selon la finalité. Formulaire de création de compte, 3 ans après dernière commande. Newsletter, 3 ans après le dernier contact actif. Formulaire de contact, 3 ans après la fin de l’échange.

Gardez en tête que ces durées doivent être cohérentes avec le tableau du chapitre 2. Pas 3 ans ici, 2 ans là, 5 ans ailleurs. Sinon c’est incohérent.

Point 3.5, Droits et modalités d’exercice

Énoncé : rappel des droits avec un lien vers la politique complète ou vers le formulaire d’exercice des droits.

Dans votre back-office PrestaShop : une phrase courte suffit. Pas besoin de reprendre les 8 droits en détail à chaque fois, la politique s’en charge. Juste de quoi informer le visiteur qu’il a des droits et où il peut les exercer.

Mentions types, à adapter pour chaque formulaire

Voici les mentions clés en main pour les 4 formulaires principaux d’une boutique PrestaShop.

À copier-coller · Formulaire création de compte

Les informations recueillies sur ce formulaire sont enregistrées dans un fichier informatisé par [DÉNOMINATION SOCIÉTÉ] pour la gestion de votre compte client et de vos commandes. Elles sont conservées pendant 3 ans à compter de votre dernière commande et sont destinées à notre service commercial et à nos sous-traitants (hébergeur, prestataire de paiement, transporteur). Conformément à la loi Informatique et Libertés et au RGPD, vous pouvez exercer votre droit d’accès, de rectification, d’effacement et d’opposition aux données vous concernant en nous contactant à [rgpd@votre-boutique.fr] ou en consultant notre politique de confidentialité.

À copier-coller · Formulaire de contact

Les informations saisies dans ce formulaire sont utilisées pour répondre à votre demande. Elles sont conservées pendant 3 ans à compter de la fin de notre échange. Destinataires : notre service client et notre outil de gestion de tickets. Vous pouvez accéder à vos données, les rectifier ou en demander l’effacement en nous contactant à [rgpd@votre-boutique.fr]. En savoir plus dans notre politique de confidentialité.

À copier-coller · Formulaire newsletter

En vous inscrivant à notre newsletter, vous acceptez de recevoir nos actualités et offres commerciales par email (environ [FRÉQUENCE, ex : 2 emails par semaine]). Votre adresse email est transmise à notre prestataire d’emailing [NOM, ex : Brevo] et conservée jusqu’à votre désinscription, et au maximum 3 ans après votre dernier clic actif. Vous pouvez vous désinscrire à tout moment en cliquant sur le lien présent au bas de chaque email, ou en nous contactant à [rgpd@votre-boutique.fr]. Plus d’informations dans notre politique de confidentialité.

À copier-coller · Formulaire d’avis client

Votre avis sera publié sur notre site avec votre prénom et votre initiale de nom de famille, ainsi que votre note. Il est conservé pendant 5 ans à compter de la date de publication. Vous pouvez à tout moment demander sa modification ou son retrait en nous contactant à [rgpd@votre-boutique.fr]. Nous nous réservons le droit de modérer les avis qui ne respecteraient pas notre politique (insultes, diffamation, hors sujet).

À copier-coller · Formulaire création de compte

À copier-coller · Formulaire de contact

À copier-coller · Formulaire newsletter

À copier-coller · Formulaire d’avis client

Mon conseil : sur PrestaShop, la mention sous le formulaire de newsletter natif (ps_emailsubscription) est souvent absente. Il faut l’ajouter via le thème, en surchargeant le template du module, ou plus simple, en passant par un module CMP qui gère lui-même les newsletters avec mentions conformes (Brevo pour PrestaShop le fait nativement, iubenda aussi).

Chapitre 4, Prospection commerciale (9 points)

Chapitre 4. Votre emailing.

Tout ce que vous envoyez à vos clients et prospects : newsletter, relances de panier abandonné, emails post-achat, campagnes promotionnelles, programmes de fidélité, ventes privées, opérations saisonnières. Tout.

C’est le chapitre où les sanctions montent régulièrement depuis 2020. Spartoo 250 k€ en 2020. Vectaury 2 M€ la même année. Plus récemment, plusieurs décisions plus modestes sur des TPE qui ont fini à 5 ou 10 k€ d’amende et qui ne font pas la une mais qui font mal à une petite boîte. Et la CNIL n’a pas besoin d’aller chercher loin pour vous mettre en faute, elle peut arriver sur un simple signalement client. Une personne qui reçoit une newsletter qu’elle n’a pas demandée peut porter plainte en 5 minutes depuis cnil.fr. C’est comme ça que commencent la plupart des procédures.

La règle de base en deux phrases : en B2C, opt-in explicite, case à cocher décochée par défaut, la personne coche activement. En B2B, opt-out toléré, mais avec des règles précises que je détaille plus bas.

Sur PrestaShop, le piège classique c’est le module natif ps_emailsubscription. Par défaut, il ne respecte pas complètement les règles. Pas de double opt-in natif (c’est une option à activer manuellement), pas de preuve horodatée exportable, et sur certains thèmes plus anciens, la case d’inscription est pré-cochée. Donc audit nécessaire sur votre installation.

Sous-section A, Prospection B2C (5 points)

Point 4.1, Consentement libre, spécifique, éclairé, univoque

Énoncé : le consentement à la prospection commerciale B2C est libre (pas conditionné à autre chose), spécifique (à la newsletter, pas mélangé avec d’autres consentements), éclairé (la personne sait à quoi elle consent) et univoque (une case à cocher active, pas une présomption).

Dans votre back-office PrestaShop : une case à cocher décochée par défaut, avec un libellé explicite.

À copier-coller · Wording de case conforme

WORDING CONFORME (case décochée par défaut) : ☐ J’accepte de recevoir par email les actualités et offres commerciales de [NOM DE LA BOUTIQUE]. Je peux me désinscrire à tout moment via le lien présent au bas de chaque email. WORDING NON CONFORME (à éviter absolument) : ☒ J’accepte de recevoir la newsletter (case pré-cochée, interdite depuis CJUE Planet49 du 1er octobre 2019) « En passant commande vous acceptez notre newsletter » (pas de case, consentement implicite) « J’accepte les CGV et la newsletter » (consentement groupé, non spécifique)

Référence : RGPD article 4.11 définition du consentement, et article 7 conditions du consentement. Arrêt CJUE Planet49 du 1er octobre 2019, qui a posé explicitement que les cases pré-cochées ne valent pas consentement.

Point 4.2, Consentement recueilli AVANT la prospection

Énoncé : la personne a donné son consentement avant de recevoir le premier email commercial. Pas de « vous avez acheté donc nous vous envoyons la newsletter ».

Dans votre back-office PrestaShop : il existe une tolérance appelée « soft opt-in » : si vous avez obtenu l’email dans le cadre d’une vente, vous pouvez envoyer des propositions commerciales pour des produits ou services analogues à ceux déjà achetés, sans consentement explicite préalable, à condition de permettre un opt-out simple dans chaque email. Mais attention, ce n’est pas une autorisation générale de newsletter.

À copier-coller · Soft opt-in post-achat

Mention au moment de la commande (cohérente avec le soft opt-in) : En passant commande, vous acceptez que nous utilisions votre adresse email pour vous envoyer des informations commerciales sur des produits similaires à ceux que vous avez achetés. Vous pouvez vous opposer à cet envoi à tout moment via le lien de désinscription présent dans chaque email. Pour recevoir notre newsletter complète (toutes catégories de produits), vous devez cocher la case dédiée.

Référence : CNIL, position sur la prospection commerciale via emails, dernière version à jour 2023.

Point 4.3, Information sur la prospection B2C complète

Énoncé : à côté de la case newsletter, les informations essentielles sont présentes : finalité, fréquence indicative, destinataire (vous et votre outil emailing), droit de retrait.

Dans votre back-office PrestaShop : voir aussi le point 3.1 du chapitre précédent. La mention doit être visible au moment du consentement, pas cachée dans la politique qu’il faut aller chercher.

Point 4.4, Cases jamais pré-cochées

Énoncé : aucune case à cocher liée à la newsletter ou à la prospection n’est pré-cochée par défaut, nulle part sur la boutique.

Dans votre back-office PrestaShop : à vérifier à trois endroits précisément. Je les prends un par un.

Premier endroit, le module ps_emailsubscription natif. Par défaut, pas de case pré-cochée dans la version récente. Mais. Certains thèmes l’ont modifié à un moment de l’histoire, et personne n’a remis les réglages d’origine quand le thème a été mis à jour. Allez dans Modules → ps_emailsubscription → Configurer, vérifiez.

Deuxième endroit, le formulaire de création de compte. PS n’a pas de case newsletter par défaut dans le formulaire de création, il faut l’ajouter via un module ou une surcharge de thème. Si quelqu’un en a ajouté une à un moment (un développeur, une agence, un ancien freelance), vérifiez qu’elle est décochée par défaut.

Troisième endroit, le formulaire de checkout. C’est l’endroit le plus sensible. Beaucoup de thèmes PrestaShop proposent « inscrivez-vous à notre newsletter » pendant le checkout. Le client est dans une logique de finalisation d’achat, il peut cocher sans réfléchir, ou pire, ne pas décocher une case pré-cochée. La règle est stricte : case strictement décochée, libellé clair, et pas de pression visuelle pour inciter au « oui ».

Référence : arrêt CJUE Planet49, 1er octobre 2019, qui a posé explicitement que les cases pré-cochées ne valent pas consentement, peu importe les modalités techniques. La sanction Spartoo 250 k€ en 2020 a repris cette jurisprudence pour une boutique e-commerce. Depuis, la CNIL ne plaisante plus avec ce point.

Point 4.5, Service non conditionné par le consentement

Énoncé : l’accès à un service (création de compte, passage de commande) n’est jamais conditionné au consentement à la newsletter ou à la prospection.

Dans votre back-office PrestaShop : le client doit pouvoir créer son compte ou passer commande en décochant la case newsletter. Si ce n’est pas le cas, le consentement n’est pas considéré comme « libre » au sens du RGPD.

Référence : RGPD article 7.4. Le consentement n’est pas libre si l’exécution d’un contrat, y compris la fourniture d’un service, est conditionnée au consentement à un traitement qui n’est pas nécessaire à cette exécution.

Sous-section B, Preuve du consentement (1 point)

Point 4.6, Consentement tracé techniquement

Énoncé : chaque opt-in est enregistré avec horodatage (date et heure précises), adresse IP au moment du consentement, formulaire source (URL de la page où la case a été cochée), version des conditions acceptées. Cette preuve doit être exportable à tout moment, en cas de contrôle CNIL ou de contestation par la personne.

Dans votre back-office PrestaShop : c’est là que le module natif ps_emailsubscription atteint ses limites. Il enregistre l’email mais pas la preuve horodatée complète. Solutions :

Si vous utilisez Brevo, Mailchimp, Klaviyo, Sendinblue, ActiveCampaign : la preuve est gérée nativement, exportable depuis votre espace en quelques clics.

Si vous utilisez ps_emailsubscription seul : ce n’est pas suffisant, il faut ajouter un outil qui fait la preuve, soit une CMP qui gère aussi les newsletters (iubenda), soit un module de tracking RGPD spécifique, soit passer l’inscription via votre outil emailing directement (script de formulaire Brevo sur votre page).

À copier-coller · Exemple de log de preuve exportable

Exemple de structure de log à conserver pour chaque consentement : Email : client@exemple.fr Date et heure : 2026-04-15 14:32:45 UTC Adresse IP : 82.67.XXX.XXX URL de la page source : https://votre-boutique.fr/checkout Wording exact de la case acceptée : « J’accepte de recevoir par email… » Version du wording : v2.1 du 2026-01-10 Méthode de consentement : case à cocher, checkbox activée par l’utilisateur Identifiant unique du consentement : cons_abc123def456 Ce log doit être conservé jusqu’à la désinscription, et un mois supplémentaire pour gérer les contestations éventuelles.

Mon conseil : demandez à votre outil emailing d’exporter un échantillon de log aujourd’hui. Si l’export existe et contient les informations ci-dessus, vous êtes bons. Si l’export n’existe pas, ou s’il ne contient que l’email et la date, c’est insuffisant, il faut passer à un outil plus sérieux.

Référence : RGPD article 7.1, charge de la preuve du consentement sur le responsable de traitement.

Sous-section C, Prospection B2B (3 points)

Point 4.7, Information sur la prospection B2B

Énoncé : en B2B, l’opt-in n’est pas strictement obligatoire (tolérance CNIL), mais l’information doit tout de même être présente : finalité, destinataires, droit d’opposition.

Dans votre back-office PrestaShop : la règle exacte est subtile. La CNIL tolère l’opt-out en B2B si l’objet de la prospection est en rapport direct avec la profession du destinataire, et si il y a une information préalable claire avec un moyen simple et gratuit de s’y opposer.

Concrètement, un éditeur de logiciel qui prospecte des DAF ou DSI peut le faire en opt-out. Un marchand de matériel industriel qui prospecte des services achats aussi. Par contre, un site e-commerce B2C qui envoie une newsletter B2B à des professionnels sans consentement, non.

À copier-coller · Information prospection B2B

Information à afficher sur un formulaire B2B : Les informations recueillies par [DÉNOMINATION SOCIÉTÉ] font l’objet d’un traitement destiné à répondre à votre demande et, dans le cadre de notre activité professionnelle, à vous adresser ultérieurement des informations commerciales en rapport direct avec votre profession. Ces informations sont conservées pendant 3 ans à compter du dernier contact actif. Vous pouvez vous opposer à recevoir nos sollicitations commerciales, à tout moment et sans frais, en nous contactant à [rgpd@votre-boutique.fr] ou en cliquant sur le lien de désinscription présent au bas de chaque email.

Référence : position CNIL sur la prospection commerciale B2B, dernière version 2023.

Point 4.8, Opposition facile à la prospection B2B

Énoncé : la personne (professionnelle) peut s’opposer à la prospection simplement et gratuitement, sans passer par un parcours complexe.

Dans votre back-office PrestaShop : deux moyens à prévoir. Un lien de désinscription fonctionnel dans chaque email (qui doit vraiment désinscrire, pas juste ouvrir un formulaire à remplir avec motif obligatoire). Et un contact simple (email) pour ceux qui préfèrent.

Testez votre propre lien de désinscription régulièrement. Envoyez-vous un email depuis votre outil, cliquez sur le lien, vérifiez que la désinscription est prise en compte immédiatement. J’ai vu plusieurs boutiques où le lien renvoyait vers une page 404 parce que l’URL de gestion des désinscriptions avait changé sans que personne s’en rende compte. Imaginez la tête de l’inspecteur CNIL qui teste ça en premier lors d’un contrôle.

Point 4.9, Traçabilité technique du choix B2B

Énoncé : même en B2B avec opt-out, vous devez pouvoir prouver que la personne n’avait pas manifesté d’opposition au moment où vous lui avez envoyé un email. Donc la non-opposition doit aussi être tracée techniquement.

Dans votre back-office PrestaShop : même logique qu’en B2C (point 4.6). Horodatage, IP, source. L’outil emailing sérieux le fait nativement.

Récapitulatif chapitre 4. Le consentement marketing est le point où les TPE/PME françaises se font le plus rattraper. Deux situations fréquentes : la case pré-cochée qui traîne sur un thème PS ancien, et l’absence de preuve exportable pour un outil emailing basique. Les deux sont facilement corrigeables, et ce sont des corrections rentables parce qu’en retirant les personnes qui n’ont pas vraiment opt-in, vous nettoyez mécaniquement votre base et vous améliorez votre délivrabilité.

Passage au chapitre 5, sécurité et confidentialité des données. C’est le plus technique et le plus volumineux des chapitres, avec 33 points.

Chapitre 5, Sécurité et confidentialité des données (33 points)

Chapitre 5. Le gros morceau. 33 points, techniques pour la plupart.

Soyons clair tout de suite. Sur ces 33 points, la majorité dépend de votre hébergeur, de votre agence technique ou de votre développeur. Pas de vous. Vous n’allez pas configurer vous-même un WAF ou optimiser la politique de session PHP un dimanche soir.

Mais. Et c’est un grand « mais ». Le marchand reste responsable de traitement au sens du RGPD. Ce qui veut dire que même si vous n’implémentez pas vous-même les points, vous devez vous assurer qu’ils sont en place. Si votre agence a laissé traîner une faille, c’est vous qui trinquerez en contrôle CNIL. Pas l’agence. Vous.

Donc la méthode pour ce chapitre. Faites-le avec votre interlocuteur technique, en face-à-face ou en visio, en partageant son écran. Si vous êtes client chez CYBERIAL en forfait maintenance, on le fait pour vous à l’audit annuel. Si vous n’avez personne, certains points se vérifient facilement vous-même (HTTPS, 2FA, modules à jour), d’autres avec un scan automatisé (ssllabs.com pour TLS, securityheaders.com pour les en-têtes, webbkoll.dataskydd.net pour un scan global, le tout en 10 minutes montre en main).

Chaque point a un énoncé et une vérification concrète sur PrestaShop. Les exemples copier-coller sont plus rares dans ce chapitre, les points sont majoritairement binaires (en place ou pas).

On attaque.

Sous-section A, Sécurité réseau (3 points)

Point 5.1.1, Pare-feu applicatif web (WAF)

Énoncé : un pare-feu applicatif web (WAF, Web Application Firewall) filtre les requêtes entrantes pour bloquer les attaques automatisées connues (injection SQL, XSS, tentatives de brute force, bots malveillants).

Dans votre back-office PrestaShop : trois options principales pour une boutique PS.

Option 1, Cloudflare en reverse proxy (même la version gratuite fournit un WAF basique). Configuration : changer les nameservers DNS chez votre registrar pour pointer vers Cloudflare, activer le mode « Proxy » sur l’enregistrement A de votre domaine, activer les règles WAF de base dans Security → WAF.

Option 2, WAF intégré à votre hébergeur. o2switch propose un WAF par défaut sur ses offres, OVH le propose en option, Ionos également. Vérifiez ce que vous avez dans votre panel hébergeur.

Option 3, Sucuri en service externe payant (à partir de 20$ par mois), très complet mais plus cher. Pertinent pour les boutiques à fort trafic ou à fort panier moyen.

Mon conseil : si vous n’avez rien, Cloudflare gratuit est le minimum vital. Configuration en 30 minutes, bénéfices immédiats sur la vitesse (CDN) et la sécurité (WAF, DDoS protection). Pour 95 % des boutiques PS moyennes, c’est largement suffisant.

Point 5.1.2, Protocole TLS utilisé pour chiffrer les communications

Énoncé : le protocole TLS (ex-SSL) chiffre les échanges entre les navigateurs de vos visiteurs et votre boutique. HTTPS partout, TLS 1.2 minimum, TLS 1.3 recommandé.

Dans votre back-office PrestaShop : deux vérifications à faire.

La première, le test SSL Labs. Allez sur ssllabs.com/ssltest, saisissez votre domaine, l’analyse dure 2 minutes. La cible c’est A ou A+. Si vous êtes en B ou moins, il y a un problème de configuration à corriger côté serveur (TLS 1.0/1.1 encore activés, ciphers faibles, chaîne de certificats mal configurée). Envoyez le lien du rapport à votre hébergeur et demandez la correction. Ça se règle en quelques heures, gratuitement, chez les hébergeurs sérieux.

La seconde, PrestaShop lui-même. Paramètres → Généraux → Général. L’option « Activer SSL » doit être sur Oui, et « Activer SSL sur toutes les pages » doit être sur Oui également. Ne laissez jamais PS en HTTPS partiel, c’est un bug de sécurité grave.

Référence : ANSSI et CNIL recommandent TLS 1.3. TLS 1.2 acceptable en transition. TLS 1.0 et 1.1 proscrits depuis 2020.

Point 5.1.3, TLS obligatoire sur toutes les pages sensibles

Énoncé : pas seulement sur le checkout ou le login. HTTPS partout, y compris sur les pages produit, le catalogue, les images, les scripts.

Dans votre back-office PrestaShop : si vous avez bien activé « Activer SSL sur toutes les pages » au point précédent, c’est réglé côté PrestaShop. Vérifiez ensuite qu’il n’y a pas de contenu mixte (images en HTTP sur une page HTTPS). Dans Chrome DevTools → Console, regardez s’il y a des warnings de type « Mixed content ». Fréquent sur les anciennes boutiques avec des images produit importées avec des URLs absolues en HTTP.

Solution si contenu mixte : dans la base de données, faire un remplacement http://votre-domaine.fr par https://votre-domaine.fr dans les tables ps_product_lang (colonne description), ps_cms_lang, ps_category_lang. Requête à faire prudemment, toujours avec sauvegarde préalable.

Sous-section B, Composants et accès (6 points)

Point 5.2.1, Composants limités au strict nécessaire et à jour

Énoncé : les modules installés sur votre boutique sont ceux que vous utilisez activement. Les modules inutilisés sont désinstallés (pas juste désactivés, désinstallés). Les modules utilisés sont à jour.

Dans votre back-office PrestaShop : dans Modules → Modules installés, filtrez par « Désactivés ». Puis désinstallez ceux que vous ne comptez pas réactiver. Chaque module, même désactivé, a son code présent sur le serveur. C’est autant de surface d’attaque potentielle.

Ce qu’on voit chez nos clients : des boutiques qui ont 80 modules installés dont 30 désactivés depuis 3 ans. Souvenirs d’anciens tests, essais non concluants, features abandonnées. Chaque ligne est une porte potentielle pour un attaquant. Le nettoyage prend une heure et vaut largement le coup.

Point 5.2.2, Composants recensés et maintenus

Énoncé : un tableau de suivi recense les modules installés, leur version, la date de leur dernière mise à jour, leur criticité. Permet de détecter les modules abandonnés (plus de mise à jour depuis 12 mois = drapeau rouge).

Dans votre back-office PrestaShop : tableau simple à tenir à jour trimestriellement. Voici le format type.

À copier-coller · Tableau de suivi des modules PS

Module | Version | Dernière MAJ | Criticité | Action ——————————- | ———– | ————– | ——— | —— ps_emailsubscription (natif) | 2.6.0 | 2024-11-15 | Basse | OK ps_gdpr | 3.1.2 | 2025-03-10 | Haute | OK Axeptio | 1.8.4 | 2026-01-22 | Haute | OK Brevo (SendinBlue) | 5.2.1 | 2025-12-05 | Moyenne | OK Stripe officiel | 2.1.0 | 2026-02-18 | Critique | OK ModuleXYZ (ancien) | 1.2.3 | 2022-06-01 | Basse | À remplacer Template [nom thème] | 3.4.2 | 2025-09-01 | Haute | OK

Mon conseil : tout module non mis à jour depuis plus de 12 mois est à surveiller. Plus de 24 mois, il faut le remplacer. Les modules abandonnés par leur éditeur sont la source la plus fréquente des failles de sécurité sur PrestaShop.

Point 5.3, Accès aux outils d’administration limité aux personnes habilitées

Énoncé : seules les personnes ayant besoin d’un accès admin en ont un. Les comptes sont individuels (pas « admin@boutique.fr » partagé entre 3 personnes), et les accès sont révoqués immédiatement après départ d’un collaborateur.

Dans votre back-office PrestaShop : dans Équipe → Employés, chaque personne a son propre compte nominatif. Les profils sont différenciés selon le rôle (Employé, Comptable, SEO, Développeur, SuperAdmin). Évitez de tout mettre en SuperAdmin.

Point 5.4, Administration via protocoles sécurisés

Énoncé : les accès techniques au serveur se font en SSH, SFTP ou HTTPS. Jamais de FTP simple (protocole non chiffré, mot de passe en clair sur le réseau).

Dans votre back-office PrestaShop : coordonnées d’accès à demander à votre hébergeur, vérifier qu’il n’y a pas de compte FTP standard actif. Chez o2switch, OVH, Ionos : SFTP par défaut. Si vous utilisez FileZilla, configurez toujours en « SFTP – SSH File Transfer Protocol », jamais en « FTP ».

Point 5.5, Filtrage réseau et authentification contre l’usurpation

Énoncé : des mécanismes empêchent qu’un attaquant usurpe l’adresse IP d’un administrateur ou accède au back-office depuis une adresse inhabituelle.

Dans votre back-office PrestaShop : plusieurs mesures possibles. Renommer le dossier /admin avec un suffixe aléatoire (par défaut PS génère un nom type /admin123abc, vérifiez que c’est bien aléatoire et pas juste /admin). Restreindre l’accès au back-office par IP si possible (module dédié ou règles .htaccess). Activer la 2FA sur tous les comptes admin (point 5.6).

Point 5.6, Administrateurs authentifiés de manière sûre

Énoncé : la 2FA (authentification à deux facteurs) est active pour tous les comptes admin de la boutique.

Dans votre back-office PrestaShop : dans PS 8+, la 2FA est native. Équipe → Employés, pour chaque compte, activer la 2FA. L’employé devra scanner un QR code avec une appli d’authentification (Google Authenticator, Authy, 1Password, Bitwarden). Dans PS 1.7, la 2FA n’est pas native, il faut un module tiers (plusieurs disponibles sur Addons).

Ce qu’on voit chez nos clients, encore en 2026, c’est beaucoup trop de comptes admin qui n’ont qu’un login/password. Le calcul est pourtant simple : la 2FA divise par 100 le risque d’intrusion par force brute ou par credential stuffing (ces listes de mots de passe leakés que les attaquants testent automatiquement sur tous les sites qu’ils trouvent). C’est 5 minutes à activer par employé.

Si vous deviez faire une seule chose après avoir lu ce chapitre, faites ça. Aujourd’hui. Maintenant même si vous avez le back-office ouvert dans un autre onglet.

Sous-section C, Principe du moindre privilège (4 points)

Point 5.7, Principe de moindre privilège appliqué

Énoncé : chaque utilisateur et chaque composant technique a juste ce qu’il faut comme droits pour faire son travail. Rien de plus.

Dans votre back-office PrestaShop : côté employés PS, profils différenciés comme au point 5.3. Côté base de données, le compte MySQL utilisé par PrestaShop n’a que les droits nécessaires sur la base de votre boutique (SELECT, INSERT, UPDATE, DELETE, CREATE TEMPORARY TABLES). Pas GRANT ALL ni accès aux autres bases si vous avez un serveur mutualisé.

Point 5.8, Fichiers servis aux clients limités au strict nécessaire

Énoncé : les fichiers techniques de PrestaShop qui ne sont pas destinés aux visiteurs (dossiers /admin, /install, /var, /tools) ne sont pas accessibles via URL publique.

Dans votre back-office PrestaShop : après installation, le dossier /install doit être supprimé. Le dossier /admin doit être renommé (point 5.5). Le fichier robots.txt doit bloquer les dossiers sensibles à l’indexation, même si ça ne remplace pas une vraie protection technique (.htaccess).

Test rapide : allez sur votre-domaine.fr/var/logs/ dans votre navigateur. Vous devez avoir un 403 Forbidden, pas un listing de fichiers.

Point 5.9, Droits sur la base de données gérés finement

Énoncé : le compte MySQL utilisé par PrestaShop a uniquement les droits nécessaires sur sa base, pas plus.

Dans votre back-office PrestaShop : à vérifier avec votre hébergeur. Le compte psuser (ou équivalent) n’a pas de GRANT ALL PRIVILEGES. Les privilèges FILE, SUPER, SHUTDOWN ne sont pas accordés. Hébergeurs sérieux : c’est réglé par défaut. Serveurs dédiés autogérés : à vérifier.

Point 5.10, Renseignements techniques limités

Énoncé : les informations sur la pile technique (version PHP, version PrestaShop, serveur web) ne sont pas exposées publiquement. Les messages d’erreur détaillés ne sont pas affichés en production.

Dans votre back-office PrestaShop : dans Paramètres avancés → Performances, désactiver le « Mode debug » (il doit être sur Non en production, évident, mais on voit encore des boutiques qui l’ont laissé à Oui depuis une intervention technique il y a 6 mois). Vérifier que les messages d’erreur ne s’affichent pas sur le front. Dans les en-têtes HTTP de réponse (à tester avec securityheaders.com ou DevTools → Network), masquer la version PHP (en-tête X-Powered-By) et la version du serveur (en-tête Server).

Ce qu’on voit chez nos clients, c’est encore beaucoup de boutiques qui exposent X-Powered-By: PHP/7.4.30. Cadeau pour un attaquant qui sait immédiatement que PHP est en fin de support et va chercher directement les exploits connus de cette version. À masquer en modifiant php.ini (directive expose_php = Off) ou via .htaccess (Header unset X-Powered-By).

Sous-section D, Architecture et traitements (8 points)

Point 5.11, Matrice des flux précise

Énoncé : une matrice documente les flux réseau autorisés en entrée et en sortie. Pertinent pour les infrastructures complexes, moins critique pour une boutique TPE en mutualisé.

Dans votre back-office PrestaShop : pour une boutique mutualisée, se limiter aux ports strictement nécessaires : 80 (HTTP, redirigé vers 443), 443 (HTTPS), 22 (SSH, idéalement sur port modifié comme 2222 ou 22022), et éventuellement 25/587/465 (SMTP pour les emails sortants). Tous les autres ports doivent être fermés par le firewall de l’hébergeur.

Pour une boutique sur serveur dédié ou VPS autogéré : audit UFW (Ubuntu), iptables ou firewalld à faire avec votre admin système.

Point 5.12, Traitements faits côté serveur

Énoncé : la validation des données utilisateur (formulaires, paramètres URL) se fait côté serveur, pas seulement côté navigateur en JavaScript. Un attaquant peut toujours contourner la validation JS.

Dans votre back-office PrestaShop : PrestaShop fait bien cette validation nativement sur tous ses formulaires. Le risque est sur les modules custom développés à la va-vite, qui parfois ne valident qu’en JS. Audit à faire sur les modules spécifiques à votre boutique développés par une agence.

Point 5.13, Requêtes SQL préparées

Énoncé : toutes les requêtes SQL vers la base de données utilisent des « requêtes préparées » ou « prepared statements », qui séparent la commande SQL des données. C’est ce qui empêche l’injection SQL.

Dans votre back-office PrestaShop : PrestaShop utilise son ORM natif (Db::getInstance()->executeS() avec des paramètres typés) qui fait du prepared statements sous le capot. Le risque, encore une fois, est sur les modules tiers qui bricolent des requêtes directes en concaténant des chaînes de caractères. Audit à faire sur tout module développé en dehors du cadre officiel.

Point 5.14, Données externes échappées

Énoncé : toutes les données qui proviennent de l’utilisateur (saisies de formulaires, paramètres URL, cookies) sont échappées avant d’être affichées dans le HTML renvoyé au navigateur. Protection contre les attaques XSS (Cross-Site Scripting).

Dans votre back-office PrestaShop : PrestaShop utilise la fonction Tools::safeOutput() ou l’échappement automatique via Smarty ({$variable|escape:'html'}). Si vous avez un thème custom ou un module qui affiche des variables sans échappement, c’est une faille XSS. À auditer.

Point 5.15, Redirections statiques favorisées

Énoncé : les redirections utilisées sur votre boutique sont définies en dur dans la configuration (.htaccess, back-office PS), pas construites dynamiquement à partir de paramètres URL contrôlables par l’utilisateur.

Dans votre back-office PrestaShop : dans Paramètres avancés → Performances → Redirections, toutes vos redirections doivent être statiques. Évitez les URLs du type /redirect.php?url=... qui permettent à un attaquant de faire du « open redirect » vers un site de phishing.

Point 5.16, Redirections dynamiques en liste blanche

Énoncé : si vous utilisez malgré tout des redirections dynamiques (par exemple pour un partage de panier ou un lien de tracking de campagne), les URLs cibles sont vérifiées dans une liste blanche de domaines autorisés.

Dans votre back-office PrestaShop : vérifiez les modules de tracking que vous avez installés. Un bon module ne redirige que vers des URLs internes à votre boutique, ou vers des domaines pré-autorisés.

Point 5.17, Pas d’inclusion de fichiers via données externes

Énoncé : aucune partie du code ne fait un include() ou require() PHP dont le nom de fichier dépend d’un paramètre utilisateur.

Dans votre back-office PrestaShop : le cœur de PrestaShop est robuste nativement. Le risque est sur les modules anciens ou mal codés. Audit à faire par un développeur PHP senior si vous avez des doutes.

Point 5.18, Données externes en liste blanche

Énoncé : quand des données utilisateur sont utilisées dans du code, elles sont validées par type, par longueur et par format avant d’être utilisées.

Dans votre back-office PrestaShop : PS valide systématiquement les saisies par défaut. Vérifiez que vos modules custom le font aussi.

Sous-section E, Sessions et authentification (7 points)

Point 5.19, Identifiants de session aléatoires

Énoncé : les identifiants de session PHP sont générés avec une entropie d’au moins 128 bits, impossibles à deviner.

Dans votre back-office PrestaShop : PHP natif est conforme depuis longtemps sur cette règle. Vérifier dans php.ini que session.use_strict_mode est à 1, que session.cookie_httponly et session.cookie_secure sont activés.

Point 5.20, HTTPS utilisé pour les sessions à privilèges

Énoncé : le cookie de session a l’attribut Secure, ce qui fait qu’il n’est transmis que sur des connexions HTTPS, jamais HTTP.

Dans votre back-office PrestaShop : vérifier dans DevTools → Application → Cookies que le cookie PHPSESSID (ou PrestaShop-*) a bien « Secure » coché. Si non, modifier php.ini (session.cookie_secure = 1) ou la configuration Apache/Nginx.

Point 5.21, Attributs HTTPOnly et Secure sur la session

Énoncé : le cookie de session a l’attribut HttpOnly (inaccessible par JavaScript côté navigateur, protection contre vol de session via XSS) et l’attribut Secure (point précédent).

Dans votre back-office PrestaShop : même vérification DevTools. Les deux attributs doivent être cochés.

Point 5.22, Mots de passe stockés hashés

Énoncé : les mots de passe clients ne sont jamais stockés en clair en base de données. Ils sont transformés par une fonction cryptographique non réversible (hashage) conforme au Référentiel Général de Sécurité.

Dans votre back-office PrestaShop : PrestaShop 8+ utilise bcrypt par défaut. PS 1.7 utilisait une combinaison MD5 + salt (cookie_key de la config), moins robuste mais acceptable. Si vous êtes toujours sur PS 1.7, la migration vers PS 8 est une occasion naturelle de moderniser le hashage.

Ne jamais afficher un mot de passe client au back-office. PrestaShop ne le fait pas nativement, mais certains modules mal codés le font, à auditer.

Point 5.23, Hachage avec salt aléatoire

Énoncé : la fonction de hachage utilisée intègre un « salt » aléatoire unique pour chaque mot de passe, ce qui empêche les attaques par table précalculée (rainbow tables).

Dans votre back-office PrestaShop : bcrypt intègre un salt aléatoire par défaut. Conforme sur PS 8+.

Point 5.24, Mécanismes pour actions sensibles

Énoncé : pour les actions sensibles (changement d’email, changement de mot de passe, suppression de compte, commande à montant élevé), des mécanismes supplémentaires s’assurent de la légitimité de la requête.

Dans votre back-office PrestaShop : PS gère nativement la confirmation par email pour le changement de mot de passe. Les tokens CSRF sont présents dans tous les formulaires. Pour les actions très sensibles (suppression définitive de compte, changement d’adresse de facturation récurrente), une reconfirmation par email est recommandée.

Point 5.25, Inclusions de contenus tiers limitées

Énoncé : les scripts externes chargés sur votre boutique (trackers, widgets, chat, réassurance) sont limités au strict nécessaire. Chacun est un point d’entrée potentiel.

Dans votre back-office PrestaShop : audit des scripts tiers. Sur une boutique PrestaShop moyenne, on compte typiquement 15 à 30 scripts externes chargés par page. GA4, Meta Pixel, Criteo, Mailchimp, chat Intercom ou Crisp, widget Trustpilot ou Avis Vérifiés, etc. Chacun doit avoir une justification business claire.

Mon conseil, faites ce test maintenant. Chrome DevTools (F12) → Network → filtre JS. Visitez votre page d’accueil. Regardez la colonne « Domain » et comptez les domaines externes. Pour chaque domaine, posez-vous la question : est-ce que j’utilise vraiment ce que me permet ce script ?.

Si la réponse est non (« ah oui tiens, ça c’est un vieux tracker que j’avais installé pour une campagne en 2023, pas sûr que ça serve encore »), supprimer. Si la réponse est oui, vérifier au moins que le script est bien chargé après consentement (point 1.13). Vous allez probablement en retirer 3 ou 4 sans même y réfléchir, et votre boutique ira plus vite.

Sous-section F, Logs et surveillance (5 points)

Point 5.26, Système d’analyse des logs

Énoncé : les logs d’accès (qui se connecte au back-office, quand, depuis quelle IP, tentatives échouées) sont conservés et analysables.

Dans votre back-office PrestaShop : PS 8 a des logs natifs dans Paramètres avancés → Logs. Pour les tentatives d’intrusion, la plupart des hébergeurs fournissent des logs d’accès Apache/Nginx accessibles par SSH ou dans le panel. Cloudflare, si vous l’utilisez, fournit des logs de requêtes.

Point 5.27, Point de contact sécurité identifiable

Énoncé : un email de contact sécurité est visible dans les mentions légales ou dans un fichier security.txt à la racine, pour permettre à un chercheur en sécurité de signaler une vulnérabilité.

Dans votre back-office PrestaShop : créez un fichier security.txt dans le dossier /.well-known/ à la racine de votre site.

À copier-coller · Fichier /.well-known/security.txt

Contact: mailto:security@votre-boutique.fr Contact: mailto:rgpd@votre-boutique.fr Expires: 2027-12-31T23:59:59.000Z Preferred-Languages: fr, en Policy: https://votre-boutique.fr/securite/ Canonical: https://votre-boutique.fr/.well-known/security.txt

Point 5.28, Site parcouru régulièrement pour détecter les anomalies

Énoncé : un monitoring automatisé vérifie régulièrement que le site fonctionne, qu’il n’y a pas eu de modification non autorisée des fichiers, que les performances sont stables.

Dans votre back-office PrestaShop : trois niveaux de monitoring à envisager, par ordre de priorité.

Niveau 1, monitoring uptime. Vérifie simplement que votre boutique répond. Gratuit chez UptimeRobot ou Better Uptime (freemium). 5 minutes à configurer. Vous recevez une alerte email ou SMS si la boutique tombe. Ça devrait être en place partout, mais je constate régulièrement que ce n’est pas le cas sur des boutiques qui font pourtant 500 k€ de CA.

Niveau 2, monitoring d’intégrité. Vérifie que les fichiers core PrestaShop n’ont pas été modifiés par quelqu’un qui n’aurait rien à y faire. Modules dédiés sur Addons, ou scripts personnalisés côté serveur. C’est ce qui permet de détecter les intrusions silencieuses, celles où un attaquant injecte du code (skimmer de carte bancaire par exemple) sans faire tomber le site. Sans ce niveau, vous découvrez l’intrusion quand un client vous signale que sa CB a fuité.

Niveau 3, monitoring des performances. Core Web Vitals, temps de réponse, erreurs 500. Google Search Console le fait gratuitement, New Relic, Datadog ou Pingdom le font plus finement pour plus cher.

Chez nos clients en forfait maintenance CYBERIAL, on fait les trois. C’est ce qui permet de détecter une intrusion en 15 minutes au lieu de 3 semaines. Et 3 semaines, en e-commerce avec un skimmer de CB, ça vous coûte plus cher que toutes les amendes CNIL cumulées. Je vous laisse calculer.

Point 5.29.1, Politique de journalisation définie

Énoncé : un document interne précise qui a accès aux logs, comment ils sont analysés, quelle est leur durée de conservation.

Dans votre back-office PrestaShop : document simple, une page suffit. Qui consulte les logs (l’admin technique principal), à quelle fréquence (chaque semaine en contrôle normal, quotidiennement après incident), quelle durée de conservation (généralement 12 mois).

Point 5.29.2, Journaux transmis hors du serveur concerné

Énoncé : les logs sont répliqués sur un serveur distinct pour éviter qu’un attaquant qui compromet votre boutique puisse effacer ses traces.

Dans votre back-office PrestaShop : pour une TPE en mutualisé, une sauvegarde quotidienne des logs est suffisante (votre hébergeur le fait normalement). Pour une boutique sur serveur dédié à fort trafic, un service externe type Papertrail, Logtail, Datadog Logs, ou stack ELK maison.

Sous-section G, Stockage et espace personnel (4 points)

Point 5.30, Stockage des données en UE

Énoncé : les données de votre boutique sont stockées sur des serveurs situés physiquement dans l’Union européenne.

Dans votre back-office PrestaShop : à vérifier avec votre hébergeur. Voici le classement des principaux hébergeurs pour PrestaShop du point de vue de la localisation des données.

À copier-coller · Hébergeurs UE pour PrestaShop

Pour une boutique TPE/PME française, o2switch est le meilleur compromis. 100 % France, aucune sous-traitance hors UE, tarif raisonnable, support francophone réactif. On recommande depuis 2010, et on a converti une centaine de clients d’autres hébergeurs vers o2switch ces dernières années sans aucun regret.

Un mot sur les « cloud » américains (AWS, GCP, Azure). Même si vous choisissez une instance UE, ces hébergeurs sont soumis au Cloud Act américain, qui autorise les autorités US à demander des données stockées sur des serveurs européens. La CNIL recommande l’hébergement chez un acteur européen non soumis au Cloud Act. Au passage, c’est aussi souvent moins cher et plus réactif en support.

Point 5.31, Complexité mot de passe client robuste

Énoncé : la politique de mot de passe pour l’espace personnel client est robuste : longueur minimum, mélange majuscules/minuscules/chiffres/caractères spéciaux, interdiction des mots de passe les plus courants.

Dans votre back-office PrestaShop : dans Paramètres → Généraux → Mots de passe, fixer la longueur minimale à 8 caractères minimum (12 recommandé), activer les règles de complexité si disponibles. Depuis PS 8, ces règles sont configurables.

Point 5.32, Authentification obligatoire espace personnel

Énoncé : l’espace personnel client (adresses, commandes, données personnelles) n’est accessible qu’après authentification.

Dans votre back-office PrestaShop : par défaut, les URLs /my-account, /history, /addresses, /identity ne sont accessibles qu’après login. Vérifier qu’aucun module custom n’a exposé de page client sans authentification.

Point 5.33, Documents envoyés chiffrés

Énoncé : si votre boutique envoie des documents contenant des données personnelles (factures, courriers), ces documents sont sécurisés de manière proportionnée à la sensibilité.

Dans votre back-office PrestaShop : les factures PDF envoyées en pièce jointe d’un email de confirmation de commande sont acceptables en clair (les coordonnées y figurant sont les mêmes que celles du destinataire). Pour des échanges plus sensibles (pièce d’identité demandée pour vérification, documents médicaux dans une pharmacie en ligne), chiffrement recommandé, ou utilisation d’un portail sécurisé plutôt qu’un attachement email.

Récapitulatif chapitre 5. 33 points, majoritairement techniques. Pour une TPE/PME moyenne sur PrestaShop avec un hébergement mutualisé chez o2switch, OVH, Ionos ou Hostinger, la plupart de ces points sont gérés par défaut et il suffit de les vérifier.

Les points qui demandent votre action directe, ceux où vous êtes maître du destin : 2FA sur les comptes admin (point 5.6), audit des scripts tiers (point 5.25), tableau de suivi des modules (point 5.2.2), WAF Cloudflare si pas déjà en place (point 5.1.1), complexité mot de passe (point 5.31).

Pour les marchands sur serveur dédié, VPS autogéré ou hébergement étranger hors UE, le chapitre est plus lourd et demande un vrai accompagnement technique. Chez CYBERIAL on ne prend pas d’hébergement autogéré en forfait maintenance justement parce que ça mélange mal les responsabilités. Si vous êtes dans ce cas, discutons.

Passage au chapitre bonus IA et LLMs 2026.

Chapitre bonus, IA et LLMs 2026 (8 points)

Chapitre bonus. Les 8 points que la grille DPO Consulting originale ne couvrait pas, parce qu’elle a été rédigée avant la généralisation des IA génératives, et qu’entre-temps tout a changé.

Ce qui s’est passé entre 2022 et 2026 en accéléré : ChatGPT a transformé le support client, Claude et Gemini ont suivi, tout le monde a commencé à intégrer de l’IA partout, l’EU AI Act a été adopté (applicable dès août 2026), la CNIL a publié ses 13 fiches pratiques IA en juillet 2025, et les premiers contentieux sur l’usage de l’IA par les e-commerces sont tombés.

Ce chapitre ajoute 8 points de contrôle spécifiques à l’ère IA. Pertinent pour vous si :

• Vous avez un chatbot IA sur votre boutique • Vous utilisez ChatGPT ou Claude ou équivalent pour générer vos fiches produits • Vous vous préparez à l’arrivée des shopping agents IA en 2026 (OpenAI Agent, Perplexity Comet, Google AI Mode, ChatGPT « Buy it ») • Vous vendez aux États-Unis (contexte CCPA/CPRA)

Si vous n’êtes dans aucun de ces cas, vous pouvez techniquement sauter le chapitre. Mais lisez quand même le point 6.4 sur le robots.txt, qui concerne toutes les boutiques, même celles sans aucune IA. Parce que même si vous ne faites rien avec l’IA, les crawlers IA, eux, s’intéressent à votre contenu.

Sous-section A, Chatbots IA et GenAI (3 points)

Point 6.1, Chatbot IA déclaré dans la politique de confidentialité

Énoncé : si vous utilisez un chatbot IA sur votre boutique (Crisp AI, Intercom Fin, Zendesk Answer Bot, Tidio AI, intégration custom OpenAI ou Claude), vous le déclarez explicitement dans votre politique de confidentialité : quel outil, quel fournisseur, quel pays de stockage, quelle base légale.

Dans votre back-office PrestaShop : bloc type à insérer dans votre politique, à la suite de la section sur les sous-traitants.

À copier-coller · Mention chatbot IA

Notre boutique utilise un chatbot d’assistance client basé sur une intelligence artificielle générative. Voici les informations essentielles à ce sujet : Outil utilisé : [NOM DU CHATBOT, ex : Crisp Magic Reply / Tidio Lyro / intégration API OpenAI custom] Fournisseur de l’IA sous-jacente : [NOM, ex : OpenAI LLC / Anthropic PBC / Google LLC / Mistral AI] Localisation du traitement : [PAYS, ex : États-Unis dans le cadre du Data Privacy Framework / France pour Mistral] Base légale : intérêt légitime (amélioration de la qualité de notre support client) pour les échanges généraux, consentement pour toute collecte d’information personnelle au-delà du nécessaire. Données traitées : contenu de vos messages, historique de conversation, adresse email si vous vous identifiez. Durée de conservation : 30 jours pour les conversations complètes, logs anonymisés conservés 12 mois pour amélioration de service. Vous pouvez à tout moment demander à échanger avec un agent humain en tapant « agent humain » dans le chat ou en nous contactant directement à [rgpd@votre-boutique.fr]. Aucune décision significative vous concernant (remboursement, litige, annulation) n’est prise par le chatbot seul, toujours par un membre de notre équipe.

Référence : cas documenté de mise en demeure CNIL en septembre 2024 d’un e-commerce français qui utilisait l’API ChatGPT dans son chatbot sans mention dans sa politique. Mise en conformité imposée sous 2 mois. Le trafic chatbot IA sur les sites français a augmenté de 340 % en 2024, c’est un angle scruté.

Point 6.2, Durée de conservation des conversations chatbot documentée

Énoncé : la durée de conservation des échanges avec le chatbot est précisée, et elle correspond à ce que fait réellement votre fournisseur IA.

Dans votre back-office PrestaShop : chaque fournisseur IA a ses propres durées par défaut, et vous devez les connaître pour les transmettre à vos visiteurs. Voici le tableau de référence.

À copier-coller · Durées conservation par fournisseur IA

Si vous utilisez l’API OpenAI pour un chatbot sur votre boutique, mon conseil c’est d’activer le mode « Zero Data Retention » (disponible sur les comptes Business/Enterprise). Ça fait passer la durée de conservation à 0, et ça simplifie énormément votre communication RGPD. Votre politique peut alors dire « aucune conservation côté fournisseur IA » au lieu de « 30 jours dans le cadre du Data Privacy Framework ».

Sur un chatbot clé en main type Crisp ou Intercom, vérifiez dans leurs conditions qu’ils activent ce mode eux-mêmes côté fournisseur. Si ce n’est pas clair dans leurs docs, demandez-leur explicitement par email. Leur réponse, ou leur non-réponse, sera un bon indicateur de sérieux.

Point 6.3, Purge des données sensibles dans les conversations

Énoncé : un mécanisme évite que des données sensibles (santé, opinions politiques, orientation sexuelle, données bancaires complètes) ne soient envoyées au LLM. Avertissement visible au démarrage du chat.

Dans votre back-office PrestaShop : deux mesures.

Première mesure, un message d’avertissement au début du chat qui rappelle au visiteur de ne pas partager d’informations sensibles.

À copier-coller · Message d’avertissement chatbot

Bonjour 👋 Je suis l’assistant de [NOM DE VOTRE BOUTIQUE]. Je suis une intelligence artificielle, pas un humain, et je peux parfois me tromper. Pour votre sécurité, merci de ne pas me communiquer dans ce chat : votre numéro de carte bancaire complet, votre mot de passe, des informations médicales ou de santé, vos coordonnées bancaires, ou toute autre donnée sensible. Pour échanger avec un agent humain de notre équipe, tapez « agent humain » à tout moment. Pour toute demande sensible (remboursement, litige), nous vous redirigerons automatiquement vers un humain.

Deuxième mesure, un filtrage technique en amont si vous développez votre chatbot en custom. Un filtre regex qui détecte les patterns de numéros de CB (16 chiffres), de numéros de sécurité sociale, etc., et qui masque ces informations avant qu’elles partent vers l’API du LLM. Les chatbots clé en main sérieux le font nativement.

Référence : RGPD article 9 sur les données sensibles, CNIL fiches pratiques IA du 22 juillet 2025.

Sous-section B, Crawlers et agents IA (3 points)

Point 6.4, robots.txt configuré pour les IA

Énoncé : votre fichier robots.txt est configuré pour gérer le passage des crawlers IA, en distinguant deux cas : les crawlers de training (qui aspirent votre contenu pour entraîner les modèles, à bloquer par défaut) et les crawlers de retrieval (qui lisent votre contenu pour répondre en temps réel à un utilisateur, à autoriser car ils vous amènent du trafic).

Dans votre back-office PrestaShop : ce point concerne toutes les boutiques. Même celles qui n’utilisent aucune IA en interne. Pourquoi ? Parce que les crawlers IA, eux, viennent chez vous, que vous le vouliez ou non.

Le fichier à modifier c’est le robots.txt à la racine de votre domaine. Dans PrestaShop, il est généré automatiquement depuis le back-office (Paramètres de la boutique → Trafic → SEO & URLs → Générer le fichier robots.txt), mais le contenu par défaut ne gère pas du tout les crawlers IA. Il faut ajouter le bloc qui suit.

Un mot sur la logique avant de copier-coller. Il y a deux familles de crawlers IA. Les crawlers de training (GPTBot, ClaudeBot, CCBot, Bytespider, etc.) aspirent votre contenu pour entraîner les modèles. Ils ne vous amènent aucun trafic, ils prennent juste votre travail. À bloquer. Les crawlers de retrieval (ChatGPT-User, Claude-User, PerplexityBot, etc.) lisent votre contenu quand un utilisateur leur pose une question, et citent votre boutique dans leur réponse avec un lien. Ceux-là vous amènent du trafic de qualité. À autoriser.

Voici le bloc à ajouter en tête de votre robots.txt.

À copier-coller · Bloc IA pour robots.txt

# ========================================== # Crawlers IA de training (bloqués) # Opt-out TDM au titre de l’EU Copyright Directive # ========================================== User-agent: GPTBot Disallow: / User-agent: ClaudeBot Disallow: / User-agent: CCBot Disallow: / User-agent: Bytespider Disallow: / User-agent: Applebot-Extended Disallow: / User-agent: Google-Extended Disallow: / User-agent: FacebookBot Disallow: / User-agent: Amazonbot Disallow: / User-agent: DuckAssistBot Disallow: / User-agent: AI2Bot Disallow: / User-agent: Diffbot Disallow: / User-agent: PetalBot Disallow: / ========================================== Crawlers IA de retrieval (autorisés) Ils vous amènent du trafic depuis ChatGPT, Perplexity, etc. ========================================== User-agent: ChatGPT-User Allow: / User-agent: OAI-SearchBot Allow: / User-agent: Claude-User Allow: / User-agent: Claude-SearchBot Allow: / User-agent: PerplexityBot Allow: / User-agent: Perplexity-User Allow: / User-agent: Google-InspectionTool Allow: /

Cette configuration protège votre contenu contre l’aspiration massive par les modèles qui s’entraînent dessus (ils peuvent ensuite le régurgiter sans vous citer, ce qui se fait déjà à grande échelle), tout en vous gardant visible par les IA qui pointent leurs utilisateurs vers vous avec un lien. C’est une bonne balance entre protection et visibilité.

Référence : directive UE 2019/790 sur le droit d’auteur, article 4 sur le Text and Data Mining. Le TDM à but commercial sur des contenus protégés nécessite un opt-out explicite, qui peut prendre la forme du robots.txt selon la position CNIL et la jurisprudence émergente.

Point 6.5, Opt-out TDM au titre de l’EU Copyright Directive

Énoncé : en complément du robots.txt, une déclaration « machine-readable » d’opt-out TDM est exprimée dans les en-têtes HTTP de réponse ou dans un fichier .well-known/tdmrep.json.

Dans votre back-office PrestaShop : pour ajouter le header HTTP, modifier le fichier .htaccess à la racine.

À copier-coller · Header TDM dans .htaccess

# Opt-out TDM au titre de l’article 4 de la directive UE 2019/790 # À ajouter dans le .htaccess à la racine de votre boutique PrestaShop Header set tdm-reservation « 1 » Header set tdm-policy « https://votre-domaine.fr/tdm-policy.html »

Alternativement, créez un fichier .well-known/tdmrep.json à la racine.

À copier-coller · Fichier /.well-known/tdmrep.json

[ { « location »: « https://votre-domaine.fr/* », « tdm-reservation »: 1, « tdm-policy »: « https://votre-domaine.fr/tdm-policy.html » } ]

Point 6.6, Schema markup Product complet

Énoncé : le balisage Schema.org Product est complet sur toutes vos fiches produit. Ce n’est pas directement un point RGPD, mais c’est un point critique pour 2026, parce que les shopping agents IA (OpenAI Agent, Perplexity Comet, Google AI Mode) lisent votre schema markup, pas votre copy, pour décider quoi présenter à leur utilisateur et comment acheter.

Dans votre back-office PrestaShop : PrestaShop 8+ génère du Schema.org Product de base. Vérification à faire sur la search console de Google (Rapport sur l’amélioration → Produit), ou via le Rich Results Test (search.google.com/test/rich-results) sur une fiche produit type. Champs à cible sur chaque fiche : name, image, description, sku, brand, offers.price, offers.priceCurrency, offers.availability, aggregateRating, review.

Modules tiers PrestaShop qui complètent le schema natif : Structured Data Enhanced (Addons), JSON-LD for SEO, SEO Expert Pro. Coût : 50-150 € selon le module. Retour sur investissement probable en 2026 avec l’essor des shopping agents.

Référence : Morgan Stanley Research janvier 2025, 50 % des acheteurs devraient utiliser un agent IA pour leurs achats en ligne d’ici 2030.

Sous-section C, Préparation vente US (2 points)

Point 6.7, Mention si GenAI utilisé en back-office pour descriptions produits

Énoncé : si vous utilisez ChatGPT, Claude, Gemini ou autre IA générative pour rédiger vos fiches produits à partir des photos et textes de vos fournisseurs, vous vérifiez les droits de ces contenus sources.

Dans votre back-office PrestaShop : ce n’est pas un point RGPD direct, mais un point de vigilance IA générale. Deux situations à surveiller.

Première situation, vos photos produit. Si votre fournisseur vous envoie un kit produit (photos + descriptions) pour revendre, vérifiez dans votre contrat que vous avez bien le droit d’utiliser les photos sur votre boutique. Une IA qui regénère des images ne vous donne pas plus de droits que vous n’en aviez sur les originales.

Deuxième situation, vos descriptions. Si vous utilisez une IA pour reformuler les descriptions de votre fournisseur, vous êtes sur un terrain glissant si le fournisseur vous a concédé une licence d’utilisation mais pas de modification. Certains contrats le précisent explicitement. Vérifiez.

Point 6.8, Préparation CCPA/CPRA si vente aux US

Énoncé : si vous vendez aux États-Unis (même quelques commandes par mois), vous êtes potentiellement soumis au CCPA californien ou équivalents dans les autres États qui ont adopté des lois similaires.

Dans votre back-office PrestaShop : trois mesures si vous vendez aux US.

Première mesure, un bandeau cookies géo-ciblé. Pour les visiteurs européens, opt-in standard. Pour les visiteurs américains (détection par IP), opt-out avec lien « Do Not Sell or Share My Personal Information » bien visible. Les CMP commerciales (Sirdata, Cookiebot) le font nativement, les solutions plus simples comme Axeptio le permettent avec configuration.

Deuxième mesure, respect du signal Global Privacy Control (GPC). Si un navigateur envoie le header GPC, votre boutique doit automatiquement désactiver le « sale » et « share » des données (Meta Pixel, remarketing). Obligatoire en Californie depuis 2024, étendu à Indiana, Kentucky, Rhode Island depuis le 1er janvier 2026.

Troisième mesure, lien « Do Not Sell » en pied de page pour les visiteurs californiens. Avec un formulaire simple qui permet de se retirer en une étape (pas de compte à créer, pas de vérification complexe).

Référence : CCPA (2020), CPRA (amendement 2023), lois Indiana 2026, Kentucky 2026, Rhode Island 2026. Class actions CIPA par des cabinets comme Swigart Law Group contre les boutiques qui utilisent Meta Pixel ou session replay sans consentement valide. Indemnités entre 10 000 et 200 000 dollars par cas, ça se règle souvent à l’amiable.

Récapitulatif chapitre bonus. 8 points qui traitent des angles morts des audits RGPD traditionnels. Pour la plupart des TPE/PME PrestaShop, les points 6.4 (robots.txt), 6.6 (schema markup) et 6.8 (CCPA si vente US) sont les plus immédiatement actionnables. Les points chatbot (6.1-6.3) ne vous concernent que si vous utilisez effectivement une IA dans votre support client. Le point 6.5 (TDM) est du renforcement pour ceux qui veulent aller au bout de la logique d’opt-out.

Passer à l’action

Vous êtes arrivé au bout des 88 points. Si vous êtes encore là, chapeau, c’était dense.

Maintenant, qu’est-ce qu’on fait ?

Priorité 1, les 10 points critiques à traiter cette semaine

Ces 10 points sont les plus exposés en cas de contrôle CNIL, et ceux qui coûtent le moins d’efforts techniques à corriger. Commencez par eux.

Point 1.4, boutons « Accepter » et « Refuser » de même niveau sur votre bandeau cookies
Point 1.13, aucun cookie non essentiel avant consentement (test DevTools)
Point 2.12, durées de conservation précisées et cohérentes avec ce que vous faites vraiment
Point 4.1, consentement newsletter libre et case décochée
Point 4.4, aucune case pré-cochée nulle part
Point 5.1.2, HTTPS partout avec note ssllabs ≥ A
Point 5.6, 2FA activée sur tous les comptes admin
Point 5.30, hébergement en UE documenté
Point 6.4, robots.txt configuré pour les IA
Point 2.13-2.14, politique de confidentialité qui mentionne les droits et les moyens de les exercer

Priorité 2, les 20 points à traiter dans le mois

Les points qui demandent un peu plus de travail (rédiger des mentions, signer des DPA, mettre en place un tableau de suivi) mais qui sont tout aussi importants pour la solidité de votre conformité.

Points 1.2, 1.3, 1.5, 1.10, 1.12, 1.14 à 1.21 (reste du chapitre 1 sur la politique des cookies et les mentions), 2.1 à 2.16 (toute la politique de confidentialité), 3.1 à 3.5 (mentions sur les formulaires), 4.2 à 4.9 (reste du chapitre 4 sur la prospection). À programmer sur 4 semaines, un paquet de 5 points par semaine.

Priorité 3, le reste dans le trimestre

Les points techniques du chapitre 5 (hors les critiques déjà en priorité 1) et les points bonus IA. À faire en bloc avec votre hébergeur ou votre prestataire technique, typiquement en une ou deux demi-journées d’intervention.

Si vous préférez qu’on s’en occupe

Chez CYBERIAL, on accompagne 350 boutiques PrestaShop avec un forfait maintenance qui intègre la conformité RGPD dans le suivi continu. Audit initial, mise en conformité, veille réglementaire trimestrielle, correctifs au fil des évolutions. C’est le format le plus sain à long terme, parce que la conformité RGPD n’est pas un état permanent : vos outils changent, la réglementation évolue, les fournisseurs IA ajustent leurs conditions.

Si vous voulez juste un coup de main ponctuel pour corriger un point précis (bandeau cookies mal configuré, politique à réécrire, ps_emailsubscription à remplacer par Brevo), on a aussi un forfait dépannage à 150 € HT qui couvre la plupart des interventions standard.

Dans tous les cas, on est joignables 7 jours sur 7 au 09 72 03 59 17. Même le dimanche si une CNIL vous a contacté le vendredi soir.

Simulateur : Audit et score RGPD de votre boutique

Si vous n’avez pas encore testé le simulateur, voici les 88 points de ce guide, dans un format cochable, avec un score global, un score par chapitre, un graphique radar, et les 10 priorités identifiées automatiquement en fonction de vos réponses. Temps de réalisation, 5 à 10 minutes. Vos réponses sont sauvegardées dans votre navigateur, vous pouvez reprendre plus tard.

Simulateur RGPD PrestaShop · 88 points · CYBERIAL

SIMULATEUR RGPD PRESTASHOP

Auditez les 88 points légaux en 5 minutes · Gratuit et confidentiel

On a audité 150 boutiques PrestaShop ces trois dernières années. 78 % avaient au moins un écart majeur. Pas des détails. Des écarts qui, aujourd’hui, avec les sanctions 2025, exposent réellement le marchand.

Ce simulateur reprend exactement la méthode d’audit qu’on utilise chez CYBERIAL. Les 88 points issus des référentiels CNIL, ANSSI, et des évolutions IA 2026. Vous répondez « Oui · Partiel · Non · Non applicable » pour chacun. Le score se calcule en temps réel.

points

chapitres

5 min

en moyenne

Pour chaque point, 4 réponses possibles

Oui

En place, conforme

Partiel

À compléter

Non

Absent, critique

N/A

Non applicable

⚠️ Aucune donnée n’est envoyée sur un serveur. Tout est stocké localement dans votre navigateur. Vous pouvez reprendre plus tard.

💾 Audit précédent détecté : 0 points déjà répondus.

Progression 0 / 88

–

SCORE GLOBAL DE CONFORMITÉ

88 points audités · 88 applicables à votre boutique

—

SCORE PAR CHAPITRE 6 sections

⚠️ VOS 10 PRIORITÉS points critiques

ON PEUT S’EN OCCUPER POUR VOUS

Votre mise en conformité, en une intervention.

CYBERIAL accompagne 350 boutiques PrestaShop. Audit complet, mise en conformité, veille continue. Dépannage ponctuel disponible 7j/7.

Demander un audit → 📞 09 72 03 59 17

CYBERIAL · cyberial.fr · Agence PrestaShop Expert

Bon courage.

Sébastien LEROU

Co-fondateur de l'agence PrestaShop CYBERIAL. J'évolue depuis 15 ans dans le monde des sites internet et boutique en ligne open source.

A lire aussi

Voir tous les articles →

Article technique PrestaShop

PrestaShop n’envoie plus d’emails

Votre PrestaShop n'envoie plus d'emails ? Diagnostic et solution. Quelles sont les 10 causes les plus fréquentes, et comment les…

Lire l'article

Article technique PrestaShop

Boutique PrestaShop piratée

Boutique PrestaShop piratée : et si ça vous arrivait en ce moment sans que vous le sachiez ? Test en…

Lire l'article

Article technique PrestaShop

Nettoyer la base de données PrestaShop

Votre base PrestaShop fait plusieurs Go ? Tables à vider sans risque, pièges à éviter. Méthode testée sur 150+ boutiques.

Lire l'article

Article technique PrestaShop

Page blanche PrestaShop : la boutique n’affiche plus rien

Page blanche PrestaShop ? Front-office, back-office ou les deux : identifiez la cause exacte et remettez votre boutique en ligne…

Lire l'article

Article technique PrestaShop

IA & PrestaShop : ce qui marche sur une boutique

Recommandations, prix dynamiques, SAV automatisé, fiches produits générées… Le guide concret des applications IA sur PrestaShop, back et front office,…

Lire l'article

Article technique PrestaShop

PrestaShop lent : Diagnostic, Mesures et Optimisations

Un PrestaShop lent ? Avant d'optimiser, nous allons mesurer. Une méthode en 3 étapes pour identifier la vraie cause et…

Lire l'article