Edtech a écrit :



Tu mets un header “Content-Security-Policy” bien restrictif au niveau du serveur (plus efficace qu’au niveau du site web), et tout ce qui est ajouté par les tiers ensuite sera bloqué par les navigateurs. Le tour est joué ! 😁





Là où je bosse on a effectivement des discussions autour de l’usage de CSP, on s’en sert déjà pour éviter certaines classes de pb de sécurité, on voudrait étendre pour ajouter du contrôle sur ce qu’il se passe côté tag manager. Après, ça nécessite pas mal de négo entre équipes business, sécurité, juridique et IT.

fred42 a écrit :



Le problème principal est donc le gars responsable de la sous-traitance du bazar et pas le dev. OK



C’est à ce gars d’exiger que ça soit convivial et que ça ne présente pas à nouveau la bannière quand ce n’est pas nécessaire par rapport au RGPD. S’il ne le fait pas, il se fout de ses utilisateurs et devrait être viré.





Si seulement c’était aussi simple. Dans le monde des grosses entreprises ça se passe plus souvent comme ça:

• le responsable expérience utilisateur signale que l’expérience est toute pourrie
  


• le responsable de la négociation avec le prestataire demande au prestataire la possibilité de faire le changement
  


• la main passe aux entité juridiques et leurs experts techniques. Si le juridique estime que le comportement est justifié par l’interprétation de je ne sais quelle ligne du texte, on peut s’arrêter là. En l’absence de précisions et de jurisprudence on reste à la lettre de la loi pour être en risque 0. (je ne sais pas si c’est le cas ici, mais il pourrait y avoir une clause mal formulée qui empêche l’état de validation d’être considéré comme un cookie ne nécessitant pas de consentement. Malheureusement, ce n’est pas parce qu’un truc semble évident d’un point de vue technique ou même de bon sens que ça l’est juridiquement)
  


• s’il n’y a pas d’opposition du département de conformité juridique, vient la question du “mais combien ça coûte”, et ce sont les départements d’achats qui vont avoir leur mot à dire (est-ce que c’était dans le budget ? est-ce que le bénéfice justifie le coût ? ). Là le niveau de souplesse dépend des boîtes. Globalement si le prestataire présente un devis jugé élevé et si le responsable UX ne peut pas garantir que le comportement actuel fait perdre de l’argent, il y a peu de chances que ça bouge.
  
  
  
   
  
   
  
  
  
  
  
  ndjpoye a écrit :
  
  
  
  Merci pour ces explications intéressantes.
  
  
  
  Au final, on en revient à un mal assez rependu. L’organisation de tout ça s’est bien complexifié avec le temps et comment ça, c’est un peut la faute à personne. Je dis pas ça contre toi, c’est juste un mal répandu. Est ce la faute du prestataire ? Des personnes qui ont qui ont choisi ce prestataire ? Des équipe Analystics et/ou business qui veulent tellement de choses que ça oblige à choisir ce type de presta ? etc.….
  
  Problème récurrent, et pas qu’en informatique " />
  
  
  
  
  
  Oui, la dilution de responsabilité est un mal bien connu, en politique comme en entreprise ^^”
  
  Après il ne faut pas se leurrer, la solution gagnante, c’est celle qui offre le meilleur équilibre entre conformité légale  et prix, et dans la composante “prix” sont pris en compte tarifs du prestataire, image de marque, relations publiques, importance des analytics dans le pilotage de l’activité, ventes perdues par rebond utilisateur…
  
  Ce sur quoi je veux surtout insister, c’est sur le fait qu’il faut se retenir de sursimplifier, en tant que techniciens on a souvent tendance à se dire “nan mais pour faire ça c’est juste quelques lignes de code, aucune raison que ça pose problème, ils font forcément expès de se planter”. On a également tendance à considérer que si un truc nous irrite, ça irrite forcément des tas de gens, et donc ça devrait être résolu. Sauf que non, j’ai tous les jours l’occasion de voir que des UX que j’estimerais inacceptables sont parfois tolérées voire préférées par la grande majorité des utilisateurs.
  
  Aussi, abstenons-nous de jugements hâtifs basés sur nos biais cognitifs personnels. Souvent chaque acteur a (de son point de vue) de très bonnes raisons d’agir comme il le fait, sans qu’aucune de ces raisons ne soit de la malveillance ou de la bêtise.

Alors, pour bosser du côté de ceux qui font dans les gros sites de ecommerce, je pense que les commentateurs ici loupent quelques trucs fondamentaux sur le fonctionnement des boîtes (et donc du web) à une certaines taille. (genre quand on a des groupes qui s’étalent sur plusieurs marques et plusieurs pays avec leurs marchés locaux)

 

Ce ne sont pas les développeurs qui mettent directement en place tout ce qui est cookies, traceurs, régies pubs, etc, etc. Ce serait tout simplement ingérable de traiter toutes les demandes des équipes business et analytics.

Ce qu’il se passe, c’est que côté dev, on intègre trois choses (niveau cookie en tout cas, pour ce qui est du reste du RGPD il y a encore d’autres actions à effectuer pour la conformité, mais c’est une autre histoire):

• les cookies pour la session et les features de la plateforme ecomm’ qu’on utilise (ceux qui sont appelés “fonctionnels” dans les bandeaux et qui ne se refusent pas donc)
  


• un “data layer” côté client. En gros il s’agit d’un objet javascript unique (donc côté navigateur) dans lequel on va enregistrer des évènements en suivant une spécification (notamment de nommage et format) fournie par l’équipe analytics (“quand l’user fait ça, on enregistre ça sur l’objet, quand tel truc se passe, en enregistre ça, etc.”). A ce stade tout reste dans le navigateur.
  
   - le code d’intégration d’un prestataire qu’on appelle un “tag manager” (le plus souvent c’est google tag manager), qui va permettre ensuite aux équipes analytics et business de gérer tout le reste. En gros il faut voir ça comme un “trou invisible” dans les pages, qui permet au métier d’installer les prestataires qu’ils veulent (qui vont injecter leur propre code dans ce “trou”). Un des prestataires installés (généralement google analytics) aura pour but “d’écouter” l’objet “data layer” de l’étape précédente pour générer des metrics non-partagées à des tiers. 
  
   
  
  Partant de là, à votre avis comment est-ce qu’on fait pour gérer cette fameuse “bannière cookie” qui casse les pieds à tous le monde avec son expérience utilisateur dégueulasse ?
  
  
  
  Si vous avez répondu “on ne le gère pas, on passe par un partenaire tiers”, vous avez bien compris comment ça marche :)
  
  
  
  Comme les développeurs n’ont aucun moyen de savoir quels traceurs ou outil d’analytics le business installe via son tag manager, ils n’ont pas moyen non plus de gérer le consentement pour ces traqueurs.  On fait donc appel à un partenaire supplémentaire, qui va permettre de gérer via un backoffice dédié les autres partenaires actifs, et fournir en temps réel une bannière de gestion des consentements (garantie conforme à la législation).
  
  Voilà qui vous explique aussi pourquoi toutes ces bannières se ressemblent (et comportent souvent un “powered by xxx” ).
  
  
  
  Contrairement à ce qu’on pourrait penser, les entreprises qui ne font pas directement leur beurre avec les traceurs ne se torchent pas avec la conformité, mais généralement elles n’ont pas d’équipe technique interne dédiées pour traiter chaque point, et cela se retrouve (plus ou moins bien) sous traité.
  
  Donc sachez que quand vous vous retrouver avec la popup chiante qui se réouvre et qui est mal foutue, ce n’est pas une volonté des sites d’avoir l’utilisateur à l’usure ou de faire un pied de nez au législateur en interprétant la loi de travers, c’est juste une conséquence systémique de l’organisation interne des entreprises et de la course aux économies: on paie le prestataire qui fournit l’outil le mois cher tout en garantissant la conformité + le fait que ses serveurs vont tenir la charge et ne vont pas péter la fonctionalité des sites.
  
  
  
  ( attention, je ne dis pas non plus que tous les gestionnaires de sites sont de bonne foi et que personne ne cherche à contourner la législation. Il y a toujours de mauvais élèves en mode “on va poser une bannière pour faire genre et parier que personne ne fera de vérification approfondie” )