Feature Flags et gestion des versions

Feature Flags et gestion des versions

1) Pourquoi des drapeaux s'il y a des communiqués ?

• Vitesse et sécurité des sorties : petits incréments + retour instantané.
• Contrôle du rayon d'impact : rollout progressif, anneaux, stop SLO.
• Expériences et A/B : drapeaux multivariés, statistiques d'effets.
• Scénarios opérationnels : kill-switch pour les chemins de paiement/jeux risqués.

Le principe clé : « ship dark, enable bright » - fournir à l'avance, inclure consciemment.

2) Types de drapeaux

Boolean : marche/arrêt des fiches, drapeaux d'arrêt d'urgence (kill-switch).
Multivariate : comportements (algorithme A/B/C, limites, coefficients).
Bou/: paramètres (délais, limites de mise, taille du bonus).
Permission/Entitlement : accès aux fonctions/limites par rôle/tiers.
Operational : routage du trafic (demande d'ombre, activation d'un nouveau service).

3) Architecture et flux de données

Control Plane : console/serveur d'indicateurs, stockage des règles/segments, audit.
Data Plane (SDK/Proxy/Edge) : obtention et mise en cache des drapeaux, évaluation des règles localement (latence minimale), folback en cas d'indisponibilité.

• Pull : Le SDK synchronise périodiquement le config (ETag/stream).
• Push/Streaming : le serveur puise les mises à jour (Server-Sent Event/WebSocket).
• Edge Cache/Proxy : plus proche de l'utilisateur, réduit p99.

• Évaluation locale des règles (pas de hop réseau dans hot-path).
• Taimauts et folbacks (sans lecture « bloquante » du drapeau).
• Signature/versioning de snapshots configs.

4) Ciblage et segments

Attributs : pays/région, langue, plate-forme, niveau KYC, niveau VIP, risque, âge du compte, méthode de paiement, limites de jeu responsable.
Segments : règles enregistrées avec des versions ; « doux » (marketing) et « dur » (conformité).
Priorités/conflits : les ordres de règles explicites, la « dernière coïncidence » est interdite sans tests.
Géo/réglementation : cases à cocher pour la disponibilité du produit par pays ; prédicats immuables (par exemple, interdiction d'un bonus pour un pays donné).

json
{
"flag": "new_withdrawal_flow",
"default": false,
"rules": [
{"when": {"country": "CA", "kyc_level": "FULL"}, "rollout": 25},
{"when": {"segment": "vip_tier_3_plus"}, "rollout": 100},
{"when": {"country": "DE"}, "force": false}
],
"expiresAt": "2026-03-31T00:00:00Z"
}

5) Rollout progressif : stratégies

Canary par %: 1 % → 5 % → 25 % → 50 % → 100 % avec auto-stop SLO.
Rings : équipe interne → utilisateurs bêta → une région → globalement.
Sampling par appareil/client : prendre en compte le hachage (ID).
Shadow traffic : dupliquer une requête vers un nouveau chemin sans affecter l'utilisateur.
Dark launch : inclus, mais pas apparent (collecte de métriques, chauffage des caches).

• Dégradation p95 de la latence API 'withdraw'> + 15 % pendant 10 minutes.
• Erreurs 5xx> 0. 5 % ou augmentation des refus du fournisseur de paiement> + 0. 3 p.
• Alert frod/risque-scoring est supérieur au seuil dans le segment.

6) Kill-switch (drapeaux d'urgence)

Une classe distincte de drapeaux, visible par SRE/On-Call.
Estimation locale garantie avec cache TTL (millisecondes).
Déconnexions non remboursables : require reason + ticket postmortem.
Intégration auto-action : désactiver le bonus, mettre les paiements en mode manuel, interdire les dépôts pour le fournisseur X.

7) Intégration avec CI/CD et GitOps

CI : validation des schémas de drapeaux, lynx de règles, « dry run » de ciblage sur échantillons anonymisés.
CD : promotion des drapeaux configus comme artefacts (semver), « approval gates » pour drapeaux sensibles (paiements/conformité).
GitOps : drapeaux dans un référentiel de configues séparé, merge request = événement de changement, audit hors boîte.

8) Sécurité et conformité

RBAC/ABAC : qui peut créer/inclure/augmenter le pourcentage ; séparation des tâches (développeur ≠ diplômé ≠ propriétaire du produit).
Vérification : qui/quand/quoi/pourquoi ; justification (ticket/JIRA), comparaison avec les incidents.
Minimisation des PII : les attributs de ciblage passent par l'anonymisation/le hachage.
Signature des snapshots : vérification de l'intégrité sur le SDK/Proxy.
SLA pour la livraison de fligs : dégradé en « défaut de sécurité ».

9) Observabilité et métriques

• Temps de propagation du drapeau (p50/p95), hit-rate de la cache locale, fréquence des mises à jour.
• Nombre de drapeaux actifs/obsolètes/ » suspendus » (non retirés).
• Garde SLO : latence, erreur, conversion, stabilité du fournisseur.

• DORA : fréquence des débris, temps avant l'allumage, pourcentage de défaillances après l'allumage, MTTR.
• Indicateurs A/B : CR, ARPPU, signaux LTV, effet sur le fred scoring.

10) Le cycle de vie du drapeau

1. Design : cible/métrique/propriétaire/date d'expiration ('expiresAt'), scénarios de retour en arrière.
2. Exécution : appels SDK, folbacks, télémétrie « exposition « / » décision ».
3. Rollout : alimentation progressive + porte SLO.
4. Stabiliser : enregistrer l'effet, mettre à jour la documentation/routines.
5. Cleanup : supprimer les branches de code, fermer l'indicateur, vérifier les « résidus ».

11) Exemples de mise en œuvre

11. 1 Web/Node. js

ts
// Инициализация SDK (псевдо)
const flags = await sdk.init({ sdkKey: process.env.FLAGS_KEY, user: { id: userIdHash, country, vipTier } });

// Не блокировать рендер:
const showNewCashout = flags.bool("new_withdrawal_flow", false);

if (showNewCashout) {
renderNewFlow();
} else {
renderClassic();
}

11. 2 Kotlin / JVM

kotlin val client = FlagsClient(sdkKey = System.getenv("FLAGS_KEY"))
val context = UserContext(id = userHash, country = country, kycLevel = kyc)
val enabled = client.getBoolean("risk_guard_withdrawals", default = true, context = context)
if (!enabled) {
// аварийный режим: все выводы в manual review routeToManual()
}

11. 3 NGINX (toggle externe via map)

nginx map $http_x_feature $cashout_new {
default 0;
"~enabled" 1;
}

location /withdraw {
if ($cashout_new) { proxy_pass http://new_flow; }
if (!$cashout_new) { proxy_pass http://classic_flow; }
}

12) Gestion des risques et étapes progressives

Étapes d'inclusion : 1 % des employés → 5 % « bêta » → 10 % RU → 25 % EU → 100 % sauf DE (régulateur).
Limiteurs : max. 1 pas/30 min ; exigence de stabilité des métriques par fenêtre de 15 min.
Auto-stop : politique au niveau de la plateforme (voir ci-dessous OPA).

rego package flags.guard

deny[msg] {
input.flag == "new_withdrawal_flow"
input.metrics["withdraw_5xx_rate"] > 0.5 msg:= "Stop rollout: withdraw 5xx too high"
}

13) Contrôle d'accès et négociation

Types de changement : standard (sécurisé) vs sensibles (paiements/paiements/limites).
Approvals : Propriétaire du produit + technique responsable + conformité (pour les juridictions).
Fenêtres temporelles (freeze) : interdiction des inclusions/extensions dans les périodes à haut risque (prime time, grands tournois).

14) Expériences et statistiques

Exposure events : Nous logions la solution du drapeau avec des attributs.
Analyse : valeur actuelle de rollout, segments, effet de conversion/erreur.
Contrôles statistiques : bon split, covariables de contrôle (appareils/géo).
Éthique et réglementation : éviter les segmentations limitées par le droit local.

15) Anti-modèles

Drapeaux de longue durée sans « expiresAt », « cimetière de branches » dans le code.
Appel réseau de blocage SDK dans hot-path.
Ciblage redondant par PII, pas d'anonymisation des attributs.
Activation sans garde SLO/arrêt automatique.
Aucun kill-switch pour les flux à haut risque (dépôts/retraits/bonus).
Modifications manuelles « secrètes » des drapeaux sans vérification ni justification.

16) Chèque de mise en œuvre (0-60-90)

0-30 jours

Sélectionner une plate-forme d'indicateurs/préparer un self-host (SDK, proxy, cache).
Entrez un schéma ('flag', 'owner', 'purpose', 'expiresAt', 'risk _ level').
Connectez les métriques SLO à la plate-forme (latence/erreurs d'API clés).

31-60 jours

Ajoutez les approvals par drapeaux sensibles, les gardes OPA.
Configurer des stratégies progressives (percent/rings), kill-switch panel.
Intégrer le linter de circuit de drapeau dans le CI ; commencer à nettoyer les premiers « suspendus ».

61-90 jours

Intégration complète avec GitOps (édition MR des drapeaux, audit).
Dashboards visuels : coverage SDK, temps de diffusion, % kesh-hits.
Régulièrement « Flag Debt Day » : supprimer le code et fermer les drapeaux.

17) Métriques de maturité

Technique : p95 acceptation de configuration <5 s ; cache hit-rate SDK> 95 %;% des drapeaux avec 'expiresAt'> 90 %.
Processus : drapeaux 100 % sensibles avec approvals ; moyenne « temps de descente » <3 min.
Hygiène des codes : proportion de drapeaux fermés dans les 30 jours suivant l'inclusion mondiale> 80 %.
Effet opérationnel : amélioration de DORA (taux de sortie ↑, MTTR ↓), réduction des incidents de sortie.

18) Applications : modèles et politiques

Diagramme du drapeau (YAML)

yaml flag: new_withdrawal_flow owner: payments-team risk_level: high purpose: "Новый поток вывода средств"
expiresAt: "2026-03-31T00:00:00Z"
sla:
propagation_p95_ms: 3000 slo_guards:
withdraw_p95_ms_increase_pct: 15 withdraw_5xx_rate_pct: 0.5 approvals:
required: ["product_owner","tech_lead","compliance"]

Politique « pas de drapeaux éternels » (conditionnel pour linter)

yaml rules:
- check: expiresAt max_days_from_now: 180 action: error

Contrat d'événements SDK (exposition)

json
{
"event": "flag_exposure",
"flag": "new_withdrawal_flow",
"variant": "on",
"userKey": "hash_abcdef",
"context": {"country":"CA","vipTier":"3"},
"traceId": "9f1c...a2",
"ts": 1730623200000
}

19) Conclusion

Feature Flags est une « poignée de volume » pour les changements. Connectez les allumages progressifs, les gardes SLO, l'audit rigoureux et le nettoyage régulier, et attachez les drapeaux à CI/CD et GitOps. En conséquence, les rejets deviendront fréquents, gérables et sécurisés, et le risque d'incidents sera prévisible et contrôlé.