Feature Flags et sortie fich

Feature Flag (FF) est une condition gérée qui active/désactive le comportement du système sans libérer le code. Les drapeaux permettent : de rouler les fiches en toute sécurité, de cibler les groupes d'utilisateurs/marchés/tenants, de désactiver rapidement les composants problématiques, de mener des expériences et de configurer les paramètres dans le rantime.

• Réduire le radius blast lors des versions.
• Diviser le déploiement et l'activation.
• Donnez une gestion transparente des changements avec un audit, un SLO et un retour en un clic.

1) Types de drapeaux et quand les appliquer

Release flags - Incorporation progressive de nouvelles fiches (dark → canary → ramp-up → 100 %).
Ops/kill-switch - Désactivation instantanée des dépendances (fournisseur, sous-système, calcul lourd).
Experiment (A/B, multi-variant) - division du trafic en variantes (weights, sticky bucketing).
Permission/Entitlement - Accès aux fiches par rôle/plan/compétence.
Remote Bou - Paramètres de comportement (seuil, temporisation, formule) du drapeau/config.
Migration flags - commutation des schémas/chemins de données (transfert vers un nouvel index/OBD/endpoint).

Anti-modèle : le même drapeau « pro tout » - fractionner en ficha, pull et paramètres.

2) Modèle de données du drapeau (minimum)

yaml flag:
key: "catalog. new_ranker"
type: "release"    # release      ops      kill      experiment      permission      config     migration description: "New Directory Ranking"
owner: "search-team@company"
created_at: "2025-10-01T10:00:00Z"
ttl: "2026-01-31" # delete deadline after 100% enable rules:
- when:
tenant_id: ["brand_eu","brand_latam"]
region: ["EE","BR"]
user_pct: 10 # progressive percentage then: "on"
- when:
kyc_tier: ["unverified"]
then: "off"
variants: # for experiments
- name: "control"; weight: 50
- name: "v1"; weight: 30
- name: "v2"; weight: 20 payload:
v1:
boost_freshness: 0. 3 boost_jackpot:  0. 2 v2:
boost_freshness: 0. 2 boost_jackpot:  0. 4 prerequisites: # dependent flags/schema versions
- key: "catalog. index_v2_ready"
must_be: "on"
audit:
require_ticket: true change_window: "09:00-19:00 Europe/Kyiv"
safeguards:
max_rollout_pct: 50 # stop threshold auto_rollback_on:
p95_ms: ">200"
error_rate: ">2%"

3) Évaluation et ciblage (évaluation)

Ключи таргетинга: `tenant_id, region/licence, currency, channel, locale, role, plan, device, user_id, cohort, kyc_tier, experiment_bucket`.
Ordre d'évaluation : prerequisites → règles deny → règles allow → défaut.
Sticky bucketing : pour les expériences, hachez un identifiant stable (par exemple, « hash (user_id, flag_key) ») - afin que l'utilisateur reçoive toujours une seule option.

ts result = evaluate(flag, context)  // pure function if (!prereqs_ok(result)) return OFF if (deny_match(result, ctx)) return OFF if (allow_match(result, ctx)) return resolve_variant_or_on(result, ctx)
return flag. default

4) Distribution et architecture FF

• SDK côté serveur (recommandé) : sources de vérité et cache dans le backend ; l'unification de la logique.
• Edge/CDN evaluation : ciblage rapide sur le périmètre (où il n'y a pas de PII/secrets).
• SDK client-side : lorsque vous avez besoin de personnaliser votre interface utilisateur, mais seulement avec un contexte minimal et sans règles sensibles.
• Bou-as-Code : stockage des drapeaux dans le référentiel, validation CI, rollout via CD.

• Startup bootstrap + streaming updates (SSE/gRPC) + fallback au dernier snapshot.
• SLA « freshness » drapeaux : p95 ≤ 5 s.

5) Stratégies de sortie

5. 1 Dark Launch

Ficha est allumé mais invisible pour l'utilisateur ; nous collectons des métriques et des erreurs.

5. 2 Canary

Nous incluons 1 à 5 % du trafic dans une juridiction/tenante ; nous surveillons p95/p99, erreurs, conversion.
Stop conditions sont les déclencheurs de seuil de l'autocatophe par métrique.

5. 3 Progressive Rollout

10 % → 25 % → 50 % → 100 % à l'horaire manuel/auto-vérification.

5. 4 Shadow / Mirroring

Dupliquez les requêtes dans un nouveau chemin (sans effet visible) et comparez les résultats/latence.

5. 5 Blue/Green + FF

Nous déployons deux versions ; le drapeau roule sur le trafic et change les dépendances en segments.

6) Les dépendances et la cohérence croisée des services

Utilisez prerequisites et "les health-drapeaux" de la volonté : l'indice est construit, la migration est terminée.
Coordination à travers les événements : 'FlagChanged (flag_key, scope, new_state)'.

1. activer le chemin de lecture → 2) vérifier les métriques → 3) activer write/side-effects.

• Contrats de service : le défaut de paiement doit être sécurisé (fail-safe OFF).

7) Observabilité et SLO

• `flag_eval_p95_ms`, `errors_rate`, `config_freshness_ms`.
• Métriques d'entreprise : 'ctr', 'conversion', 'ARPU', 'retraite', guardrails (par exemple, incidents RG).
• Seuils SLO automatiques pour autocatof.

Logi/tracing : ajoutez 'flag _ key', 'variant', 'decision _ source' (server/edge/client), 'context _ hash'.

Dashboards : « escalier » rollout avec seuils, erreurs heatmap par segments.

8) Sécurité et conformité

PII-minimisation dans le contexte.
RLS/ACL : qui peut changer quels drapeaux (par domaine/marché).
Fenêtres de changement d'heure (change Windows) et « double confirmation » pour les indicateurs sensibles.
Vérification immuable : qui/quand/quoi/pourquoi (ticket/incident link).
Juridictions : les drapeaux ne doivent pas contourner les interdictions réglementaires (par exemple, inclure le jeu dans un pays interdit).

9) Gestion des drapeaux « à longue durée de vie »

Chaque drapeau a une TTL/date de suppression.
Après 100 % d'activation - créez une tâche pour supprimer les branches de code, sinon le drapeau-dette augmentera.
Marquez les drapeaux comme 'migration '/' one-time', séparez-les des permanents 'permission/bou'.

10) Exemple de contrat API/SDK

Evaluation API (server-side)

http
POST /v1/flags/evaluate
Headers: X-Tenant: brand_eu
Body: { "keys":["catalog. new_ranker","rgs. killswitch"], "context": { "user_id":"u42", "region":"EE" } }
→ 200
{
"catalog. new_ranker": { "on": true, "variant":"v1", "as_of":"2025-10-31T12:10:02Z" },
"rgs. killswitch":  { "on": false, "variant":null, "as_of":"2025-10-31T12:10:02Z" }
}

Client SDK (кэш, fallback)

ts const ff = await sdk. getSnapshot()     // bootstrap const on = ff. isOn("catalog. new_ranker", ctx)
const payload = ff. payload("catalog. new_ranker", "v1")

11) Interaction avec d'autres circuits

Limites de taux/quotas : les drapeaux peuvent abaisser le RPS/activer la trottinette pendant l'incident.
Circuit breaker/degradation : kill-switchy désactive les voies lourdes et implique la dégradation.
Catalogue/personnalisation : les drapeaux changent de poids/règles de classement (via Remote Bou).
Migration OBD : les drapeaux transfèrent progressivement les lectures/écritures dans un nouveau schéma (read-replica → dual-write → write-primary).

12) Pleybooks (runbooks)

1. Incident après inclusion 25 %

L'auto-atof a fonctionné → le drapeau OFF pour tout le monde/segment, le ticket sur l'appel, la collecte des statuts, RCA.
Activer temporairement la dégradation/ancienne branche via le drapeau de migration.

2. Croissance p95 par catalogue

Le seuil 'p95 _ ms> 200' est auto-atof ; Fixer le snapshot des logs avec 'flag _ key = bou. new_ranker`.
Activer les signaux de classement simplifié (payload bou).

3. Incohérence de la compétence

Le drapeau de permission a par erreur ouvert le jeu dans 'NL' - OFF + post-fact audit, l'ajout d'une règle de garde « région deny ».

4. Variance en A/B

Arrêter l'expérience, effectuer une analyse CUPED/stratified, recalculer avec des poids mis à jour.

13) Tests

Unité : évaluation déterministe des règles/priorités/pré-visites.
Contrat : schéma des drapeaux (JSON/YAML), validateurs, contrôle CI avant merge.
Property-based : « deny> allow », « most specific wins », bucketing stable.
Replay : lecture de contextes réels sur une nouvelle configuration.
E2E : scripts canaris (step-up/step-down), vérification auto-atophe et audit-événements.
Chaos : falaise du streaming, snapshot obsolète, renouvellement massif des drapeaux.

14) Erreurs typiques

Logique secrète dans les drapeaux clients (fuites/échanges).
L'absence de TTL → le « cimetière » des drapeaux dans le code.
Les drapeaux « universels » sans segmentation ne peuvent → localiser le problème.
Pas de guardrails/autocatofs - incidents manuels.
Dépendances incompatibles entre les indicateurs → boucles/dissynchron.
L'évaluation des drapeaux dans chaque requête sans cache → des surtensions de latence.
Absence d'audit/fenêtre de changement - risques de conformité.

15) Chèque-liste avant la vente

• Le drapeau est créé avec le type, owner, description, TTL et l'exigence ticket.
• Les règles de ciblage sont définies ; « deny » pour les régions/rôles indésirables.
• Le bâton est déterministe ; l'ID est choisi stable.
• Les pré-visites et les drapeaux de santé sont prêts ; le défaut est sûr.
• Dashboards et alertes sur p95/p99, error_rate, business guardrails.
• Autocatof est personnalisé ; seuil d'arrêt rollout et conditions de retrait.
• Plan canarien : intérêts/étapes/fenêtre de changement/responsable.
• Les configis sont validés dans l'IC ; le snapshot est réparti en grappes/régions.
• Documentation pour le support/produit ; les pleybooks des incidents.
• Plan de suppression des branches du code et du drapeau lui-même après 100 %.

16) Exemple de drapeau « migratoire » (OBD/index)

yaml flag:
key: "search. use_index_v2"
type: "migration"
description: "Switching reads to index v2"
prerequisites:
- key: "search. index_v2_built"
must_be: "on"
rules:
- when: { tenant_id: ["brand_eu"], user_pct: 5 } then: "on"
- when: { tenant_id: ["brand_eu"], user_pct: 25 } then: "on"
safeguards:
auto_rollback_on:
search_p95_ms: ">180"
error_rate: ">1%"
ttl: "2026-02-01"

Conclusion

Feature Flags n'est pas seulement « on/off », mais une discipline de gestion des risques de changement. Les types clairs de drapeaux, le ciblage déterministe, les mises en place progressives avec les guardrails, l'auto-atof, l'audit et le plan de suppression rendent les sorties prévisibles et les incidents brèves et contrôlables. Incorporez les drapeaux dans l'architecture en tant que première classe de citoyens - et vous serez en mesure de fournir de la valeur plus souvent, plus sûr et plus significatif.