Comment les flags arrivent à votre app

Votre app n’appelle pas FortressFlag chaque fois qu’elle vérifie un flag. Les lectures de flags sont locales — instantanées, sûres hors ligne, sans réseau sur le chemin. Ce qui voyage sur le réseau est un polling périodique, et ce que ce polling récupère dépend du plan sur lequel vous êtes.

Le plan client : vos apps reçoivent des réponses, pas des règles

Les SDK iOS, Android et web utilisent le plan client. L’appareil envoie son identité et ses tags ; FortressFlag évalue vos règles de ciblage côté serveur et renvoie uniquement les valeurs de cet appareil — une petite table comme {"new-checkout": true, "dark-mode": false}.

L’appareil ne reçoit jamais vos règles. C’est voulu, doublement : votre logique de ciblage (« cohorte bêta », « appareils internes ») vous appartient et ne devrait pas être embarquée dans quelque chose que n’importe qui peut extraire d’un binaire d’app — et la charge utile reste minuscule.

Le plan client s’authentifie avec une clé client (ffc_…), qui est embarquée dans votre app et publique par conception — plus de détails dans Clés.

Le plan serveur : votre backend reçoit le ruleset

Le SDK Go utilise le plan serveur. Votre serveur télécharge le ruleset complet pour un projet + un environnement — types, valeurs par défaut, règles, avec les segments déjà aplatis dedans — et évalue les flags dans son propre processus. Une vérification de flag est un appel de fonction sur des données déjà en mémoire : aucun saut réseau par vérification, aucune latence par requête, et un seul polling sert tout votre processus quel que soit le nombre de requêtes qu’il traite.

Parce que le ruleset inclut vos règles de ciblage, ce plan est protégé par une clé serveur (ffs_…) — un vrai secret, manipulé comme un mot de passe de base de données. Et puisque vos règles atteignent chaque serveur qui détient cette clé, le corollaire est à vous d’appliquer : ne mettez pas de secrets ni de données personnelles de vos utilisateurs dans les conditions des règles.

Sur ce plan, il n’y a pas d’identité d’appareil. Votre code passe une clé de contexte par évaluation — un identifiant d’utilisateur, un identifiant de session, ce sur quoi vous répartissez — et l’arithmétique des déploiements progressifs l’utilise exactement comme le plan client utilise l’identifiant d’appareil, de sorte que la même entrée tombe dans la même cohorte quel que soit le plan qui l’évalue.

Le polling, et pourquoi il ne coûte presque rien

Les deux plans interrogent à intervalle régulier, et les deux utilisent des requêtes conditionnelles : chaque réponse porte un validateur (un ETag), et quand rien n’a changé depuis le dernier polling, la réponse est un minuscule « rien n’a changé » — sans corps, sans réévaluation. L’état stable d’un parc qui ne change pas ses flags est un flux de vérifications quasi gratuites.

Quand vous changez vraiment quelque chose — une bascule, une règle, une planification qui se déclenche — le polling suivant le récupère en entier. En pratique, un changement atteint les appareils clients en ligne en une minute environ.

(Une note de facturation : une réponse « rien n’a changé » compte quand même comme une activité pour le nombre d’appareils actifs mensuels — mais rappelez-vous qu’un appareil compte une fois par mois, quelle que soit la fréquence de son polling.)

La promesse de repli

Une panne de FortressFlag ne doit jamais faire tomber votre app. Chaque SDK conserve les dernières valeurs reçues dans un cache local durable et résout les flags par la même cascade :

Les dernières valeurs reçues — même lors d’une exécution précédente. Un appareil hors ligne depuis un mois sert ce qu’il a vu en dernier ; l’obsolescence est préférée aux régressions surprises.
La valeur par défaut de votre code — celle du point d’appel — quand rien n’a jamais été reçu. (Les SDK clients retombent sur false pour les lectures booléennes sans valeur par défaut.)

Deux conséquences à connaître :

Un identifiant révoqué ou défaillant ne casse pas votre app. Le SDK continue de servir son cache et continue d’essayer. Les erreurs n’atteignent jamais vos utilisateurs à travers une lecture de flag.
Une charge utile que le SDK ne peut pas vérifier est traitée comme s’il n’y en avait pas. Chaque réponse est signée, et le SDK vérifie la signature avant que quoi que ce soit ne change — voir Signature des payloads.
Archiver un flag le désactive vraiment. Quand un flag quitte la charge utile, le SDK le retire des valeurs en direct et du cache au même polling — en une minute environ, les appareils en ligne partout résolvent la valeur par défaut de votre code. Le cache ne préserve jamais les flags supprimés — s’il le faisait, archiver ne pourrait pas mettre fin à un déploiement pour de bon.

Où aller ensuite

Clés — ffc_ contre ffs_, et pourquoi l’une est publique et l’autre réveille quelqu’un
Identité d’appareil et facturation — ce qu’est l’identité du plan client
Installez un SDK — choisissez votre plateforme et livrez un flag