TL;DR, Réponse rapide
8 min de lectureLa limite de 7 jours des cookies Safari plafonne tout cookie posé via JavaScript à une expiration de sept jours, quelle que soit l'expiration demandée par le script. L'Intelligent Tracking Prevention de WebKit raccourcit cette limite à 24 heures quand le cookie est posé juste après un clic intersite portant des paramètres d'URL de type tracking. Les cookies posés par le serveur via un en-tête de réponse Set-Cookie, HttpOnly compris, ne sont soumis à aucune des deux limites.
Qu'est-ce que la limite de 7 jours des cookies Safari ?
L'Intelligent Tracking Prevention d'Apple applique la limite de 7 jours des cookies Safari en plafonnant l'expiration de tout cookie posé via JavaScript à sept jours à partir de sa création, quelle que soit la date d'expiration demandée par le script. Un script qui appelle document.cookie et demande une expiration d'un an reçoit sept jours à la place ; Safari réécrit l'expiration en silence et ne renvoie aucune erreur à la page qui a posé le cookie. La limite s'applique au stockage du cookie sur l'appareil, pas à la capacité du site à continuer de demander au visiteur de s'authentifier de nouveau.
Pourquoi Apple a-t-il introduit l'Intelligent Tracking Prevention ?
Apple a intégré l'Intelligent Tracking Prevention à WebKit pour empêcher les traceurs d'utiliser des cookies posés par script et à longue durée de vie comme identifiant durable une fois l'accès intersite aux cookies restreint. Les versions antérieures d'ITP bloquaient les cookies third-party qui suivaient un visiteur entre des sites sans lien entre eux ; les traceurs ont réagi en écrivant leur identifiant dans un cookie first-party sur chaque site via JavaScript, ce qui continuait de fonctionner puisqu'un cookie first-party n'était jamais bloqué. La limite de 7 jours a comblé cette brèche en faisant expirer tout cookie côté client, first-party ou non, sur une horloge courte.

Quand la limite passe-t-elle à 24 heures au lieu de 7 jours ?
WebKit raccourcit la limite à 24 heures quand un cookie est posé via JavaScript immédiatement après une navigation intersite dont l'URL porte une décoration de lien, comme un paramètre de requête utilisé pour transmettre un identifiant de clic ou de campagne, et que le domaine référent est un domaine que le classificateur embarqué de WebKit a signalé comme capable de tracking intersite. Cette règle cible exactement le schéma que produit un clic publicitaire : un visiteur clique sur une publicité, atterrit via une redirection portant un paramètre de tracking, et la page d'atterrissage écrit aussitôt ce paramètre dans un cookie. Sans la limite raccourcie, ce parcours aurait conservé les 7 jours complets.
| Type de cookie | Posé par | Limite ITP |
|---|---|---|
| Cookie JavaScript standard | document.cookie | 7 jours |
| Cookie JavaScript après un clic signalé sur un lien décoré | document.cookie | 24 heures |
| Cookie de réponse serveur, quel que soit le réglage HttpOnly | En-tête Set-Cookie | Aucune limite ITP |
| Cookie de session sans expiration définie | Les deux | Se termine avec la session du navigateur, non plafonné par ITP |
document.cookie tombe sous la limite ; un cookie écrit par le serveur non.Que survit-il à la limite de 7 jours des cookies Safari ?
Les cookies posés directement par le serveur via un en-tête de réponse Set-Cookie survivent intacts à la limite de 7 jours des cookies Safari, puisque la limite ne réécrit que l'expiration des cookies qu'une page pose via JavaScript côté client. Un cookie de session sans attribut Expires ni Max-Age survit aussi à la limite en pratique, puisqu'il se termine déjà à la fermeture de la session du navigateur, plus tôt que sept jours pour la plupart des visiteurs. Ce qui ne survit pas, c'est tout identifiant qu'un script de tracking fait dépendre de document.cookie pour persister au-delà d'une semaine sans que le visiteur revienne directement sur le site.
Les cookies HttpOnly posés par le serveur sont-ils plafonnés eux aussi ?
Non. Un cookie HttpOnly ne peut être créé et lu que via un en-tête de réponse Set-Cookie du serveur, puisque HttpOnly existe précisément pour empêcher JavaScript de toucher au cookie, et la limite de Safari sur les cookies de script ne s'applique qu'aux cookies écrits par JavaScript. Un cookie de session de connexion, un jeton CSRF, ou tout autre cookie que votre backend pose et marque HttpOnly conserve l'expiration que le serveur lui a attribuée, sans aucune réécriture à sept jours ou 24 heures de la part d'ITP.
Que casse la limite de 7 jours des cookies Safari pour l'attribution ?
La limite de 7 jours des cookies Safari casse tout modèle d'attribution qui dépend d'un cookie côté client pour relier un clic publicitaire à une conversion plus d'une semaine plus tard, et raccourcit cette fenêtre à un seul jour quand le clic portait une URL de tracking décorée. Une vente B2B avec un cycle de vente de trois semaines, une commission d'affiliation réclamée lors d'une visite de retour dix jours après le premier clic, ou une campagne de remarketing qui mesure une fenêtre d'attribution de deux semaines perdent toutes, sur Safari, le cookie côté client qui aurait relié le clic d'origine à la conversion finale, bien avant que la conversion ne survienne. Le visiteur n'est pas perdu pour le site ; seul disparaît le cookie posé par JavaScript qui aurait relié deux visites distinctes.

Comment les équipes contournent-elles la limite de 7 jours des cookies Safari ?
Les équipes contournent la limite de 7 jours des cookies Safari en déplaçant l'étape de pose du cookie du JavaScript côté client vers le serveur, puisqu'un en-tête de réponse Set-Cookie provenant de votre propre domaine first-party n'est soumis à aucune des deux limites ITP. Le tracking côté serveur pose le cookie identifiant dans le cadre de la réponse HTTP plutôt que via un appel de script, et le marquer HttpOnly le sort entièrement du champ d'application d'ITP tout en empêchant tout script côté client de le lire ou de le modifier. Passer en revue lesquels de vos cookies first-party et third-party sont encore posés par JavaScript est la première étape pour trouver chaque identifiant que cette limite peut faire expirer en silence.
L'autre voie consiste à ne plus dépendre d'aucun cookie pour l'attribution. Flowsery propose une analytics sans cookie hébergée dans l'UE qui relie les sessions au chiffre d'affaires sans jamais écrire d'identifiant dans un cookie, si bien que les réglages Safari d'un visiteur et les règles d'expiration d'Apple n'ont rien à faire expirer dès le départ.
Questions fréquentes
La limite de 7 jours des cookies Safari s'applique-t-elle aussi à Chrome ou Firefox ?
Non. Les limites de 7 jours et de 24 heures viennent de l'Intelligent Tracking Prevention de WebKit, présente dans Safari et dans tout navigateur construit sur WebKit, y compris Safari sur iOS et iPadOS. Chrome et Firefox utilisent leurs propres systèmes de prévention du tracking, séparés, avec des règles et des durées de limite différentes.
Un site peut-il réinitialiser l'horloge des 7 jours du cookie ?
Seulement si le cookie est réécrit par le serveur via un en-tête Set-Cookie, ou si le visiteur revient directement sur le site et que le script de la page écrit de nouveau le cookie avant l'écoulement des sept jours ; l'une ou l'autre action démarre une nouvelle fenêtre de sept jours. Un cookie jamais renouvelé avant le septième jour expire et disparaît, et le visiteur doit être réidentifié comme si le cookie n'avait jamais existé.
La limite de 7 jours des cookies Safari bloque-t-elle aussi les cookies third-party ?
Les cookies third-party sont bloqués par Safari d'emblée, sous une règle ITP distincte, et n'atteignent jamais la question des sept jours. La limite de 7 jours vise spécifiquement les cookies first-party posés par JavaScript, soit précisément la solution de contournement vers laquelle les traceurs se sont tournés une fois les cookies third-party inopérants.
Effacer les données de site de Safari réinitialise-t-il la limite du cookie ?
Effacer les données de site supprime le cookie immédiatement au lieu de réinitialiser sa limite, si bien que le site repart de zéro à la prochaine arrivée du visiteur, exactement comme si sept jours s'étaient déjà écoulés. La limite régit la durée de vie d'un cookie existant, pas le comportement du cookie une fois supprimé manuellement.
Le stockage local est-il plafonné de la même façon que les cookies ?
Cette page ne couvre que la limite des cookies, puisque c'est la règle spécifique décrite ici. Les mécanismes de stockage côté client autres que les cookies relèvent d'autres volets de l'Intelligent Tracking Prevention, avec leurs propres conditions déterminant quand les données stockées d'un domaine sont effacées, donc traitez les limites de cookies et les autres limites de stockage comme des règles séparées plutôt que de supposer que l'une implique l'autre.
Flowsery
Essai gratuit
Tableau de bord en temps réel
Suivi des objectifs
Suivi sans cookies
Pourquoi certains sites voient-ils encore l'attribution fonctionner au-delà de 7 jours sur Safari ?
Un site continue de fonctionner au-delà de sept jours quand il n'a jamais dépendu d'un cookie posé par JavaScript pour le lien entre le clic et la conversion, parce qu'il pose le cookie identifiant depuis le serveur avec Set-Cookie, ou parce qu'il réidentifie le visiteur via une connexion plutôt que via un cookie. Les sites qui mesurent les conversions sans aucun cookie, via un rapprochement de session côté serveur ou une approche d'analytics sans cookie, ne sont jamais soumis à la limite car il n'existe aucun cookie inscriptible par script qu'ITP puisse faire expirer.
La limite de 7 jours des cookies Safari s'applique-t-elle aux cookies que JavaScript se contente de lire, ou seulement à ceux qu'il pose ?
La limite ne s'applique que lorsque JavaScript écrit un cookie via document.cookie, pas lorsqu'il en lit un. Un cookie posé par le serveur qu'un script se contente de lire garde l'expiration fixée par l'en-tête Set-Cookie, car seules les écritures par script sont réécrites. Les cookies HttpOnly suppriment même cet accès en lecture, mais la règle sur l'écriture couvre déjà la lecture pour tout cookie que JavaScript pourrait sinon voir.
Un lien d'affiliation déclenche-t-il la limite de 24 heures plutôt que celle de 7 jours ?
Seulement si le lien d'affiliation porte des paramètres de suivi décorés, comme un identifiant de clic ou de campagne dans l'URL, et que le domaine référent est marqué par le classificateur de WebKit comme capable de pistage cross-site. Sans ces deux conditions, un lien d'affiliation reste sous la limite standard de 7 jours pour tout cookie posé par JavaScript. L'exemple d'affiliation de cet article, une commission réclamée dix jours après le premier clic, rate déjà la fenêtre de 7 jours, donc la limite plus courte ne ferait qu'aggraver cet écart.
La limite de 7 jours des cookies Safari s'applique-t-elle aussi aux scripts d'analyse third-party ?
Oui, si le script écrit son cookie via document.cookie sur le domaine de la page elle-même, car la limite de 7 jours couvre tout cookie posé côté client, first-party ou non. Ce qui compte pour l'ITP, c'est comment le cookie a été posé, pas quelle entreprise a écrit le script. Une balise d'analyse third-party qui dépend encore de document.cookie pour son identifiant perd cet identifiant au bout de sept jours, exactement comme un script de tracking first-party.
La limite de 24 heures peut-elle raccourcir un cookie qui existait déjà avant le clic sur la publicité ?
La limite de 24 heures ne s'applique qu'à un cookie posé juste après le clic cross-site décoré lui-même ; elle ne revient pas raccourcir un cookie déjà présent sur l'appareil. Un cookie écrit par JavaScript avant que le visiteur ne clique sur la publicité continue de suivre la limite en vigueur au moment de sa création, en général la limite standard de 7 jours. Le clic peut démarrer un nouveau cookie plus limité, mais il ne touche pas rétroactivement celui qui tourne déjà.
Cet article vous a-t-il été utile ?
Dites-nous ce que vous en pensez !
Nous voir plus souvent sur Google
Un clic définit Flowsery comme source préférée. Nos articles remontent alors dans vos À la une, en mode IA et dans les aperçus IA.
Avant de partir...
Flowsery
Des analyses orientées revenus pour votre site web
Suivez chaque visiteur, source et conversion en temps réel. Simple, puissant et sans cookies.
Tableau de bord en temps réel
Suivi des objectifs
Suivi sans cookies
Termes connexes du glossaire


Pourquoi le trafic direct est le fourre-tout de tout ce que l'analytics n'a pas pu attribuer
Une session atterrit en trafic direct quand ni referrer ni tag de campagne ne survivent au saut. Les causes : referrer policy, apps, PDF, redirections, QR.


Comment fonctionne l'analyse web, et où elle s'arrête
Une définition simple de l'analyse web, ce que collecte un script de suivi, les métriques clés et leurs mauvaises lectures.


Comment fonctionne le session replay et ce qu'il ne voit pas
Le session replay reconstruit une visite à partir des mutations du DOM et des saisies, pas d'une vidéo. Ce qu'il capture, ce que le masquage cache, ses limites.


Ce que ces chiffres disent du taux de rebond moyen par secteur
Neuf secteurs suivis affichent un taux de rebond moyen par secteur documenté allant de 35.76% à 48.38%, selon les données Databox datées de septembre 2024.


Comprendre la formule de la valeur moyenne des commandes étape par étape
La formule de la valeur moyenne des commandes divise le revenu par les commandes, et un simple code de remise peut fausser en silence chaque chiffre publié.


Ce que la durée moyenne de session mesure vraiment
En analytics classique, la durée moyenne de session donne zéro temps à la dernière page vue de chaque session et tire la moyenne vers le bas discrètement.
Articles connexes


Pourquoi beforeunload vs pagehide décide si vos analytics survivent
Comparer beforeunload vs pagehide montre pourquoi le mobile saute beforeunload, bloque le bfcache et pagehide envoie fiablement les données via sendBeacon.


Comment l'empreinte digitale du navigateur vous identifie sans cookie
Rendu canvas, polices, taille d'écran et fuseau horaire, combinés par l'empreinte digitale du navigateur en un identifiant qui survit à la suppression.


Le modèle de rapport de bug qu'aucun relecteur ne rejette
Un modèle de rapport de bug nomme chaque champ qu'un relecteur attend, des étapes de reproduction jusqu'à la gravité, sinon le ticket incomplet est rejeté.

