Gestion du cycle de vie des expériences

Cette compétence couvre les transitions d'état des expériences — ce que fait chaque action, quand l'utiliser et comment elle affecte l'assignation des variantes et l'analyse.

Diagramme d'état

draft ──launch──▶ running ──end──▶ stopped ──archive──▶ archived
                    │   ▲              │
                  pause resume    ship_variant
                    │   │         (also ends if running)
                    ▼   │
                  paused (flag inactive, still "running" status)

Any non-draft state ──reset──▶ draft

Actions et leurs implications

Pour chaque action, deux questions clés :

1. Qui voit quelle variante ? (perspective utilisateur)
2. Qui est dans mon analyse ? (perspective statistique)

Launch (experiment-launch)

Transition brouillon → en cours. Active le feature flag et définit start_date.

• Préconditions : doit être en brouillon, le flag doit avoir ≥2 variantes avec "control" en premier
• Checklist pré-lancement : au moins une métrique ? Variantes correctes ? Flag implémenté dans le code ?
• Variantes : les utilisateurs commencent à être distribués entre les variantes selon la répartition configurée
• Analyse : la collecte de données commence à partir de start_date

Aucun corps de requête nécessaire.

Pause (experiment-pause)

Désactive le feature flag. Les utilisateurs reviennent à l'expérience par défaut (généralement le contrôle).

• Préconditions : doit être en cours et pas déjà en pause
• Variantes : le flag n'est pas retourné par /decide — aucun nouvel événement d'exposition enregistré
• Analyse : aucune nouvelle donnée pendant la pause, mais les données existantes sont conservées. L'expérience reste "en cours".

Aucun corps de requête. Utilisez experiment-resume pour réactiver.

Resume (experiment-resume)

Réactive le feature flag après une pause. Les utilisateurs sont redistribués de manière déterministe dans les mêmes variantes.

• Préconditions : doit être en pause
• Variantes : même assignation qu'avant la pause — bucketing déterministe
• Analyse : le suivi des expositions reprend

Aucun corps de requête.

End (experiment-end)

Définit end_date et transition vers arrêté. Le feature flag n'est PAS modifié.

• Préconditions : doit être en cours (lancé, pas déjà arrêté)
• Variantes : les utilisateurs continuent à voir leurs variantes assignées (le flag reste actif)
• Analyse : les résultats sont figés selon les données jusqu'à end_date

Corps optionnel : conclusion ("won", "lost", "inconclusive", "stopped_early", "invalid") et conclusion_comment.

Utilisez ceci quand vous voulez figer les résultats sans changer ce que voient les utilisateurs.

Ship variant (experiment-ship-variant)

Réécrit le feature flag pour que la variante sélectionnée soit servie à 100 % des utilisateurs.

• Préconditions : doit être lancé (en cours ou arrêté). Impossible de pousser depuis le brouillon.
• Variantes : TOUS les utilisateurs voient la variante poussée. Le flag est réécrit avec un groupe catch-all.
• Analyse : si toujours en cours, l'expérience est aussi terminée (end_date défini)

Toujours confirmer avec l'utilisateur avant de pousser — cela réécrit définitivement le feature flag.

Obligatoire : variant_key (ex. "test"). Optionnel : conclusion, conclusion_comment.

Retourne 409 si une politique d'approbation nécessite un examen avant le changement de flag.

Archive (experiment-archive)

Masque une expérience arrêtée de la vue de liste par défaut.

• Préconditions : doit être arrêté (end_date défini)
• Variantes : aucun changement — le flag est inaffecté
• Analyse : aucun changement — les résultats restent accessibles

Aucun corps de requête. Peut être restauré en définissant archived=false via experiment-update.

Reset (experiment-reset)

Retourne une expérience à l'état brouillon. Efface start_date, end_date, conclusion et archived.

• Préconditions : ne doit pas déjà être en brouillon
• Variantes : le flag est laissé inchangé — les utilisateurs continuent à voir leurs variantes assignées
• Analyse : les données précédemment collectées existent toujours mais ne seront pas incluses dans les résultats à moins que start_date soit ajusté après un relancement

Aucun corps de requête.

Duplicate (experiment-duplicate)

Crée une copie en tant que nouveau brouillon avec des dates fraîches et aucun résultat.

Important : fournissez toujours une feature_flag_key unique différente de l'originale. Si la même clé est utilisée, les deux expériences partagent un flag — les changements dans l'une affectent l'autre.

Optionnel : name personnalisé (par défaut "Original Name (Copy)").

Cadre décisionnel

Résolution des expériences

Toutes les actions du cycle de vie nécessitent un ID d'expérience. Si vous n'en avez pas, chargez la compétence finding-experiments pour résoudre la référence de l'utilisateur (nom, description, "latest", etc.) vers un ID concret avant de procéder.

Gestion des erreurs

Quand vous recevez un 400, expliquez la situation à l'utilisateur plutôt que de réessayer.