Feature flags

Les feature flags de Kilden sont booléens ou multivariés, ciblés par propriétés de personne et cohortes, déployés par pourcentage, et évalués par un service dédié à faible latence (/decide). Ce guide couvre la mécanique ; les méthodes du SDK sont dans la référence du SDK.

Créer un flag

Dans le panel, sous Feature flags de votre projet, créez un flag avec une clé (ce que vous vérifierez dans le code), un ciblage optionnel et un pourcentage de déploiement. Voir les flags demande d’être membre du projet ; les créer ou les modifier demande un rôle admin — les flags changent le comportement du produit, ils sont donc au rang des réglages.

Ciblage

Le ciblage est une liste de groupes de conditions. Les groupes se combinent en OR ; les conditions à l’intérieur d’un groupe en AND. Aucun groupe signifie “tout le monde”.

Les conditions peuvent porter sur :

Les propriétés de personne : plan exact "pro", company icontains "acme". Les opérateurs sont exact et icontains (contient, insensible à la casse) ; les valeurs non textuelles sont comparées sous leur forme texte.
L’appartenance à une cohorte : la personne est dans une cohorte. L’appartenance est précalculée et rafraîchie environ toutes les 10 minutes — les flags n’évaluent pas les définitions de cohortes en direct.

Le pourcentage de déploiement s’applique après que le ciblage a correspondu : “50 % des utilisateurs du plan pro” signifie la moitié des utilisateurs qui remplissent les conditions.

Pour les flags multivariés, définissez des variantes avec des poids dont la somme fait 100 (control: 50, test: 50) ; la valeur évaluée est la clé de la variante, sous forme de chaîne.

Bucketing déterministe

Qu’un utilisateur donné tombe dans un déploiement est une fonction pure de la clé du flag et de son distinct id — un hash projeté sur [0, 100). Pas d’état, pas de coordination, pas de stockage :

Le même utilisateur obtient la même valeur à chaque requête, sur chaque SDK, à chaque déploiement.
Monter un déploiement de 30 % à 50 % ne fait qu’ajouter des utilisateurs ; personne qui avait le flag ne le perd.
L’assignation de variante utilise un hash indépendant, donc les variantes ne sont pas corrélées à la coupe du déploiement.

Un compromis assumé : le bucket dépend du distinct id, donc quand identify() fait passer un utilisateur de son id anonyme à son id utilisateur, quelqu’un proche de la frontière du déploiement peut changer de côté. C’est le coût documenté de l’évaluation sans état (persister les assignations impliquerait des écritures dans le chemin chaud et une dérive par rapport à la config). Le SDK recharge les flags immédiatement après identify() et reset(), donc la valeur converge tout de suite.

Lire les flags dans votre application

kilden.onFeatureFlags((flags) => {
  render(flags['new-checkout'] === true);
});

// ou des vérifications ponctuelles :
kilden.isFeatureEnabled('new-checkout');   // false tant que non chargé
kilden.getFeatureFlag('pricing-test');     // 'control' | 'test-b' | true | false | undefined

Les flags se chargent de façon asynchrone via POST {apiHost}/decide à l’init — il n’y a pas de bootstrap synchrone, donc conditionnez le rendu dépendant des flags sur onFeatureFlags. Chaque réponse porte tous les flags du projet (les inactifs à false), ce qui permet au SDK de distinguer “désactivé” de “inconnu”.

Vous pouvez aussi appeler /decide directement depuis du code qui n’utilise pas le SDK. L’évaluation n’écrit jamais rien : les person_properties de la requête ne remplacent les traits stockés que pour cette seule évaluation.

Suivi des expositions

La première fois qu’une session lit un flag, le SDK émet $feature_flag_called avec $flag_key et $flag_value. Le panel trace ces expositions par flag (séries quotidiennes par valeur, totaux sur 7 jours avec répartition par variante), pour confirmer qu’un déploiement atteint réellement des utilisateurs avant de s’y fier.

Notes sur la fraîcheur

Les changements de config des flags atteignent /decide en ~10 secondes (il sert depuis une réplique en mémoire de la table des flags).
L’appartenance aux cohortes est matérialisée environ toutes les 10 minutes.
Les changements de propriétés de personne se propagent par le pipeline d’événements, puis un court cache d’évaluation (~30 s). Si vous avez besoin d’un override maintenant, passez person_properties dans la requête /decide.