TL;DR
L’A/B testing repose souvent sur des cookies pour identifier les visiteurs et leur attribuer une variante. Dès que ces cookies permettent de suivre un utilisateur dans le temps ou de croiser des données comportementales, ils entrent dans le périmètre du RGPD et nécessitent un consentement préalable. La distinction clé est celle entre un cookie strictement nécessaire au fonctionnement du test (exemption possible) et un cookie qui alimente un profil analytique ou marketing (consentement obligatoire). Pour tester sans enfreindre la réglementation, il faut comprendre cette frontière, configurer sa CMP en conséquence et choisir des outils compatibles avec le cadre européen.
Qu’est-ce que l’A/B testing et pourquoi les cookies sont impliqués ?
L’A/B testing est une méthode qui consiste à présenter deux variantes d’une page ou d’un élément à des groupes distincts de visiteurs, puis à mesurer laquelle produit les meilleurs résultats. Pour fonctionner correctement, le test doit garantir qu’un même visiteur voit toujours la même variante pendant toute la durée de l’expérience.
C’est là que les cookies interviennent. La plupart des outils d’A/B testing déposent un cookie first-party sur le navigateur du visiteur. Ce cookie stocke l’identifiant de la variante assignée, parfois un identifiant utilisateur, et garantit la cohérence de l’affichage entre les pages et les sessions.
Le problème juridique apparait quand ce cookie dépasse la simple attribution de variante. Si l’outil enregistre également des données de navigation, des événements de conversion, ou recoupe l’identifiant du test avec un profil analytics ou publicitaire, le cookie sort du périmètre “strictement nécessaire” et entre dans celui du consentement RGPD.
Ce que la CNIL considère comme un cookie de test A/B
La CNIL distingue deux situations dans ses lignes directrices sur les cookies. Un cookie qui sert uniquement à mémoriser la variante affichée, sans transmission de données à des tiers et sans croisement avec d’autres traceurs, peut être considéré comme strictement nécessaire au fonctionnement du site. Dans ce cas précis, il bénéficie de l’exemption de consentement prévue par l’article 82 de la loi Informatique et Libertés.
En revanche, si le cookie de test alimente un outil tiers (Google Optimize historiquement, VWO, AB Tasty, Optimizely) qui collecte des données comportementales, croise les résultats avec un identifiant analytics, ou partage les données avec des partenaires, il ne remplit plus les critères d’exemption. Le consentement devient obligatoire avant le dépôt du cookie.
Notre fiche service AB Tasty indique par exemple que cet outil exige un consentement préalable dans la catégorie analytique.
Comment savoir si vos cookies d’A/B testing nécessitent un consentement ?
La réponse dépend de trois critères concrets : la nature des données collectées, la destination des données, et la durée de vie du cookie.
Nature des données collectées
Si le cookie stocke uniquement un identifiant de variante (par exemple ab_variant=B) sans aucun identifiant utilisateur, sans données de navigation et sans événement de conversion, il reste dans le périmètre de l’exemption. Dès qu’il enregistre un visitor ID, un timestamp de session, des pages vues ou des clics sur des éléments, il devient un traceur soumis au consentement.
Destination des données
Un cookie qui reste en local sur le navigateur et dont la valeur n’est lue que par le code front-end du site pour afficher la bonne variante ne pose pas de problème. Un cookie dont la valeur est envoyée à un serveur tiers (SaaS d’A/B testing, plateforme analytics) pour y être stockée et analysée nécessite un consentement.
Durée de vie du cookie
Un cookie de session qui disparait à la fermeture du navigateur est moins intrusif qu’un cookie persistant de 6 ou 12 mois. La CNIL recommande une durée maximale de 13 mois pour les cookies soumis au consentement. Un cookie de test qui persiste au-delà d’une session sans justification technique renforce l’obligation de consentement.
L'origine et la portée de cette limite sont expliquées dans notre article sur la règle des 13 mois pour la durée de conservation des cookies.
Les outils d’A/B testing les plus courants et leur conformité RGPD
Chaque outil a son propre mécanisme de cookies et de collecte de données. Voici ce qu’il faut vérifier avant de lancer un test.
La majorité des outils SaaS d’A/B testing nécessitent un consentement parce qu’ils collectent des données comportementales et les transmettent à leurs serveurs. L’exemption n’est réaliste que pour des implémentations server-side maison où le cookie se limite à stocker la variante sans aucune collecte analytique associée.
Comment configurer votre CMP pour l’A/B testing
La configuration de votre CMP (plateforme de gestion du consentement) détermine si vos tests A/B respectent le RGPD ou non. L’erreur la plus fréquente est de classer le script d’A/B testing dans la mauvaise catégorie de cookies.
Étape 1 : identifier la catégorie correcte
Votre outil d’A/B testing doit être classé dans la catégorie qui correspond à son fonctionnement réel. Si l’outil collecte des données comportementales et les envoie à un tiers, il appartient à la catégorie “analytics” ou “mesure de performance” de votre CMP. Ne le classez jamais dans les cookies “strictement nécessaires” sauf si vous avez vérifié qu’aucune donnée ne quitte le navigateur.
Dans FlowConsent, chaque service du catalogue est rattaché à une catégorie de consentement, comme le décrit la documentation services, catégories de consentement et bases légales.
Pour bien comprendre les différentes catégories de cookies et leurs implications, consultez le guide des 4 catégories de cookies RGPD.
Étape 2 : bloquer le script avant consentement
Votre CMP doit bloquer le chargement du script d’A/B testing tant que le visiteur n’a pas accepté la catégorie correspondante. Cela signifie que les visiteurs qui refusent les cookies analytics ne verront pas de test A/B. C’est une contrainte réelle, mais c’est l’exigence du RGPD.
Le blocage des scripts avant consentement est un fondamental de la conformité cookies. Votre CMP doit gérer ce blocage de manière fiable.
Étape 3 : gérer le Consent Mode v2
Si vous utilisez des outils Google (GA4, Google Ads) en complément de votre solution d’A/B testing, le Consent Mode v2 permet d’envoyer des pings sans cookies lorsque le consentement est refusé. Certains outils d’A/B testing commencent à proposer des intégrations compatibles avec le Consent Mode. Vérifiez si votre outil le supporte.
Étape 4 : documenter dans votre politique de cookies
Votre politique de cookies doit mentionner les cookies déposés par votre outil d’A/B testing, leur finalité, leur durée de vie et le tiers qui y accède. C’est une obligation souvent oubliée par les growth teams.
L’impact sur vos tests : que se passe-t-il quand le visiteur refuse ?
C’est la question qui préoccupe le plus les product managers et growth marketers. Si le script d’A/B testing est bloqué pour les visiteurs qui refusent les cookies, une partie du trafic est exclue des tests.
Le biais de sélection
Les visiteurs qui acceptent les cookies ne sont pas identiques à ceux qui les refusent. Les utilisateurs sensibles à la vie privée ont souvent des comportements de navigation différents : ils convertissent différemment, naviguent différemment, et réagissent différemment aux interfaces. Exclure ce segment introduit un biais dans les résultats du test.
Ce biais est réel, mais il n’est pas un argument pour contourner le RGPD. Il faut le prendre en compte dans l’analyse des résultats et ajuster la significativité statistique en conséquence.
Les alternatives pour réduire l’impact
Plusieurs approches permettent de limiter la perte de trafic testable tout en restant conforme.
L’A/B testing server-side permet d’assigner la variante côté serveur, sans cookie dans le navigateur, en se basant sur un identifiant de session. Si aucune donnée personnelle n’est collectée et si les résultats restent en interne, cette approche peut bénéficier de l’exemption de consentement.
L’A/B testing basé sur le feature flagging côté serveur (LaunchDarkly, Unleash, Flagsmith) n’utilise pas de cookies navigateur. L’attribution se fait côté back-end. La mesure des résultats se fait via les données internes (base de données, events server-side) sans traceur tiers.
L’optimisation du taux de consentement est aussi un levier direct. Plus votre bannière est claire et bien conçue (sans dark patterns), plus le pourcentage de visiteurs qui acceptent les cookies analytics est élevé, et plus votre base testable est large.
Erreurs fréquentes
Classer le script d’A/B testing comme “strictement nécessaire”. C’est l’erreur la plus courante. Les outils comme AB Tasty, VWO ou Optimizely collectent des données comportementales et les envoient à des serveurs tiers. Ils ne sont pas strictement nécessaires au fonctionnement du site. Les classer ainsi expose à un risque de sanction en cas de contrôle CNIL.
Lancer un test sans vérifier si le script est bloqué avant consentement. Beaucoup de growth teams installent le script d’A/B testing sans passer par la CMP, ou le placent dans la catégorie “nécessaire” pour qu’il se charge sans attendre le consentement. Le scanner de cookies FlowConsent permet de vérifier quels scripts se chargent avant le consentement.
Ignorer les cookies déposés par l’outil de test dans la politique de cookies. Chaque cookie doit être déclaré. L’outil d’A/B testing dépose souvent plusieurs cookies (variante, visitor ID, session). Tous doivent apparaitre dans la politique.
Croiser les données du test avec des identifiants publicitaires. Envoyer les résultats d’un test A/B vers Google Ads, Meta Ads ou un DMP sans consentement marketing explicite est une infraction au RGPD. Le consentement analytics ne couvre pas le ciblage publicitaire.
Ce même consentement marketing encadre les pixels publicitaires, comme le montre notre guide sur le Meta Pixel et la conformité RGPD.
Ne pas recueillir de preuve de consentement. En cas de contrôle, vous devez pouvoir prouver que le visiteur avait consenti avant le dépôt du cookie de test. Sans preuve horodatée, la conformité ne peut pas être démontrée.
Utiliser un test A/B pour modifier le bandeau cookies lui-même. Tester des variantes de votre bannière de consentement (couleurs, textes, boutons) avec un outil qui nécessite lui-même un consentement crée une situation circulaire. Pour tester votre bannière, utilisez des méthodes qui ne nécessitent pas de cookies : tests utilisateurs, tests server-side, ou fonctionnalités intégrées à votre CMP.
A/B testing server-side : la solution conforme par défaut ?
L’A/B testing server-side consiste à attribuer la variante sur le serveur, avant que la page ne soit envoyée au navigateur. Le visiteur reçoit directement la version A ou B sans qu’un script client ne soit exécuté et sans qu’un cookie tiers ne soit déposé.
Les avantages pour la conformité
Pas de script tiers dans le navigateur, donc pas de blocage par la CMP. Pas de cookie de tracking, donc pas de consentement requis (si les conditions d’exemption sont respectées). Pas de flicker (l’effet de clignotement entre les variantes) qui dégrade l’expérience utilisateur et les Core Web Vitals.
Les conditions pour bénéficier de l’exemption
Pour qu’un A/B test server-side soit exempt de consentement, il faut que le cookie déposé (si un cookie de session est utilisé) serve uniquement à maintenir la cohérence de la variante affichée. Les données de résultat doivent rester en interne, sans transmission à un tiers. Aucun identifiant personnel ne doit être stocké dans le cookie. La durée du cookie ne doit pas excéder la durée du test.
Si l’une de ces conditions n’est pas remplie, le consentement redevient nécessaire, même en server-side.
La même logique vaut pour le tracking en général, comme le détaille notre article sur le server-side tagging et son impact sur le consentement.
Checklist : A/B testing conforme au RGPD
- Identifier tous les cookies déposés par votre outil d’A/B testing (nom, durée, finalité).
- Déterminer si ces cookies transmettent des données à un serveur tiers.
- Classer le script dans la bonne catégorie de votre CMP (analytics, pas “nécessaire”).
- Vérifier que le script est bloqué avant consentement pour les visiteurs qui refusent.
- Déclarer tous les cookies de test dans votre politique de cookies.
- Ne pas croiser les résultats du test avec des identifiants publicitaires sans consentement marketing.
- Si vous utilisez le Consent Mode v2, vérifier la compatibilité de votre outil de test.
- Évaluer l’option server-side pour les tests critiques où la couverture du trafic est prioritaire.
- Conserver la preuve de consentement pour les visiteurs inclus dans les tests.
- Scanner votre site après installation pour vérifier qu’aucun script ne se charge avant consentement.
Conclusion
L’A/B testing et la conformité cookies ne sont pas incompatibles, mais ils nécessitent une configuration rigoureuse. La majorité des outils SaaS de test déposent des cookies qui nécessitent un consentement préalable. La solution la plus robuste pour les équipes qui veulent maximiser la couverture de leurs tests est de migrer vers du server-side ou du feature flagging, où le consentement cookies n’est plus un facteur limitant.
Pour vérifier quels scripts et cookies se chargent sur votre site avant et après consentement, lancez un scan gratuit avec FlowConsent.