Aller au contenu

Créez votre premier flag

Dans les prochaines minutes, vous allez créer un compte FortressFlag, basculer un vrai flag et voir le changement atterrir dans la même réponse d’API que vos apps liront. Aucun SDK à installer pour l’instant — juste un terminal à la fin.

Rendez-vous sur la page d’inscription du tableau de bord et créez votre organisation. Vous choisissez un nom, définissez votre e-mail et votre mot de passe, et acceptez les accords de service — une seule case à cocher, qui couvre l’ensemble des documents liés juste à côté.

C’est tout le formulaire. Votre essai démarre immédiatement, inclut 1 000 appareils actifs mensuels et n’expire jamais avec le temps — évaluez à votre rythme.

Vous arrivez connecté en tant qu’Owner de l’organisation, et il y a déjà quelque chose à regarder : un projet Example avec deux environnements — dev et production — et trois flags booléens dans des états crédibles :

  • new-checkout — désactivé partout, en attente de son déploiement
  • dark-mode — activé dans dev, désactivé dans production
  • beta-banner — activé dans les deux

C’est votre bac à sable. Tout ce que vous faites dans le reste de cette page se passe dans l’environnement dev, où vous pouvez tout changer librement.

Ouvrez le projet Example, trouvez new-checkout et activez-le dans dev. C’est un vrai changement : il est en ligne pour chaque appareil qui lit cet environnement, il figure dans votre journal d’audit, et vous le verrez depuis l’API dans un instant.

(Essayez la même chose dans production et vous remarquerez que le tableau de bord le traite différemment — les environnements de classe production ont un style plus voyant et des règles plus strictes. Ce sont les rôles et la sécurité à l’œuvre.)

Pour lire les flags comme le fait une app, il vous faut une clé client. Dans le projet Example, ouvrez Clés SDK et créez-en une pour l’environnement dev.

La clé complète — elle commence par ffc_dev_ — est affichée une seule fois, maintenant. Copiez-la. Après cet écran, la liste n’en montre que de quoi l’identifier. (Perdue ? Créez-en une autre et révoquez la première — les clés ne coûtent rien, et la révocation est instantanée.)

Demandez à l’API client les flags de cet appareil — la même requête que fait chaque SDK. Mettez la clé que vous venez de copier dans une variable, puis :

Terminal window
export FF_SDK_KEY="(la clé ffc_dev_ que vous venez de créer)"
curl -s "https://edge.fortressflag.com/v1/client/flags?environment=dev" \
-H "Authorization: Bearer $FF_SDK_KEY" \
-H "X-FF-Device: dev_8KqW3nR2vT7yLp0aZxQmBg" \
| jq -r .payload | tr '_-' '/+' | base64 -d | jq

(La réponse enveloppe ses données dans un payload encodé — les trois derniers étages du pipe le déballent. L’en-tête X-FF-Device porte une identité d’appareil ; les SDK créent la leur, et pour une expérience en terminal n’importe quelle valeur bien formée convient.)

Vous recevez exactement ce que reçoit un appareil dans dev :

{
"v": 1,
"tenant": "…l’identifiant de votre organisation…",
"environment": "dev",
"device": "dev_8KqW3nR2vT7yLp0aZxQmBg",
"issuedAt": "2026-08-23T15:00:00Z",
"expiresAt": "2026-08-23T15:30:00Z",
"flags": {
"new-checkout": true,
"dark-mode": true,
"beta-banner": true
}
}

Voilà new-checkout: true — votre bascule, servie. Désactivez-le à nouveau dans le tableau de bord, relancez le curl, et regardez-le suivre. C’est tout — vous avez fait votre premier changement de flag et vous l’avez lu depuis le plan de données.