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

# Détails des entités

> Découvrez les entités d’Experiment Center : les Feature flags, les variations, les segments, les expériences et les attributions.

> [!WARNING]
>
> **La fonctionnalité Auth0 Experiment Center est en .**

Avec la [Management API](https://auth0.com/docs/fr-ca/api/management/v2.md) d’Auth0, vous pouvez définir les détails de l’entité Experiment Center, y compris ses propriétés, ses états du cycle de vie et ses règles de validation.

## Expérience

### 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 à l’aide de remplacements de paramètres de requête. |
| `active` | En cours d’exécution. L’attribution des variantes et l’injection du contexte sont actives pour toutes les transactions d’authentification. |
| `paused` | Temporairement suspendu. Aucune nouvelle attribution. Les sessions en cours conservent leur variation attribuée. |
| `completed` | Terminé. Aucune nouvelle attribution. La configuration est conservée à des fins de référence pendant la promotion manuelle. |
| `archived` | Supprimé de façon réversible. Masqué dans les vues de liste par défaut. Les données analytiques sont conservées. |

Pour faire passer le cycle de vie d’un état à l’autre, utilisez le point de terminaison de la Management API [`/api/v2/experimentation/experiments/{id}`](https://auth0.com/docs/fr-ca/api/management/v2/experimentation/update-experiment).

La transition de `completed → active` n’est pas autorisée. Si vous devez relancer le même test, créez une nouvelle expérience.

### Le contrôle `is_valid`

Avant qu’une expérience puisse être activée, elle doit passer une vérification de l’état de préparation.

Experiment Center stocke un booléen `is_valid` pour chaque expérience et le recalcule à chaque modification. Cela vous donne une rétroaction immédiate pendant la configuration.

Vous pouvez aussi déterminer explicitement l’état de préparation à l’aide du point de terminaison [`/api/v2/experimentation/experiments/{id}/validate`](https://auth0.com/docs/fr-ca/api/management/v2/experimentation/validate-experiment) de la Management API.

Cela renvoie `is_valid: true/false` et un tableau `errors` qui répertorie tous les éléments bloquants. La même vérification s’exécute automatiquement lorsque vous tentez d’activer une expérience au moyen du point de terminaison de status.

**Règles de validation vérifiées lors de l’activation :**

* Le feature flag référencé a le status `active`
* Au moins une allocation existe
* Toutes les valeurs `variation_id` des allocations appartiennent au feature flag de l’expérience
* Exactement une allocation a `is_control: true`
* La somme des pondérations des allocations est de 100 (stratégie en pourcentage)
* Exactement une allocation a `is_fallback: true` (stratégie par segment)
* Aucune autre expérience n’est actuellement active pour le tenant (Beta seulement)

### Attribution

**Remplacements par paramètres de requête**

Vous pouvez forcer une attribution précise pour toute requête `/authorize` en transmettant des paramètres de requête :

| Paramètre | Description |
| - | - |
| `experiment_id` | Inscrire à une expérience précise |
| `variation_id` | Forcer une variation précise (nécessite `experiment_id`) |
| `segment_id` | Forcer un segment précis (nécessite `experiment_id`) |

Cela fonctionne pour les expériences, peu importe leur état, y compris `draft`. Utilisez cette option pendant le développement pour vérifier que les deux variations s’affichent correctement avant l’activation.

## Drapeau de fonctionnalité

### Cycle de vie du Feature flag

Les Feature flags ont un cycle de vie enregistré comportant trois états :

| **Statut** | **Signification** |
| - | - |
| `draft` | Créé, mais pas encore actif. Ne peut pas être référencé par une expérience active. |
| `active` | Prêt à être utilisé. Obligatoire avant qu’une expérience qui référence ce flag puisse être activée. |
| `archived` | État terminal. Aucune nouvelle expérience ne peut référencer ce flag. Créez un nouveau flag au besoin. |

Pour passer d’un statut à l’autre, utilisez le point de terminaison [`/api/v2/experimentation/feature-flags/{id}`](https://auth0.com/docs/fr-ca/api/management/v2/experimentation/update-feature-flag) de l’Auth0 Management API.

**Condition d’activation :** un Feature flag ne peut pas passer à `active` tant qu’il ne comporte pas au moins deux variations. Cela garantit que chaque flag actif possède au minimum un control et un treatment avant sa mise en service.

```text wrap lines theme={null}
draft → active   (requires ≥2 variations)
draft → archived
active → archived (terminal; no way back)
```

Il n’est pas possible de passer de `archived → active`. Si vous archivez un flag et que vous devez lancer un autre test, créez un nouveau feature flag.

### Variation

**Paramètres et remplacements**

Les paramètres du feature flag définissent les éléments de configuration de votre expérience. Chaque paramètre comprend :

* Un nom (par exemple, `show_passkey_prompt`)
* Un type : `string`, `boolean`, `number`, `array` ou `object`
* Une valeur par défaut (la configuration de base)

Les `overrides` d’une variation indiquent uniquement les paramètres qui diffèrent. À l’exécution, Experiment Center fusionne la configuration de base du flag avec les remplacements de la variation et transmet l’objet `config` complet ainsi fusionné à ACUL, Actions et aux gabarits de page. Chaque paramètre a toujours une valeur dans `config`; vous n’avez donc jamais besoin d’écrire de logique de secours.

Les paramètres utilisent **uniquement le mode structuré**. Chaque paramètre comporte une clé nommée et une valeur typée.

## Segment

### Règles de segment

Le `rules` d’un segment est un array d’objets rule. Une requête correspond au segment si **au moins une** rule du array correspond.

* `match` : toutes les conditions doivent être vraies (logique ET)
* `not_match` : toutes les conditions doivent être vraies (logique NON)

Chaque condition compare un attribut à une valeur à l’aide d’un opérateur : `contains`, `starts_with`, `ends_with`, `exists`.

### Attributs de condition disponibles

Les segments peuvent uniquement utiliser les attributs disponibles au début de la transaction `/authorize` :

| **Catégorie** | **Attributs** |
| - | - |
| Client | `client_id` |
| Connexion | `connection`, `connection_type` |
| Organisation | `organization_id` |
| Domaine | `domain` |
| Appareil et navigateur | `device_type`, `browser`, `platform`, `user_agent` |
| Géographique (tiré de l’adresse IP) | `country`, `region` |

## En savoir plus

> **[Intégration ACUL](https://auth0.com/docs/fr-ca/customize/experiment-center/integrations/acul-integration-guide.md)**
>
> Consultez le contexte de l’expérience dans les écrans Auth0 Custom Universal Login (ACUL).