Choisir une plateforme de consentement aux cookies quand votre agence gère plusieurs sites clients

Tous les articles

La bonne plateforme est celle où un changement de politique atteint tous les sites en même temps et où chaque journal de consentement reste limité à un seul client. Jugez les candidats là-dessus, pas sur la liste de fonctionnalités : qui est responsable du traitement sur chaque journal, si une configuration unique se réplique ou si des dizaines dérivent, et ce que coûte une demande relative aux données sur des constructeurs différents.

La liste de fonctionnalités ne fait pas la décision

Presque toutes les réponses publiées à cette question sont des classements de produits, notés sur le prix par domaine, la marque blanche, les sous-comptes et les certifications. Ce sont de vrais critères, et c'est aussi la partie de la décision qu'un fournisseur peut faire tenir dans un tableau.

Ce qu'aucun d'eux ne chiffre, c'est le travail qui retombe sur votre équipe le lendemain de l'achat. Un portefeuille n'est pas un site multiplié. Ce sont des parcs sur des constructeurs différents, sur des marchés différents, appartenant à des clients différents, chacun auditable séparément. Soit l'outil absorbe cela, soit il vous le renvoie sous forme de travail manuel récurrent. Quatre questions permettent de trancher.

Qui est responsable du traitement sur chaque journal de consentement ?

Celle-ci a une portée juridique, et c'est la plus susceptible d'être négligée lors de l'achat. Le schéma habituel veut que votre client contrôle les données de ses visiteurs et que la plateforme agisse comme sous-traitant, même si toutes les plateformes ne sont pas organisées ainsi : vérifiez donc ses conditions. Là où les agences se font piéger, c'est en supposant qu'elles sont elles aussi sous-traitants. Si vous décidez pourquoi le suivi s'exécute et quelles finalités la bannière déclare, vous pouvez être vous-même responsable du traitement, soit conjointement avec votre client au titre de l'article 26 du RGPD, soit séparément. Les lignes directrices du CEPD sur les notions de responsable du traitement et de sous-traitant indiquent que ces rôles découlent de ce que chaque partie fait réellement, pas de l'étiquette inscrite dans un contrat. Déterminez donc les rôles à partir des faits, consignez-les dans votre contrat avec chaque client, puis vérifiez que la plateforme sait traduire ce dont vous avez convenu.

Concrètement, cela veut dire un journal de consentement attribuable à un seul site et exportable séparément. Remettre cet enregistrement quand un client part relève du contrat et du produit, pas d'un droit que le client peut exercer, et c'est pourquoi cela vaut la peine de le confirmer avant de signer. Et si une plateforme mutualise les enregistrements de tous les sites sans frontière par site, documenter l'audit d'un client revient à entrer dans un stockage qui contient aussi ceux de tous les autres. Demandez un export d'un seul site avant de vous engager, pas une description de cet export.

Comment un changement de politique atteint-il chaque site ?

La configuration du consentement ne se règle pas une fois pour toutes. Un client ajoute un widget de chat. Un fournisseur s'avère déposer un cookie publicitaire que vous aviez classé comme fonctionnel. Chacun de ces changements modifie ce que votre bannière déclare et ce qu'elle bloque, et chacun doit atteindre tous les sites concernés.

Sur un outil pensé pour un seul site, cela représente une connexion par parc, effectuée par une personne, un jour où il y a aussi d'autres choses à faire. Ça tient avec une poignée de sites. Au-delà d'un certain seuil, cela devient la tâche qui ne se fait pas, sans que personne ne s'en aperçoive, et la dérive reste invisible parce que chaque site a toujours l'air correct quand on l'ouvre. Demandez donc comment une modification se propage. Existe-t-il une configuration parente dont les sites héritent, ou seulement une fonction de copie qui clone une fois puis les laisse diverger ? Pouvez-vous voir, dans une seule vue, quels sites appliquent la politique en vigueur ? Cette dernière question sépare un véritable outil de portefeuille d'un outil monosite affublé d'un tarif multidomaine.

Qu'est-ce qui change quand les parcs reposent sur cinq constructeurs de sites différents ?

Le portefeuille réel d'une agence repose rarement sur une seule plateforme. C'est un peu de WordPress, quelques boutiques Shopify, un site Webflow, quelque chose sur Squarespace, et une application développée sur mesure qu'un développeur a laissée derrière lui il y a deux ans. La bannière est la moitié facile du problème : la plupart des outils s'affichent sur n'importe quoi.

C'est dans la pile de balises que tout diverge. Chaque constructeur a sa propre idée de l'endroit où placer les scripts, ses propres intégrations natives qui injectent leurs propres balises, et son propre parcours de paiement ou de formulaire qui se déclenche en dehors des pages que vous avez instrumentées. Un outil qui se comporte de la même façon sur toutes ces plateformes vaut mieux qu'un outil excellent sur celle que la plupart de vos clients n'utilisent pas, parce que chaque chemin d'intégration supplémentaire est un endroit de plus où le comportement doit être vérifié séparément. C'est une autre question que celle de la marque blanche, traitée dans ce qui compte vraiment dans le consentement aux cookies en marque blanche.

Que coûte vraiment un audit ou une demande relative aux données ?

Voici le coût que personne n'affiche, et sur un portefeuille assez grand, c'est lui qui départage les outils. Un visiteur d'un client demande ce qui a été collecté à son sujet, ou le service juridique du client vous demande de prouver le consentement à une date donnée. Avec une frontière par site et un journal consultable, c'est une simple requête. Avec un stockage mutualisé, c'est tout un exercice : retrouver le compte, déterminer quel journal correspond à quel domaine, l'exporter, vérifier que vous n'avez inclus personne d'autre, recommencer pour les autres sites de ce client. Quelques fois par trimestre sur l'ensemble de vos clients, et vous avez trouvé le vrai prix de la licence la moins chère.

Que faut-il vérifier avant de vous engager ?

1. Demandez l'export du journal de consentement d'un seul site

   Pas une description. Regardez quelqu'un le produire. S'il faut un ticket au support, chaque audit futur en demandera un aussi.

2. Modifiez une catégorie et regardez où elle arrive

   Vérifiez qu'il atteint un site en production sans republication. Si le seul mécanisme est un clone, vous achetez de la dérive.

3. Installez-le d'abord sur la plateforme client que vous aimez le moins

   Le parc qui révèle les limites d'un outil, c'est l'exception de votre portefeuille, pas celui que vous connaissez le mieux.

4. Vérifiez qui le journal désigne comme responsable du traitement

   Par site, par écrit, conformément aux rôles convenus avec ce client. Cela compte le jour où un client part et emporte son parc avec lui.

Quand un outil par site est-il vraiment le meilleur achat ?

Disons-le franchement : si vous gérez une poignée de sites, tous sur le même constructeur, tous destinés au même marché, un outil par site est plus simple et généralement moins cher, et tout ce qui précède ne vous apporte rien. Une gestion centralisée n'est qu'une charge tant qu'il n'y a pas assez à gérer.

Le point de bascule n'est pas un nombre de sites, c'est un rythme de changement. Quand le nombre de sites multiplié par la fréquence de vos changements de politique dépasse ce qu'une personne peut garder en tête de façon fiable, une préférence d'outillage est devenue un risque opérationnel. Velo est conçu pour ce second cas : un seul tableau de bord pour tout le portefeuille, un journal de consentement propre à chaque client, et un seul extrait de code et un seul jeu de règles de catégories qui valent d'un constructeur à l'autre, avec une réserve : les intégrations natives d'une plateforme doivent quand même être vérifiées partout où elles injectent des balises. Si vous êtes dans le premier cas, nous vous le dirons. Le modèle est présenté sur la page produit.