Drapeaux d'expérimentation et tests A/B

1) Pourquoi est-ce nécessaire

L'expérimentation est un moyen gérable d'améliorer la conversion et la fiabilité sans risque de « casser la prod ». Dans iGaming, cela affecte : inscription, dépôt/retrait, paris/settle, KYC/AML-entonnoir, lobby/UX, bonus et antifrod. Les ficheflags donnent des changements rapides et réversibles ; Les tests A/B sont la preuve de l'effet avant l'échelle.

2) Principes de la plateforme

1. Safety-by-design : drapeaux avec TTL, retraits et limites de couverture ; interdiction d'inclusion dans les SLO rouges.
2. Compliance-aware : SoD/4-eyes pour les drapeaux sensibles (paiements, RG, PII) ; géo-résidence des données.
3. Single Source of Truth : tous les drapeaux/expériences sont comme des données (Git/dépôt de stratégies).

3) Taxonomie des drapeaux

Release Flags : Contrôle du déroulement des versions (canary/rollout/kill-switch).
Drapeaux d'expérience : A/B/n, bandit multi-armed, interleaving pour le classement.
Drapeaux ops : dégradation de la fiche (temporaire), changement de fournisseur (PSP/KYC).
Ses drapeaux : paramètres sans sortie (limites, textes, coefficients).
Drapeaux de sécurité : interrupteurs d'urgence (export PII off, bonus caps).

Chaque indicateur a : 'owner', 'risk _ class', 'scope (tenant/region)', 'rollout _ strategy', 'ttl', 'slo _ gates', 'audit'.

4) Architecture de plateforme

Flag Service (CDN-cache) : donne une solution pour ≤10 -20 ms ; signé sur GitOps/pe consiler.
Assignment Engine : hachage stable + stratification (GEO/brand/device) → baquets.
Service expert : catalogue de tests, calcul MDE/puissance, SRM/guardrails, statistiques.
Exposure Logger : logue idempotent « sous le drapeau/variante » + clé d'événement.
API Metrics : agrégats SLI/KPI/KRI et expériences (CUPED/corrections).
Moteur de politique : SoD/4-eyes, fenêtres freeze, géo-restrictions, gates SLO.
Dashboards & Bot : rapports, alertes guardrail, équipes courtes en chatbot.

5) Modèle de données (simplifié)

Flag: `id`, `type`, `variants`, `allocation{A:0. 5,B:0. 5}`, `strata{geo,tenant,device}`, `constraints`, `ttl`, `kill_switch`, `slo_gates`, `risk_class`, `audit`.
Experiment: `id`, `hypothesis`, `metrics{primary,secondary,guardrails}`, `audience`, `power`, `mde`, `duration_rule`, `sequential?`, `cuped?`, `privacy_scope`.

6) Processus « de l'idée au retrait »

1. Hypothèse : métrique-objectif, risque/conformité-évaluation, EMI (effet minimal perceptible).
2. Conception : choix du public et des stratifications (GEO/tenant/device), calcul de la puissance et de la durée.
3. Randomisation et démarrage : activation via Policy-Engine (SLO vert, SoD passé).
4. Surveillance : contrôles SRM (distorsion de randomisation), guardrails (erreurs/latence/recettes).
5. Analyse : fréquentielle (t-test, U-test) ou bayésienne ; CUPED pour réduire la variance.
6. Solution : promote/rollback/iterate ; entrée dans le répertoire des connaissances.
7. Archivage : Désactiver le drapeau par TTL, libérer la configuration/code, nettoyer la télémétrie.

7) Le but et le baquet

Déterminisme : 'bucket = hash (secret_salt + user_id) mod N'.
Stratification : séparément par 'geo, tenant, device, new_vs_returning' → uniformité dans les couches.
Sel unique pour la période : change de manière contrôlée pour éviter les conflits/fuites.
Expositions : sont logées jusqu'à la première métrique cible (pour éviter le logage sélectif).

8) Métriques et guardrails

Primary : conversion enregistrement/dépôt, ARPPU, rétention de D1/D7, vitesse KYC, lobby CTR.
Secondaire : erreurs LCP/JS, p95 « stavka→settl », PSP auth-success.
Guardrails : error_rate, p99 latences, SLO-burn-rate, plaintes/tickets, RG-seuil (jeu responsable).
À long terme : churn, LTV-proxé, chargebacks, drapeaux RG.

9) Statistiques et prise de décisions

MDE & puissance : prédéfinis (par exemple MDE = + 1. 0 pp, puissance = 80 %, α = 5 %).
SRM (Sample Ratio Mismatch) : χ ²-test une fois toutes les N minutes ; Avec SRM, arrêtons le test et enquêtons.
CUPED : covariata - comportement pré-test/conversion de base (réduit la variance).
Corrections de multiplicité : Bonferroni/Holm ou contrôle FDR.
Sequential : groupe sequential/always-valid p-values (SPRT, mSPRT) - arrêts précoces sécurisés.
Bayesian : probabilité d'amélioration post-période et loss expected ; bon pour prendre des décisions avec l'asymétrie du prix de l'erreur.
Interference/peeking : interdiction de « regarder et résoudre » en dehors des procédures sequential ; logs de toutes les vues.
Non paramétrique : Mann-Whitney pour les résidus lourds ; bootstrap pour la durabilité.

10) Vie privée et conformité

Pas de PII dans les labels et les expositions : tokenization, stockage geo-scope.
SoD/4-eyes : expériences affectant les paiements/limites/PII/jeu responsable.
Holdout par RG/Compliance : une partie du trafic est toujours dans le contrôle (pour voir les effets réglementaires/éthiques).
Minimisation des données : ne stocker que les unités et clés nécessaires.
Audit WORM : qui a lancé/modifié/arrêté, paramètres, versions.

11) Intégrations (opérationnelles)

CI/CD & GitOps : drapeaux comme données ; PR, validation des schémas.
Alerting : guardrail→avto -pause du drapeau, notification IC/propriétaire.
Incident-bot : commandes '/flag on/off ', '/bou pause/resume', '/bou report '.
Release-gates : interdire les releases si des expériences actives dans des zones sensibles sans owner-online.
API Metrics : rapports, gates SLO, implars (trace_id pour les dégradations).
Page d'état : ne publie pas les détails des expériences ; seulement si cela affecte l'accessibilité.

12) Configurations (exemples)

12. 1 Drapeau de roulement selon le schéma canarien

yaml apiVersion: flag.platform/v1 kind: FeatureFlag metadata:
id: "lobby.newLayout"
owner: "Games UX"
risk_class: "medium"
spec:
type: release scope: { tenants: ["brandA"], regions: ["EU"] }
allocation:
steps:
- { coverage: "5%", duration: "30m" }
- { coverage: "25%", duration: "1h" }
- { coverage: "100%" }
slo_gates: ["slo-green:auth_success","slo-green:bet_settle_p99"]
ttl: "30d"
kill_switch: true

12. 2 Expérience A/B avec guardrails et CUPED

yaml apiVersion: exp.platform/v1 kind: Experiment metadata:
id: "payments.depositCTA.v3"
hypothesis: "Новая кнопка повышает депозит-конверсию на +1 п.п."
owner: "Payments Growth"
spec:
audience:
strata: ["geo","tenant","device"]
filters: { geo: ["TR","EU"] }
split: { A: 0.5, B: 0.5 }
metrics:
primary: ["deposit_conversion"]
secondary: ["signup_to_kyc","auth_success_rate"]
guardrails: ["api_error_rate<1.5%","latency_p99<2s","slo_burnrate<1x"]
stats:
alpha: 0.05 power: 0.8 mde: "1pp"
cuped: true sequential: true operations:
srm_check: "5m"
pause_on_guardrail_breach: true ttl: "21d"

13) Dashboards et rapports

Exec : lift par métriques clés, pourcentage d'expériences réussies, impact économique.
Ops/SRE : guardrail-alerts, SRM, dégradation des SLO, impact sur les lagunes/files d'attente.
Domaine : entonnoirs (registratsiya→depozit→stavka), segments GEO/PSP/appareil.
Catalogue : base de connaissances sur les expériences terminées (ce qui a été essayé, ce qui a fonctionné/non, effets sur la RG/conformité).

14) fonction KPI/KRI

Time-to-Test : ideya→start (jours).
Test Velocity : expériences/mes par commande/domaine.
Taux de réussite : proportion de tests ayant un effet positif statistiquement significatif.
Guardrail Breach Rate : fréquence des auto-auses par SLO/erreurs.
MRS Incapacité : proportion de tests avec randomisation perturbée.
Documentation Lag : Temps entre la fin et l'écriture dans le répertoire.
Cost per Test : $ de télémétrie/calculs/escorte.
Long-term Impact : changement de LTV/churn/chargebacks sur les cohortes d'options gagnantes.

15) Feuille de route pour la mise en œuvre (6-10 semaines)

• Référentiel d'indicateurs/expériences, schémas (JSON Schema), service Flag de base avec cache.
• Policy-Engine (SoD/4-eyes, SLO-gates), intégration avec GitOps.

• Assignment Engine (hash + strates), Exposure Logger, chèque SRM, guardrails-alerts.
• Premier jeu de drapeaux : release + ops (kill-switch), 1-2 sécurisés A/B.

• Module statistique : CUPED, rapports fréquentiels et bayésiens, contrôle séquentiel.
• Dashboards (Exec/Ops/Domain), commandes incident-bot '/flag ', '/bou'.

• Autopause par guardrails, intégration avec Release-gates, catalogue de connaissances.
• Documentation des processus, formation des équipes (Growth/Payments/Games).

• Multi-région et géo-résidence, FinOps limites de cardinalité, exercice de chaos (rupture de SRM).
• Certification des propriétaires d'expériences, audit WORM.

16) Anti-modèles

Allumez les drapeaux « tout le monde à la fois » sans les canaries et les gats SLO.
Mélanger les drapeaux de libération et expérimentaux en une seule entité sans objectifs explicites.
Randomisation « sur le client » sans sel/déterminisme → MRS/manipulation.
Peeking sans contrôle séquentiel ; après coup, choisir la métrique gagnante.
L'absence de guardrails et d'owner-service → l'augmentation des incidents.
Stocker le PII dans les expositions/labels ; ignorer la géo-résidence.
Ne pas éteindre les drapeaux TTL → les branches « accrochées » et la séparation du comportement.

17) Meilleures pratiques (brièvement)

Petites hypothèses claires ; Une métrique primaire par test.
Départ avec 5-10 % du trafic et des guardrails stricts.
CUPED presque toujours ; Bayesian - lorsque la vitesse de la solution est importante et que le coût des erreurs est asymétrique.
Vérifiez toujours les MRS et les métriques invariantes.
Écrivez un post-analyse et ajoutez-le à votre catalogue de connaissances.
Respecter le jeu responsable (RG) : Ne stimulez pas le comportement nuisible avec des métriques de revenus à court terme.

Total

Les flags et les tests A/B sont le circuit de production des changements : flags comme données, randomisation sécurisée et statistiques rigoureuses, SLO/conformité-guardrails, observation et audit. Cette approche permet d'apprendre rapidement de la vente, en augmentant la conversion et la qualité sans augmenter les risques, avec un effet prouvable pour les entreprises et les régulateurs.