Flags et types

Un flag est une décision nommée que votre app demande à FortressFlag de prendre : cet appareil doit-il voir le nouveau tunnel de paiement ? Quel libellé va sur le bouton d’achat ? Combien de tentatives avant d’abandonner ? Cette page vous donne le vocabulaire sur lequel le reste de la documentation repose.

Les flags vivent dans un projet, et ont une valeur par environnement

Chaque flag appartient à un projet et est identifié par sa clé — un nom court en minuscules comme new-checkout. La clé est ce que votre code demande, et elle est immuable après la création : vos apps déjà livrées ont la clé intégrée dans leur code, donc la renommer les casserait. Vous pouvez changer le nom d’affichage d’un flag à tout moment ; la clé est définitive.

Un flag n’a pas une valeur — il a une valeur par environnement. new-checkout peut être activé dans dev, en cours de déploiement dans staging et désactivé dans production, tout cela en même temps. Vous basculez et ciblez chaque environnement indépendamment.

Les trois types

Chaque flag a un type, choisi à la création et immuable ensuite :

Type	Valeurs	Idéal pour
Booléen	true / false	Kill switches, feature gates, déploiements progressifs
Chaîne	Variantes textuelles nommées	Tests de libellés, choix d’algorithme, thèmes
Nombre	Variantes numériques nommées	Limites, délais d’attente, seuils

Le type est immuable pour la même raison que la clé : votre code lit le flag par un appel typé (isEnabled, stringValue, numberValue), et un flag qui changerait de type sous une app déjà livrée cesserait d’avoir un sens pour elle.

Les variantes

Les flags chaîne et nombre servent des variantes — des valeurs nommées comme control → "buy-now" et treatment → "start-free". Les noms sont pour vous et votre tableau de bord ; les appareils de vos utilisateurs ne reçoivent jamais que la valeur. Les noms de variantes ne quittent jamais le plan de gestion.

Les valeurs par défaut, et la valeur par défaut derrière la valeur par défaut

Deux choses différentes s’appellent « valeur par défaut », et il vaut la peine de les distinguer :

• La valeur par défaut du flag est ce qu’un environnement sert quand aucune règle de ciblage ne correspond. Pour un flag booléen, c’est son état activé/désactivé ; pour un flag multivarié, c’est la variante que vous choisissez comme valeur par défaut.
• La valeur par défaut de votre code est la valeur que vous passez au point d’appel — isEnabled("new-checkout", default: false). C’est le bas de la chaîne de repli : ce que votre app utilise quand elle n’a jamais atteint FortressFlag, ou quand le flag n’existe pas (ou n’a pas de valeur à servir) dans cet environnement.

Un flag multivarié tout neuf sans variante par défaut choisie ne sert rien — la valeur par défaut de votre code répond jusqu’à ce que vous décidiez. C’est voulu : un flag que vous n’avez pas fini de configurer doit se comporter comme un flag qui n’existe pas.

Le cycle de vie : archiver, restaurer, purger

Supprimer un flag est réversible — jusqu’à un certain point. L’archivage le retire de vos apps : sur chaque appareil en ligne, le flag cesse de se résoudre en une minute environ, et les valeurs par défaut de votre code prennent le relais. Un flag archivé peut être restauré intact pendant la fenêtre de rétention, ou purgé définitivement après. La liste des archives vit dans chaque projet, à côté des flags qu’il contient.

Si un flag est resté intouché pendant 90 jours, le tableau de bord le marque comme inactif — une invitation à l’archiver, jamais un archivage automatique. Les flags que vous avez oubliés sont de la complexité que votre base de code continue de payer.

Où aller ensuite

• Ciblage — règles, segments et déploiements progressifs
• Environnements et projets — là où vivent les flags
• Comment les flags arrivent à votre app — ce qu’un appareil reçoit vraiment