Experiment Center

Découvrez Auth0 Experiment Center et apprenez à créer des flux d’authentification pour des tests A/B.

Auth0 Experiment Center est un moteur d’expérimentation natif d’Auth0. Il vous permet d’effectuer des tests A/B sur votre expérience d’authentification et d’en voir l’impact dans vos logs d’événements d’authentification.

Avec Experiment Center, vous définissez votre test A/B dans Auth0, le trafic est réparti de manière déterministe et vos événements d’authentification existants sont enrichis de métadonnées d’expérimentation afin que vous puissiez analyser les résultats dans vos propres outils.

​

Fonctionnement

Experiment Center vous permet d’exécuter des tests A/B contrôlés sur votre pipeline d’authentification Auth0. Au lieu de déployer une modification à tous les utilisateurs en même temps, vous exposez un nouveau comportement à un pourcentage contrôlé du trafic, mesurez le résultat à l’aide d’événements d’authentification enrichis, puis faites passer en production la variation gagnante lorsque vous êtes prêt.

Experiment Center s’articule autour de trois entités :

• expérience : définit comment le trafic est réparti et à quel moment le test s’exécute.
• Feature flag : définit ce que vous testez et les variations possibles.
• Segment : définit un ensemble de règles pour orienter les expériences vers des variations précises.

Pendant la phase bêta, Experiment Center fonctionne uniquement sur les tenants de développement. Les tenants de production ne sont pas pris en charge.

​

Expérience

Une expérience sert de cadre de mesure autour d’un flag de fonctionnalité. Elle définit :

• Quel flag de fonctionnalité est testé
• Comment le trafic est réparti entre les variations
• Quand le test est en cours

Chaque expérience fait référence à un seul flag de fonctionnalité.

​

Cycle de vie des expériences

Les expériences ont cinq états :

Statut	Signification
draft	Créé, mais non en cours d’exécution. Peut être testé sans risque au moyen de remplacements de paramètres de requête.
active	En cours d’exécution. L’attribution des variantes et l’injection de contexte sont actives pour toutes les transactions d’authentification.
paused	Temporairement suspendu. Aucune nouvelle attribution. Les sessions en cours conservent leur variante attribuée.
completed	Terminé. Aucune nouvelle attribution. La configuration est conservée à titre de référence lors de la promotion manuelle.
archived	Supprimé de façon logique. Masqué des vues de liste par défaut. Les données analytiques sont conservées.

​

Stratégies d’allocation

Une expérience utilise l’une des deux stratégies d’allocation suivantes :

Basée sur un pourcentage : Le trafic est réparti entre les variations selon leur pondération. Toutes les pondérations doivent totaliser 100. Une pondération de 0 est valide (la variation figure dans la définition de l’expérience, mais ne reçoit aucun trafic).

Basée sur les segments (ciblée) : Le trafic est acheminé vers les variations selon l’appartenance à un segment. Les segments sont évalués par ordre de priorité. Le premier segment correspondant est retenu. Si aucun segment ne correspond, l’allocation is_fallback reçoit la requête.

Pour en savoir plus sur l’entité d’expérience, consultez Détails des entités.

​

Contexte de l’expérience

Lorsqu’une expérience est active et qu’une variation est attribuée, Experiment Center injecte un objet ExperimentContext dans vos surfaces d’exécution.

Les écrans ACUL ne le reçoivent que si vous activez explicitement l’écran au moyen de context_configuration. Pour en savoir plus, consultez le guide d’intégration ACUL.

Les Actions et les modèles de page le reçoivent automatiquement chaque fois qu’une expérience est active. Voici la structure de l’objet :

{
  experiment_id: string;   // L'ID de l'expérience active
  variation_id: string;    // L'ID de la variation attribuée
  config: {                // Configuration fusionnée (référence + remplacements)
    [paramName]: { value: unknown }
  };
  is_control: boolean;     // True si c'est la variation témoin
}

Le champ config contient l’intégralité de la configuration fusionnée pour la variation attribuée. Chaque paramètre défini dans le feature flag a toujours une valeur. Vous n’avez pas à prévoir de logique de secours.

​

Attribution

Une attribution correspond à la façon dont un utilisateur est dirigé vers une variation précise pendant une transaction d’authentification. Les attributions sont déterministes et persistantes : le même utilisateur voit systématiquement la même variation pour la même expérience sur le même appareil, de sorte que son expérience demeure stable d’une connexion à l’autre.

• L’allocation en pourcentage répartit le trafic entre les variations selon leur pondération. Un sujet donné est systématiquement attribué à la même variation.
• L’allocation par Segment évalue les propriétés de la requête en fonction des règles de votre segment, par ordre de priorité. Le premier segment correspondant détermine la variation, et une requête qui correspond au même segment est toujours associée à la même variation.

Les résultats d’attribution sont consignés dans les logs du tenant sous details.experiment ; ils ne sont pas exposés par une API distincte.

Pour en savoir plus sur l’entité d’attribution, consultez Détails des entités.

​

Feature flag

Un feature flag est l’unité de contrôle de ce qui est testé. Il contient :

• Une configuration de référence : des paramètres typés et leurs valeurs par défaut
• Une ou plusieurs variations : des configurations alternatives qui diffèrent de la configuration de référence

Les feature flags sont propres à un tenant et réutilisables. Le même flag peut être utilisé par plusieurs expériences au fil du temps (par exemple, un test du T1 et un ajustement du T2 sur la même fonctionnalité).

​

Cycle de vie des Feature flags

Les Feature flags ont un cycle de vie défini en trois états :

Statut	Signification
draft	Créé, mais pas encore actif. Ne peut pas être utilisé par une expérience active.
active	Prêt à être utilisé. Obligatoire avant qu’une expérience qui utilise ce flag puisse être activée.
archived	État final. Aucune nouvelle expérience ne peut utiliser ce flag. Créez-en un nouveau au besoin.

Pour en savoir plus sur l’entité Feature flag, consultez Détails des entités.

​

Variation

Une variation correspond à une version de l’expérience définie dans un feature flag. Elle indique quels paramètres de configuration diffèrent de la configuration de référence, et dans quelle mesure.

• La variation témoin correspond à la référence; elle ne comporte aucun remplacement (aucun paramètre n’est modifié par rapport aux valeurs par défaut du flag).
• Les variations de traitement définissent chacune un ou plusieurs remplacements de paramètres.

Les variations n’ont pas de marqueur is_control. Le fait qu’une variation soit le témoin statistique d’une expérience donnée se définit au niveau de l’allocation, et non de la variation. Une même variation peut être le témoin dans une expérience et un traitement dans une autre.

Pour en savoir plus sur l’entité variation, consultez Détails des entités.

​

Segment

Un segment est un groupe nommé de requêtes d’authentification qui correspondent à un ensemble de règles. Les segments sont utilisés dans des expériences d’allocation ciblée pour acheminer des cohortes de trafic précises vers des variations précises.

Les segments sont propres à un tenant et réutilisables d’une expérience à l’autre.

Pour en savoir plus sur l’entité Segment, consultez Détails des entités.

​

Limitations

Les limitations suivantes s’appliquent pendant la phase Beta :

• Une expérience active par tenant. Vous pouvez avoir plusieurs expériences dans les états draft, paused ou completed, mais une seule peut être active à la fois.
• Paramètres structurés uniquement. Les paramètres des feature flags utilisent la structure clé/type/valeur.
• Trois déclencheurs d’Actions. Le contexte de l’expérience est disponible dans post_login, pre_user_registration et post_user_registration.
• Trafic de test uniquement. La Beta fonctionne sur des tenants de développement avec le trafic que vous générez. Les données des utilisateurs finaux en Production ne transitent pas par la Beta.
• Promotion manuelle. Lorsqu’une expérience est terminée, vous devez appliquer manuellement à votre tenant la configuration de la variation gagnante.

​

En savoir plus

Lisez Détails des entités pour en savoir plus sur les entités et les propriétés d’Experiment Center.

Lisez Quickstart d’Experiment Center pour apprendre à créer un flag, à activer une expérience et à observer des événements consignés enrichis de bout en bout.