La bannière de cookies est l'un des rares éléments d'un site à réussir le grand chelem : elle agace le visiteur, fait baisser la conversion et, dans la plupart des cas, ne met même pas en conformité. C'est presque toujours un plugin installé à la hâte et laissé en configuration par défaut. Avant de toucher au design, mieux vaut savoir ce qu'exige exactement la réglementation andorrane, qui n'est pas celle que presque tout le monde imagine, et quelle marge réelle elle vous laisse pour ne pas faire fuir celui qui vient d'arriver. L'implémentation présentée est en Laravel, l'un des stacks sur lesquels nous travaillons, mais le blocage des scripts et la preuve du consentement se montent de la même façon sous WordPress, Next.js ou autre.
En Andorre, il n'y a pas de loi sur les cookies, il y a une loi sur le consentement
Cela déroute ceux qui arrivent d'Espagne en s'attendant à trouver une norme équivalente à celle des communications électroniques. Elle n'existe pas.
Ce qui existe, c'est le Reglament del 28 de setembre del 2022 d'aplicació de la Llei 29/2021, qualificada de protecció de dades personals, et son article 8 alinéa 2 le dit sans détour :
"Les característiques i les condicions establertes als articles 7 i 8 de la Llei 29/2021 [...] són el marc legal per redactar polítiques de privacitat de pàgines web i polítiques informatives de rastrejadors web."
Autrement dit : les traceurs web relèvent des règles générales de consentement, et non d'une loi à part. Et ces règles, dans le même article, sont bien plus exigeantes que ce que respecte la plupart des bannières. Vous pouvez lire le texte consolidé sur le Portal Jurídic.
Trois de ces règles conditionnent la conception tout entière.
Refuser doit coûter autant qu'accepter
L'article 8.1.a exige que le consentement soit libre, étant entendu par libre que l'utilisateur ait eu un choix réel et non conditionné au fait de subir un préjudice s'il ne le donne pas. Et le 8.1.e ajoute que seul est valable le consentement qui peut être révoqué ou refusé gratuitement et sans effets négatifs.
En pratique, cela veut dire que les trois boutons (configurer, tout refuser, tout accepter) vont sur la même ligne et à la même taille. Le schéma qui consiste à cacher "refuser" derrière deux clics, ou à le peindre en gris clair sur blanc pendant qu'"accepter" prend la couleur de la marque, est exactement ce que la norme décrit comme un choix conditionné.
Si vous devez jouer quelque chose ici, le conseil est d'aplatir le contraste entre les deux boutons. Avec un système basé sur des variables CSS, c'est changer une ligne, pas refaire le composant.
L'article 8.1.d ferme la porte au consentement tacite
Littéralement : "El consentiment no pot ser implícit o tàcit", et "el silenci o la inacció de l'interessat no es poden considerar eines vàlides per atorgar el consentiment".
Traduit en code : toutes les catégories optionnelles naissent désactivées et ne s'activent que par un clic. Pas de "si vous continuez à naviguer, vous acceptez". Pas de cases précochées. Et pas d'activation de l'analytique pendant que l'utilisateur décide.
Cette dernière est celle que l'on enfreint le plus, et c'est elle qui transforme une bannière correcte en décoration.
Une bannière sans blocage de scripts est décorative
Installer une bannière et considérer la conformité acquise est ce que font la plupart des sites, et cela se comprend : la bannière apparaît, le visiteur clique, l'écran disparaît. Rien dans cette séquence ne signale que les scripts que l'on voulait contrôler avaient déjà été chargés avant même le clic.
Un composant de consentement enregistre un choix et signale qu'il a changé. C'est tout ce qu'il peut faire. Si votre application charge le script d'analytique dans le <head> quoi qu'il arrive, la bannière ne protège rien : elle documente noir sur blanc que vous saviez qu'il fallait demander l'autorisation et que vous l'avez demandée après avoir collecté.
La partie que votre application doit écrire, c'est la porte :
const prefs = JSON.parse(localStorage.getItem('cookie-preferences') || '{}');
if (prefs.analytics) {
// c'est seulement ici que le script d'analytique est injecté
}
window.addEventListener('wirecookies-saved', (e) => {
if (e.detail.marketing) { /* activer les pixels */ }
});
Ce sont dix lignes, et ce sont les dix qui séparent la conformité de l'apparence de conformité.
Andie recommande
L'article 8.1.g du règlement oblige à arrêter le traitement si quelqu'un retire son consentement. Cela implique que la porte ne peut pas être vérifiée uniquement au chargement de la page : il faut aussi écouter l'événement de changement, car un utilisateur peut désactiver l'analytique sans recharger. Si vous ne lisez la valeur qu'au démarrage, un refus ultérieur ne prend effet qu'à la visite suivante.
La bannière qui ne bloque pas convertit mieux et c'est aussi celle qui est conforme
On vit généralement cela comme un conflit : se conformer coûte de la conversion, alors on cherche la bannière la plus agressive que le conseil juridique laissera passer. Avec la réglementation andorrane sous les yeux, cette tension se révèle fausse, et le design qui dérange le moins est aussi celui qui tient devant une inspection.
Un mur de cookies n'est pas conforme au 8.1.a, car il conditionne l'accès à l'octroi du consentement. Et c'est en plus ce qui génère le plus de rebond : le visiteur arrive depuis une recherche, tombe sur un écran qui lui masque le contenu et fait demi-tour.
L'alternative correcte est aussi celle qui convertit : un bandeau en bas qui ne masque rien, sans voile sombre, avec la page navigable pendant que l'utilisateur décide. S'il ne décide pas, rien n'est enregistré et rien d'optionnel n'est activé. Juridiquement impeccable et sans friction.
Il y a deux autres détails qui pèsent sur des métriques réelles. La bannière apparaît avec un léger retard, de l'ordre de 800 millisecondes, pour ne pas entrer dans le premier rendu et ne pas compter comme un décalage de mise en page. Et une fois le choix fait, elle ne réapparaît plus jamais, parce que le choix persiste. Une bannière qui revient à chaque visite fait partie des rares éléments capables de couler une conversion à eux seuls.
Pouvoir retirer son consentement n'est pas une politesse
L'article 8.1.c est littéral et très concret : "Els mecanismes posats a disposició de l'interessat per part del responsable de retirar el consentiment han de ser tan intuïtius i accessibles com els que facilita per obtenir el consentiment."
Autrement dit, si vous avez demandé l'autorisation avec une bannière visible, la retirer doit être tout aussi visible. L'enterrer dans un paragraphe de la politique de confidentialité n'est pas conforme.
La solution est un bouton flottant discret qui persiste après le choix et rouvre le même panneau de préférences. Il prend peu de place, ne gêne pas, et c'est la pièce qui transforme la bannière en mécanisme bidirectionnel au lieu d'une porte à sens unique.
Si vous avez un autre bouton flottant dans le coin, mettez-les dans des coins différents. Cela paraît évident et c'est la collision la plus fréquente.
L'endroit où le choix est stocké change ce que vous pouvez en faire
Il y a une décision que presque personne ne prend consciemment et qui conditionne tout ce qui suit : stocker le consentement dans un cookie ou dans localStorage. Cela paraît interchangeable et ne l'est pas, car un cookie voyage à chaque requête tandis que localStorage ne quitte jamais le navigateur.
Pour : le composant qui gère le consentement aux cookies ne dépose aucun cookie, ne voyage pas à chaque requête et n'est pas en soi un traitement qu'il faille consentir.
Contre : le serveur ne peut pas le lire. Vous ne pouvez pas décider en PHP s'il faut intégrer ou non le script d'analytique ; la décision est toujours côté client. Et localStorage est par origine, donc un sous-domaine différent demande le consentement séparément.
Pour un site web normal, l'échange est rentable. Si votre cas exige de décider côté serveur, il vous faut un cookie, en sachant que ce cookie est technique et n'exige pas de consentement préalable.
La preuve du consentement, c'est votre application qui la fournit
La bannière règle la demande de consentement et son respect. Ce qu'elle ne règle pas, et que presque aucun projet n'anticipe avant qu'on le lui demande, c'est de prouver des mois plus tard que tel visiteur a accepté telle chose à telle date.
Enregistrer le choix dans le navigateur résout le comportement, pas la responsabilité proactive qu'exige l'article 5.3 de la Llei 29/2021. Si l'Agència Andorrana de Protecció de Dades demande quand un utilisateur précis a consenti et à quelle version de la politique, le navigateur de cette personne n'est pas une réponse.
Si votre exposition le justifie, ce qu'il faut ajouter est un journal côté serveur avec date, catégories acceptées et version de la politique. C'est une table et un endpoint, et cela se branche sur le même événement d'enregistrement. Si votre site est informatif et que vous ne chargez rien de plus que le strict nécessaire, vous n'en aurez probablement pas besoin.
La même logique vaut pour l'expiration. Un choix enregistré n'expire pas tout seul ; si vous voulez le renouveler à intervalles réguliers, il faut ajouter un horodatage et le vérifier.
Ce qui existe sur le marché et en quoi c'est différent
Les plateformes de gestion du consentement font des choses qu'un composant ne fait pas, et il vaut mieux savoir lesquelles.
Cookiebot et OneTrust scannent votre site périodiquement, détectent quels cookies et quels tiers il charge, génèrent la déclaration et tiennent un registre des consentements côté serveur avec sa preuve. Pour une entreprise avec beaucoup de domaines et beaucoup de tiers, c'est du travail réel que l'on externalise. Le compromis : coût récurrent par domaine, un script externe chargé sur toutes vos pages et qui devient donc un tiers de plus sur votre chemin critique, et une esthétique qui est la leur.
Axeptio soigne davantage l'expérience et le même échange demeure : script externe et abonnement.
La différence d'approche, quand on le résout à l'intérieur de sa propre application, c'est que rien ne sort de la page. Pas de requête à un tiers pour décider si vous pouvez faire des requêtes à des tiers, pas de coût par domaine, et l'apparence est celle de votre produit parce qu'elle partage les mêmes variables CSS que le reste de votre interface. En échange, le blocage des scripts et le journal de la preuve, c'est vous qui les écrivez : les dix lignes et la table plus haut.
Et si vous ne travaillez pas avec Laravel
Les critères ne dépendent pas du langage et servent à juger n'importe quelle solution :
- Que les catégories optionnelles naissent désactivées. Si elles arrivent précochées, le consentement n'est pas valable.
- Qu'accepter et refuser aient le même poids visuel et le même nombre de clics.
- Qu'il existe un moyen visible et permanent de changer d'avis.
- Que la bannière ne bloque pas la page. Ni pour la réglementation ni pour la conversion.
- Et que ce soit vous qui contrôliez le blocage des scripts. Si l'outil ne vous donne pas un événement et une valeur lisible, vous ne pouvez pas être conforme même avec une bannière parfaite.
Où se trouve le code
Le paquet est sur Packagist, le code sur GitHub et la documentation du paquet recense toutes les options. Il est sous licence MIT et ne fait aucune requête réseau : il ne trace rien de son côté.
Si vous avez aussi besoin des textes, nous avons un générateur de politique de confidentialité et un générateur de mentions légales pour Andorre.
La conformité en matière de données est l'une des choses les plus chères à corriger tardivement. Nous la traitons en partenaire digital, et si vous nous exposez votre cas, nous vous dirons ce qui vous manque.
