Gestion du consentement

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.

​

Politiques de consentement​

Pour un visiteur donné, le consentement légal à l’utilisation de Kameleoon est considéré comme accordé, refusé ou inconnu (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 :

• Consentement non requis : 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.
• Consentement requis : Avec cette politique, le consentement doit être explicitement obtenu du visiteur. Tant qu’il n’est pas donné, le consentement légal est considéré comme « inconnu » 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.

​

Lire l’état actuel du consentement pour un visiteur​

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.

​

Modes de fonctionnement du moteur 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 Comportement lorsque le consentement est inconnu ou le Comportement en cas d’opt-out. La section suivante décrit tous les modes possibles pour le moteur :

​

Mode actif​

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.

​

Mode désactivé​

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 « Bloquer complètement Kameleoon » lorsque le consentement est inconnu.
• Kameleoon.API.Visitor.experimentLegalConsent ou Kameleoon.API.Visitor.personalizationLegalConsent est false, et le client a sélectionné « Bloquer complètement Kameleoon » pour le comportement en cas d’opt-out.

​

Mode différé​

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 mode actif (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 « différé » : si le consentement complet est obtenu à un moment donné, le résultat final sera que Kameleoon s’est comporté presque comme en mode actif. Ce mode est opérationnel lorsque Kameleoon.API.Visitor.experimentLegalConsent / Kameleoon.API.Visitor.personalizationLegalConsent est null, et vous avez sélectionné l’option « Ne pas bloquer Kameleoon » lorsque le consentement est inconnu.

​

Mode restreint​

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 mode restreint est équivalent au mode différé, 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 « Bloquer partiellement Kameleoon » lorsque le consentement est inconnu.
• Kameleoon.API.Visitor.experimentLegalConsent ou Kameleoon.API.Visitor.personalizationLegalConsent est false, vous avez sélectionné l’option « Bloquer partiellement Kameleoon » pour le comportement en cas d’opt-out.

​

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 (mode désactivé) 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 mode différé 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é.