Skip to main content
Consultez le Guide utilisateur pour des instructions sur la configuration de la politique de gestion du consentement lors de l’utilisation de Kameleoon sur votre application web.
Kameleoon fournit des intégrations natives intégrées avec les plateformes de gestion du consentement.

Politiques de consentement

Pour un visiteur donné, le consentement légal à l’utilisation de Kameleoon est considéré comme granted, denied or unknown (un état spécial utilisé lorsque le consentement n’est pas défini, car le visiteur ne l’a ni accordé ni refusé pour le moment). Pour commencer, vous devez choisir comment Kameleoon traite le consentement légal :
  • Consent not required : Avec cette politique, le consentement n’est pas explicitement requis pour ce site web et ce module. Kameleoon suppose qu’il est accordé automatiquement et démarre immédiatement en mode pleinement fonctionnel.
  • Consent required : Avec cette politique, le consentement doit être explicitement obtenu du visiteur. Tant qu’il n’est pas donné, le consentement légal est considered to be « unknown » et Kameleoon ne fonctionnera pas normalement.
Pour informer Kameleoon lorsque le consentement légal a été obtenu, vous devez utiliser soit la méthode de l’Activation API Kameleoon, qui nécessite l’implémentation de code JS personnalisé, soit l’un des SDK si vous exécutez des feature flags. Pour plus d’informations à ce sujet, consultez le guide utilisateur.
Pour couvrir tous les cas d’usage possibles, le comportement de Kameleoon Web Experimentation peut être davantage personnalisé lorsque le consentement est considéré comme inconnu ou lorsqu’il est refusé par l’utilisateur. Pour en savoir plus sur les options disponibles, lisez l’article sur le comportement lorsque le consentement est inconnu.

Lire l’état actuel du consentement pour un visiteur

Cette section s’applique uniquement à la solution Kameleoon Web Experimentation.
Pour obtenir (lire) l’état actuel du consentement légal pour un visiteur, utilisez l’objet Kameleoon.API.Visitor :
  • Kameleoon.API.Visitor.experimentLegalConsent : renvoie true, false ou null si l’état est inconnu (le consentement est requis mais n’a pas encore été accordé ni refusé).
  • Kameleoon.API.Visitor.personalizationLegalConsent : renvoie true, false ou null si l’état est inconnu (le consentement est requis mais n’a pas encore été accordé ni refusé).
Alors que les méthodes Kameleoon.API.Core.enableLegalConsent() et Kameleoon.API.Core.disableLegalConsent() vous permettent de modifier (écrire) l’état du consentement légal pour ce visiteur, l’obtention (lecture) de l’état actuel se fait via Kameleoon.API.Visitor.
Si vous avez choisi une policy Consent not required, le consentement légal ne peut jamais être dans un état inconnu. Kameleoon.API.Visitor.experimentLegalConsent ou Kameleoon.API.Visitor.personalizationLegalConsent renverront toujours true par défaut et seront définis sur false uniquement si la méthode Kameleoon.API.Core.disableLegalConsent() est appelée.

Modes de fonctionnement du moteur Kameleoon Web Experimentation

Cette section s’applique uniquement à la solution Kameleoon Web Experimentation.
Le moteur de Kameleoon fonctionne différemment selon son mode de fonctionnement. Pour déterminer le mode opérationnel, Kameleoon tient compte de la valeur actuelle du consentement dans Kameleoon.API.Visitor.experimentLegalConsent et Kameleoon.API.Visitor.personalizationLegalConsent. Si la valeur est null (état inconnu) ou false, Kameleoon tient compte de la valeur de configuration correspondante dans les paramètres du projet pour le Behavior when consent is unknown ou le Behavior in case of opt-out. La section suivante décrit tous les modes possibles pour le moteur :

Active mode

Il s’agit du mode de fonctionnement normal. Kameleoon envoie des données aux serveurs de tracking et écrit des données sur l’appareil au besoin. Le visiteur est supposé avoir accordé son consentement à l’utilisation de Kameleoon. Ce mode est opérationnel lorsque Kameleoon.API.Visitor.experimentLegalConsent ou Kameleoon.API.Visitor.personalizationLegalConsent est true.

Disabled mode

Dans ce mode, Kameleoon ne fait rien du tout - les données ne sont ni envoyées aux serveurs distants ni écrites sur l’appareil local. Les expériences et personnalisations ne sont jamais affichées. À toutes fins utiles, c’est comme si Kameleoon n’existait pas pour ce visiteur particulier. Ce mode est opérationnel lorsque :
  • Kameleoon.API.Visitor.experimentLegalConsent ou Kameleoon.API.Visitor.personalizationLegalConsent est null, et vous avez sélectionné l’option « Completely block Kameleoon » lorsque le consentement est inconnu.
  • Kameleoon.API.Visitor.experimentLegalConsent ou Kameleoon.API.Visitor.personalizationLegalConsent est false, et le client a sélectionné « Completely block Kameleoon » pour le comportement en cas d’opt-out.

Delayed mode

Dans ce mode, Kameleoon n’envoie aucune donnée aux serveurs de tracking et n’écrit aucune donnée sur l’appareil. Cependant, il affichera toujours normalement les expériences (ou personnalisations) si le visiteur déclenche le segment associé. De plus, toutes les données qui devraient être écrites ou envoyées à un serveur distant sont conservées en mémoire. Si Kameleoon passe ensuite en active mode (généralement parce que le consentement est accordé à un certain moment), toutes les données recueillies jusqu’alors (dans le contexte de cette page) sont écrites et envoyées en une seule fois. D’où le nom « delayed » : si le consentement complet est obtenu à un moment donné, le résultat final sera que Kameleoon s’est comporté presque comme en active mode. Ce mode est opérationnel lorsque Kameleoon.API.Visitor.experimentLegalConsent / Kameleoon.API.Visitor.personalizationLegalConsent est null, et vous avez sélectionné l’option « Do not block Kameleoon » lorsque le consentement est inconnu.

Restricted mode

Dans ce mode, Kameleoon n’envoie aucune donnée aux serveurs de tracking et n’écrit aucune donnée sur l’appareil. Cependant, il affichera toujours les expériences (ou personnalisations) qui ont été marquées avec le tag « Technical » dans Kameleoon. Toutes les autres expériences / personnalisations ne sont pas affichées. Il s’agit d’un mode très utile qui permet de désactiver la plupart des opérations Kameleoon si un visiteur ne souhaite pas donner son consentement, mais qui permet toutefois aux expériences et personnalisations critiques de s’exécuter pour ce visiteur. Très souvent, Kameleoon est utilisé comme solution rapide pour déployer des correctifs de bugs et de petites améliorations en production. Dans ce contexte particulier, les réglementations en matière de confidentialité telles que RGPD ne s’appliquent explicitement pas, et Kameleoon peut être utilisé sans consentement pour de tels cas d’usage. Le restricted mode est équivalent au delayed mode, mais plus restrictif. Comme il peut être choisi à la suite d’un choix de consentement légal final (un refus), il est attendu que les données ne seront probablement jamais écrites ni envoyées dans ce cas (alors que le mode différé n’est normalement qu’un mode « transitoire »). Ce mode est opérationnel lorsque :
  • Kameleoon.API.Visitor.experimentLegalConsent ou Kameleoon.API.Visitor.personalizationLegalConsent est null, et vous avez sélectionné l’option « Partially block Kameleoon » lorsque le consentement est inconnu.
  • Kameleoon.API.Visitor.experimentLegalConsent ou Kameleoon.API.Visitor.personalizationLegalConsent est false, vous avez sélectionné l’option « Partially block Kameleoon » pour le comportement en cas d’opt-out.
Il est tout à fait possible que Kameleoon ait différents modes opérationnels pour les A/B tests et les personnalisations. Dans ce cas, tout fonctionne comme prévu. Par exemple, les expériences sont affichées et les données de tracking, mais rien ne se passe pour les personnalisations.

Considérations avancées

Choisir de mettre en œuvre une politique de consentement explicite dans le contexte des A/B tests conduit généralement à des problèmes complexes, et il n’existe pas de solution idéale. Les deux principaux problèmes sont décrits ici. La première chose à prendre en compte est que si vous choisissez un comportement strict (disabled mode) tant que le consentement est inconnu, les expériences / personnalisations seront déclenchées « tardivement » dans le contexte de la première vue de page d’un visiteur entièrement nouveau. Avec cette configuration, elles ne peuvent en effet être affichées qu’après l’obtention du consentement légal, ce qui prend généralement quelques secondes. Cela peut malheureusement conduire à des problèmes UX sérieux, selon les expériences et personnalisations sous-jacentes, et doit être pris en compte. Le delayed mode peut atténuer ce problème, car l’affichage est immédiat et seule l’écriture est différée. Cependant, un deuxième problème se pose lorsqu’un visiteur « reste » avec un statut de consentement légal inconnu sur plusieurs pages. Comme Kameleoon n’écrit aucune donnée sur l’appareil, pas même l’identifiant Kameleoon visitorCode, celui-ci continue d’être (re)généré aléatoirement à chaque page tant que le consentement final n’est pas déterminé. Cela implique que pour les expériences, l’allocation des variations aura lieu à chaque nouvelle vue de page, et aucune cohérence n’est garantie dans ces allocations. Il est donc important de prendre des mesures pour empêcher cette situation de se produire. Plusieurs options sont possibles (bannière de consentement bloquante, refus automatique du consentement après X secondes…), mais un visiteur ne doit jamais rester indéfiniment dans le statut de consentement légal inconnu. Soit le consentement est accordé, soit il est refusé.
Pour la même raison technique (réallocation permanente des variations), si le restricted mode est choisi pour le comportement en cas d’opt-out, il est attendu que seules les personnalisations ou expériences avec une déviation de trafic de 100 % vers une variation seront marquées avec le tag « Technical ». Faire autrement peut sérieusement détériorer l’expérience de navigation des utilisateurs ayant refusé, car ils pourraient être soumis à plusieurs variations différentes au cours de la même session.

FAQ

Conformément au RGPD, sans le consentement du visiteur, Kameleoon n’utilise que les informations techniques nécessaires au bon fonctionnement des fonctionnalités du produit.Si vous exemptez les règles Targeted Delivery et les règles de diffusion progressive de la gestion du consentement, Kameleoon les déclenche sans consentement et limite les données collectées aux informations techniques. Toutes les autres informations (par exemple, CustomData, Page Views et Geolocation) ne sont envoyées qu’avec le consentement du visiteur.Pour savoir comment choisir votre politique de gestion du consentement, consultez l’article Gestion du consentement.