Les surfaces de suivi Adobe Experience Cloud

Une installation Adobe « unique » représente, du point de vue de la confidentialité, cinq surfaces de suivi distinctes. Chacune pose sa propre question de consentement.

Adobe Experience Cloud ID Service

Le service ECID (chargé depuis cdn.cookielaw.org ou auto-hébergé via Adobe Launch) attribue un identifiant visiteur persistant et le stocke dans les cookies AMCV_*. ECID est le substrat qui relie tous les autres services Adobe — Adobe Analytics, Adobe Target et Adobe Audience Manager utilisent tous le même ECID pour associer des événements à un profil. Contrôler ECID est la décision de consentement fondamentale ; sans lui, aucun des services en aval ne peut identifier le visiteur de manière cohérente.

Adobe Analytics (Site Catalyst)

La balise Adobe Analytics (chargée via s_code.js ou AppMeasurement) rapporte les événements de pages vues et de clics vers l'infrastructure d'analyse d'Adobe. Le script définit les cookies s_cc, s_sq et s_pers entre autres. Comme ECID, c'est une surface d'analyse comportementale nécessitant un consentement opt-in dans l'EU en vertu de l'Article 5(3) d'ePrivacy.

Adobe Target

Le script Adobe Target (chargé via at.js) gère les décisions de personnalisation en temps réel. Il se charge côté serveur, surveille le comportement des visiteurs et modifie le contenu des pages en fonction des règles de segmentation. Les cookies Adobe Target incluent mbox et mboxEdgeCluster. Adobe Target est sans ambiguïté une surface de suivi à des fins marketing.

Adobe Audience Manager

Adobe Audience Manager (la couche DMP, chargée via dpm.demdex.net) est le moteur de segmentation qui construit des audiences pour l'activation dans les médias payants. Il définit le cookie demdex et transfère les données des visiteurs vers le graphe d'identité d'Adobe. AAM est la surface la plus exposée du point de vue réglementaire car elle constitue sans ambiguïté de la publicité comportementale inter-contextes selon le CPRA et du marketing explicite selon le GDPR.

Adobe Real-Time CDP

Adobe Real-Time CDP unifie l'identité à travers les sources web, mobiles et hors ligne, construisant un profil client unique. Du point de vue du consentement, elle hérite par défaut de l'état de consentement le plus permissif parmi ses entrées ; une intégration CMP doit plutôt imposer l'état le plus restrictif.

Les primitives de consentement natives d'Adobe

Adobe a investi considérablement dans les primitives de gestion du consentement, particulièrement depuis 2023. La plateforme expose désormais des surfaces de consentement à chaque couche de la pile.

Adobe Privacy & Consent service

Lancé en 2025, le Privacy & Consent service est la couche de consentement unifiée d'Adobe. Il accepte les décisions de consentement d'un CMP via API ou le signal IAB GPP standard et les propage à travers Adobe Analytics, Adobe Target, Adobe Audience Manager et Adobe Real-Time CDP. C'est le point d'intégration recommandé en 2026.

Extension de consentement Adobe Launch

Pour les déploiements qui utilisent Adobe Launch comme gestionnaire de balises, le framework d'extension de consentement (similaire au mode de consentement de Google Tag Manager) permet de configurer chaque balise Adobe pour attendre des catégories de consentement spécifiques. Les intégrations de OneTrust, TrustArc, Cookiebot et d'autres se connectent à ce framework.

L'API Privacy JS

Adobe Analytics, Adobe Target et ECID exposent une API optIn sur l'objet Adobe au niveau de la page. Appeler visitor.optIn.approve(["aam", "ecid", "target", "analytics"]) accorde le consentement pour les services nommés ; visitor.optIn.deny(...) le révoque. C'est la primitive appropriée pour une application granulaire du consentement par service.

Intégration CMP étape par étape

L'architecture fiable consiste à différer chaque balise Adobe jusqu'à ce qu'une décision de consentement soit enregistrée, puis à propager la décision via le Privacy & Consent service ou l'extension de consentement Adobe Launch.

1. Différer l'initialisation d'Adobe Launch

La bibliothèque Adobe Launch elle-même initialise le gestionnaire de balises qui charge tout le reste. Différez le script Adobe Launch jusqu'à ce que le CMP ait capturé la décision du visiteur. C'est le contrôle le plus déterminant — le faire correctement prévient presque tous les défauts en aval.

2. Configurer les catégories de consentement par service

Associez chaque service Adobe à une catégorie CMP. ECID et Adobe Analytics se contrôlent généralement sous l'analyse ; Adobe Target et Adobe Audience Manager sous le marketing ; Adobe Real-Time CDP sous la catégorie qui couvre l'utilisation en aval la plus permissive. Documentez l'association ; la défense d'audit repose sur elle.

3. Utiliser l'API optIn

Lorsque le CMP déclenche son callback de catégorie acceptée, appelez visitor.optIn.approve([...]) avec les services qui correspondent aux catégories accordées. Le service ECID et les scripts Adobe en aval commenceront à envoyer des événements. Lors de la révocation, appelez visitor.optIn.deny(...) pour les arrêter.

4. Connecter au Privacy & Consent service

Pour l'état de consentement qui doit se propager au-delà de l'application sur la page — dans Adobe Real-Time CDP, dans l'ingestion côté serveur, dans les importations par lots depuis d'autres systèmes — le CMP doit écrire vers le Privacy & Consent service d'Adobe via API. Le service applique ensuite la décision à chaque couche Adobe qui le prend en charge.

5. Honorer la révocation à travers le graphe d'identité

Lorsqu'un utilisateur révoque son consentement, Adobe Real-Time CDP et Adobe Audience Manager doivent retirer l'utilisateur des audiences actives, pas seulement cesser d'ajouter des événements à son profil. Configurez le workflow de suppression du Privacy & Consent service pour se déclencher lors de la révocation, et auditez que les surfaces d'activation d'audience en aval (Google Ads, Meta, LiveRamp) honorent la suppression.

Pièges courants

Quatre erreurs d'intégration représentent la plupart des conclusions d'audit sur les déploiements Adobe d'entreprise.

Laisser Adobe Launch s'initialiser avant le consentement

L'intégration Adobe Launch par défaut charge le gestionnaire de balises au rendu de la page, ce qui initialise ECID et toutes les autres balises qu'Adobe Launch est configuré pour déclencher automatiquement. C'est le défaut le plus courant et le plus facile à corriger — différez le script Adobe Launch.

Traiter ECID comme exempt

Certaines équipes soutiennent qu'ECID est une infrastructure d'identité plutôt qu'un suivi, et contrôlent les services en aval tout en laissant ECID se déclencher. Le cookie ECID est un identifiant non essentiel selon l'Article 5(3) d'ePrivacy, quelle que soit l'utilisation de ses données en aval. Contrôlez-le.

Consentement désynchronisé à travers la pile

Si le CMP enregistre le consentement pour l'analyse mais que l'API optIn n'approuve que ecid et analytics tout en laissant aam et target non spécifiés, le comportement en aval dépend de la plateforme et correspond rarement à ce que le CMP a enregistré. Approuvez l'ensemble complet accordé par l'utilisateur, refusez explicitement le reste.

Oublier l'ingestion côté serveur

Adobe Real-Time CDP prend en charge l'ingestion de données côté serveur depuis les CRM, entrepôts et systèmes hors ligne. Ces flux n'honorent pas automatiquement le consentement côté navigateur. Le Privacy & Consent service doit être appelé depuis le pipeline d'ingestion côté serveur pour appliquer l'enveloppe de consentement.

Liste de vérification d'audit

Six questions concrètes auxquelles répondre pour tout déploiement Adobe Experience Cloud touchant le trafic EU, UK ou Californie.

• Adobe Launch attend-il le consentement ? Ouvrez la page dans une fenêtre privée et confirmez qu'aucune requête vers les domaines Adobe ne se déclenche avant l'acceptation de la bannière.
• L'association service-catégorie est-elle documentée ? Pour chaque service Adobe (ECID, Adobe Analytics, Adobe Target, AAM, Adobe Real-Time CDP), existe-t-il un enregistrement écrit de quelle catégorie CMP le contrôle ?
• L'API optIn correspond-elle à l'état du CMP ? Confirmez que les appels approve/deny listent explicitement chaque service Adobe, l'ensemble accordé correspondant à la décision enregistrée par le CMP.
• Le Privacy & Consent service est-il configuré ? Confirmez que le CMP écrit les décisions vers l'API du Privacy & Consent service afin que les surfaces non-navigateur (Adobe Real-Time CDP, ingestion côté serveur) les honorent.
• Les activations en aval honorent-elles la révocation ? Confirmez que révoquer le consentement retire l'utilisateur des audiences actives dans Google Ads, Meta et LiveRamp, pas seulement des synchronisations futures.
• Les chemins d'ingestion côté serveur sont-ils contrôlés ? Confirmez que les importations CRM et entrepôt dans Adobe Real-Time CDP appliquent la même enveloppe de consentement que les événements navigateur.

Où Adobe s'intègre dans une pile orientée consentement

Les piles marketing d'entreprise construites autour d'Adobe Experience Cloud sont simultanément les plus puissantes et les plus exposantes de toute configuration courante. La bonne nouvelle est qu'Adobe a investi massivement dans les primitives de consentement au cours des deux dernières années, et qu'un déploiement 2026 qui utilise correctement le Privacy & Consent service est nettement plus défendable qu'un déploiement construit uniquement sur l'ancien Visitor ID Service. Le travail réside dans la discipline : documenter l'association service-catégorie, utiliser l'API optIn explicitement plutôt que de s'appuyer sur les paramètres par défaut de la plateforme, propager le consentement aux surfaces côté serveur, et auditer que les activations en aval honorent réellement les révocations. Fait correctement, la même pile Adobe qui pilote la personnalisation et la segmentation pour lesquelles les marketeurs l'ont achetée cesse d'être une exposition silencieuse à la conformité en attente qu'un régulateur la révèle.