Durée du consentement aux cookies : quand la bannière doit reposer la question

Tous les articles

Le RGPD ne fixe aucune expiration pour le consentement aux cookies : il dure donc le temps que votre autorité de contrôle accepte, couramment fixé à douze mois. La bannière doit reposer la question quand cette durée est écoulée, quand les fournisseurs ou les finalités pour lesquels vous collectez changent, ou quand aucun enregistrement de consentement valide ne peut être lu. En pratique, la plupart des bannières réapparaissent bien plus tôt que la durée configurée, pour des raisons qui n'ont rien à voir avec la loi.

La loi ne fixe aucune horloge. Les régulateurs en fixent plusieurs.

Mieux vaut être précis, car beaucoup de conseils publiés présentent un chiffre comme s'il s'agissait d'une loi. Aucun article du RGPD ne fixe de durée de vie au consentement. Ce que le règlement exige, c'est que le consentement reste un reflet fidèle de ce que le visiteur a accepté.

Les durées viennent des lignes directrices. Le Comité européen de la protection des données recommande de renouveler le consentement à intervalles appropriés, sans en fixer un. Les autorités de contrôle nationales en ont chacune tiré leurs propres chiffres, ce qui explique que les conseils publiés se contredisent aussi volontiers. Le régulateur britannique ne fixe aucune durée : ses lignes directrices sur les cookies suggèrent d'envisager de redemander à intervalles adaptés, et de redemander quand votre usage des cookies change. Les chiffres couramment cités vont de six à vingt-quatre mois, et douze mois est devenu la valeur de référence parce qu'il se situe dans la majeure partie de cette fourchette. Nous ne reprenons volontairement ici aucun chiffre national précis. Les chiffres qui circulent dans les articles de blog confondent régulièrement des règles différentes, et la seule source fiable pour la durée qui s'impose à vous est votre propre autorité de contrôle.

La conséquence que les lignes directrices énoncent rarement clairement : quel que soit le chiffre choisi, c'est un maximum, pas une promesse. Il fixe combien de temps vous pouvez vous appuyer sur un consentement stocké, pas combien de temps l'enregistrement survit, et sur une bonne partie de votre trafic, les deux sont très loin l'un de l'autre.

Pourquoi votre bannière réapparaît-elle sans cesse ?

Le consentement n'est pas un état juridique qui persiste quelque part dans l'abstrait. C'est un enregistrement : un cookie ou une entrée de stockage local, dans un navigateur que vous ne contrôlez pas et qui décide de sa durée de vie.

Si votre outil de consentement écrit cet enregistrement sous forme de cookie propriétaire depuis JavaScript, la prévention du suivi de Safari plafonne sa durée de vie à sept jours, et à vingt-quatre heures pour un visiteur arrivé par un lien enrichi par un traceur connu. Configurez douze mois, cela ne change rien : l'enregistrement disparaît en moins d'une semaine, et chaque visiteur Safari qui revient ensuite revoit la bannière comme s'il n'avait jamais répondu. Le stockage local produit le même résultat par un autre chemin.

Un enregistrement déposé par votre propre serveur dans un en-tête de réponse HTTP échappe à ce plafond lié aux scripts, c'est pourquoi les implémentations durables procèdent ainsi. Une condition s'applique : si le point de terminaison est atteint via un nom qui pointe vers un service tiers au lieu de vous appartenir réellement, Safari le traite comme tiers et le plafond revient.

Rien de tout cela n'est exotique. C'est le comportement ordinaire d'une grande partie du trafic mobile européen, et c'est la différence entre demander une fois par an et demander cinquante fois.

Trois raisons pour lesquelles une bannière redemande, et une seule est l'expiration

1. La durée s'est réellement écoulée

   Le visiteur a consenti, l'enregistrement a survécu et la durée que vous avez configurée est arrivée à son terme. C'est le seul cas qui fonctionne comme prévu, et ce devrait être la cause la plus rare dans un ticket de support. Un visiteur qui signale des demandes chaque semaine n'est presque certainement pas dans ce cas.

2. L'enregistrement n'a jamais survécu

   Bien plus fréquent, et invisible depuis l'écran de réglages, qui montre ce que vous avez demandé plutôt que ce qui s'est passé. Acceptez, puis lisez ce qui a réellement été écrit et avec quelle expiration, et revenez une semaine plus tard sur Safari.

3. L'enregistrement est illisible là où se trouve le visiteur

   Un consentement stocké sur l'hôte www n'est pas lu sur le domaine racine, et aucun des deux n'est lu sur un checkout situé sur un autre sous-domaine ou domaine. L'enregistrement existe, mais la page qui pose la question ne peut pas le voir. Vérifiez le domaine et le chemin sur lesquels il est écrit avant de conclure à une expiration.

4. Un élément important a changé, et l'ancien consentement ne le couvre plus

   Un nouveau fournisseur, une nouvelle finalité, une nouvelle catégorie de cookie. Le consentement est propre à ce qui a été décrit au moment où il a été donné : élargir cet ensemble invalide la réponse stockée, aussi récente soit-elle. Un outil qui honore encore l'ancien enregistrement après un changement de la liste des fournisseurs fait discrètement fausse route.

Pourquoi redemander plus souvent que nécessaire coûte cher

Sous l'angle de la conformité, une durée plus courte paraît automatiquement plus sûre, mais côté mesure, elle n'est pas gratuite. Chaque demande est une occasion de plus de refuser, et ceux qui refusent sont soustraits de tout ce que vous mesurez ensuite. Une bannière qui réapparaît parce que l'enregistrement était plafonné à sept jours obtient donc un taux d'acceptation plus faible que la même bannière demandant une fois par an, sans que personne n'ait choisi ce compromis ni ne le voie dans un tableau de bord.

Cela s'ajoute à ce que le consentement retire de toute façon. L'ampleur dépend de votre région, de votre audience et du design de votre bannière. Pour mesurer votre propre part, consultez le taux de consentement dans votre CMP, ou comparez les sessions GA4 aux journaux de requêtes de votre serveur ou de votre CDN. Un défaut de durabilité s'y ajoute sans rien rapporter, ce qui en fait l'un des rares problèmes de consentement qui soit une perte pure. Ce qu'un refus fait à vos rapports est expliqué dans ce que deviennent les données GA4 quand les utilisateurs refusent les cookies, et l'envoi ou non d'un signal en cas de refus dépend du choix entre Consent Mode basique et avancé.

La réponse honnête est donc : aussi longtemps que votre régulateur l'accepte, et pas une visite de moins par accident. Choisissez la durée délibérément, puis vérifiez que l'enregistrement vit réellement aussi longtemps. Ce sont deux chantiers distincts, et seul le premier a un écran de réglages. L'autre bout de la même question, ce qui doit se passer au moment où un visiteur retire son consentement, est traité dans ce qui se passe quand quelqu'un retire son consentement aux cookies.

Velo dépose l'enregistrement du consentement depuis le serveur plutôt que depuis un script : ce n'est donc pas le plafond de sept jours qui décide de sa durée, et la question est reposée quand l'ensemble des fournisseurs change, pas seulement selon un minuteur. Aucun outil ne peut survivre à un visiteur qui efface son stockage, et aucun ne devrait le prétendre. Le mécanisme est présenté sur la page produit.