Jump to content

Module officiel RGPD gratuit 1.7 et payant 1.6 ?!


kokoon

Recommended Posts

Bon, je suis perdu.
Dans ses permissions j'ai coché tout ce qui est en rapport avec le RGPD mais ça ne change rien.

J'ai lu qu'on pouvait vider le cache de PS.
Ca se fait dans le BO ?
Dans "Performances" j'ai mis le cache sur non, ai enregistré et relancé mais toujours accès interdit. Je ne sais pas si c'est le bon cache.

Link to comment
Share on other sites

il y a 26 minutes, Sébastien Boureau a dit :

Hmm, j'ai du le créer alors (je ne m'en souviens plus).
Je vais switcher sur un des autres.

Sinon comme je disais au dessus : dans cette table ps_configuration je n'ai pas l'entrée GDPRCOMPLIANCY_EMPLOYEE ! oO

Euh... là c'est pas possible^^

Vous ne devez pas être sur la bonne table ou la bonne base.

Envoyez-moi un accès ftp au cas où...

Link to comment
Share on other sites

Il y a 2 heures, chafox a dit :

Bonsoir,

J'ai téléchargé l'archive blocknewsletter.zip, j'ai ajouté la ligne {hook h='displayGDPRConsent' mod='psgdpr' id_module=$id_module} dans le fichier tpl de mon template et activé la demande de consentement pour le bloc newsletter puis vidé les caches mais rien ne s'affiche (ni popup ni case à cocher).

Je suis un peu perdue, que puis-je faire de plus ?

Allez dans Modules -> Positions et accrochez le module blocknewsletter à ses nouveaux hook ;) 

Link to comment
Share on other sites

1 hour ago, Eolia said:

Allez dans Modules -> Positions et accrochez le module blocknewsletter à ses nouveaux hook ;) 

 

Merci,

Du coup le blocknewsletter est bien greffé à tout sauf à displayGDPRConsent mais je n'arrive pas à le greffer dessus car ce hook n'apparait pas dans la liste des hooks :

 

 

Capture d’écran 2018-05-29 à 22.04.38.png

Link to comment
Share on other sites

Eolia : si l'on désactive les modules Sendinblue et/ou Bloc Newsletter, est-il normal que dans l'onglet "Contrôle & gestion" ces deux modules apparaissent toujours ?

Il est demandé de mettre à jour les modules affichés comme incompatibles mais j'en ai certains dont la mise à jour ne fonctionne pas !
Ils restent en alerte "Nécessite une mise à jour".

Vous avez déjà eu ça ?

Link to comment
Share on other sites

2 minutes ago, doekia said:

Les modules payant addons ne peuvent être mis à jour que si tu es connecté addons et que le flux addons est présent sur ton compte (dépend des modules)

Merci pour la réponse.
Là ça concerne Systempay et Expertise PrestaShop.
Systempay je ne sais plus comment je l'ai eu. Il est payant mais peut-être que ma cliente l'a eu avec sa banque.
L'autre c'est clairement un module natif !

Donc je ne pense pas que ça provienne d'un compte addon (je ne pense pas en avoir un d'ailleurs).

Link to comment
Share on other sites

Il y a 10 heures, chafox a dit :

 

Merci,

Du coup le blocknewsletter est bien greffé à tout sauf à displayGDPRConsent mais je n'arrive pas à le greffer dessus car ce hook n'apparait pas dans la liste des hooks :

 

 

Capture d’écran 2018-05-29 à 22.04.38.png

Non display est uniquement dans le tpl (système made by Prestashop^^)

Link to comment
Share on other sites

il y a 50 minutes, Sébastien Boureau a dit :

Eolia : si l'on désactive les modules Sendinblue et/ou Bloc Newsletter, est-il normal que dans l'onglet "Contrôle & gestion" ces deux modules apparaissent toujours ?

Il est demandé de mettre à jour les modules affichés comme incompatibles mais j'en ai certains dont la mise à jour ne fonctionne pas !
Ils restent en alerte "Nécessite une mise à jour".

Vous avez déjà eu ça ?

 

Oui car ils sont toujours chargés par Prestashop (même inactifs) Si vous ne voulez plus les voir, désinstallez-les complètement.

Pour l'autre question cela dépend de la configuration de votre boutique, du module concerné et de votre configuration serveur.

Link to comment
Share on other sites

4 minutes ago, krokus said:

Bonjour, 1er installation impeccable tout fonctionne, 1ere mise à jour " Accès interdit ! Veuillez contacter le responsable RGPD "  ok pas grave, 2eme mise à jour problème droit d'accès au module résolu mais plus d'affichage du pop up d'acceptation de confidentialité, ok bon je désinstalle et supprime le module et le reinstalle dans sa dernière version + vidage cache etc, 1ere surprise la base de donnée liée au module n'a pas été supprimée, 2 éme surprise cela ne fonctionne toujours pas. Alors la je ne sais plus quoi faire.

Regarde l'entrée GDPRCOMPLIANCY_EMPLOYEE  de la table ps_configuration.

Si la valeur est à 0, modifie la à 1 et vois si cela fonctionne.

Link to comment
Share on other sites

Il y a en effet eu 2 coquilles successives lors de la seconde mise à jour.

Veuillez re-télécharger la dernière version en cours svp (1.9.2) dans votre onglet Modules puis retournez dans le module lui-même.

C'est normal lors de la désinstallation que les tables ne soient pas vidées car vous perdriez tout votre historique et ca poserait problème en cas de contrôle et également pour les clients qui ont déjà donné leur accord.

Link to comment
Share on other sites

Je rencontre un autre soucis avec MailAlert, si la case Afficher dans le Bouton du produit est coché, j'obtiens l'erreur ci-dessous :


Fatal error: Uncaught --> Smarty Compiler: Syntax error in template "/var/www/vhosts/...fr/modules/mailalerts/views/templates/hook/button.tpl" on line 14 "{addJsDef mailalerts_url_check=$link->getModuleLink('mailalerts', 'actions', ['process' => 'check','key' => $key]])}" - Unexpected "]", expected one of: "","" , ")" <-- thrown in /var/www/vhosts/....fr/tools/smarty/sysplugins/smarty_internal_templatecompilerbase.php on line 14

Si je décoche la case, cela fonctionne mais plus d'accès au bouton AlertMail sur la page produit, la version du module installée est celle d'Eolia en page 6, que faire ?

Le module apparait bien dans le module RGPD

 

Capture d’écran 2018-05-30 à 10.33.51.png

Link to comment
Share on other sites

il y a 23 minutes, krokus a dit :

je viens de m'apercevoir que dans la liste des modules compatible il devrait y avoir celui d'eolia "RGPD", il a disparu

 

rgpd.jpg

Bonjour,

Pouvez-vous m'envoyer un accès ftp en MP ou par mail ?

Link to comment
Share on other sites

3 minutes ago, Eolia said:

Voici les 2 zips mis à jour avec la méthode d'upgrade automatique

blocknewsletter-rgpd.zip

mailalerts-rgpd.zip

Il faut qu'on supprime et remplace ces 2 modules par ceux-là ?
Mon client n'utilise pas le module Newsletter mais mailalerts est activé. Il est reconnu comme RGPD. Que fait celui que vous proposez en lien ?

Edited by Sébastien Boureau (see edit history)
Link to comment
Share on other sites

il y a 33 minutes, krokus a dit :

ok message envoyé par la page contact eolia shop

 

réparé.

Je remarque que certaines configurations de shop ont des soucis pour les mises à jour automatiques, je vais voir à intégrer ma propre méthode.

Link to comment
Share on other sites

il y a 29 minutes, Sébastien Boureau a dit :

Il faut qu'on supprime et remplace ces 2 modules par ceux-là ?
Mon client n'utilise pas le module Newsletter mais mailalerts est activé. Il est reconnu comme RGPD. Que fait celui que vous proposez en lien ?

 

Bah ne remplacez que celui que vous utilisez.

Cette version permet un export propre des données.

Link to comment
Share on other sites

Bonjour,

Je viens d'installer ce module pour test dans mon environnement de dév.

Un petit retour de bug pour Eolia, sous Windows:

Dans le template menu.tpl, ligne 67, remplacer

var ad = "{/literal}{$ad|escape:'htmlall':'UTF-8'}{literal}";

par

var ad = "{/literal}{$ad|escape:'javascript':'UTF-8'}{literal}";

Ceci pour tenir compte des '\' dans le chemin absolu vers le répertoire admin.

Cette correction est peut-être à faire ailleurs.

 

Je continue mes tests

Link to comment
Share on other sites

5 hours ago, Eolia said:

Non display est uniquement dans le tpl (système made by Prestashop^^)

 

OK.

Du coup, j'ai fait un test pour voir si le hook fonctionne dans le blocknewsletter.tpl avec le code ci-dessous dans ce tpl.

Apparemment j'ai OUI qui s'affiche donc le hook est ok mais rien ne s'affiche. Je désespère.

{assign var='displayGDPRConsent' value={hook h='displayGDPRConsent[spam-filter]
{if $displayGDPRConsent}
  {$displayGDPRConsent}
OUI
{else}
NO
{/if}

Edited by chafox (see edit history)
Link to comment
Share on other sites

Il y a 4 heures, phf64 a dit :

Bonjour,

Je viens d'installer ce module pour test dans mon environnement de dév.

Un petit retour de bug pour Eolia, sous Windows:

Dans le template menu.tpl, ligne 67, remplacer

var ad = "{/literal}{$ad|escape:'htmlall':'UTF-8'}{literal}";

par

var ad = "{/literal}{$ad|escape:'javascript':'UTF-8'}{literal}";

Ceci pour tenir compte des '\' dans le chemin absolu vers le répertoire admin.

Cette correction est peut-être à faire ailleurs.

 

Je continue mes tests

Thanks^^

Non à priori c'est le seul chemin relatif (requis par tiny_mce)

Link to comment
Share on other sites

6 hours ago, Eolia said:

Voici les 2 zips mis à jour avec la méthode d'upgrade automatique

blocknewsletter-rgpd.zip

mailalerts-rgpd.zip

 

J'arrive toujours pas a voir le message de consentement.

J'ai regardé au niveau du module de newsletter et il n'y a plus le hook

{hook h='displayGDPRConsent' mod='psgdpr' id_module=$id_module}

normal ?

 

Edited by DaveHorizon (see edit history)
Link to comment
Share on other sites

Bonjour,

j'ai fais un peu de debug sur ton module

        $id_customer = $this->context->customer->id;
        $id_guest = $this->context->cookie->id_guest;
        $id_lang = $this->context->language->id;
        $id_module = (int)$params['id_module'];
        
        echo '<pre>';
        echo 'id_customer = ' . $id_customer . PHP_EOL; // Vide
        echo 'id_guest = ' . $id_guest . PHP_EOL; // Vide
        echo 'id_module = ' . $id_module . PHP_EOL; // OK
        echo 'Message';
        print_r(GdprCompliancyCompliant::getHtml($id_module, $id_lang, $this->id, $this->context->shop->id)); // Ok, MessageArray
        //print_r($this->context->cookie);
        echo '</pre>';
        
		
		if(!$id_customer && !$id_guest) {
			//return;
			echo 'condition 1'; // S'affiche donc ça ne va pas plus loin
		}
        if (!$id_module || !$messages = GdprCompliancyCompliant::getHtml($id_module, $id_lang, $this->id, $this->context->shop->id)) {
            //return;
            echo 'condition 2'; // Toujours faux
        }
		if(count($messages) < 2){
			//return;
			echo 'condition 3'; // Ok
		}

En clair quand je ne suis pas connecté, je n'ai rien dans $id_guest et donc le message ne s'affiche pas.

Si je crée un panier par contre cela fonctionne et logiquement aussi quand je suis connecté.

 

 

Link to comment
Share on other sites

Oui, j'ai vu ça hier en intervenant sur plusieurs sites^^

L'archive a été mise à jour, il suffit de supprimer cette ligne:

if(!$id_customer && !$id_guest) {
	return;
}

La version 1.9.3 ne va pas tarder à sortir ;) 

Link to comment
Share on other sites

Un grand MERCI à Eolia pour sa patience, sa gentillesse, sa disponibilité et son savoir-faire et qui à cause de moi prend ses repas à des heures décalées (désolé ;))

Le module RGPD remplit toutes ses fonctions à merveille sur ma 1.6 !

Voilà, de temps en temps il faut savoir afficher sa reconnaissance !

Ce n'est certainement pas avec le sav prestashop que cela serait arrivé, croyez-en mon expérience personnelle en la matière.

  • Like 1
Link to comment
Share on other sites

On 18/05/2018 at 5:59 PM, Twistix said:

Tout ce foin pour la RGPD ... désolé de casser l'ambiance mais il faut s'appuyer sur les leaders pour se rendre compte qu'ils n'iront certainement pas aussi loin que vous pour mettre en conformité leur site le 25 Mai 2018 à moins que vous cherchiez absolument à affoler la population pour vendre des trucs derrière !

1) Art. 32 et les cases à cocher = c'est une recommandation, un exemple !!! IL suffit d'insérer dans votre TPL avant le bouton SUBMIT sur chaque formulaire un exemple de  phrase (ci-dessous) pour être totalement conforme !

EXEMPLE DANS LE FORMULAIRE
[Texte] En cliquant sur le bouton, j'accepte les conditions générales ainsi que la collecte de mes données personnelles [/Texte]
[BOUTON]
Puis en dessous du bouton de répéter une phrase personnalisée mais obligatoire du genre
[Texte]
XXXXX est responsable de la collecte et du traitement des données personnelles. Les informations sécurisées recueillies font l’objet d'un traitement informatique destiné à l'enregistrement volontaire d'une adresse e-mail vous permettant de communiquer par messagerie / OU / Les informations sécurisées recueillies font l’objet d'un traitement informatique destiné à la gestion de votre compte. Le destinataire des données est le service technique de XXXXXX

Conformément à la loi "informatique et libertés" du 6 Janv. 1978 modifiée en 2004, vous bénéficiez d’un droit d’accès et de rectification aux informations qui vous concernent, que vous pouvez exercer en vous adressant à tout moment et par tous moyens, notamment par courrier postal à l'adresse suivante : XXXX | "Données personnelles" XXXX | Adresse - CP VILLE et par mail à l'adresse suivante : contact [at] blablabla.prout
Vous pouvez, pour des motifs légitimes, vous opposer au traitement des données vous concernant.
[/Texte]
 

A côté de ça vous reprenez vos conditions générales d'utilisation que vous blindez

Vous créez une nouvelle page CMS "Données Personnelles"
> La dedans vous allez devoir rédiger toutes les recommandations de la directive (pompez celles d'un site grand public et adaptez les) + la Gestion des Cookies + vous ne vous faites pas chier à créer un module de gestion de Cookies ça existe déjà !!!
[Texte]
Refuser ou supprimer un Cookie de mesure d’audience

Si vous ne souhaitez pas que notre site enregistre des Cookies dans votre navigateur à des fins de mesure d’audience, vous pouvez cliquer sur les liens de désactivation suivants qui enregistreront au sein de votre navigateur un Cookie ayant pour unique objet de les désactiver :
Google Analytics : https://tools.google.com/dlpage/gaoptout?hl=fr
[/Texte]

Pour les autres cookies il va falloir faire preuve de pédagogie et les informer comment les désactiver avec chaque navigateur et/ou les diriger vers les liens des sites officiels POINT

Concernant les mentions légales, idem vous les reprenez et veillez bien à identifier les informations de votre boite + le nom du responsable de publication + d'ajouter ou le site est hébergé etc etc....

Concernant la compta, je crois rêver ??? Vous devez les télécharger en local sur vos terminaux pour les conserver donc imprimez les, c'est les documents papiers qui seront contrôlés pas une boutique en production bande de bananes !!! Les contrôles fiscaux se font comme ça hein, vous allez pas créer un compte superadmin à un de ces vainqueurs qui viendra vous contrôler ...

Il ne reste plus qu'à adapter une chose essentielle, vielliez à bien déterminer dans vos CGU ce principe simple :
[TEXTE]

Conformément à la loi Informatique et Libertés en date du 6 janvier 1978 telle que modifiée en 2004, vous disposez d'un droit d'accès, de rectification, d’opposition et de suppression concernant vos données personnelles.

Vous pouvez exercer ces droits à tout moment et par tous moyens, notamment par courrier postal à l'adresse suivante :
VOS COORDS..........
La demande doit être obligatoirement accompagnée d'une photocopie d'une pièce d'identité conforme et valide.
Conformément à la loi, votre demande sera traitée dans un délais maximum de 1 mois suivant réception.
Nous vous rappelons que les demandes abusives sont punies par la loi.

[/TEXTE]

Vous aurez ainsi 1 mois pour remettre les données de vos Utilisateurs/Membres/Clients et d'effacer leurs données personnelles

Pourquoi faire compliqué ?? Dès le début de cette publication ça parlait d'intégration TPL + un peu de JS, moi j'ajouterai juste de créer un document CMS bien fourni et vous êtes conforme + un bandeau TOP à l'ouverture du site, la phrase bien conventionnelle + lien vers la page "données personnelles" + "cgu" et c'est torché !!!

Encore un truc, veillez plutôt à passer vos boutiques en https car la fuite de données est bien plus sanctionnée qu'un choix de caser à cocher/pas

a+++

@Twistix Merci pour tes explications sur ton interprétation du RGPD. Effectivement, je me demandais s'il était vraiment obligatoire de demander sur chaque formulaire le recueil du consentement au traitement de données. Après avoir regardé ce que font actuellement les gros sites comme La Redoute et m'être renseignée auprès de juristes et ici et là, j'en arrive à la même conclusion que toi : le consentement n'est pas nécessaire partout. Seule les informations sur le traitement des données l'est. 

En bref, si le client veut passer commande maintenant ou plus tard (formulaire de création de compte), le traitement des données est considéré comme licite. De même lorsqu'un client s'inscrit à une newsletter ou demande à être informé du retour d'un produit. a mon sens on est bien sur la base légale n°1 => les données (nom/prénom/adresse/tel/mail) sont nécessaires à l'exécution du contrat. 

En revanche, si on utilise les données pour d'autres fins (notamment envoyer une newsletter à un client qui a créé un compte ou juste demandé d'être informé du retour produit), là il faut demander son consentement. En d'autres termes, s'il est ok pour recevoir de la prospection commerciale. 


Si on a une case à cocher "abo newsletter" dans la création de compte, alors on a recueilli le consentement. Sur mailalert, là par contre, il faudrait prévoir une case à cocher supplémentaire "voulez-vous être aussi informé des promos,etc...". Sur Newsletter, ben il demande à être informé des promos :-)

Il faut prévoir cependant l'info sur les données personnelles à chaque fois (au moment où il inscrit son mail pour la newsletter, il doit y avoir un petit texte expliquant rapidement le traitement des données et renvoyant vers la pages CMS Politique de Confidentialité).

Voilà pour ma contribution au topic et au sujet épineux RGPD. 

Quel est votre avis ?

 

Edited by LiliB. (see edit history)
Link to comment
Share on other sites

Bonjour Eolia, 

J'avais compris que ton module insérait une pop up avec case à cocher ? Je l'ai vu actif sur un site et j'ai vu des pop-up partout. Quand j'ai voulu créer un simple compte client, paf pop-up "acceptez notre politique de confidentialité". Pour ma part, je considère que ce n'est pas obligatoire.

Y-a-t-il d'autres fonctionnalités dans ton module qui m'auraient échappé ? Comme le fait de choisir ou non de mettre une pop-up en création de compte.
 

Link to comment
Share on other sites

Bonsoir,

Alors j'ai tenté une nouvelle fois la mise à jour et de nouveau, tout disparait.
C'est d'autant plus gênant que je suis aussi agacée par trop de popup sur de nombreuses pages, de contact au blog.
ça fait trop et je voudrais alléger le site pour arrêter de faire fuir des clients!

Une idée de ce qui cloche puisque la version 1.8.8 fonctionne sans souci ?

Link to comment
Share on other sites

20 hours ago, LiliB. said:

@Twistix Merci pour tes explications sur ton interprétation du RGPD. Effectivement, je me demandais s'il était vraiment obligatoire de demander sur chaque formulaire le recueil du consentement au traitement de données. Après avoir regardé ce que font actuellement les gros sites comme La Redoute et m'être renseignée auprès de juristes et ici et là, j'en arrive à la même conclusion que toi : le consentement n'est pas nécessaire partout. Seule les informations sur le traitement des données l'est. 

En bref, si le client veut passer commande maintenant ou plus tard (formulaire de création de compte), le traitement des données est considéré comme licite. De même lorsqu'un client s'inscrit à une newsletter ou demande à être informé du retour d'un produit. a mon sens on est bien sur la base légale n°1 => les données (nom/prénom/adresse/tel/mail) sont nécessaires à l'exécution du contrat. 

En revanche, si on utilise les données pour d'autres fins (notamment envoyer une newsletter à un client qui a créé un compte ou juste demandé d'être informé du retour produit), là il faut demander son consentement. En d'autres termes, s'il est ok pour recevoir de la prospection commerciale. 


Si on a une case à cocher "abo newsletter" dans la création de compte, alors on a recueilli le consentement. Sur mailalert, là par contre, il faudrait prévoir une case à cocher supplémentaire "voulez-vous être aussi informé des promos,etc...". Sur Newsletter, ben il demande à être informé des promos :-)

Il faut prévoir cependant l'info sur les données personnelles à chaque fois (au moment où il inscrit son mail pour la newsletter, il doit y avoir un petit texte expliquant rapidement le traitement des données et renvoyant vers la pages CMS Politique de Confidentialité).

Voilà pour ma contribution au topic et au sujet épineux RGPD. 

Quel est votre avis ?

 

 

Il faut demander le consentement pour chaque formulaire où l'utilisateur envoie des données personnelles et le fait de remplir un formulaire n'est pas suffisant en soit, c'est ce qu'on faisait avant. Il faut un consentement explicite avec une phrase claire et case à cocher pour chacun des différents traitement.

Je suppose qu'on peut obtenir un consentement plus global si, par exemple, on utilise un système de commentaire ou autre tâche répétitive telles qu'acheter des produits mais ça ne dispense pas qu'il faut tout de même l'accord du visiteur. Et je n'en suis pas certain car lorsque l'on paye sur un e-commerce, on valide normalement les conditions d'utilisation à chaque fois.

Je pense que tout le monde est loin d'être dans les clous car cela demande beaucoup d'adaptation au niveau du code et du rédactionnel (sans parler du jargon juridique, au secours). Sans parler de la complexité voir impossibilité de mettre ça en place correctement avec les différents CMS, modules ou plugins.

 

 

Edited by DaveHorizon (see edit history)
Link to comment
Share on other sites

Bonjour DaveHorizon, 

Justement je ne suis pas d'accord : il n'est pas utile de demander le consentement pour chaque formulaire de données. C'est ce que j'expliquais : si le client veut passer commande, nous avons besoin de ses coordonnées pour exécuter notre contrat. Donc, ça ne fait pas partie de la base légale 6 (consentement). et le consentement avec case à cocher n'est pas requis. En revanche si on veut utiliser ses données pour autre chose (lui envoyer de la pub par exemple), là oui. Mais ça on le faisait déjà : la majorité des sites avaient la case Newsletter avant le RGPD. Ou si tu lui demande des données qui ne sont pas nécessaires au traitement de sa commande (sa date de naissance par exemple).

En revanche il faut lui indiquer clairement que nous conservons et traitons ses données. Donc il faut ajouter un peu de texte sur tous les formulaires avec un lien vers la page CMS détaillée sur notre politique de confidentialité. Je suis d'accord avec Twistix qui en parlait plus haut.

Quant au consentement général, j'ai des doutes car le texte parle de consentement pour chaque finalité de traitement (donc une case à cocher pour la newsletter, une case à cocher pour la pub de partenaires, etc...). 

https://www.august-debouzy.com/fr/blog/1037-rgpd-et-bases-legales-de-traitement-la-place-du-consentement

http://dpo-consulting.fr/rgpd-marketing-gerer-consentement/

  • Like 1
Link to comment
Share on other sites

Salut !
Nous avons tous avec cette RGPD deux missions à réaliser ; un plan d'action technique ainsi qu'une mission d'information obligatoire.

Côté : Plan d'action technique

1) Le module d'Eolia ( l'approche technique) qui répond certainement plus qu'aux exigences imposées par la RGPD et tant mieux.  C'est aussi pour ça que j'ai suivi Eolia avec son module, pour garantir sereinement côté client ce passage, diminuer les risques de non conformité et pour  profiter de ce gain de temps afin de me focaliser sur la partie information. (cgu, charte ...)

2) Vous pouvez très bien ne rien installer, aucun module et garantir cette conformité en bidouillant votre site, en avertissant sur votre formulaire avant soumission qu'en poursuivant " j'accepte les conditions générales ainsi que la collecte de mes données personnelles " y a absolument rien qui vous en empêche, rien qui vous l'oblige.

La RGPD c'est pas QUE la gestion des cookies, des Formulaires, c'est la transparence des données personnelles, de son cheminement de son traitement et c'est là qu'il faut être transparent avec ses Utilisateurs. C'est pas en verrouillant avec un checkbox qu'on garanti la transparence mais bien en inscrivant clairement ce qu'on recueille et comment c'est exploité sans omettre d'indiquer le texte du droit d'accès...

Ceci dit on va pas reprendre toute la RGPD mais ce sont des sites marchands et là ou ça devient compliqué c'est bien la partie "je veux voir, modifier ou supprimer mes données" alors OUI la RGPD n'impose à personne de mettre ça en pratique techniquement sur son site, un simple courrier en LAR et une pièce d'identité peuvent très bien garantir ce droit. L'ennui c'est que sur un site marchand on est censé (je vous le souhaite) avoir des milliers de clients donc c'est juste ingérable et ça couterai trop cher comme solution. Sur un site pro autre que marchand là OUI sans aucun soucis !

Côté : Mission d'information/ communication

Nous avons tous lu et relu et relululu les recommandations de la CNIL ainsi que la règlementation complète (en allant aux WC ou autre) .
Fondamentalement qu'est ce qu'on nous demande ? De la transparence, Pourquoi ? Parce qu'avant certaines entreprises détournaient des infos sans aucun consentement et c'est justement là que la RGPD intervient.

Bon, il est clair que sur ce forum on s'oriente sur la partie technique (ici c'est la thématique) néanmoins, étant DPD moi même pour mes clients cela m'a permis d'affiner encore plus ma connaissance sur la RGPD et objectivement même si la plupart des sites sont conformes techniquement, il faut s'intéresser à l'approche interne en entreprise pour en comprendre et appréhender encore mieux les mécanismes, parce que côté web c'est FLOU en revanche côté registre tout est CLAIR ! Il suffit d'en voir un exemple ici : https://www.cnil.fr/sites/default/files/atoms/files/registre_rgpd_basique.pdf

Pour faire court, il faudrait dans l'absolu soigner ses conditions générales, créer une charte de confidentialité en reprenant pourquoi pas la base des registres, la partie sécurité est bien trop souvent négligée sur les sites internet, appuyez vous sur le registre papier qui lui est clair et fait parti de la RGPD il vous permettra de ne pas vous disperser quand vous rédigerez vos pages cms et en plus il a le mérite de suivre une ligne directrice cohérente.

Voilà mon avis et c'est ce que je fais pour tous mes clients

 


 

Edited by Twistix (see edit history)
  • Like 3
Link to comment
Share on other sites

Ah oui autre chose, et je vais être hors sujet pour pas changer, vous pouvez tous être DPD. C'est je pense une opportunité qu'offre la RGPD, hors moi j'ai un gros coup de gueule à passer la dessus car à ce jour on veut donner ce rôle de délégué à des avocats, des juristes etc ce qui est très bien côté juridique en revanche côté technique ils sont totalement à la ramasse alors si vous prenez le temps de mieux connaitre la RGPD que vous êtes plutôt bon comme technicien que vous possédez un sens aigu de l'organisation et que vous pouvez contribuer dans les entreprises, faites le, c'est dans la continuité de ce que vous faites ici pour vos clients

Edited by Twistix (see edit history)
Link to comment
Share on other sites

Pour ceux qui ont du temps à perdre, n'hésitez pas à demander à Prestashop la mise en conformité des modules natifs suivants:

- blocknewsletter

- blockfacebook

- blocksharefb

- blocksocial

- blockwishlist

- favoriteproducts

- loyalty

- mailalerts

- productcomments

- refferalprogram

- socialsharing

 

Et pour rappel, depuis le 25 mai, la fonctionnalité "Comptes invités" (commander sans créer de compte) est illégale car le "client" ne peut pas se connecter à son compte ni avoir accès à ses données personnelles.

La différence entre un compte invité et un compte normal, c'est juste le mot de passe^^

Edited by Eolia (see edit history)
  • Like 5
Link to comment
Share on other sites

3 minutes ago, Eolia said:

Et pour rappel, depuis le 25 mai, la fonctionnalité "Comptes invités" (commander sans créer de compte) est illégale car le "client" ne peut pas se connecter à son compte ni avoir accès à ses données personnelles.

La différence entre un compte invité et un compte normal, c'est juste le mot de passe^^

Très pertinent ! J'en ai fais aucune mention merci !

Link to comment
Share on other sites

Merci @Twistix pour ce complément d'infos. J'avoue qu'entre les interprétations des uns et d'autres sur les formulaires et la RGPD, je commence à m'y perdre et je doute de ce qui est pertinent de faire. @DaveHorizon Sur les fiches de la CNIL, je n'ai rien vu sur le consentement implicite et tu vois qu'entre ta source et la mienne, les interprétations divergent. Mais j'ai bien vu les bases légales au nombre de 6 (c'est une juriste qui m'en a parlé)  et cette info ici : https://www.cnil.fr/fr/respecter-les-droits-des-personnes
 

"Le consentement préalable de la personne concernée est notamment requis :

En cas de collecte de données sensibles

De réutilisation des données à d’autres fins

D'utilisation de cookies pour certaines finalités  

D'utilisation des données à des fins de prospection commerciale par voie électronique"

Dans tous les cas, il faut comme le dit Twistix être transparent (page de Politique de confidentialité, info préalable à la collecte de données...) et surtout penser sécurité du site et ne plus abuser des adresses mails pour noyer les clients de Newsletter. 

Pour l'instant c'est ce qu'ont fait les très gros sites (La Redoute, Leroy Merlin...) et je pense qu'ils ont des juristes qui ont pensé le truc. 
De toutes façons, comme ça reste en core flou (la preuve, les différents points de vue sur la question des formulaires), je pense qu'on aura d'ici quelques semaines des éclaircissements par la CNIL. 

Il est d'ailleurs intéressant d'aller sur leur site et de s'inscrire à la newsletter : pas de case à cocher obligatoire et une simple info sur l'utilisation de la donnée et la possibilité de se désabonner à tout moment...

Link to comment
Share on other sites

Et côté modules, je pense que le plus important est d'avoir des outils qui gèrent l'extraction, la diffusion et la suppression très facilement et simplement. 
Moi, je suis un petit site, donc je peux le faire mais pour les très gros effectivement, ce sera du temps de gagner c'est sûr ! Et le module d'Eolia fait tout ça :-) (en plus y'a un SAV top)

Link to comment
Share on other sites

J'ai commencé ma lecture par le site de la cnil il y a quelques jours et j'ai pas trouvé ça hyper clair. Pour certains articles on sait pas vraiment si c'est antérieur ou si cela concerne RGPD et on ne comprend pas ce qu'il faut faire concrètement. Je pense que tout ça va se formaliser à l'usage et on va prendre l'habitude de faire les choses correctement dans le futur.

J'ai pas trop exploré les sites e-commerces ces derniers temps mais à mon avis très peu sont réellement dans les clous. Sur prestashop, on devrait proposer au client de conserver son adresse hors là c'est obligatoire lorsque l'on crée un compte. Après il y a un formulaire commun entre adresse de facturation et livraison dans prestashop mais normalement on devrait avoir un case si l'on souhaite voir conserver son adresse pour les futures livraisons. Bref, c'est beaucoup de choses à vérifier et c'est toute la problématique des solutions à base de CMS surtout lorsque l'éditeur n'a pas la volonté / ne met pas les moyens pour rendre les choses conforme.

 

Link to comment
Share on other sites

Justement, l’interprétation et le besoin de faire le buzz voir du putaclic de certains sites vont vous embrouiller et côté technique le module d'Eolia pallie à toutes les objections. Nous n'en sommes plus à devoir faire des choix, ce module réuni franchement tout. Si Prestashop addon avait du faire le même module ainsi que tous les ptits plus à côté qu'offre le module RGPD d'Eolia sans surcout, la plateforme aurait certainement créer d'autres modules complémentaires pour faire du fric. Nous n'en sommes plus à devoir faire des choix, prenez ce module qui profite d'un vrai suivi régulier et blindez vos documents en suivant les recommandations mais directement de la CNIL

Link to comment
Share on other sites

il y a 24 minutes, tresorsdargan a dit :

J'avais déjà évoqué la question de la commande en "Comptes invités" resté sans réponse, cependant, est il judicieux de le conserver ?

 

Certainement pas, c'est interdit !

Comment le client accède-t-il à ses données ? Comment peut-il les modifier ou supprimer son compte ?

Bon, ok, il croit naïvement qu'il n'a pas de compte, sauf que celui-ci existe réellement.

Link to comment
Share on other sites

Je suis bien d'accord que la différence entre un vrai compte et un compte invité, ça n'est jamais qu'un mot de passe.

L'intérêt jusqu'ici était donc surtout psychologique... le client pouvait en effet croire naïvement que ses données n'étaient pas enregistrées.

Mais de là à dire que c'est devenu illégal avec le RGPD, sincèrement, je ne crois pas.

D'après moi la seule différence à présent c'est que désormais le client ne doit justement plus croire naïvement que ses données ne sont pas enregistrées. D'où l'intérêt des popin et autres cases à cocher lui signifiant ce qu'on va faire de ses données et pendant combien de temps...

En ce qui concerne l'accès, la modification ou la suppression des données d'un tel compte invité, bah à priori rien ne nous oblige à ce que tout ceci soit accessible en live et sans intervention humaine côté marchand, en effet, on a 1 mois pour réagir. Je dirais en fait qu'il faut plutôt comprendre "droit d'accès" par "droit de savoir".

D'ailleurs le garagiste du coin va (peut-être ^^) vous faire une facture, mais il va pas vous donner accès à un compte personnel en ligne...

Au passage quelques liens :

Un site franchement bien structuré façon checklist et très complet, but in english :

https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-of-access/

Une version assez claire en français à ce sujet (site belge, équivalent CNIL en quelque sorte) :

https://www.autoriteprotectiondonnees.be/droit-dacceder-a-vos-donnees-art-15-rgpd

 

Ceci étant dit, est-ce qu'il y a du coup encore un intérêt aux comptes invités ?

Je dirais moins qu'avant, mais sans doute encore un peu... disons que ça reste utile tant que les clients penseront que c'est mieux pour quelque raison que ce soit... (genre allergie aux mots de passe ^^)

Link to comment
Share on other sites

ok...

- Comment allez-vous procéder à l'export de toutes les données de ce client s'il vous le demande ?

- Comment allez-vous anonymiser son compte ?

- Comment allez-vous récupérer ses consentements dans le registre ? (pas d'id_customer commun donc impossible de prouver que ce client a donné son consentement pour telle action) 

- ce même client ayant la possibilité de créer x comptes avec x adresses e-mail (identiques ou pas) comment allez-vous les identifier ?

Link to comment
Share on other sites

Attention que je parle dans l'absolu. Je n'ai pas dit que c'était nécessairement simple ni qu'un module existait déjà pour réaliser les tâches...

Mais techniquement je ne vois pas en quoi ce serait insurmontable.

Le guest passe sa commande avec une adresse email donc ça me semble être une base suffisante pour l'identifier et extraire (ou anonymiser) ses informations (on obtiendrait une liste de x clients avec x adresses et x commandes)

Pareil pour ses consentements, on peut très bien les enregistrer sur base de son email, à chaque commande ou "inscription" du coup. Ca ne fait pas une grosse différence avec un simple formulaire de contact qui restera de toute façon utilisable aussi bien par les visiteurs que par les clients enregistrés.

D'ailleurs, une bonne chose quand même avec un compte guest, c'est que ses données sont limitées et s'éparpillent donc moins dans différents modules (pas de favoris, pas de fidélité, pas de programme d'affiliation, ...).

4 hours ago, Eolia said:

- ce même client ayant la possibilité de créer x comptes avec x adresses e-mail (identiques ou pas) comment allez-vous les identifier ?

 

Il faut bien que le client s'identifie auprès du marchand d'une manière ou d'une autre. Donc s'il a passé commande en guest avec x adresses email différentes, à lui de les fournir. Au même titre qu'il pourrait très bien avoir créé x vrais comptes avec des adresses email différentes.

 

En fait, on pourrait même pousser un peu plus loin et donner au compte guest un réel intérêt pour le client.

On pourrait en effet imaginer :

- un nettoyage régulier des comptes invités sans commande (pas besoin de les conserver, donc toutes les semaines ou tous les mois, poubelle)

- une suppression ou anonymisation automatique des données en ligne sur une période relativement courte. Tous les 3 mois, 6 mois, 1 an, 2 ans, ça peut dépendre un peu du business de la boutique. Rien n'empêche de toute façon de conserver une version offline des factures pour raisons administratives légales.

En gros ce serait peut-être l'occasion de faire de ces comptes invités de réels comptes invités, comme le client l'a (naïvement) compris :)

Avis donc aux développeurs de modules...

 

Et puis, je viens seulement d'y penser, mais quid des commandes qui proviennent des marketplaces ?

Prenons par exemple le module Ebay, qui rapatrie les commandes sur des comptes "visiteurs". Il va bien falloir les gérer toutes ces données personnelles aussi...

J'ai pas encore creuser l'affaire, et je suppose que là le consentement est "hérité" depuis les marketplaces, mais ça n'empêche pas de devoir gérer ces données clients par la suite. Donc si une gestion doit être prévue pour eux, elle sera automatiquement compatible avec les comptes invités créés directement sur la boutique. Ca me semble kif-kif ;)

 

Link to comment
Share on other sites

Un guest n'est identifié en navigation que par sa clef (token), techniquement plusieurs guest peuvent utiliser la même adresse mail (genre yopmail). Si on affiche toutes les données d'une email on risque de donner des informations privées d'une autre personne (c'est pire je pense de donner l'adresse/numéro de téléphone d'une jeune fille à un vieux pervert - et ne dites pas au juge que le scénario était tiré par les cheveux et que vous l'avez "ignoré" ).

Ensuite un guest n'ayant pas de password nous n'avons pas d'espace mon compte (c'est chaud pour donner le choix)

Enfin une même personne peux faire mille commandes/compte guest avec la même email, et pour prestashop ce sont milles id customer différents ça devient impossible

Ce ne sont pas vraiment les comptes invités qui sont illégaux, c'est que dans ce cas nous sommes incapable de respecter le moindre droit imposé par cette loi, mais après vous pouvez toujours prendre le risque de vous exposer à la sanction mais mes clients ont prévus d'investir les 20 millions dans des choses plus utiles

Edited by doekia (see edit history)
Link to comment
Share on other sites

Ces arguments sont encore une fois vrais avec une vision automatisée ou autonome du processus suite aux requêtes RGPD des clients.

Mais je le répète, l'intervention humaine côté marchand et un minimum de contrôle restent inévitables dans certains cas.

Et à ce sujet :

Can we ask an individual for ID?

If you have doubts about the identity of the person making the request you can ask for more information. However, it is important that you only request information that is necessary to confirm who they are. The key to this is proportionality.

You need to let the individual know as soon as possible that you need more information from them to confirm their identity before responding to their request. The period for responding to the request begins when you receive the additional information.

 

Donc si on a un doute sur l'identité, à cause de l'adresse email  ou à cause de données non concordantes... on a le droit (voire l'obligation) de demander des éléments complémentaires prouvant l'identité.

Link to comment
Share on other sites

je n'ai pas vu d'adresse mail sur les cartes d'identitiés (enfin pas sur la mienne en tout cas)

et ce n'est pas parce que je m'appelle robert que je n'ai pas de droit d'envoyer une commande à jessica.

Tu vas contrôler quoi.

 

Quand à l'idée d'un traitement manuel, si tu as même que 20 commandes jour je te vois mal creuser les 3600 commandes à la main dans 6 mois.

surtout quand ton "guest" aura fait 6 commandes avec 6 adresses mails différentes dont, il ne se rappelle plus si c'est [email protected], ou yahoo ou 123jupette ou giselle_du_89

 

  • Haha 1
Link to comment
Share on other sites

c'est un réel casse tête dès qu'un compte invité demandera l'accès à ses données, c'est juste un nid de guêpes de plus et niveau comptabilité c'est à la limite de la fraude de ne posséder aucune donnée non sensible d'identification client. Ces inscriptions rapides ça fonctionnait dans le temps plus maintenant :)
Bah ... sinon on va faire simple, on attend la première victime et on pourra corriger ces détails, en attendant vivez heureux !

Link to comment
Share on other sites

Lol doekia, c'est plus des arguments là, c'est de la mauvaise foi...

 

@coes.pro : les coordonnées entre elles des comptes invités "enregistrés" sous le même email

Je répondais en fait à l'exemple des emails jetables, de la jeune fille et du vieux pervers ^^

En même temps si on veut pousser le bouchon avec des exemples tirés par les cheveux, on peut aller loin, et ça marche aussi avec des vrais comptes :

- la jeune fille crée un vrai compte avec un email jetable pour passer sa commande

- le vieux pervers arrive 6 mois plus tard avec le même email et souhaite s'enregistrer mais la boutique dit que cet email est déjà utilisé. "Voulez-vous récupérer le mot de passe ?"

Bref, si les gens sont idiots au point d'associer des données personnelles à un email jetable, manquerait plus qu'on vienne nous le reprocher.

 

@Twistix : je ne vois pas pourquoi il y aurait plus facilement question de fraude. La facture d'un invité va en compta comme toutes les autres...

 

Euh sinon, vous pensez qu'il faudrait prévenir Ebay de préparer 300 millions asap ? Parce que l'achat immédiat en tant que visiteur est toujours possible apparemment :P

 

 

Link to comment
Share on other sites

28 minutes ago, Zebx said:

 

@Twistix : je ne vois pas pourquoi il y aurait plus facilement question de fraude. La facture d'un invité va en compta comme toutes les autres...

 

Tout simplement a cause des fuites de données sanctionnées par la RGPD et niveau compta tu ne peux pas historiser ce genre de compte

Link to comment
Share on other sites

il se passe quoi quand l'internaute clique sur un des liens des réseaux sociaux ?

Untel à partagé/aimé/posté à telle heure, tel jour , tel lien de votre site.

C'est un enregistrement de données personnelles, après, vous pouvez le voir différemment^^

Link to comment
Share on other sites

c/c une une url dans Facebook ou Twitter nécessite que tu sois déjà connecté sur ton Fb ou Twitter.

Là, c'est la boutique qui renvoie vers ces sites et leur donne du grain à moudre (et surtout des data).  Tu en es donc responsable ;) 

Link to comment
Share on other sites

Justement je me posais la question sur le socialsharing natif. Perso quand je clique, la fenêtre de partage affiche mon nom fb (j'imagine un cookie FB sur mon ordi pour me retrouver). Mais le nom de la personne qui clique est-il transmis ? Si c'est juste un internaute qui passe par là (donc moi j'ai rien sur lui) et qui clique, c'est FB qui fait le lien entre l'internaute et la page de partage, j'imagine. Il voit que "MartinT" a partagé la page lamba du site Tartanpion. Il le garde dans sa base à lui pour faire du profilage. C'est bien ça ? Il n'y a pas de cookie posé par ce module natif ?

Link to comment
Share on other sites

Pour FB j'ai retrouvé ce bout de texte qui trainait sur mon ordi, çà ressemble bien à des mentions trouvables dans des "politique de vie privée" mais je ne me souviens plus d'où j'avais sortie çà, ni si c'est d'actualité :

Quote

FACEBOOK
Nous utilisons des plugins du réseau social facebook.com, exploité par Facebook Inc., 1601 S. California Ave, Palo Alto, CA 94304, USA (“Facebook”). Le lien permettant de consulter leur politique d'utilisation des données est le suivant : https://www.facebook.com/policy.php

De plus, nous utilisons le pixel de suivi de conversion Facebook. Avec votre permission, nous utilisons le “pixel Facebook" de Facebook Inc., 1601 S. California Ave, Palo Alto, CA 94304, USA (abrégé "Facebook"). Grâce à cet outil, le comportement de l'utilisateur vis-à-vis de notre offre peut être analysé après que l'utilisateur ait sélectionné une publicité sur le réseau Facebook. Cela permet à la fonction de mesurer le succès des publicités et de les évaluer pour les intégrer à ses statistiques, et sert également à des fins d'actions marketing et éventuellement à optimiser les futures propositions publicitaires. Les informations que nous recueillons ne sont généralement pas personnelles mais anonymes - cela signifie que nous ne pouvons pas assigner ces données à une personne en particulier. Cependant, Facebook sauvegarde et traite les informations, selon ce que nous savons, comme suit : Facebook peut établir des liens aux profils des utilisateurs concernés. Facebook peut également utiliser ces informations à ces propres fins publicitaires, selon leur politique d'utilisation des données (que vous pouvez consulter ici https://www.facebook.com/policy). En utilisant ces données, Facebook et ses partenaires peuvent proposer des publicités sur Facebook et d'autres sites et, lorsque nécessaire, stocker des cookies sur les ordinateurs des utilisateurs à cet effet. Vous devez accepter la procédure ci-dessous comme suit :

Déclaration de consentement
"J'accepte l'utilisation du Pixel de Conversion de Facebook.” Si vous avez moins de 13 ans, veuillez demander l'autorisation de votre tuteur légal.
Je peux revenir sur cette déclaration à tout moment en désactivant les cookies dans les paramètres de mon navigateur.»

 

 

Edited by kokoon (see edit history)
Link to comment
Share on other sites

C'est bien pour ça que vous devez identifier tous les réseaux sociaux présents sur vos boutiques et d'inclure un chapitre dans votre charte de confidentialité afin d'informer l'internaute qu'en naviguant sur la boutique tel ou tel réseau génèrera un cookie puis de le convier ensuite à se rendre sur chaque réseau social pour en consulter sa propre politique de confidentialité.
----
Refuser un Cookie émis par un réseau social

Si vous ne souhaitez pas que notre site enregistre des Cookies dans votre navigateur à cette fin, vous pouvez cliquer sur les liens de désactivation suivants qui enregistreront au sein de votre navigateur un Cookie ayant pour unique objet de neutraliser l’utilisation des autres cookies provenant d’un même émetteur. Désactiver ces Cookies empêchera donc toute interaction avec le ou les réseaux sociaux concernés :

Facebook : https://www.facebook.com/about/privacy/
Twitter : https://twitter.com/privacy?lang=fr
Google+ : https://support.google.com/accounts/answer/61416?hl=fr
LinkedIn : http://www.linkedin.com/legal/cookie-policy
Youtube : https://support.google.com/accounts/answer/61416?hl=fr
----

Link to comment
Share on other sites

On 31/05/2018 at 2:11 PM, LiliB. said:

@Twistix Merci pour tes explications sur ton interprétation du RGPD. Effectivement, je me demandais s'il était vraiment obligatoire de demander sur chaque formulaire le recueil du consentement au traitement de données. Après avoir regardé ce que font actuellement les gros sites comme La Redoute et m'être renseignée auprès de juristes et ici et là, j'en arrive à la même conclusion que toi : le consentement n'est pas nécessaire partout. Seule les informations sur le traitement des données l'est. 

En bref, si le client veut passer commande maintenant ou plus tard (formulaire de création de compte), le traitement des données est considéré comme licite. De même lorsqu'un client s'inscrit à une newsletter ou demande à être informé du retour d'un produit. a mon sens on est bien sur la base légale n°1 => les données (nom/prénom/adresse/tel/mail) sont nécessaires à l'exécution du contrat. 

En revanche, si on utilise les données pour d'autres fins (notamment envoyer une newsletter à un client qui a créé un compte ou juste demandé d'être informé du retour produit), là il faut demander son consentement. En d'autres termes, s'il est ok pour recevoir de la prospection commerciale. 


Si on a une case à cocher "abo newsletter" dans la création de compte, alors on a recueilli le consentement. Sur mailalert, là par contre, il faudrait prévoir une case à cocher supplémentaire "voulez-vous être aussi informé des promos,etc...". Sur Newsletter, ben il demande à être informé des promos :-)

Il faut prévoir cependant l'info sur les données personnelles à chaque fois (au moment où il inscrit son mail pour la newsletter, il doit y avoir un petit texte expliquant rapidement le traitement des données et renvoyant vers la pages CMS Politique de Confidentialité).

Voilà pour ma contribution au topic et au sujet épineux RGPD. 

Quel est votre avis ?

 

 

Bravo LiliB, tu as tout compris.

Une petite recommandation cependant : quand tu cites une source (ex: "base légale n°1"), prend la numérotation du RGPD officiel, ça permet à tout le monde de suivre : base légale 1b (article 6). 

Par contre, n'oubliez pas que cela ne concerne pas que le site web, mais tous les traitements au sein de l'entreprise. La suppression des données, par exemple, c'est pas uniquement dans le site web, mais aussi sur les ordinateurs...

 

Link to comment
Share on other sites

18 hours ago, LiliB. said:

Justement je me posais la question sur le socialsharing natif. Perso quand je clique, la fenêtre de partage affiche mon nom fb (j'imagine un cookie FB sur mon ordi pour me retrouver). Mais le nom de la personne qui clique est-il transmis ? Si c'est juste un internaute qui passe par là (donc moi j'ai rien sur lui) et qui clique, c'est FB qui fait le lien entre l'internaute et la page de partage, j'imagine. Il voit que "MartinT" a partagé la page lamba du site Tartanpion. Il le garde dans sa base à lui pour faire du profilage. C'est bien ça ? Il n'y a pas de cookie posé par ce module natif ?

 

En fait cela t'envoie vers facebook mais il n'y a pas de donnée personnelle qui passe entre prestashop et facebook. La seule donnée transmise est l'url de la page via un paramètre dans l'url. https://www.facebook.com/sharer.php?u=http://url-partagee.com

Mais non, pas de cookie.

Ce qui crée des cookies ce sont les widgets, pixels de tracking, certains modules de partage comme add to any (dans le cas du partage il faut vraiment vérifier au cas par cas).

Link to comment
Share on other sites

14 minutes ago, Twistix said:

Oui mais tu as quand même le devoir d'informer tes Utilisateurs que tu génères des cookies de réseaux sociaux
facebook : c_user, datr, fr, locale

Et avec quel module et comment si le module natif socialsharing ne génère pas de cookie ? 

Link to comment
Share on other sites

La question est alors de savoir si on est responsable des cookies générés lorsque l'on dirige vers un site tiers (ce qui vaudrait alors pour n'importe quel lien hypertexte). Perso cela me paraît vraiment tiré par les cheveux. D'autre part je ne suis pas certain qu'on puisse être identifié avec un simple cookie lorsque l'on est pas connecté. Dans le cas contraire c'est pour moi la politique de confidentialité du réseau social qui prend le relais car vous n'êtes de toute façon plus sur votre boutique mais sur un réseau social ; facebook, twitter, etc.

Sur le site de la Cnil il est dit :

les cookies des réseaux sociaux générés notamment par leurs boutons de partage lorsqu'ils collectent des données personnelles sans consentement des personnes concernées.

Ce qui n'est absolument pas le cas pour le module socialsharing. Mais par contre vrai si vous utilisez les boutons j'aime de facebook ou autre widget.

 

Link to comment
Share on other sites

En gros, si je comprends bien, avec le module natif socialsharing, l'internaute est simplement redirigé vers FB (ou autre réseau social). A l'ouverture de la nouvelle fenêtre, l'internaute arrive sur le réseau social en question et c'est lui qui pose un cookie, pas nous.

D'où l'intérêt de faire attention aux différents modules qu'on intègre sur notre site car on n'est pas forcément au courant que le module pose des cookies à nos visiteurs (finalement sans notre propre consentement). J'ai découvert récemment seulement qu'Avis Vérifiés posait des cookies sur tous les visiteurs de mon site (j'ai évidemment leur widget)... 

Je me rend compte que je ne sais même pas quelle est la liste de tous les cookies que pose mon site sur le terminal de l'internaute ! Et je suis sûre que je ne suis pas la seule dans ce cas. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...