Guide de démarrage Python

En quelques minutes, votre service Python évaluera des feature flags in-process — aucun saut réseau par vérification, aucune latence sur le chemin de vos requêtes, un seul polling servant chaque requête que votre processus traite.

Zéro dépendance : le SDK n’utilise que la bibliothèque standard, sur Python 3.11 et ultérieur. Il fonctionne de la même façon dans une app asyncio — l’évaluation est une simple lecture en mémoire, il n’y a donc rien à attendre avec await.

1. Installez

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

pip install "git+https://github.com/FortressFlag/FortressFlag_SDK_python@v1.0.0"

Sans @v1.0.0, vous suivez la branche development à la place — pratique pour essayer un correctif, pas ce que vous voulez en production.

2. La clé serveur — un vrai secret

Ce SDK utilise une clé serveur (ffs_…), et c’est l’opposé des clés client embarquées par les SDK mobiles et web : elle peut télécharger votre ruleset complet, règles de ciblage incluses. Traitez-la exactement comme un mot de passe de base de données — une variable d’environnement ou un gestionnaire de secrets, jamais du code, jamais un dépôt, jamais un journal. Les deux classes de clés, côte à côte.

3. Démarrez le client

import os

import fortressflag

try:
    client = fortressflag.create(
        fortressflag.Configuration(key=os.environ["FF_SERVER_KEY"])
    )
except fortressflag.MalformedKeyError:
    # Le seul endroit où le SDK lève une exception : une clé malformée, avant que quoi que ce soit ne serve.
    raise SystemExit(1)

client.start(timeout=15.0)  # rend la main au premier ruleset (ou à l’échéance)

# ... votre service tourne ; les vérifications de flags sont désormais des appels de fonction en mémoire.

start ne lève jamais d’exception — si la première récupération ne peut pas aboutir à temps, le client continue d’essayer sur son thread d’arrière-plan et vos appelants reçoivent leurs replis entre-temps. Le poller est un thread démon : il n’empêche jamais votre interpréteur de se terminer.

4. Évaluez un flag

enabled = client.bool_value(
    "new-checkout",
    fortressflag.Context(
        key="user-42",  # votre clé de contexte stable : un id d’utilisateur, un id de session — à vous de choisir
        tags={"cohort": "beta"},
    ),
    False,  # le repli si le flag est inconnu ou si rien n’a jamais été récupéré
)

client.string_value et client.number_value fonctionnent de la même façon. La key du contexte est ce sur quoi les déploiements progressifs répartissent — passez le même identifiant de façon cohérente et chaque utilisateur obtient une cohorte stable. Ce sont vos données : le SDK ne les valide, ne les stocke ni ne les journalise jamais.

C’est tout — votre service évalue les flags localement. Un changement dans le tableau de bord atteint chaque processus en une minute environ.

L’évaluation n’échoue jamais

bool_value, string_value et number_value répondent toujours et ne lèvent jamais d’exception — un problème de flags ne doit jamais faire tomber votre service. Un processus redémarré sert les replis de vos points d’appel jusqu’à ce que sa première récupération aboutisse (ou définissez cache_path dans la configuration pour persister le dernier ruleset dans un fichier de votre choix, et les redémarrages reprennent depuis celui-ci instantanément). Même une clé révoquée ne casse rien : le SDK continue d’évaluer avec le dernier ruleset qu’il a téléchargé jusqu’à ce que vous lui donniez une nouvelle clé.

Où aller ensuite

• Comment les flags arrivent à votre app — le plan serveur, expliqué
• Clés — créez, faites tourner et révoquez les clés ffs_
• Ciblage — les règles que votre service évalue désormais