Pourquoi Amplitude exige le consentement

Le SDK Browser Amplitude par défaut et les SDK mobiles Amplitude font bien plus qu'enregistrer des pages vues. À l'initialisation, ils définissent un identifiant d'appareil dans le stockage first-party, génèrent un identifiant de session, capturent le référent, analysent les identifiants UTM et de clic à partir de l'URL, et commencent à mettre en file d'attente les événements capturés automatiquement : pages vues, clics sur des éléments, interactions avec des formulaires, téléchargements de fichiers et — dans les dernières versions — les replays de session. Ils enrichissent également ces événements avec la géolocalisation dérivée de l'IP, les données d'appareil dérivées du user-agent, et, si configuré, l'enrichissement tiers provenant de partenaires de données.

Chacune de ces étapes engage une base juridique de consentement distincte. Le stockage d'un identifiant d'appareil est une opération de stockage et d'accès au titre de l'article 5(3) de la directive ePrivacy, qui exige un consentement préalable, librement donné, spécifique, éclairé et non ambigu dans l'Espace économique européen, au Royaume-Uni et dans toute juridiction ayant adopté la même norme. La capture d'événements comportementaux liés à cet identifiant constitue un traitement de données personnelles au titre du RGPD. L'enrichissement avec des données tierces introduit une deuxième relation de responsable de traitement. Le CCPA et le CPRA classifient le même traitement comme une vente ou un partage, sauf si l'éditeur dispose d'un contrat de prestataire de services correctement délimité avec Amplitude — qui est disponible, mais uniquement si l'intégration est configurée pour désactiver les fonctionnalités publicitaires.

Ce qu'Amplitude collecte avant le consentement — et ce que vous devez supprimer

L'erreur d'implémentation la plus courante consiste à traiter Amplitude comme un outil d'analyse léger pouvant fonctionner en parallèle avec la bannière de cookies. Ce n'est pas possible. Lors d'un appel amplitude.init() par défaut, le SDK, dès le premier rendu de la page, écrira au moins un cookie ou une entrée de stockage local, enverra un appel identify et commencera à mettre des événements en mémoire tampon. Rien de tout cela n'est autorisé avant qu'un utilisateur ait accepté de manière affirmative la catégorie de consentement concernée.

Une intégration conforme doit donc retarder amplitude.init() jusqu'à ce que la CMP ait signalé que la catégorie de consentement analytique a été accordée. Le SDK ne doit pas du tout être chargé depuis une balise <script> soumise au consentement qui dépend du signal de la finalité 8 (analytique) ou de la finalité 1 (stockage et accès) de la CMP, selon le cadre que la CMP expose. Si le SDK doit être chargé plus tôt — par exemple parce qu'il est intégré dans le code de l'application et ne peut pas être récupéré de manière différée — l'appel d'initialisation doit passer defaultTracking: false et optOut: true afin qu'aucun événement ne soit émis avant que le consentement ne soit enregistré, puis un événement d'opt-in différé doit basculer ces indicateurs.

Les cookies et le stockage qu'Amplitude écrit

Le SDK Browser 2.x écrit par défaut un seul cookie first-party nommé AMP_{apiKey} avec une expiration d'un an, contenant l'identifiant d'appareil et les métadonnées de session. Les versions plus anciennes écrivaient également amplitude_id_{apiKey}. Les SDK mobiles conservent le même identifiant dans le stockage sandboxé de l'application. Le replay de session ajoute un second cookie, AMP_MKTG_{apiKey}, et les partenaires d'enrichissement d'Amplitude peuvent définir des cookies tiers supplémentaires si les modules de ciblage d'expérimentation ou d'audiences sont activés. Tous ces éléments sont non essentiels et nécessitent un consentement.

Cartographier Amplitude sur les cadres de consentement

Amplitude n'implémente pas nativement Google Consent Mode v2, l'IAB TCF, ni l'IAB Global Privacy Platform. Ce n'est pas un défaut — Amplitude est une plateforme d'analyse first-party, et non un vendeur ad-tech — mais cela signifie que la responsabilité de l'intégration incombe à l'éditeur. Le schéma qui fonctionne en pratique consiste à traiter chaque module Amplitude comme une porte de consentement distincte et à le lier à un signal spécifique que la CMP expose déjà.

• Les événements d'analyse principaux sont liés à la finalité analytique. En termes de TCF, il s'agit le plus souvent de la finalité 8 (mesurer les performances du contenu) combinée à la finalité 1 (stocker et/ou accéder à des informations). Pour Google Consent Mode, cela correspond à analytics_storage.
• Le replay de session devrait être soumis à un signal plus strict. Le replay capture le DOM rendu, y compris les valeurs de formulaire sauf si elles sont explicitement masquées, donc un opt-in distinct pour les préférences ou le fonctionnel est approprié, et le replay devrait être désactivé par défaut même lorsque l'analytique est accordée.
• Les audiences, cohortes et enrichissement tiers sont liés à la finalité marketing. En termes de TCF, il s'agit de la finalité 7 (mesurer les performances publicitaires) ou de la finalité 9 (appliquer des études de marché). Pour Google Consent Mode, cela correspond à ad_storage et ad_user_data.
• L'expérimentation — Amplitude Experiment peut fonctionner avec une allocation anonyme et éphémère sur la base d'un intérêt légitime, mais une allocation persistante liée à un identifiant utilisateur nécessite le même consentement que l'analyse principale.

Le schéma d'intégration qui fonctionne

L'implémentation de référence qui résiste à l'examen d'un régulateur comporte quatre éléments mobiles : une CMP qui expose un événement en temps réel lorsque l'utilisateur modifie le consentement, un chargeur de SDK différé qui ne récupère Amplitude qu'après le déclenchement de cet événement pour la catégorie concernée, un garde de niveau session qui respecte l'opt-out sans perdre l'identifiant d'appareil anonyme précédent de l'utilisateur là où la loi le permet, et un pont côté serveur pour les événements qui nécessitent véritablement une collecte quel que soit le consentement — telle que la télémétrie de sécurité ou la détection de fraude — acheminés via un endpoint distinct avec sa propre base juridique.

Implémentation web

Sur le web, le schéma le plus propre consiste à exposer l'état de consentement de la CMP via un objet window.__cmp_consent ou le callback standard __tcfapi, puis à avoir un petit script bootstrap qui s'abonne aux changements de consentement. Lorsque le consentement analytique passe de false à true, le bootstrap récupère le SDK Amplitude depuis le CDN géré par la CMP, appelle amplitude.init(apiKey, undefined, { defaultTracking: true }) et rejoue tous les événements qui étaient mis en file d'attente en mémoire pendant que le consentement était en attente. Lorsque le consentement repasse à false, le bootstrap appelle amplitude.setOptOut(true), efface le cookie AMP_ via l'expiration de document.cookie et supprime tout état en mémoire. De façon critique, le bootstrap ne doit jamais initialiser Amplitude de manière paresseuse dans le même flux de requête que le rendu de la bannière — le SDK doit attendre un accord explicite.

Implémentation mobile

Sur iOS, l'équivalent consiste à conserver le framework Amplitude importé mais à différer Amplitude.instance().initialize(apiKey: apiKey) jusqu'à ce que le flux de consentement intégré à l'application renvoie un signal analytique positif. La fenêtre ATT est une préoccupation distincte : l'ATT régit l'IDFA, tandis que l'identifiant d'Amplitude est l'UUID propre du SDK stocké dans le sandbox de l'application. Les deux nécessitent un consentement dans l'EEE, mais les bases juridiques et les fenêtres sont distinctes. Sur Android, la même logique s'applique avec Amplitude.getInstance().initializeApolloClient() ou l'équivalent selon la version du SDK.

Mode côté serveur

Amplitude prend en charge l'ingestion côté serveur via l'API HTTP V2. Les événements côté serveur ne sont pas exemptés du consentement — la base juridique suit les données, pas le transport — mais l'ingestion côté serveur donne à l'éditeur un contrôle total sur les champs envoyés, ce qui facilite le respect du consentement partiel. Un schéma courant consiste à capturer un ensemble minimal d'événements essentiels uniquement côté serveur dans le cadre d'un intérêt légitime, et à n'enrichir ces événements de détails comportementaux qu'après que l'utilisateur a accordé le consentement analytique côté client.

Valider l'intégration

L'étape de validation est celle que les éditeurs omettent le plus souvent et que les régulateurs vérifient le plus souvent. Un déploiement Amplitude correctement intégré devrait passer quatre vérifications. Premièrement, un navigateur avec la bannière de consentement affichée mais sans choix effectué devrait produire zéro requête vers api.amplitude.com ou api.eu.amplitude.com et zéro cookie AMP_ dans document.cookie. Deuxièmement, le refus de la catégorie analytique devrait maintenir cet état — aucun événement, aucun cookie, aucune entrée de stockage local avec un préfixe AMP_. Troisièmement, l'acceptation de l'analytique devrait produire un seul identify suivi d'un trafic d'événements, et le cookie AMP_ devrait apparaître avec un attribut SameSite cohérent avec la politique CMP de l'éditeur. Quatrièmement, le retrait du consentement après coup devrait immédiatement arrêter les autres événements et effacer les identifiants stockés — un nettoyage différé est une constatation.

La piste d'audit est importante séparément. Conformément aux lignes directrices sur les bannières de cookies 2023 de l'EDPB et aux priorités renouvelées du groupe de travail 2026, les régulateurs s'attendent à ce que l'éditeur soit en mesure de prouver, pour tout événement donné dans le projet Amplitude, que l'utilisateur qui l'a généré avait donné un consentement valide au moment de la capture. Cela nécessite que le journal de consentement de la CMP soit interrogeable par identifiant d'appareil ou identifiant de session, et que la charge utile d'événement Amplitude porte un champ de version de consentement qui renvoie à ce journal. Stocker la chaîne de consentement en tant que propriété utilisateur personnalisée sur chaque événement est le moyen le plus simple de rendre ce lien auditable.

Choisir la bonne région et la résidence des données

Amplitude exploite deux régions de production : les États-Unis (api.amplitude.com) et l'UE (api.eu.amplitude.com). Pour le trafic EEE et Royaume-Uni, la région UE est le bon choix par défaut — elle maintient les données dans l'EEE et réduit la surface de risque de transfert que la décision Schrems II et le cadre de protection des données UE-États-Unis ont placé au centre de toute évaluation analytique. Le changement de région n'est pas rétroactif : les données existantes restent là où elles ont été ingérées pour la première fois. Pour les éditeurs qui planifient un déploiement de CMP, il vaut donc la peine de confirmer la région avant de passer à l'échelle, et de documenter le choix dans la notice de confidentialité afin que la chaîne de base juridique soit propre de la collecte au stockage. Une région correctement choisie, associée à un SDK correctement contrôlé et à un journal de consentement interrogeable, est ce qui transforme un déploiement Amplitude d'un risque réglementaire en une partie défendable de la pile analytique.