La règle de ciblage est un prédicat
Une règle de ciblage est un prédicat booléen évalué contre un contexte utilisateur au moment de l'évaluation du flag. Le contexte utilisateur est une map d'attributs que votre application fournit à runtime :
const context = {
userId: 'usr_8f3k2',
email: 'ada@example.com',
plan: 'pro',
country: 'FR',
accountAgeDays: 142,
betaOptIn: true,
};
const enabled = await signal.isEnabled('new-dashboard', context);Signal évalue les règles que vous avez définies dans le dashboard contre ce contexte. Si les règles correspondent, le flag résout à son état activé. Sinon, il revient à la valeur par défaut.
Les opérateurs de règles
Signal supporte huit opérateurs de règles :
| Opérateur | Exemple |
|---|---|
equals |
plan == "enterprise" |
not_equals |
plan != "free" |
contains |
email contains "@corp.example.com" |
starts_with |
userId starts_with "internal_" |
in |
country in ["FR", "DE", "ES"] |
greater_than |
accountAgeDays > 90 |
less_than |
accountAgeDays < 7 |
exists |
betaOptIn exists |
Les règles se combinent avec AND au sein d'un groupe de conditions, et OR entre les groupes. Cela se traduit par : tout utilisateur qui correspond à au moins un groupe, où chaque groupe exige que toutes ses conditions soient vraies.
Les segments réutilisables
Les règles de ciblage utilisées sur plusieurs flags doivent être extraites en segments. Un segment est un prédicat nommé et réutilisable :
Segment : "Comptes enterprise"
Règles : plan == "enterprise" AND accountAgeDays > 90
Attachez ce segment à n'importe quel flag. Quand votre définition enterprise change — par exemple, vous ajoutez un nouveau tier — mettez à jour le segment une fois. Chaque flag qui le référence récupère le changement immédiatement.
Sans segments, mettre à jour la définition enterprise signifie traquer chaque flag qui code en dur plan == "enterprise" et les mettre à jour un par un. Un flag manqué entraîne un comportement incohérent.
L'ordre des règles compte
Quand un flag a plusieurs règles de ciblage, Signal les évalue dans l'ordre et retourne la première correspondance. Cela a des implications pratiques sur la façon dont vous structurez vos règles.
Un pattern courant : la règle la plus restrictive en premier.
Règle 1 : userId in ["internal_001", "internal_002"] → enabled: true (équipe interne)
Règle 2 : plan == "enterprise" → enabled: true (utilisateurs enterprise)
Règle 3 : betaOptIn == true AND plan != "free" → rollout: 10% (utilisateurs payants opt-in)
Défaut : enabled: false
Si vous mettez la règle de déploiement avant les règles d'activation explicites, les membres de votre équipe interne qui sont aussi des utilisateurs payants pourraient être capturés dans le déploiement à 10% plutôt que d'avoir un accès garanti.
Tester votre contexte
Le bug de ciblage le plus courant est une inadéquation entre les attributs que vous passez au moment de l'évaluation et les attributs que vous avez utilisés pour écrire les règles.
Si votre règle dit plan == "enterprise" mais que votre application passe plan: "Enterprise" (E majuscule), la règle ne correspondra pas. Signal est sensible à la casse.
Pour déboguer, loguez le contexte d'évaluation complet en développement :
const signal = getServerInstance();
const result = await signal.evaluate('new-dashboard', context);
console.log(result.context, result.matched_rule, result.value);Une stratégie de ciblage en couches
Pour la plupart des équipes, une stratégie en couches fonctionne bien :
Couche 1 — Équipe interne. Activez pour votre équipe ingénierie et produit par domaine email ou une liste hardcodée d'IDs utilisateur. C'est votre canary pour chaque flag.
Couche 2 — Utilisateurs bêta. Un attribut d'opt-in explicite (betaOptIn: true) permet aux utilisateurs de se sélectionner eux-mêmes. Cela vous donne une cohorte stable d'utilisateurs qui s'attendent à des imperfections et donnent de bons retours.
Couche 3 — Déploiement basé sur segment. Ciblez un tier spécifique, une région ou une cohorte avec une exposition à 100% avant tout déploiement plus large.
Couche 4 — Déploiement par pourcentage. Une fois que vous avez des signaux des couches ci-dessus, ouvrez le déploiement à un pourcentage de l'audience restante.
Défaut — Désactivé. L'état par défaut doit toujours être le comportement sûr et existant. Ne jamais faire du nouveau code non testé le chemin par défaut.
Cette approche en couches vous donne plusieurs points d'observation avant une exposition large, et un chemin d'escalade clair quand quelque chose se passe mal.