Aller au contenu principal

Feature flags

Statut

Document de cadrage backend — v1.0 — relu le 2026-05-10.

Vue d'ensemble

Les feature flags permettent d'activer ou désactiver des onglets et fonctionnalités par type d'acteur (kind), sans déploiement.

Deux tables gèrent ce mécanisme :

  • feature_tabs : définition globale d'un onglet (activé, global, listes blanche/noire).
  • feature_tab_overrides : surcharges individuelles par acteur ou contexte.

Modèle FeatureTab

Table : feature_tabs

ColonneTypeRôle
idstring (UUID)Identifiant
slugstringClé lisible
enabledbooleanInterrupteur global
is_globalbooleanActif pour tous les kinds
only_for_kindsarrayListe blanche de kinds
excluded_for_kindsarrayListe noire de kinds

Logique d'activation

La méthode isEnabledFor(string $kind): bool évalue dans l'ordre :

  1. Si enabled = false → désactivé pour tous.
  2. Si is_global = true → actif pour tous les kinds.
  3. Si only_for_kinds non vide et kind absent → désactivé.
  4. Si kind dans excluded_for_kinds → désactivé.
  5. Sinon → actif.

Surcharges

Le modèle FeatureTabOverride permet de surcharger l'état d'un onglet pour un acteur ou un contexte spécifique via une relation overrides() sur FeatureTab.

Kinds d'acteur connus

Les kinds sont des chaînes libres représentant le type d'acteur DMV (exemple : association, commerce, commune, individu). La liste exacte est gérée dans le module Actor.

Utilisation

Les feature flags sont lus par le backend pour :

  • adapter les réponses d'API selon le profil acteur ;
  • conditionner l'affichage de certains onglets ou actions côté frontend ;
  • préparer des contextes différenciés selon le kind.

État actuel vs cible

AspectÉtat actuelCible
StockageTable feature_tabs PostgreSQLIdem
GranularitéPar kind d'acteurPar acteur individuel (overrides)
SynchronisationVia APICache Redis + invalidation
Interface adminNon confirméeBackoffice

Points à clarifier

  • Liste exhaustive des kinds d'acteurs.
  • Processus de création/modification d'un flag en production.
  • Interface backoffice pour gérer les flags sans migration.
  • Propagation des changements aux frontends en temps réel.