Feature flags Node.js : comparatif et coûts réels

Relier la variante à un résultat concret

Pour chaque parcours, enregistrez au minimum :

• un identifiant de requête stable, stocké dans des journaux structurés plutôt que dans des étiquettes de métriques ;
• la variante choisie, par exemple « contrôle » ou « candidate » ;
• la durée totale du parcours et, si besoin, celle de chaque appel au modèle ;
• les jetons consommés et le coût estimé, quand le fournisseur les expose ;
• un résultat métier défini à l'avance : demande résolue, transférée à un humain ou échouée.

Le résultat doit coller à votre produit. Pour un service client, une réponse générée n'est pas toujours une demande « résolue ». Vous pouvez définir la résolution comme une réponse acceptée sans transfert, ou comme l'absence de nouvelle sollicitation dans un délai donné. L'important : garder la même définition entre les variantes.

Avec ça, une métrique peut répondre à une question simple : la variante candidate augmente-t-elle la latence au 95e percentile, le coût moyen par parcours, ou le taux de transfert ? Sans ce lien entre variante et outcome, le flag reste activable techniquement, mais vous ne saurez pas vraiment ce qu'il change.

Garder les métriques à faible cardinalité

N'ajoutez pas le texte brut du client, son adresse e-mail, ou un identifiant unique de conversation dans les étiquettes de métriques. Chaque valeur distincte crée une nouvelle série temporelle. La documentation de Prometheus met justement en garde contre cette cardinalité incontrôlée : ça alourdit le stockage et rend les requêtes pénibles.

Préférez des métriques agrégées par variante, modèle ou résultat, et gardez l'identifiant de requête dans les journaux. Comme ça, vous pouvez passer d'un tableau de bord global à l'examen d'un parcours précis, sans transformer chaque conversation en dimension de métrique. En contexte européen, cette séparation aide aussi à limiter la collecte de données personnelles et à préparer une revue de conformité au RGPD. (Ça ne remplace pas une analyse juridique ni une politique de conservation adaptée.)

Traiter l'absence de coût comme une donnée manquante

Le coût par parcours peut être estimé à partir des métadonnées renvoyées par le fournisseur. Si le nombre de jetons n'est pas disponible, la valeur doit rester « inconnue », pas « 0 ». Sinon, une intégration qui ne transmet plus les compteurs donne l'impression, trompeuse, que certaines variantes sont moins chères.

Enfin, mesurez ce qui influe réellement sur votre décision. Si le coût du modèle est marginal et que la qualité de réponse prime, votre tableau de bord doit refléter cette priorité. La mesure sert à choisir, pas à cocher des cases.

Isoler l'accès au fournisseur

Créez une petite interface adaptée à votre application, par exemple une fonction qui renvoie « contrôle » ou « candidate ». Le reste du code ne doit pas connaître l'URL, le format de réponse ou le SDK du fournisseur. Si vous changez de service, vous remplacez l'adaptateur et vous gardez le même schéma de mesure.

Voici un exemple volontairement réduit. La lecture du flag est fournie par un adaptateur propre au service ; le code du parcours reste indépendant :

type Variante = "controle" | "candidate";
type Resultat = "resolu" | "transfere" | "echec";
type Mesure = {
variante: Variante;
resultat: Resultat;
dureeMs: number;
coutEstimeEur: number | null;
};
interface Flags {
lire(cle: string): Promise<Variante>;
}
export async function executerParcours(
entree: string,
flags: Flags,
agent: (entree: string, variante: Variante) => Promise<{
resultat: Resultat;
coutEstimeEur?: number;
}>,
enregistrer: (evenement: Record<string, unknown>) => void,
): Promise<Mesure> {
const debut = performance.now();
let variante: Variante = "controle";
try {
variante = await flags.lire("agent-support");
const reponse = await agent(entree, variante);
const mesure: Mesure = {
variante,
resultat: reponse.resultat,
dureeMs: Math.round(performance.now() - debut),
coutEstimeEur: reponse.coutEstimeEur ?? null,
};
enregistrer({ evenement: "parcours_support", ...mesure });
return mesure;
} catch (erreur) {
enregistrer({
evenement: "parcours_support",
variante,
resultat: "echec",
dureeMs: Math.round(performance.now() - debut),
typeErreur: erreur instanceof Error ? erreur.name : "inconnu",
});
throw erreur;
}
}

Cet exemple n'est pas un SDK à brancher tel quel. Il sert surtout à matérialiser la frontière : l'instrumentation vient de votre application, pas d'un format imposé par le fournisseur. En production, ajoutez au minimum un identifiant de requête, une politique de journalisation et une stratégie de secours testée.

Décider quoi faire si le service de flags est indisponible

Le comportement par défaut doit être un choix produit. Pour une fonctionnalité expérimentale pas critique, revenir à la variante de contrôle peut être acceptable. Pour un changement lié à une protection ou à une règle métier, ce retour peut être risqué. Définissez explicitement la valeur de secours pour chaque flag, puis testez une panne du fournisseur et un dépassement de délai.

Évitez de réessayer sans limite : une erreur de configuration peut sinon transformer une dégradation temporaire en blocage du parcours. Si vous gérez déjà les erreurs de limitation de débit, respectez l'en-tête de délai de reprise quand il existe, limitez le nombre de tentatives, et évitez de répéter des appels inutiles. Pour des flags consultés très souvent, la mise en cache ou un SDK adapté peut réduire la dépendance à un appel réseau par parcours. Là encore, tout dépend de la fraîcheur attendue et du comportement du fournisseur.

Enfin : ne transmettez pas une clé d'API à une URL fournie dans la réponse du service. Utilisez une configuration maîtrisée par votre déploiement et limitez les droits du secret. Un simple appel REST ne supprime pas les règles habituelles de sécurité des identifiants.