> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ

> Cette liste est regulierement mise a jour avec les questions courantes des clients.

<AccordionGroup>
  <Accordion title="Quelle est la fonction du SDK web par rapport au script d'application Kameleoon ?">
    Utilisez le script d'application Kameleoon pour les expériences web creees avec l'editeur graphique ou de code. Utilisez le SDK web pour les feature flags et les expériences de feature.

    Notez que Kameleoon peut s'executer en mode hybride. Le mode hybride utilise a la fois les SDK Web et le fichier d'application JavaScript Kameleoon. Le mode hybride vous permet d'utiliser l'approche optimale pour des taches individuelles. Par exemple, vous pouvez implementer et deployer plus facilement des variations cote serveur, tandis que le suivi peut etre effectue plus efficacement avec le fichier JavaScript.
  </Accordion>

  <Accordion title="Combien de temps prend une initialisation du SDK ?">
    Kameleoon utilise des serveurs CDN lors de l'initialisation. Une fois la configuration recue et mise en cache, la recuperation et la mise a jour se produisent rapidement (50-70 ms selon la latence du serveur par rapport au CDN le plus proche).
  </Accordion>

  <Accordion title="Comment la configuration du SDK est-elle synchronisee avec le serveur ?">
    Il existe deux methodes pour obtenir la configuration : le [Polling](./technical-considerations#polling-par-defaut) et le [Streaming](./technical-considerations#streaming-premium-option-premium-option).
  </Accordion>

  <Accordion title="Quelle technologie utilise la methode streaming ?">
    Le protocole [Server Side Events](https://en.wikipedia.org/wiki/Server-sent_events) (SSE ou EventSource) est utilise.
  </Accordion>

  <Accordion title="Quand le CDN Kameleoon fournit-il une nouvelle configuration au SDK ?">
    Le CDN est purge a chaque fois que vous mettez a jour une configuration de feature flag (par exemple, variations, expositions de trafic et ciblage), ou toutes les 24 heures.
  </Accordion>

  <Accordion title="Quels sont les domaines Kameleoon que je dois mettre sur liste blanche ?">
    Si vous utilisez un SDK cote client et que le site web restreint le chargement de ressources (scripts, images, medias, CSS) via l'en-tete HTTP standard Content-Security-Policy (CSP), mettez a jour la CSP du site pour permettre le chargement des ressources Kameleoon :

    ```
    script-src https://[your-site-code].kameleoon.io https://[your-site-code].kameleoon.eu https://client-config.kameleoon.com https://sdk-config.kameleoon.eu https://*.experimentation.dev 'unsafe-eval';
    connect-src https://[your-site-code].kameleoon.io https://[your-site-code].kameleoon.eu https://eu-data.kameleoon.eu https://eu-data.kameleoon.io https://na-data.kameleoon.eu https://na-data.kameleoon.io https://editor.kameleoon.com https://api.kameleoon.com https://customers.kameleoon.com https://logger.kameleoon.io https://client-config.kameleoon.com https://sdk-config.kameleoon.eu https://*.experimentation.dev;
    ```

    <Note>
      Si vous utilisez Kameleoon en [mode hybride](../get-started/hybrid-experimentation), le domaine de vos scripts Kameleoon `https://[your-site-code].kameleoon.xx` peut varier d'un projet a l'autre. Vos projets peuvent etre hebergees soit sur `kameleoon.eu`, soit sur `kameleoon.io` selon leur date de creation. Assurez-vous d'utiliser le domaine affiche dans votre projet dans l'application Kameleoon. Remplacez \[your-site-code] par votre [site code](/user-manual/faq#how-do-i-find-my-sitecode) Kameleoon dans chaque ligne ou il apparait et ajoutez ceci a votre configuration.
    </Note>
  </Accordion>

  <Accordion title="Comment configurer le SDK si le serveur dispose de plusieurs instances ?">
    Comme chaque instance de serveur dispose de sa propre memoire, toutes les donnees visiteur collectees seront stockees sur une instance donnee. Vous devez utiliser un framework dans lequel les requetes d'un meme visiteur sont traitees par la meme instance de serveur. Sinon, les donnees visiteur doivent etre ajoutees completement avant chaque requete de suivi, ou chargees a l'aide de la methode `getRemoteVisitorData`.

    Si le probleme reside dans la difference de configuration du SDK, utilisez l'option [Streaming](./technical-considerations#streaming-premium-option-premium-option).
  </Accordion>

  <Accordion title="L'attribution des variations / l'allocation de trafic se produit-elle localement ou sur un serveur ?">
    Toutes les evaluations se produisent localement pour eliminer la latence. Les requetes de suivi sont ensuite envoyees de maniere asynchrone aux serveurs Data API de Kameleoon.
  </Accordion>

  <Accordion title="Comment le SDK garantit-il que les visiteurs sont exposes a la meme variation ?">
    Pour affecter un visiteur a une variation d'expérience, Kameleoon construit d'abord un identifiant en utilisant le visitor code, l'ID d'expérience et un element supplementaire potentiel en cas de respooling. Ensuite, une implementation synchrone de la fonction de hachage [SHA-256](https://project.kameleoon.net/issues/256) calcule un hash de cet identifiant. L'entier obtenu par hashing est ensuite mappe a un nombre flottant entre zero et un pour l'affecter a une variation d'expérience. La fonction [SHA-256](https://project.kameleoon.net/issues/256) est deterministe, donc le meme utilisateur (avec le meme visitor code) sera toujours affecte a la meme variation pour une expérience, sauf si un recalcul de l'attribution est explicitement demande.
  </Accordion>

  <Accordion title="Comment afficher d'abord une variation specifique dans une simulation de feature flag ?">
    Suivez la methodologie detaillee [ici](/user-manual/experimentation/feature-experimentation/use-cases/build-whitelists-to-rollout-a-feature-for-internal-users).
  </Accordion>

  <Accordion title="Si je modifie la distribution de trafic / l'exposition, les visiteurs verront-ils toujours leur variation attribuee ?">
    Tous les cas possibles sont expliques dans cet [article](/user-manual/experimentation/feature-experimentation/using-the-rollout-planner/rules-and-targeting/add-a-new-rollout-rule#user-targeting-and-bucketing).
  </Accordion>

  <Accordion title="Pourquoi aucune visite n'est affichee sur la page de resultats ?">
    Plusieurs raisons peuvent expliquer l'absence d'affichage de donnees sur la page de resultats :

    * Si vous avez active le filtrage des bots dans les parametres du projet, il peut y avoir une erreur dans la valeur user-agent definie sur le SDK. Reportez-vous a [cet article](/user-manual/faq#how-does-kameleoon-filter-bot-traffic-from-my-results) pour plus de details.
    * Le consentement legal est defini sur **Required** dans les parametres du projet, mais la methode SDK setLegalConsent n'a pas ete appelee. Reportez-vous a [cette documentation](/user-manual/project-management/consent-management-policy#for-web-experiments-/-feature-experiments-/-hybrid-experiments) pour plus de details.
    * Aucune des methodes SDK qui envoient une requete de suivi aux serveurs Kameleoon n'a ete utilisee.

    [L'article suivant](/fr/user-manual/experiment-analytics/analyze-results/feature-flag-results/analyze-a-feature-flags-overall-results) fournit une aide supplementaire pour deboguer le probleme.
  </Accordion>

  <Accordion title="Pourquoi le nombre de visites ne correspond-il pas a mon trafic reel ?">
    Si vous voyez un grand nombre de visites provenant de visiteurs, il peut s'agir de bots. Pour empecher les bots d'affecter votre expérience, activez l'[option Bot filtering](/user-manual/faq#how-does-kameleoon-filter-bot-traffic-from-my-results) dans les parametres de votre projet. Pour indiquer qu'un visiteur n'est pas un bot, vous devez passer les donnees UserAgent Kameleoon a l'aide de la methode SDK. Appeler la methode empechera Kameleoon de filtrer l'utilisateur.
  </Accordion>

  <Accordion title="Pourquoi l'allocation des visiteurs dans mes rapports est-elle incorrecte ?">
    Si vos rapports montrent une allocation inattendue (par exemple, 10/90 au lieu de 50/50) ou si des visiteurs manquent, cela peut etre du a l'une des raisons suivantes :

    * **Restreindre le pool de visiteurs pour des variations specifiques :** Si vous appelez d'abord `getVariations(onlyActive: true, track: false)`, le SDK ne renvoie que les visiteurs affectes a des variations actives (`ON`). Si vous n'affichez ensuite que les pages d'expérience et appelez `getVariation(track: true)` pour ces visiteurs specifiques, Kameleoon ne suit que la variation `ON`, ce qui donne un rapport qui ne montre qu'une seule variation.
    * **Temps insuffisant pour les requetes de suivi :** Kameleoon envoie des donnees a un intervalle specifique. Si un visiteur reste sur une page avec un client Kameleoon integre pour la variation `ON`, mais passe a une page sans client pour la variation `OFF`, le client peut ne pas avoir suffisamment de temps pour envoyer la requete de suivi pour la variation `OFF`.
    * **Configuration manquante pour des variations specifiques :** Vous avez peut-etre omis le `UserAgent` ou `setLegalConsent` pour certaines variations. Par exemple, si vous ne fournissez le consentement que sur la page pour la variation `ON`, Kameleoon ne peut pas suivre les visiteurs de la variation `OFF`.
    * **Donnees visiteur manquantes :** Le SDK ne collecte pas automatiquement les donnees visiteur ; vous devez les ajouter explicitement pour que le ciblage et le suivi fonctionnent correctement.

    ### Verifiez votre configuration de ciblage

    Si vous suspectez des problemes de ciblage, suivez ces etapes :

    1. Creez une regle sans ciblage avec 100 % d'exposition et attribuez votre variation souhaitee.
    2. Ajoutez le ciblage et assurez-vous que l'utilisateur cesse de recevoir la variation.
    3. Ajoutez les donnees Kameleoon requises.

    L'utilisateur devrait recevoir la variation a nouveau. Si cela echoue, essayez d'utiliser des conditions de ciblage plus simples pour isoler le probleme.
  </Accordion>

  <Accordion title="Lorsque j'utilise addData(), les donnees sont-elles immediatement disponibles pour le ciblage ?">
    Oui, les donnees sont immediatement disponibles pour le ciblage. Les donnees seront disponibles pendant la session du visiteur pour les SDK bases sur le serveur et pendant la duree de vie definie pour les SDK bases sur le client (mobile et web).
  </Accordion>

  <Accordion title="Ou les donnees sont-elles stockees ?">
    Cela depend du type de SDK.

    Dans les SDK serveur, les donnees du visiteur sont stockees en memoire operationnelle pendant la session du visiteur. La duree de la session peut etre definie, bien que la valeur par defaut soit de 30 minutes.

    <Note>
      Plus la duree de la session est longue avec le parametre sessionDuration, plus le SDK conserve de donnees en memoire. Plus de donnees signifie une consommation accrue. La session est prolongee de 30 minutes supplementaires chaque fois qu'un visiteur est contacte. Ainsi, le SDK garantit que les donnees ne seront pas supprimees pendant au moins 30 minutes a partir de la derniere requete.
    </Note>

    Dans les SDK client (mobile et web), les donnees sont stockees dans des stockages locaux (dans le web LocalStorage). Les donnees peuvent etre stockees indefiniment ; cependant, en utilisant le parametre [dataExpirationInterval ou targetingDataCleanupInterval](../../sdks/web-sdks/js-sdk#configuration-parameters), vous pouvez definir la date d'expiration des donnees, apres laquelle les donnees seront supprimees.
  </Accordion>

  <Accordion title="Quand est-il pertinent de flusher les donnees ?">
    Generalement, il n'est pas necessaire d'appeler manuellement la methode "flush" : les donnees sont envoyees avec d'autres appels aux [methodes SDK](#which-methods-trigger-http-requests-are-they-synchronous-or-asynchronous). Cependant, si vous devez envoyer des donnees a la Data API sans declencher le feature flag du visiteur, utilisez la methode "flush".
  </Accordion>

  <Accordion title="Comment utiliser les donnees precedemment collectees pour le ciblage ?">
    Si vous disposez d'un SDK base sur le serveur, les donnees sont stockees pendant la session du visiteur. Vous n'avez pas besoin de charger les donnees a chaque requete si la session de l'utilisateur n'a pas expire. Dans les SDK mobiles, les donnees sont stockees indefiniment (ou conformement a vos parametres).

    Si la session de l'utilisateur n'est plus active ou si le visiteur passe d'un appareil a l'autre dans le SDK client, appelez la methode `getRemoteVisitorData` avec les parametres appropries pour obtenir les donnees envoyees a la Data API. Apres le chargement, les donnees sont incluses dans le ciblage du visiteur.
  </Accordion>

  <Accordion title="Pourquoi mon expérience ne collecte-t-elle pas de donnees ?">
    <Warning>
      Si le consentement legal est active, les donnees ne peuvent etre collectees qu'avec le consentement des visiteurs.
    </Warning>

    Si vous utilisez la regle Experiment et ne recevez pas de statistiques visiteurs, verifiez que :

    * **Dans l'[application Kameleoon](https://app.kameleoon.com)**

      * La regle est creee pour le bon environnement (production, staging ou development).
      * La regle est activee (mise sur on).
      * La regle cible un trafic qui peut reellement etre expose.
      * Si le filtrage des bots est active sur votre projet, [ajoutez l'User Agent au filtre](/user-manual/faq#how-does-kameleoon-filter-bot-traffic-from-my-results).

    * **Dans le SDK**

      * Le KameleoonClient est cree avec la bonne configuration (siteCode, variable environment et, le cas echeant, networkDomain).
      * getVisitorCode est appele une seule fois, et sa valeur est reutilisee partout ou le visitorCode est necessaire.
      * Si vous utilisez le mode hybride (engine.js sur le front), le visitorCode est correctement synchronise avec le front-end.
      * Pour les regles d'expérience, setLegalConsent(true) est appele pour s'assurer que la collecte de donnees est autorisee.
      * Pour les regles de delivrance, isFeatureActive() (ou getVariation()) est appele et retourne true (ou la variation attendue).
      * Pour les regles d'expérience, getVariation() est appele et retourne la variation attendue.

    * **Conseils de debogage**

      * Journalisez dans la console : la valeur de consentement, le visitorCode et les valeurs de variation, et verifiez qu'elles correspondent a ce que vous voyez dans le navigateur.
      * Activez la journalisation du SDK et verifiez les erreurs eventuelles.
  </Accordion>

  <Accordion title="Quelles donnees necessitent un consentement pour etre envoyees ?">
    Conformement aux regles RGPD, sans consentement du visiteur, Kameleoon n'utilise que les informations techniques necessaires au bon fonctionnement des fonctionnalites du produit.

    Sans consentement, Kameleoon envoie les variations pour les regles de Targeted Delivery (mais pas pour les regles d'Experiment). Toutes les autres informations (par exemple, CustomData, Page Views et Geolocation) ne sont envoyees qu'avec le consentement du visiteur (lorsque l'autorisation a ete accordee).

    Vous pouvez en savoir plus sur la gestion du consentement [ici](/user-manual/project-management/consent-management-policy#how-to-choose-your-consent-management-policy).
  </Accordion>

  <Accordion title="Quand le SDK envoie-t-il une requete de suivi pour l'analytique ?" id="when-does-the-sdk-send-a-tracking-request-for-analytics">
    Par defaut, le SDK regroupe plusieurs evenements ensemble et envoie une requete de suivi aux serveurs Kameleoon a des fins d'analyse a un intervalle configurable. Cette approche ameliore l'efficacite et reduit la charge du serveur.

    Une requete de suivi sera envoyee :

    * **Periodiquement :** Par defaut, une requete est envoyee toutes les **1000 millisecondes (1 seconde)**. Vous pouvez modifier cet intervalle en definissant la valeur **tracking interval**.
    * **A la demande :** Instantanement, si une methode comme `flush(instant=true)` est appelee dans votre code.

    Plus precisement, une requete de suivi est declenchee si l'une des methodes suivantes est appelee avant l'expiration de l'intervalle :

    * `getVariation` (lorsque `track` est defini sur `true`).
    * `getVariations` (lorsque `track` est defini sur `true`).
    * `isFeatureActive` (lorsque `track` est defini sur `true`).
    * `trackConversion`
    * `flush` (avec ou sans `instant=true`)

    En plus des appels de methode ci-dessus, les **SDK cote client** envoient une requete de suivi toutes les **60 secondes** par defaut si aucune autre activite ne s'est produite, ce qui aide a maintenir la session du visiteur. Vous pouvez modifier cette valeur par defaut en definissant le parametre `activityTrackingIntervalMillisecond` (ou `activity_tracking_interval_millisecond`) dans la configuration du SDK.

    Pour les **SDK cote serveur**, le regroupement d'evenements est particulierement utile car chaque requete de suivi peut consolider les donnees de plusieurs visiteurs dans une seule requete. Cette approche agrege les informations sur tous les visiteurs affectes et les envoie une fois par intervalle, ameliorant l'efficacite et reduisant la charge du serveur.

    <Warning>
      Les requetes de suivi sont soumises aux [limites de debit de la Data API](../../apis/data-api-rest/overview#limites-de-débit).

      Pour les **SDK cote client**, dans les environnements ou plusieurs visiteurs partagent le meme reseau (par exemple, dans un bureau), ils peuvent apparaitre comme provenant de la meme adresse IP, ce qui peut depasser la limite de debit et provoquer une erreur `429 - Too Many Requests`.
    </Warning>
  </Accordion>

  <Accordion title="Quelles methodes declenchent des requetes HTTP ? Sont-elles synchrones ou asynchrones ?" id="which-methods-trigger-http-requests-are-they-synchronous-or-asynchronous">
    <Note>
      Dans les differents SDK, les methodes peuvent etre nommees differemment en raison des particularites linguistiques.
    </Note>

    Voici une liste des methodes SDK qui effectuent des requetes HTTP :

    * isFeatureActive / getFeatureVariationKey / getFeatureVariable / trackConversion / flush
      * Ces methodes effectuent des requetes asynchrones vers la Data API pour stocker toutes les informations sur le visiteur (y compris les variations recues par l'utilisateur), qui sont utilisees pour afficher les statistiques dans app.kameleoon.com
    * getRemoteData / getRemoteVisitorData / getWarehouseAudience
      * Ces methodes effectuent des requetes synchrones vers la Data API pour obtenir des informations sur le visiteur
    * De plus, le SDK effectue des requetes asynchrones pour obtenir la configuration necessaire au travail interne.
  </Accordion>

  <Accordion title="Quand dois-je utiliser isFeatureActive ou getFeatureVariationKey ?">
    `isFeatureActive` peut etre appele lorsque vous devez savoir si le flag est actif, mais que vous n'avez pas besoin de connaitre la variation exacte recue pour le visiteur. Lorsque vous utilisez des regles d'expérience, il est preferable d'appeler `getFeatureVariationKey` si vous avez deux variations ou plus en plus de "off."
  </Accordion>

  <Accordion title="Puis-je utiliser a la fois un SDK cote client (y compris le fichier d'application engine.js) et un SDK cote serveur sur mon site web ?">
    Oui, vous pouvez implementer une integration hybride en utilisant a la fois un SDK cote client (tel que le SDK JavaScript Kameleoon ou le fichier d'application `engine.js`) et un SDK cote serveur. Dans cette configuration, il est essentiel d'appeler la methode `getVisitorCode`. Cela garantit une reconnaissance coherente du visiteur entre le navigateur et le serveur, et garantit une allocation coherente des variations lors de l'execution de code cote client (par exemple, le suivi des evenements) et de code cote serveur (comme l'execution de fonctionnalites) pour un feature flag donne.
  </Accordion>

  <Accordion title="Dois-je appeler getVisitorCode ?">
    Vous devez utiliser `getVisitorCode` dans les cas ou vous utilisez une integration hybride (site web \<-> server sdk, js sdk \<-> server, engine \<-> server sdk). Lors de l'appel a `getVisitorCode`, le visitor code sera obtenu et transmis a l'aide d'un cookie. Si vous n'utilisez pas d'integration hybride, vous n'avez pas besoin d'appeler `getVisitorCode` ; cependant, vous pouvez toujours l'appeler pour generer un visitor code aleatoire.
  </Accordion>

  <Accordion title="Le domaine est-il obligatoire pour le SDK ou getVisitorCode ?">
    L'installation de domaine est requise pour `getVisitorCode`. Sinon, vous pourriez obtenir differentes variations pour un meme visiteur, car il aurait differents visitor codes sur differents sous-domaines de votre site.
  </Accordion>

  <Accordion title="Si j'utilise une integration hybride, dois-je gerer le consentement deux fois ?">
    Si vous utilisez les SDK serveur et client en meme temps, vous devez definir le consentement pour les deux SDK.

    Veuillez consulter [cet](../../privacy-and-compliance/consent-management) article pour plus de details.
  </Accordion>

  <Accordion title="Comment les bloqueurs de publicites affectent-ils Kameleoon ?" id="how-do-ad-blockers-affect-kameleoon">
    Kameleoon, comme de nombreuses solutions d'optimisation d'experience, peut etre bloque par certains bloqueurs de publicites. Ceux-ci affectent principalement le fichier d'application Web Experimentation (`engine.js`) et les SDK cote client, qui s'appuient sur du code JavaScript charge sur votre site web. Les SDK cote serveur, cependant, fonctionnent au sein de vos serveurs et ne sont pas affectes par les bloqueurs de publicites.

    Si vous voulez que les utilisateurs avec des bloqueurs de publicites soient inclus dans vos expériences, Kameleoon propose une option premium qui vous permet d'utiliser un domaine personnalise au lieu du domaine par defaut de Kameleoon. Les domaines personnalises empechent les bloqueurs de publicites de detecter et de bloquer Kameleoon. Une fois configure, Kameleoon utilisera votre domaine personnalise pour toutes les requetes reseau sortantes vers nos serveurs, que ce soit a des fins de suivi ou pour recuperer les mises a jour de configuration du SDK.

    Utiliser un domaine personnalise n'est pas la meme chose que l'auto-hebergement. Lorsque vous utilisez un domaine personnalise, l'infrastructure Kameleoon heberge et sert toujours tout le contenu (par exemple, `engine.js`, configuration SDK, appels de suivi). La difference est que ces requetes sont acheminees via un domaine que vous controlez, comme `experiments.mydomain.com`.

    Pour activer cette option, contactez votre Technical Account Manager. Vous devez fournir un domaine complet (par exemple, `experiments-mydomain.com`), pas un sous-domaine (par exemple, `experiments.mydomain.com`). Le nom de domaine ne peut pas contenir la sous-chaine `kameleoon`.

    * Pour Web Experimentation, remplacez les references au domaine Kameleoon par defaut (`kameleoon.`) par votre domaine personnalise.
      * **Exemple :** `//SITE_CODE.{your-domain}/engine.js`
    * Pour les SDK cote client, utilisez le parametre `networkDomain` dans l'initialisation du SDK.

    Si vous souhaitez vous auto-heberger plutot que d'utiliser un domaine personnalise, suivez [ce guide](../../web-experimentation/self-hosting/simple-self-hosting-and-on-premises-options#auto-hébergement-du-fichier-d’application).
  </Accordion>
</AccordionGroup>