📖 Manuel

Système de Feature Flags

Workflow

1. Comprendre le besoin : identifier le type de flag nécessaire (rollout, A/B, kill switch, beta).
2. Concevoir la configuration :
• Définir les règles de ciblage (utilisateur, pourcentage, attribut, date)
• Définir les variantes si nécessaire (A/B testing)
3. Implémenter : proposer le code adapté au framework utilisé.
4. Vérifier : s'assurer que les deux chemins (activé/désactivé) sont testés.

Types de feature flags

Structure de base

interface FlagConfig {
  key: string;
  enabled: boolean;
  description: string;
  rules?: FlagRule[];
  variants?: FlagVariant[];
}

interface FlagRule {
  type: "user" | "percentage" | "attribute" | "datetime";
  operator: "in" | "equals" | "contains" | "gt" | "lt" | "between";
  attribute?: string;
  values: any[];
}

interface FlagVariant {
  key: string;
  weight: number;  // Pourcentage de trafic
  value: any;
}

Stratégies de rollout

Déploiement progressif

1. 1% — Équipe interne uniquement
2. 5% — Beta testeurs
3. 25% — Premier quart d'utilisateurs
4. 50% → 100% — Montée progressive avec monitoring

A/B Testing

• Utiliser un hash stable (userId + flagKey) pour des résultats cohérents
• Toujours tracker les évaluations pour l'analyse
• Définir les métriques de succès avant le lancement

Bonnes pratiques

À faire

• Nommer les flags de manière descriptive
• Documenter le but et le cycle de vie de chaque flag
• Tracker les évaluations pour l'analytique
• Nettoyer régulièrement les anciens flags
• Tester les deux états (activé/désactivé)
• Utiliser un hashing cohérent pour la stabilité

À éviter

• Utiliser des flags pour de la configuration permanente
• Accumuler de la dette technique avec des flags obsolètes
• Rendre les flags trop granulaires
• Hard-coder les vérifications de flags partout
• Ignorer le monitoring

Règles

• Toujours proposer une stratégie de nettoyage des flags.
• Chaque flag doit avoir une date d'expiration prévue (sauf ops flags).
• Ne jamais déployer un flag sans monitoring associé.