tech

« Cookieless » : promesse marketing et réalité technique, une plongée technique

Par Laurent Fidahoussen, le 12 novembre 2026

Introduction

Le mot « cookieless » est devenu le buzzword le plus chaud du marketing digital et de l’ad tech. Impossible d’aller à une conférence, de lire un pitch d’éditeur ou de parcourir LinkedIn sans tomber sur une « solution cookieless ». Google a abandonné la dépréciation des cookies tiers dans Chrome, Safari les bloque, Firefox les cloisonne, et le RGPD et ePrivacy durcissent les exigences de consentement. Tout le monde cherche des alternatives.

Mais la question qui dérange est la suivante : quand une solution se dit « cookieless », que veut dire ce mot, concrètement ? Dans la plupart des cas : « on vous suit toujours, on a juste changé de méthode ». Dans cet article, on ouvre les DevTools du navigateur, on inspecte les vrais cookies, on examine le local storage et on écrit du JavaScript pour détecter la réapparition des identifiants. À la fin, vous saurez auditer n’importe quel site pour voir quelles techniques de suivi il utilise réellement.

1. Contexte : pourquoi tout le monde parle de « cookieless »

Les cookies tiers (posés par un domaine autre que celui que vous visitez) ont été pendant des décennies la colonne vertébrale du suivi inter-sites. Les navigateurs les éliminent :

Côté réglementation, le RGPD et la directive ePrivacy exigent un consentement explicite pour les cookies non essentiels, et la CNIL a publié des lignes directrices qui rendent le suivi persistant plus difficile à justifier. Les éditeurs martech l’avaient vu venir : « cookieless » est devenu un argument commercial (« future-proof », « privacy-first »). La réalité est bien plus nuancée, et souvent trompeuse.

2. Le Master ID : faire persister un identifiant

Une des techniques « cookieless » les plus sophistiquées est l’approche Master ID : au lieu de s’appuyer sur un seul cookie, on crée un réseau d’identifiants qui se sauvegardent mutuellement.

2.1 Commanders Act : CAID + Phoenix

Le CAID (Commanders Act ID) est un Master ID bien documenté : un cookie first-party de 24 caractères, combinant l’année et des chiffres aléatoires, expirant au bout de 12 mois. Dans Chrome DevTools (F12) → Application → Cookies → votre domaine, cherchez :

CookieRôleDurée typique
CAIDMaster ID (Commanders Act ID)12 mois
TCIDID visiteur Commanders Act sur .commander1.com (tiers)365 jours
TC_PRIVACYChoix de consentement13 mois
tC_CJ_*Déduplication du parcours clientVariable
TC_PRIVACY_CENTERPréférences d’affichage du centre de confidentialité13 mois

Pour lire le CAID :

// In browser console
document.cookie.split('; ').find(row => row.startsWith('CAID='))
// Example output:
// "CAID=202512345678901234567890"
// Year (2025) + 20 random characters

Phoenix est la réponse de Commanders Act à l’ITP de Safari, qui supprime les cookies écrits par JavaScript après 7 jours sans interaction. D’après la documentation de Commanders Act (Phoenix, liste des cookies), Phoenix tourne sur un sous-domaine que vous routez vers leur service (via votre CDN ou WAF), copie les cookies first-party concernés par l’ITP dans des cookies Secure HttpOnly posés par le serveur, que l’ITP ne plafonne pas, puis recrée le cookie d’origine à partir de cette copie à une visite ultérieure, quand Safari l’a supprimé. Depuis le 06/05/2024, ses cookies s’appellent « FIRST » au lieu de « PHOENIX ».

Pour tester la régénération :

// Step 1: Note your current CAID
const originalCAID = document.cookie.split('; ')
  .find(row => row.startsWith('CAID='))
  ?.split('=')[1];
console.log('Original CAID:', originalCAID);

// Step 2: Delete the CAID cookie. It is set on .yourdomain.com, so the domain is required
// (or delete it in DevTools > Application > Cookies)
document.cookie = 'CAID=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/; domain=.' + location.hostname.replace(/^www\./, '') + ';';

// Step 3: Verify it's gone
console.log('CAID after deletion:', 
  document.cookie.split('; ').find(row => row.startsWith('CAID=')));
// Should return undefined

// Step 4: Reload the page and check again
// (You'll need to reload manually)

// Step 5: After reload, check if CAID was regenerated
const newCAID = document.cookie.split('; ')
  .find(row => row.startsWith('CAID='))
  ?.split('=')[1];
console.log('New CAID:', newCAID);
console.log('Match?', originalCAID === newCAID);

Si le cookie a bien disparu à l’étape 3 et revient avec la même valeur après le rechargement, il a été recréé à partir d’une sauvegarde. Si l’étape 3 affiche encore une valeur, la suppression a échoué et le test ne prouve rien. Certains montages stockent aussi des données Commanders Act dans le local storage (clés comme tC.visitor_id, TC_PRIVACY, tC.id_sync_data) : à vérifier.

2.2 Adobe : l’écosystème ECID

Adobe suit une approche voisine avec son Experience Cloud ID (ECID). Dans DevTools → Application → Cookies :

CookieRôleDurée typiqueType
AMCV_{ORG_ID}Experience Cloud Visitor ID (contient l’ECID)2 ans (tronqué à 13 mois)First-party
s_ecidCookie de référence de l’ECID (posé par réponse HTTP)13 moisFirst-party
s_viID visiteur Analytics historique (posé par réponse HTTP)2 ans ; bloqué par Safari en tiers, 7 jours via un CNAME first-party masquéFirst ou tiers
s_fidID de secours quand s_vi ne peut pas être posé2 ansFirst-party
demdexID de synchronisation inter-domaines (UUID)180 joursTiers (demdex.net)

L'{ORG_ID} dans le nom du cookie AMCV est l’identifiant d’organisation Adobe Experience Cloud. Le cookie AMCV contient plusieurs informations en paires clé-valeur séparées par des pipes :

// Extract and decode AMCV cookie
function decodeAMCV() {
  const amcvCookie = document.cookie.split('; ')
    .find(c => c.startsWith('AMCV_'));
  
  if (!amcvCookie) {
    console.log('No AMCV cookie found');
    return;
  }
  
  const cookieValue = decodeURIComponent(amcvCookie.split('=')[1]);
  const parts = cookieValue.split('|');
  
  console.log('=== AMCV COOKIE STRUCTURE ===');
  for (let i = 0; i < parts.length; i += 2) {
    const key = parts[i];
    const value = parts[i + 1];
    console.log(`${key}: ${value}`);
    
    // Highlight the ECID
    if (key === 'MCMID' || key === 'MID') {
      console.log('  ^^^ THIS IS YOUR ECID (Experience Cloud ID)');
    }
  }
}

decodeAMCV();

Si l'API Visitor d'Adobe est chargée, on peut aussi lire l'ECID directement (window.s.visitor.getMarketingCloudVisitorID()). Enfin, le FPID (First-Party Device ID) est posé côté serveur par le client et sert à initialiser l'ECID : s'il est présent, c'est le signe d'un montage conçu pour contourner les limites de l'ITP.

3. Le Local Storage : le cookie qui ne dit pas son nom

Astuce favorite : arrêter les cookies et passer au local storage. Problème réglé ? Pas vraiment. Le local storage est un mécanisme HTML5 de stockage dans le navigateur. Contrairement aux cookies : pas de date d'expiration fixée par le site (mais Safari le supprime après 7 jours sans interaction), plus de capacité (5 à 10 Mo contre 4 Ko), et il n'est pas envoyé avec les requêtes HTTP.

Pour l'inspecter : DevTools → Application → Local Storage → votre domaine, puis chercher des clés liées au suivi (user_id, visitor_id, session_id, amplitude_*, mixpanel_*…). Contre-exemple : GA4 stocke ses identifiants dans des cookies first-party (_ga, _ga_<container-id>, 2 ans), pas dans le local storage (Google : usage des cookies GA4).

Beaucoup de solutions stockent le même identifiant à la fois dans un cookie et dans le local storage : la sauvegarde mutuelle. Pour tester si un site le fait, repérez un cookie de suivi, cherchez sa valeur dans le local storage, supprimez le cookie, rechargez et regardez s'il revient avec la même valeur. Un script d'audit complet couvre aussi sessionStorage et IndexedDB, que certains sites utilisent pour un stockage encore plus persistant :

// Comprehensive storage audit (cookies + local + session + IndexedDB)
async function auditAllStorage() {
  console.log('=== COMPLETE STORAGE AUDIT ===\n');
  
  // 1. Cookies
  console.log('COOKIES (' + document.cookie.split('; ').length + '):');
  document.cookie.split('; ').forEach(c => {
    const [name, value] = c.split('=');
    console.log(`  ${name}: ${value.substring(0, 40)}${value.length > 40 ? '...' : ''}`);
  });
  
  // 2. Local Storage
  console.log('\nLOCAL STORAGE (' + Object.keys(localStorage).length + ' keys):');
  Object.keys(localStorage).forEach(key => {
    const value = localStorage.getItem(key);
    console.log(`  ${key}: ${value.substring(0, 40)}${value.length > 40 ? '...' : ''}`);
  });
  
  // 3. Session Storage
  console.log('\nSESSION STORAGE (' + Object.keys(sessionStorage).length + ' keys):');
  Object.keys(sessionStorage).forEach(key => {
    const value = sessionStorage.getItem(key);
    console.log(`  ${key}: ${value.substring(0, 40)}${value.length > 40 ? '...' : ''}`);
  });
  
  // 4. IndexedDB
  console.log('\nINDEXEDDB:');
  const databases = await indexedDB.databases();
  if (databases.length > 0) {
    databases.forEach(db => console.log(`  ${db.name} (v${db.version})`));
  } else {
    console.log('  None');
  }
}

auditAllStorage();

4. Cookie respawning : les techniques de résurrection

Le cookie respawning (aussi appelé « evercookies » ou « zombie cookies ») consiste à recréer un cookie supprimé à partir de données sauvegardées ailleurs. L'utilisateur croit avoir supprimé son cookie de suivi, mais le site a stocké en secret le même identifiant à plusieurs endroits. Quand il détecte que le cookie a disparu, il le recrée automatiquement depuis la sauvegarde.

Pour le détecter en temps réel, on peut écrire un moniteur qui prend un instantané de tous les cookies, surveille leur disparition, puis note ceux qui reviennent avec la même valeur (le script complet, CookieRespawnDetector, est dans la version anglaise).

La technique la plus sophistiquée, et étonnamment courante, est le fingerprinting : au lieu de stocker l'identifiant côté client, le serveur crée une « empreinte » de votre navigateur (user agent, langues, plateforme, nombre de cœurs, mémoire, rendu canvas, WebGL, polices…) et l'associe à votre identifiant de suivi. On peut détecter l'activité de fingerprinting en surveillant les appels à toDataURL (canvas) ou les requêtes réseau vers des endpoints dont l'URL contient « fingerprint », « canvas », « webgl » ou « device info ».

5. Ce que « cookieless » veut vraiment dire

Le « cookieless » existe sur un spectre :

  1. « Pas de cookies tiers » : l'affirmation la plus courante. Techniquement exacte, mais ils utilisent toujours des cookies pour un suivi persistant, simplement sur le domaine first-party.
  2. « Pas de cookies côté client » : les cookies sont posés côté serveur via des en-têtes HTTP Set-Cookie. Pour vérifier : onglet Network, une requête, Response Headers.
  3. « Pas de cookies, seulement du local storage » : c'est du théâtre de la vie privée, comme vu plus haut.
  4. « Tout le tracking est server-side » : l'identifiant n'est peut-être pas stocké côté client du tout. Certains éditeurs server-side peuvent retomber sur IP + User-Agent pour relier les requêtes : posez la question. On peut aussi chercher des paramètres de suivi dans les URL (utm_, fbclid, gclid, msclkid…).
  5. « Fingerprinting pur » : « on ne stocke rien côté client ».

6. Les questions juridiques (je ne suis pas juriste, mais…)

7. Ce qui compte vraiment : la transparence

Mon avis après 10 ans dans l'ad tech et l'analytics : « cookieless » est devenu un habillage marketing. Le terme ne veut plus dire ce qu'il dit, et il obscurcit plus qu'il n'éclaire. Face à un éditeur qui se dit « cookieless », posez-lui ces questions :

Identifier les utilisateurs n'est pas mal en soi : gestion de session, personnalisation, analytics, attribution et lutte contre la fraude sont des raisons légitimes. Mais la transparence et le respect passent en premier : dire clairement ce que l'on fait et pourquoi, donner un vrai contrôle, respecter les refus. Ne pas se dire « cookieless » en utilisant six techniques de persistance. Ne pas régénérer les identifiants après leur suppression. Ne pas se cacher derrière le jargon.

Conclusion

Le « cookieless » n'est pas binaire : c'est un spectre. Les techniques décrites ici sont réelles, et leur licéité dépend du consentement et de la transparence, pas du type de stockage. Vous avez maintenant de quoi auditer vous-même n'importe quel site : scripts d'inspection pour Commanders Act et Adobe, outils d'audit du stockage, détecteurs de respawning, moniteurs de fingerprinting.

Sources

Pour aller plus loin, lisez la version complète de l'article (en anglais), avec tous les scripts d'audit : “Cookieless”: Marketing Promise vs Technical Reality – A Deep Technical Dive.

Besoin d'aide sur ce sujet ? Consent Mode v2 et CMP.

Vous doutez de votre tracking ?

Réserver un appel Ou commencez par l’audit analytics gratuit →