Pourquoi Optimizely Web Experimentation nécessite un consentement

Une initialisation Optimizely par défaut effectue plusieurs opérations lors du premier rendu de la page. Elle pose un cookie propriétaire sous optimizelyEndUserId contenant l'identifiant persistant du visiteur, évalue le visiteur par rapport aux expériences actives, écrit les attributions de variantes dans un second cookie sous les marqueurs d'espace de noms optimizelyOptOut, déclenche un événement de décision vers logx.optimizely.com et applique les modifications de variante à la page rendue. Lorsque l'opérateur a connecté une intégration analytique — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap ou l'Optimizely Data Platform — le SDK déclenche également des événements d'exposition de variante dans la couche analytique, qui associe alors la variante au profil analytique plus large du visiteur.

Chacune de ces activités déclenche une porte de consentement distincte. Persister l'identifiant du visiteur est une opération de stockage et d'accès au titre de l'Article 5(3) de la directive ePrivacy nécessitant un consentement préalable, libre, spécifique, éclairé et non ambigu dans l'EEA, au Royaume-Uni et dans toute juridiction ayant adopté le même standard. Lier les attributions de variantes expérimentales à cet identifiant d'une session à l'autre constitue un traitement de données personnelles au sens du RGPD, car la combinaison de l'identifiant, de l'adresse IP et de l'exposition à la variante est suffisante pour identifier un individu et caractériser son interaction avec le programme d'expérimentation. La propagation inter-outils des données de variante — Optimizely exposant l'attribution de variante à Google Analytics, par exemple — ajoute la porte analytique à la chaîne. Les orientations de l'EDPB de 2023 ont été explicites : l'expérimentation impliquant une identification persistante est soumise aux mêmes règles de consentement que l'analytique ; la CNIL a été le régulateur le plus vocal sur ce point, mais n'est pas le seul.

Ce qu'Optimizely écrit avant le consentement — et ce qui doit être supprimé

Le snippet Optimizely standard installe le SDK JavaScript directement dans l'en-tête de la page et s'initialise immédiatement au chargement. C'est le quickstart documenté et la source de l'échec de conformité le plus courant : le SDK s'exécute avant que la bannière de cookies ait été rendue, le cookie optimizelyEndUserId est écrit en quelques millisecondes, l'attribution de variante est effectuée et l'événement de décision est déclenché quoi que décide le visiteur par la suite. Chaque autorité de régulation européenne qui s'est prononcée sur ce modèle a statué de la même façon : les cookies posés avant le consentement sont illicites, l'attribution de variante capturée avant le consentement est un traitement illicite et l'éditeur porte la responsabilité.

Une intégration conforme doit donc empêcher Optimizely d'écrire l'identifiant persistant et de déclencher des événements de décision jusqu'à ce que la catégorie de consentement pertinente ait été accordée. Optimizely prend en charge deux schémas pour cela. Le premier est l'attribut de consentement dédié — passer OPTIMIZELY_OPT_OUT=true comme chaîne de requête ou définir le cookie optimizely.opt_out avant l'initialisation du SDK — ce qui place le SDK en mode opt-out où aucun identifiant n'est écrit et aucun événement n'est déclenché. Le second est le mode anonyme uniquement pris en charge dans la configuration du SDK, où le SDK fonctionne en mode sans session qui attribue des variantes uniquement sur la base d'une identification locale à la session, sans identification persistante entre les visites. Le mode anonyme permet au programme d'expérimentation de fonctionner sur la base d'un intérêt légitime pour la décision de rendu tout en différant l'identification persistante jusqu'à l'octroi du consentement.

Les cookies et le stockage qu'Optimizely écrit

Le SDK Optimizely Web Experimentation écrit les identifiants suivants lors de l'initialisation, tous non essentiels et nécessitant un consentement : optimizelyEndUserId avec une expiration pluriannuelle contenant l'identifiant persistant du visiteur, les marqueurs optimizelyOptOut suivant l'état d'opt-out, optimizelyDomainTestCookie pour l'expérimentation inter-sous-domaines et des cookies d'espace de noms supplémentaires lorsque l'opérateur a activé l'identification inter-domaines. Le retrait du consentement doit donc à la fois faire expirer les cookies et placer le SDK en mode opt-out via optimizely.push({ type: 'user', attributes: { opt_out: true } }) pour arrêter toute collecte d'événements ultérieure.

Cartographier Optimizely sur les référentiels de consentement

Optimizely n'implémente pas nativement l'IAB TCF ni l'IAB Global Privacy Platform — c'est une plateforme d'expérimentation propriétaire, pas un fournisseur adtech — mais il expose une API d'opt-out native, prend en charge une intégration documentée du Consent Mode via l'Optimizely Data Platform et respecte le CMP de l'éditeur via l'attribut OPTIMIZELY_OPT_OUT. Le schéma qui survive à la revue d'un régulateur traite chaque capacité d'Optimizely comme une porte distincte liée à un signal CMP spécifique.

• L'expérimentation anonyme peut fonctionner sur la base d'un intérêt légitime avec une identification locale à la session, ce qui est approprié pour les décisions de rendu qui ne nécessitent pas d'identification persistante entre les visites et qui ne se propagent pas vers l'analytique en aval. Ce mode est lié à la catégorie strictement nécessaire ou fonctionnelle.
• L'expérimentation persistante avec un identifiant stable est liée à la finalité analytique. En termes TCF, cela correspond à la finalité 8 combinée à la finalité 1 ; pour le Consent Mode, cela correspond à analytics_storage.
• L'intégration inter-outils — les événements d'exposition de variante propagés vers Google Analytics, Amplitude ou l'Optimizely Data Platform — hérite de la porte analytique de l'outil récepteur et ne doit pas se déclencher si la porte de cet outil n'a pas été accordée.
• La personnalisation et le ciblage basé sur les audiences construits sur l'expérimentation déclenchent la porte marketing car ils passent de la mesure expérimentale au ciblage au niveau utilisateur.

Le schéma d'intégration qui fonctionne

Le déploiement de référence comporte quatre parties : un CMP exposant un événement de modification du consentement en temps réel, un bootstrap différé qui initialise le SDK Optimizely avec l'opt-out activé ou le mode anonyme actif, un listener de consentement qui bascule le SDK hors de l'opt-out et démarre l'identification persistante quand la porte analytique s'ouvre, et un chemin de retrait qui remet le SDK en mode opt-out, fait expirer les cookies optimizely via document.cookie et propage le retrait vers toute intégration analytique en aval.

Implémentation web avec le bootstrap différé

Sur le web, le schéma le plus propre consiste à charger le snippet Optimizely avec window.optimizelyOptOut = true défini avant l'initialisation du SDK. Abonnez-vous à l'événement de modification du consentement du CMP. Lorsque la catégorie analytique passe à true, appelez window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) et laissez le SDK s'initialiser normalement. Lorsque la porte est retirée, remettez l'attribut d'opt-out à true, faites expirer le cookie optimizelyEndUserId et propagez la modification vers toutes les plateformes analytiques intégrées via leurs API de consentement respectives.

Expérimentation côté serveur via le Decision Service

Optimizely prend également en charge l'expérimentation côté serveur via l'API Decision Service. Les décisions côté serveur ne sont pas exemptées du consentement — la base légale suit les données — mais l'exécution côté serveur donne à l'éditeur un contrôle total sur les identifiants propagés. Le schéma qui fonctionne consiste à passer un identifiant de session éphémère au Decision Service lorsque la porte analytique est fermée, et à basculer vers l'identifiant persistant uniquement lorsque la porte est ouverte. Les attributions de variantes retournées par le Decision Service peuvent toujours être appliquées à la page rendue ; ce qui change, c'est si elles sont liées à un enregistrement de visiteur stable.

Valider l'intégration et la piste d'audit

L'étape de validation est ce que les régulateurs vérifient et ce que les éditeurs omettent le plus souvent sur les outils d'expérimentation. Un déploiement Optimizely correctement intégré doit réussir quatre tests en séquence. Premièrement, une session de navigateur propre avec la bannière affichée mais aucun choix effectué doit produire zéro requête vers logx.optimizely.com au-delà du téléchargement du fichier SDK et zéro cookie optimizely dans document.cookie. Deuxièmement, refuser l'analytique doit maintenir cet état — pas d'identifiant persistant, pas d'événement de décision, pas d'attribution de variante liée à un enregistrement stable. Troisièmement, accepter l'analytique doit produire le cookie optimizelyEndUserId attendu et le trafic d'événements de décision, avec l'attribution de variante correctement appliquée. Quatrièmement, retirer le consentement doit immédiatement arrêter les événements de décision ultérieurs, faire expirer les cookies et propager l'opt-out vers toute intégration analytique en aval.

L'attente de piste d'audit au titre des orientations de l'EDPB de 2023 sur les bannières cookies et des priorités renouvelées du groupe de travail 2026 est que l'éditeur puisse démontrer, pour toute exposition expérimentale spécifique dans le projet Optimizely, que le visiteur avait donné un consentement valide au moment de l'exposition. Le schéma standard consiste à définir la version du consentement et le timestamp comme attribut personnalisé sur le profil visiteur Optimizely via l'API d'attribut du SDK, de sorte que toute exposition individuelle soit traçable jusqu'à une entrée spécifique du journal des consentements. Un déploiement correctement cloisonné, couplé à la gestion du mode anonyme pour les décisions de rendu pré-consentement et à un chemin de retrait se propageant en aval, est ce qui transforme Optimizely d'une responsabilité cachée au niveau de la couche d'expérimentation en une partie défendable du produit et de la pile de croissance d'un éditeur.