RGPD et les Add-On Prestashop

[Tederic]

Bonjour tout le monde,

 

Un petit topic pour résumer un peu la politique de Prestashop par rapport aux réglementations de la RGPD et notamment les différentes développeur sur la plateform Add-On.

Vous avez surement vu durant vos échanges avec les prestataires, la première chose qu'il va vous réclamer, et il insistera lourdement, ce sont vos identifiants de backoffice ainsi qu'un accès FTP à votre Prestashop.

Sachez toutefois qu'avec la RGPD vous êtes maintenant pénalement responsable de donnée de vos clients, donc si vous donnez accès à n'importe qui, sachez que se sera votre responsabilité si les données clients que vous avez laisser "echapé" s'avère venir de votre site web.

Du coté de Prestashop ils se déchargent totalement sur cet aspect (ci joint un petit échange de mail avec le service juridique).

 

Quote

 

Bonjour,

Je suis en cours de discussion avec un des vendeurs d'Add-On sur votre site. 

Module Outil de ***********************

Développeur :   ************ Commande :  #*********.

Pour la troisième fois celui-ci refuse de m'aider sur un soucis technique sans avoir un accès à mon back-office ainsi qu'à mon FTP.

 

Avant l'achat, il m'avait pourtant assuré que tout fonctionnerait sans soucis avec leur dernière mise à jour, et notamment, les déclinaisons de mes produits.

Il demande maintenant l'accès à mon site de production ainsi qu'à mon site de test. Dans les deux cas des données personnelles sur mes clients y sont présentes. Ainsi que toutes mes ventes et mon catalogue de produit.

Je m'interroge sur le bien fondé de cette demande et notamment sur la protection des données via la RGPD.

Je ne vois pas comment garantir à mes clients la protection de leurs données, en communiquant leurs informations personnelles à des prestataires tiers, situé notamment dans des pays en dehors de l'EU.

 

Ainsi des doutes et des questions m'interpellent : 

Etes-vous garants judiciairement de votre prestataire ? 
Réalisez vous des audits afin d'être certain que les données ne soient pas réutilisées à des fins mercantiles, ou pires des malversations ?

Cordialement,

 

 

 

Quote

 

Bonjour Monsieur, 

 

Lorsque vous achetez un Addon sur le site www.addons.prestashop.com, et que cet Addon est développé par un contributeur, PrestaShop n'intervient que comme un intermédiaire technique. 

 

Les contributeurs sont des sociétés tierces et ne sont pas des prestataires de PrestaShop. De ce fait, PrestaShop ne peut se porter garante "judiciairement" de ces derniers. 

 

Nous ne réalisons pas d'audit pour être certains que les données soient utilisées à des fins mercantiles : PrestaShop n'a pas accès aux données des boutiques des utilisateurs. 

 

En tant qu'utilisateur du logiciel téléchargeable,  vous êtes considéré comme le responsable de traitement des données des clients de votre boutique.   

 

PrestaShop ne peut être considérée comme sous-traitant, car elle ne propose pas de solution d'hébergement ; elle n'effectue aucun traitement de données personnelles pour le compte des utilisateurs et n'a pas accès aux données des boutiques. 

 

Il vous incombe donc de respecter les obligations du Règlement européen sur la protection des données du 27 avril 2016 et de la loi Informatiques et Libertés. 

 

Afin d'aider les utilisateurs à comprendre ces obligations, PrestaShop a mis à la disposition de ses utilisateurs une FAQ ainsi qu'un livre blanc que vous pouvez retrouver sur cette page. Vous pouvez également consulter le guide de la CNIL. 

 

Il arrive souvent que les contributeurs demandent des accès FTP aux utilisateurs car ils ont besoin d'avoir accès au code source de la boutique pour pouvoir effectuer les modifications adéquates sur le code de leur Addon. Il vous appartient ensuite de modifier ces accès une fois la prestations terminée. 

 

En tout état de cause, vous avez la responsabilité, en tant que responsable de traitement, de faire signer les contrats nécessaires à la protection des données de vos clients si des tiers interviennent sur votre boutique.

 

Bien à vous, 

 

 

 

Aussi je m'interpelle et me demande sincèrement si je suis le seul à m'en soucier.

Avez-vous déjà signer ce type de contrat ? Vous êtes vous déjà renseigné sur leur validité dans l'EU ?

Etant donné que l'aspect juridique à changer, n'est-il pas temps d'imposer aux prestataires de travailler autrement qu'avec un accès direct au backoffice ?

Ou au moins peut-on imposer à Prestashop de faire auditer ses prestataires "Premium" afin d'avoir des garanties en terme de sécurité des données ?

 

A bientôt,

 

Ted

Edited April 15, 2019 by Tederic (see edit history)

[Janett]

3 minutes ago, Tederic said:

Avez-vous déjà signer ce type de contrat ? Vous êtes vous déjà renseigné sur leur validité dans l'EU ?

Etant donné que l'aspect juridique à changer, n'est-il pas temps d'imposer aux prestataires de travailler autrement qu'avec un accès direct au backoffice ?

Ou au moins peut-on imposer à Prestashop de faire auditer ses prestataires "Premium" afin d'avoir des garanties en terme de sécurité des données ?

Clairement non, je n'ai jamais signé ce type de contrat et je n'ai jamais donné mes accès FTP ou base de données à un développeur addons.

Je ne pense pas que ce soit à Prestashop d'imposer, ils ne sont qu'une marketplace qui fait l'intermédiaire pour mettre en relation les marchants et les développeurs ainsi que fournir le système de paiement facturation. Comment pourrait-il garantir que le développeur respecte bien la loi en dehors des audits lors des échanges avec les marchants ? Ils ne sont pas omniscient...

C'est plutôt aux marchands, de veiller à cela puisqu'ils sont responsable des données de leurs clients. S'ils sont mal informés des lois en vigueur, je ne vois pas ce que Prestashop peut y faire, nul n'est censé ignorer la loi. Surtout lorsqu'on est marchands, il faut se renseigner sur l'aspect juridique, c'est pour cela qu'il y a des formations dans le Chambre de Commerce et d'Industrie notamment.

Quoi qu'il en soit, c'est au marchant de faire les démarches nécessaires avec ses prestataires pour se conformer à ses propres obligations légales, selon moi.

Sinon les développeurs qui demandent les accès FTP et base de données, c'est souvent pour s'épargner la peine d'essayer de reproduire un environnement similaire aux caractéristiques de votre installation pour tenter de reproduire le bug. D'autant que les marchants ne savent pas toujours exprimer clairement quelle version de Prestashop ils utilisent, avec quelle version de PHP, quelles extensions PHP, quels modules, quel thème etc... Donc difficile de reproduire un environnement dont on ignore tout...

[Eolia]

Ce type de contrat (formulaire à remplir) est fourni avec ma version du module RGPD:

[Tederic]

32 minutes ago, okom3pom said:

Je ne vois pas comment un prestataire pourrait corriger un problème sans un accès ?

Vous pouvez passer un contrat avec une agence ou un freelance et lui envoyer vos modules via addons, dans ce cas l'option ZEN ne servira à rien car ce n'est pas la personne qui a fait le module qui fera le support mais votre agence ou votre freelance.

 

Pour l'exemple par mail, j'entends qu'il est particulièrement difficile d'y remédier même si nous avons réussi à corriger le problème avec un peu de patience.

Merci notamment au développeur en question si il se reconnait.

 

Pour ce qui est des développeurs de thème, je trouve que c'est abusé, quand on a un accès restreint au FTP du répertoire du thème. Pas besoin d'avoir les accès Backoffice.

Il me semble que c'est largement suffisant en demandant au client de vider un cache ou remplir 3 modules.

Peut-on dans ce cas, modifier les accès back-office pour ne laisser aucun droit de lecture sur les commandes/produits/clients ?

 

31 minutes ago, Janett said:

Je ne pense pas que ce soit à Prestashop d'imposer, ils ne sont qu'une marketplace qui fait l'intermédiaire pour mettre en relation les marchants et les développeurs ainsi que fournir le système de paiement facturation. Comment pourrait-il garantir que le développeur respecte bien la loi en dehors des audits lors des échanges avec les marchants ? Ils ne sont pas omniscient...

Aux dernières nouvelles, 30% des ventes sont perçues par Prestashop Addons.

Il me semble que lorsque l'on vend un service,  ici mettre en relation un client et un développeur, la moindre des choses serait de s'assurer de intégrité des personnes que l'on recommande, particulièrement lorsqu'on le tag "Top Developer"

 

 

Ps : Merci Eolia

Edited April 15, 2019 by Tederic (see edit history)

[Janett]

3 minutes ago, Tederic said:

Aux dernières nouvelles, 30% des ventes sont perçues par Prestashop Addons.

Il me semble que lorsque l'on vend un service,  ici mettre en relation un client et un développeur, la moindre des choses serait de s'assurer de intégrité des personnes que l'on recommande, particulièrement quand on le tag "Top Developer"

Oui comme la plupart des marketplaces

Si seulement Google pouvait faire pareil avec les applications disponibles dans son Play Store, idem pour Apple et son AppStore... Ce n'est pas si simple, l'intégrité d'un tiers à part être omniscient, je vois mal comment la garantir...

C'est à vous en tant que responsable des données de vos clients, de prendre les dispositions nécessaires et le contrat type d'Eolia vous mets sur la bonne piste de ce que vous devriez faire avec vos prestataires. N'hésitez pas à contacter votre Chambre de Commerce et d'Industrie (j'ai fait une formation pour l'autoentreprise il y a quelques années et d'autres avec des experts comptables ou des juristes). Vous pouvez aussi prendre contact avec des professionnels qui pourront vous conseiller.

[Eolia]

Il y a 1 heure, Tederic a dit :

Pour ce qui est des développeurs de thème, je trouve que c'est abusé, quand on a un accès restreint au FTP du répertoire du thème.

Pour info, à partir ou la personne a un accès en écriture sur le ftp il a accès à tout ce qu'il veut que ce soit BO ou BDD et par extension, au ftp en entier même plus^^

[doekia]

Un prestataire DOIT tout simplement avoir sa charte RGPD et la communiquer. Si le prestataire est européen, un entité déclarée (RCS, ...), sont engagement contractuel spécifiant le périmètre de chacune des obligations est réputé conforme. J'ai cette charte pour tout client la demandant depuis l'entrée en vigueur de la loi.

 

[Mediacom87]

Il y a 4 heures, Janett a dit :

Donc difficile de reproduire un environnement dont on ignore tout

C’est même impossible.

[Tederic]

5 hours ago, Eolia said:

Pour info, à partir ou la personne a un accès en écriture sur le ftp il a accès à tout ce qu'il veut que ce soit BO ou BDD et par extension, au ftp en entier même plus^^

Oui c'est sure, mais bon dans ce cas, on est directement dans la malversation. Légalement, ça sera beaucoup plus rapide

[doekia]

Comment ça malversation?

Ce que veux signifier @Eolia, c'est un fait dont certains n'ont pas connaissance, autrement dit, que ce soit l'accès BO, l'accès FTP, ... vous devez être conscient et n'accepter de donner ces accès qu'a ceux auquel vous avez parfaitement confiance. D'autant que je vois mal comment vous pourriez savoir dans le détail ce que fait un intervenant.

Donc accès, implique engagement RGPD de vos intervenants

[joseantgv]

Dans ce cas, il propose au développeur de résoudre le problème par TeamViewer.

[doekia]

@joseantgv Je te vois mal passer 2h a regarder une session teamviewer, sans parler de la licence de ce dernier à acheter, des outils boiteux sur le poste du client, des problèmes de connexion et du fait qu'au final on a accès de la même manière à des données à caractères privées.

Perso si après avoir fourni mes garanties on m'impose teamviewer (que je n'ai pas), je refuse de travailler.

RGPD parle de l'accès a des données privées. Que je vois le numéro de téléphone de ta client au travers de teamviewer ou depuis mon pc ne change rien au fait que j'ai accès à des données privées. ça entre donc dans le cadre de se que couvre la loi et vos/votre intervenant doit être RGPD compliant. Le gonze du bengladesh choppé sur codeur.com, n'est pas RGPD. Vous êtes donc dans ce cas punissable au titre de la loi.

 

 

[Eolia]

Il y a 11 heures, Tederic a dit :

Oui c'est sure, mais bon dans ce cas, on est directement dans la malversation. Légalement, ça sera beaucoup plus rapide

C'est bon, je laisse tomber... Pourquoi perdre du temps à essayer d'expliquer les risques existants lorsque l'on file les clés à quelqu'un sans vraiment en connaitre les conséquences.

Amusez-vous bien ici et faites comme bon vous semble^^

[Tederic]

J'entends ton argument et tu as tout à fait raison.

Mais là, on est directement dans l'intrusion. Ce n'est plus directement de notre responsabilité si il y a hacking.

[joseantgv]

@doekia Donc, s'ils ne vous donnent pas accès au backoffice ou FTP, ne résolvez-vous pas le problème?

[doekia]

@Tederic

Erreur grave, le hacking est de votre responsabilité. Vous devez prendre les mesures adaptées pour corriger et communiquer à l'ensemble de vos clients sur la pénétration, les données potentiellement spoilées et ce dans un délai maximal de 72h après découverte de l'intrusion.

Relisez vos obligation RGPD que diable!!!

[doekia]

Just now, joseantgv said:

@doekia Donc, s'ils ne vous donnent pas accès au backoffice ou FTP, ne résolvez-vous pas le problème?

Exact je suis comme un médecin auquel on refuserait l’auscultation. Je ne suis pas magicien.

 

[Mediacom87]

 

il y a 1 minute, joseantgv a dit :

 Donc, s'ils ne vous donnent pas accès au backoffice ou FTP, ne résolvez-vous pas le problème?

Je confirme que, pareil, si je n'ai pas accès et si le problème n'est pas reproductible sur une installation de test je ne peut rien faire puisque je n'ai pas accès au problème.

C'est comme demander à un dentiste de soigner une carie sans apporter votre bouche.

On tombe dans le ridicule à devoir toujours prouver nos compétences, nos savoir faire, notre probité. J'ai dû intervenir sur des dizaines de milliers de sites et franchement dans 95% des cas je ne sais même pas ce que vendent ces sites. Alors les données personnelles des clients de ces boutiques je m'en fiche complétement aussi.

Mais bon, comme cela ne fait que 10 ans que je suis freelance, rien ne prouve que je ne suis pas le voleur de grand chemin qui va piller les passants.

[Eolia]

Dernière intervention en date, un client m'achète un module et me dit "il ne fonctionne pas"

Vu qu'il fonctionne chez tous mes clients ayant la même version Presta je lui demande un accès ftp (J'ai le même environnement de test que sa boutique mais je ne reproduis pas)

Un fois l'accès ftp récupéré non sans mal, le client ignorant ce qu'était un ftp, je constate 2 overrides et une classe modifiée en dur qui modifient (enfin écrasent la fonction native appelée par mon module)

J'ai donc effectué les modifications nécessaires et tout refonctionne correctement.

J'aurais fait comment sans accès ftp ?

C'est comme si vous confiez votre voiture au garage sans laisser les clés...

[Janett]

1 hour ago, Eolia said:

Je constate 2 overrides et une classe modifiée en dur qui modifient (enfin écrasent la fonction native appelée par mon module)

Cela illustre parfaitement le mal qui gangrène PrestaShop et qui fait planter les mises à jour. Les overrides qui modifient les comportements initiaux de PrestaShop.

Une très mauvaise habitude dont il faut se passer, en tout cas si le but de l'override est de modifier un comportement natif.

C'est bien pour ça qu'ils sont en train de migrer vers une nouvelle architecture qui s'écarte de l'héritage pour s'appuyer sur la composition.

Par contre, dans mes modules je force l'utilisation de la classe core en zappant l'override (Genre CustomerCore au lieu d'utiliser Customer) mais il y a toujours le problème des gens qui font leurs modifications dans le code de PrestaShop sans passer par les overrides. Le mieux étant au final de passer par un Adapter mais je n'en suis pas encore là dans le refactoring de mes modules... Il reste tant de travail pour adapter mes modules sur 1.7 tout en gardant la rétrocompatibilité...

[doekia]

Pointer les overrides comme mère de tous les vices, n'a pas de sens.

Il en est de même avec un hook qui cause des problèmes.

La question ici est de savoir si oui ou non nous pouvons faire du support sans accès à un système - la réponse est non.

Le sujet parle de RGPD, certains semblent penser qu'un module les rend RGPD compliant alors que RGPD est un méthode dont 90% n'a rien a voir avec le code.

RGPD c'est s'assurer d'avoir des intervenants respectant les mêmes méthode, et contraints aux mêmes lois. Donc pour être RGPD vous devez ne faire intervenir que des opérateur Européens et seulement si ces derniers suivent les préceptes RGPD - engagement, charte, méthode.

 

Je vois pas en quoi la composition résout le problème, ni du support, ni de l'interaction entre de multiples fonctionnalitées tiers. L'erreur est de penser que l'on peut juste ajouter une myriade de module sans se poser la question de la stabilité de l'éco-système. Un exemple parmi tant d'autre. 2 modules de transport, chacun présentant une carte google, Immédiatement Il y a erreur coté API Google map (multiple map on single page).

Forcer l'usage de <class>Core c'est très égoïste, type "après moi le déluge". Ton module fonctionne en casant toute interaction avec d'autres composants. Il faut utiliser les overrides quand (et seulement) c'est obligatoire. Les overrides sont vitaux dès que l'on veux mettre en oeuvre des fonctions avancées. Et lorsque la boutique contient de nombreux composants supplémentaire, il est souvent nécessaire d'analyser, ajuster, merger des overrides. Pour les hooks, c'est pareils, lequel des modules doit être en 1er, quelle séquence. A nouveau ceci requiert d'accéder au système et à nouveau la loi RGPD va dicter qui/comment cela sera fait.

 

[Janett]

4 minutes ago, doekia said:

Un exemple parmi tant d'autre. 2 modules de transport, chacun présentant une carte google, Immédiatement Il y a erreur coté API Google map (multiple map on single page).

Un problème en partie réglé sur 1.7 avec FrontController::registerJavascript() si tous les carriers mettent en premier argument un Id standardisé du type gmap (je ne sais pas s'il y a une convention d'établie d'ailleurs) le script ne sera inclus qu'une fois. Problème aucun module carrier actuel ne gère cela correctement donc chacun inclus sa propre map ^^

8 minutes ago, doekia said:

Forcer l'usage de <class>Core c'est très égoïste, type "après moi le déluge". Ton module fonctionne en casant toute interaction avec d'autres composants. Il faut utiliser les overrides quand (et seulement) c'est obligatoire. Les overrides sont vitaux dès que l'on veux mettre en oeuvre des fonctions avancées. Et lorsque la boutique contient de nombreux composants supplémentaire, il est souvent nécessaire d'analyser, ajuster, merger des overrides.

Alors il est important effectivement que j'apporte une précision ici, mes modules ne sont pas distribués, ni sur addons ni ailleurs. Ils ne sont utilisés que sur les sites de mes clients dont je maitrise l'ensemble de la chaine. Tous mes modules suivent les mêmes conventions, je n'ai aucun override et les hooks sont un ancêtre du système d'événement type Symfony dans mon cas peu importe l'ordre. Comme tu le fais remarqué, cela ne pourrait surement pas fonctionner dans un écosystème ouvert où d'autres modules ou prestataire ajouteraient leur sauce. Néanmoins dans mon cas, l'absence d'override et la connaissance des dysfonctionnements des comportements initiaux des objets Prestashop que j'utilise me permet de gérer cela dans mes modules là où j'ai besoin de les corriger. Pour le code le plus récent, dans des Adapters, mais pour la majorité qui date de la 1.5, je gère ça dans mes modules de façon plus ou moins propre mais de façon à ce que cela n'impacte ni Prestashop, ni les autres modules.

[Tederic]

30 minutes ago, doekia said:

La question ici est de savoir si oui ou non nous pouvons faire du support sans accès à un système - la réponse est non.

Le sujet parle de RGPD, certains semblent penser qu'un module les rend RGPD compliant alors que RGPD est un méthode dont 90% n'a rien a voir avec le code.

RGPD c'est s'assurer d'avoir des intervenants respectant les mêmes méthode, et contraints aux mêmes lois. Donc pour être RGPD vous devez ne faire intervenir que des opérateur Européens et seulement si ces derniers suivent les préceptes RGPD - engagement, charte, méthode.

 

Parfaitement résumé, on part sur un post récapitulant tous les développeurs EU et RGPD friendly ?

Bref le boulot de Prestashop en somme.

[Janett]

Bah déjà je pense que là plupart des intervenants ici

Vous qui fréquentez le forum, vous pouvez vous fier aux intervenants présents depuis longtemps, avec pas mal de posts à leur actifs ainsi qu'une bonne réputation 👍

[joseantgv]

Mais je veux dire qu'il existe d'autres moyens de fournir une assistance sans accès à backoffice et FTP, tels que TeamViewer ou le téléchargement d'une version du module enregistrant les traces dans un log.

[doekia]

1 hour ago, Janett said:

Alors il est important effectivement que j'apporte une précision ici, mes modules ne sont pas distribués, ni sur addons ni ailleurs. Ils ne sont utilisés que sur les sites de mes clients dont je maitrise l'ensemble de la chaine. Tous mes modules suivent les mêmes conventions, je n'ai aucun override et les hooks sont un ancêtre du système d'événement type Symfony dans mon cas peu importe l'ordre. Comme tu le fais remarqué, cela ne pourrait surement pas fonctionner dans un écosystème ouvert où d'autres modules ou prestataire ajouteraient leur sauce. Néanmoins dans mon cas, l'absence d'override et la connaissance des dysfonctionnements des comportements initiaux des objets Prestashop que j'utilise me permet de gérer cela dans mes modules là où j'ai besoin de les corriger. Pour le code le plus récent, dans des Adapters, mais pour la majorité qui date de la 1.5, je gère ça dans mes modules de façon plus ou moins propre mais de façon à ce que cela n'impacte ni Prestashop, ni les autres modules.

bonne précision

[doekia]

52 minutes ago, joseantgv said:

Mais je veux dire qu'il existe d'autres moyens de fournir une assistance sans accès à backoffice et FTP, tels que TeamViewer ou le téléchargement d'une version du module enregistrant les traces dans un log.

En TeamViewer tu as exactement les même contraintes RGPD. Je vois des données personnelles! - et bon si tu veux que je fasse du teamviewer avec toi, pas de problème, achète moi la licence, 360€/an ça va pas mal changer la donne.

Un module qui enregistre des traces dans un log, oui mais comme il va falloir que je le lise on revient à la contrainte RGPD.

Et puis ton raisonnement est idiot. Si nous savions déjà a priori les données dont nous avons besoin, c'est que nous connaissons déjà la panne donc nous avons déjà la solution. Vous confondez recherche de panne qui peut mener a des heures de recherche avec appliquer un patch. Pour ce dernier point je n'ai même pas besoin de FTP et le client non plus. Je lui renvoi un zip d'update.

[joseantgv]

Correct, je faisais référence à offrir un bon service client pour résoudre le problème