Guide de démarrage web

En quelques minutes, votre site web lira un vrai feature flag — avec un cache durable, une réponse fail-safe pour chaque situation, et rien à gérer pour vous dans le navigateur.

Zéro dépendance à l’exécution ; tout le SDK tient sous un plafond de 10 kB gzip.

1. Installez

Le SDK vit dans un dépôt public sur GitHub — installez-le directement depuis là, épinglé sur la version publiée :

npm install github:FortressFlag/FortressFlag_SDK_web#v1.0.0

Le package se compile tout seul à l’installation, et l’import ci-dessous est son point d’entrée.

2. Démarrez le SDK

Une fois, tôt dans l’amorçage de votre page ou de votre app :

import { Environment, FortressFlag } from "@fortressflag/sdk-web";

FortressFlag.start({
  sdkKey: "ffc_prod_…", // depuis l’écran Clés SDK de votre projet
  environment: Environment.PRODUCTION,
});

start rend la main immédiatement ; les valeurs en cache des visites précédentes sont disponibles tout de suite, et les valeurs fraîches arrivent en arrière-plan. La clé est une clé client — elle est visible dans le code source de votre page par conception.

3. Lisez un flag

if (FortressFlag.isEnabled("new-checkout", false)) {
  // afficher le nouveau tunnel de paiement
}

stringValue et numberValue lisent les flags multivariés de la même façon, et FortressFlag.onChange vous prévient quand les valeurs bougent pour que vous puissiez réafficher.

C’est tout — votre flag est en ligne. Basculez-le dans le tableau de bord et rouvrez la page (ou attendez un polling) pour le voir suivre.

Rien ici ne lève jamais d’exception

Aucun appel de cette API ne lève d’exception, et aucune promesse qui en vient n’est rejetée. Chaque lecture se résout par la cascade : la valeur récupérée la plus fraîche, puis la dernière valeur que ce navigateur a enregistrée, puis votre valeur par défaut, puis false. Une panne de FortressFlag, un réseau mort, un bloqueur de publicités, une clé révoquée — tous se résolvent en une valeur de flag, aucun n’atteint votre code comme une erreur.

(Le cas du bloqueur de publicités est réel : certaines extensions de confidentialité bloquent les requêtes de flags. Les valeurs en cache continuent d’être servies, et un navigateur qui n’a jamais rien récupéré sert vos valeurs par défaut — « les flags ne se mettent pas à jour avec uBlock activé », c’est la cascade qui fonctionne, pas un bug.)

Ce qui vit dans le navigateur, honnêtement

• L’identité d’appareil vit dans localStorage, limitée à votre origine. Elle est créée aléatoirement et pseudonyme — et lisible par le JavaScript de votre propre page, la même classe de valeur que la clé SDK à côté d’elle.
• Les fenêtres privées créent des identités jetables. Chaque session privée compte comme un appareil tant qu’elle dure ; un utilisateur qui efface les données du site est aussi un nouvel appareil. Et une même personne sur votre site web, votre app iOS et votre app Android représente jusqu’à trois appareils — il n’y a aucun lien entre plateformes, par conception.
• Vos suites de tests sont gratuites. Les navigateurs pilotés par Playwright, Selenium, Puppeteer ou Cypress se déclarent comme tels, et le SDK y crée une identité sim_ : flags servis, jamais facturés.
• Les tags de version n’existent pas sur le web. Le SDK envoie platform et sdkVersion automatiquement, mais il n’y a pas d’appVersion ni d’osVersion fiables pour une page — une règle de ciblage sur ceux-ci ne correspond simplement jamais à un navigateur.

Où aller ensuite

• Comment les flags arrivent à votre app — le polling et le cache
• Identité d’appareil et facturation — l’identité dans cette clé de stockage
• Ciblage — règles, segments et déploiements progressifs