Deux tâches différentes

Lorsqu'un visiteur fait un choix de consentement, deux choses distinctes doivent se produire. D'abord, le navigateur doit mémoriser le choix pour que la bannière ne réapparaisse pas à chaque page et que les balises sachent ce qu'elles ont le droit de faire. Ensuite, vous pouvez avoir besoin de prouver plus tard que le choix a été fait, ce qui a été montré au visiteur et quand. Ces tâches sont souvent confiées à des mécanismes de stockage différents, et les confondre cause de vrais problèmes : des bannières qui réapparaissent sans cesse, des choix qui disparaissent sur certains navigateurs, ou aucun enregistrement à présenter quand on vous le demande.

Cette comparaison examine les trois options courantes — les cookies first-party, le stockage du navigateur comme localStorage, et les enregistrements de consentement côté serveur — et le cas d'usage de chacune.

Option 1 : les cookies first-party

Les cookies sont le lieu traditionnel de l'état de consentement. Les CMP TCF stockent couramment la chaîne de consentement dans un cookie first-party, et beaucoup y stockent aussi leurs propres données de préférences.

Points forts

• Lisible par le serveur. Le cookie est envoyé avec chaque requête : le code côté serveur, la logique de périphérie et le tagging côté serveur peuvent donc lire le choix sans attendre JavaScript.
• Partageable entre sous-domaines. Un cookie défini sur votre domaine enregistrable peut couvrir les sous-domaines www, blog et shop.
• Largement attendu. De nombreuses intégrations ad tech cherchent le consentement dans les cookies.

Points faibles

• Limites de taille. Les navigateurs plafonnent la taille d'un cookie à environ 4 Ko, et une chaîne TCF comportant de nombreux fournisseurs plus d'autres valeurs peut s'en approcher.
• Surcharge des requêtes. Chaque requête vers votre domaine transporte le cookie, y compris les requêtes d'images et de scripts.
• Plafonds de durée de vie dans certains navigateurs. L'Intelligent Tracking Prevention de Safari limite à sept jours maximum la durée de vie des cookies créés via JavaScript. Les cookies définis par votre propre serveur dans une réponse HTTP sont généralement traités plus généreusement, avec toutefois des exceptions.

Option 2 : localStorage et autres stockages du navigateur

Certains CMP stockent des préférences détaillées dans localStorage, parfois en complément d'un cookie plus petit.

Points forts

• Plus d'espace. Plusieurs mégaoctets par origine, de quoi enregistrer des choix détaillés au niveau des fournisseurs.
• Aucune surcharge des requêtes. Rien n'est envoyé automatiquement au serveur.

Points faibles

• Invisible pour le serveur. Le code côté serveur et la logique de périphérie ne peuvent pas le lire : toute décision côté serveur doit donc attendre le navigateur.
• Lié à une seule origine. Le stockage sur www.example.com n'est pas disponible sur shop.example.com : un visiteur peut donc revoir la bannière sur chaque sous-domaine.
• Sujet à suppression. Safari peut supprimer le stockage modifiable par script, localStorage compris, pour les sites avec lesquels l'utilisateur n'a pas interagi pendant sept jours d'utilisation du navigateur, et les modes de navigation privée l'effacent généralement à la fin de la session.

Option 3 : les enregistrements de consentement côté serveur

Un enregistrement côté serveur est une entrée stockée par vous ou par votre fournisseur de CMP chaque fois qu'un choix est fait. Il contient généralement un identifiant pseudonyme, l'horodatage, les choix, la version de la bannière ou de la politique affichée, et un contexte tel que la région.

Points forts

• Preuve durable. Il survit à l'effacement des cookies et aux restrictions des navigateurs, ce qui en fait l'outil adapté pour démontrer que le consentement a été obtenu.
• Auditable. Vous pouvez produire des rapports sur les choix dans le temps et répondre à des questions sur des événements précis.
• Potentiel multi-appareils. Pour les lecteurs connectés, un enregistrement serveur peut synchroniser les choix entre appareils, si vous le leur expliquez.

Points faibles

• Ne remplace pas l'état local. Les balises dans le navigateur ont toujours besoin d'un signal local rapide ; interroger un serveur à chaque page vue pour retrouver le consentement ajoute de la latence.
• C'est lui-même une donnée personnelle. Les enregistrements exigent une durée de conservation, des contrôles d'accès et une place dans votre notice de confidentialité.
• Dépendance à un identifiant. Les visiteurs anonymes ne peuvent être rattachés à un enregistrement que par un identifiant stocké sur leur appareil, ce qui vous ramène au stockage local.

Synthèse côte à côte

• Le meilleur pour mémoriser le choix sur le web : les cookies first-party, idéalement définis par votre serveur pour une durée de vie stable.
• Le meilleur pour des données de préférences détaillées dans le navigateur : localStorage, associé à un cookie que le serveur peut lire.
• Le meilleur pour prouver le choix : les enregistrements côté serveur.
• Le pire choix unique : ne s'appuyer que sur localStorage, ce qui laisse le serveur aveugle et rend le choix fragile sur certains navigateurs.

Une approche combinée pratique

1. Stockez le signal local de référence — par exemple la chaîne TCF et un enregistrement compact des préférences — dans un cookie first-party limité à votre domaine enregistrable.
2. N'utilisez localStorage que pour des données complémentaires qui n'ont pas besoin d'atteindre le serveur.
3. Écrivez un enregistrement côté serveur pour chaque choix, en y incluant la version de la bannière et de la politique affichées.
4. Si un choix stocké disparaît, réaffichez la bannière plutôt que de supposer une réponse précédente.
5. Définissez une période de nouvelle sollicitation pour les choix stockés et consignez-la dans votre politique.

Le stockage du choix de consentement du visiteur lui-même est généralement considéré comme nécessaire pour fournir le service que le visiteur a demandé — mémoriser sa décision — mais vérifiez les orientations applicables dans vos principaux marchés.

À retenir

• Mémoriser un choix et prouver un choix sont deux tâches différentes qui demandent des stockages différents.
• Les cookies sont lisibles par le serveur et partageables entre sous-domaines, mais limités en taille et, dans Safari, en durée de vie lorsqu'ils sont définis par script.
• localStorage offre de l'espace mais reste invisible pour le serveur et peut être effacé par les navigateurs.
• Les enregistrements côté serveur constituent la couche de preuve, et non un substitut au signal local.
• Combinez un cookie first-party défini par le serveur, un stockage navigateur facultatif et des enregistrements serveur.