Il n'existe pas une durée unique pour tout ce qui porte le mot cookie. Il faut distinguer la vie du traceur, la conservation des informations produites, la mémoire du choix et le moment où une nouvelle demande de consentement devient nécessaire.
Quatre horloges différentes dans le même parcours
La première horloge concerne l'identifiant déposé sur le terminal. La deuxième concerne les données conservées dans les systèmes après collecte. La troisième mémorise le consentement ou le refus afin de respecter le choix. La quatrième organise la revue de la configuration et l'éventuel renouvellement.
Mettre la même valeur partout crée des contradictions. Un cookie peut disparaître tandis que le profil associé reste en base. À l'inverse, une preuve peut être supprimée trop tôt alors que le traitement continue. Dessinez les quatre lignes séparément et reliez chacune à une finalité.
La durée de vie du traceur doit rester proportionnée
Un traceur strictement nécessaire suit le besoin technique : session, authentification, panier ou sécurité. Un identifiant d'audience ou de personnalisation demande une analyse propre. La valeur maximale d'un outil n'est pas une justification.
La recommandation consolidée de la CNIL donne des repères pour certaines mesures d'audience, notamment une durée de vie qui ne se prolonge pas automatiquement à chaque visite. Vérifiez toujours que les conditions d'exemption sont réellement réunies avant d'appliquer ce cadre.
Les données collectées ont leur propre sort
Suivez ce qui quitte le navigateur. Agrégats, journaux techniques, profils et exports ne répondent pas aux mêmes besoins. Pour chacun, précisez le point de départ, la base active, l'archivage éventuel et l'effacement ou l'anonymisation.
Une donnée agrégée n'est anonyme que si la réidentification n'est plus raisonnablement possible. Retirer le nom ou tronquer un identifiant ne suffit pas toujours. Documentez la méthode et les possibilités de croisement encore disponibles.
Mémoriser le refus sans le contourner
Le site doit se souvenir d'un refus pour ne pas redemander à chaque page. Cette mémoire peut reposer sur un traceur fonctionnel limité au choix. Elle ne doit pas servir de clé publicitaire ou alimenter un autre objectif.
Expliquez ce stockage dans l'information détaillée. Sa durée cherche un équilibre : respecter la préférence assez longtemps, tout en permettant une nouvelle décision lorsque le contexte change. Le refus n'est pas moins digne de preuve que l'acceptation.
Renouveler quand le temps ou le périmètre le justifie
Une nouvelle demande peut devenir nécessaire après une période raisonnable ou un changement substantiel des finalités, des fournisseurs ou des données. Ne sollicitez pas de nouveau simplement parce qu'une campagne souhaite davantage d'acceptations. Le renouvellement doit correspondre à une vraie décision à reprendre.
Conservez la version des finalités. Si seul un partenaire technique change sans effet sur l'usage présenté, analysez si une nouvelle demande est nécessaire ou si une information mise à jour suffit. Une règle automatique de reconsentement à chaque modification mineure fatigue les personnes et affaiblit la valeur du choix.
Empêcher le renouvellement silencieux
Certains scripts repoussent l'expiration à chaque visite. Ce mécanisme transforme une durée annoncée en conservation potentiellement permanente. Testez la date avant et après navigation. Pour les identifiants soumis à une borne, une simple consultation ne doit pas créer artificiellement un nouveau départ.
Regardez aussi les copies : domaine principal, sous-domaines, stockage local, SDK mobile et identifiants côté serveur. Supprimer un cookie visible sans casser le lien avec un profil persistant ne clôt pas la conservation.
Construire une matrice exécutable
Pour chaque traceur, créez les colonnes finalité, catégorie, fournisseur, statut de consentement, durée terminal, durée serveur, déclencheur d'effacement, renouvellement et preuve. Rattachez la ligne à la règle technique correspondante. Cette matrice permet à l'audit de comparer l'annonce et l'exécution.
Ajoutez une alerte avant expiration des contrats ou des versions de SDK. Un fournisseur peut modifier ses durées par défaut lors d'une mise à jour. La revue doit détecter l'écart avant que la politique publiée ne devienne fausse.
Tester le temps sans attendre des mois
Utilisez un environnement de test où l'horloge ou les dates de stockage peuvent être contrôlées. Vérifiez l'expiration, l'absence de prolongation, la suppression des données aval et la conservation mesurée de la preuve. Répétez après retrait.
Le rapport indique la valeur configurée et la valeur observée. Il précise aussi les composants non testables automatiquement, comme une purge réalisée par le fournisseur. Pour ceux-ci, demandez une attestation ou un export démontrant l'exécution.
La règle de gestion à écrire en langage clair
Une phrase par horloge suffit : combien de temps, depuis quel événement, pour quelle raison, et quelle action à la fin. Si l'équipe ne peut pas répondre, la durée n'est pas gouvernée. Elle dépend seulement d'un réglage hérité.
Relisez cette règle lors d'un changement de finalité ou de fournisseur. Une durée n'est jamais une constante décorative. Elle matérialise le moment où l'organisation cesse d'avoir besoin de l'identifiant et accepte de perdre la capacité de rattacher les visites entre elles.
Documenter le point de départ
Une durée n'est applicable que si son déclencheur est clair. Précisez si elle part du choix, de la dernière visite ou d'un changement de configuration. Le même événement doit être lu par l'interface, la preuve et la purge. Testez la frontière en avançant le temps dans un environnement de recette. Cette vérification évite les délais annoncés qui ne correspondent pas au comportement du navigateur.
Commentaires
Aucun commentaire pour le moment