Forcer une variante de test A/B ou de feature flag pour la QA

16 mai 2026 · par JustZix Team

Les tests A/B et les feature flags sont parfaits pour les équipes produit et pénibles pour la QA. Vous êtes assigné une fois, au hasard, et vous ne reverrez plus jamais l'autre variante. Cet article montre comment prendre le contrôle : trouver la valeur que le site utilise pour vous assigner, l'écraser avant que la page la lise, et bloquer une variante par motif d'URL avec une règle JustZix.

Comment les sites vous assignent

Presque tous les outils d'expérimentation côté client — Optimizely, GrowthBook, LaunchDarkly, Statsig, Split, les solutions maison — fonctionnent de la même façon. À votre première visite, ils tirent au sort, écrivent le résultat dans un endroit persistant, et lisent ce même endroit à chaque visite ultérieure pour que votre expérience reste stable. Cet « endroit persistant » est presque toujours l'une de ces trois choses :

Un cookie (p. ex. ab_variant=B ou un identifiant utilisateur anonyme dont le hash détermine un groupe).
Une clé localStorage (courant avec les SDK GrowthBook et Statsig).
Une décision côté serveur intégrée dans le HTML ou renvoyée par un appel d'API.

Les deux premières, vous pouvez les écraser directement. La troisième est plus difficile — voir plus bas.

Trouver la clé d'assignation

Ouvrez les DevTools et allez dans l'onglet Application. Sous Storage, vous avez Cookies et Local Storage côte à côte. Rechargez la page et cherchez tout ce qui ressemble à une expérience : des clés contenant ab, exp, variant, flag, bucket, test, feature, ou un nom de fournisseur comme optimizely ou growthbook.

Si rien d'évident n'apparaît, la décision arrive par le réseau. Ouvrez l'onglet Network, filtrez sur Fetch/XHR, rechargez, et cherchez une requête vers quelque chose comme /api/flags, /decide, ou config.json. Le JSON de la réponse vous donne les noms des variantes et — surtout — sous quelle clé le SDK les stocke.

Écraser le localStorage avant que les scripts le lisent

Le timing fait tout. Le SDK d'expérimentation lit sa clé tôt, souvent avant DOMContentLoaded. Votre règle JS JustZix doit s'exécuter avant cette lecture. Réglez la règle pour qu'elle s'exécute au moment document_start et écrivez la valeur immédiatement :

// Bloque la variante de type GrowthBook avant l'initialisation du SDK
const KEY = 'gb_anonymous_id';      // la clé d'assignation que vous avez trouvee
const FORCED = 'qa-pinned-variant-b';

// Ecrase la valeur que le SDK aurait tiree au sort
localStorage.setItem(KEY, FORCED);

// Certains SDK mettent en cache tout un objet de decision - bloquez-le aussi
localStorage.setItem('growthbook_features', JSON.stringify({
  'new-checkout': { defaultValue: true },
  'pricing-table-v2': { defaultValue: 'variant-b' }
}));

Choisissez un identifiant stable et non aléatoire pour l'approche par identifiant anonyme : la plupart des SDK hachent cet identifiant en un groupe, donc la même chaîne tombe toujours dans la même variante. Essayez quelques identifiants une fois, notez celui qui donne la variante B, et réutilisez-le pour toujours.

Écraser un cookie

Les cookies sont plus simples — pas de SDK qui s'interpose, juste une chaîne. Écrivez-la au moment document_start pour que les propres scripts de la page voient votre valeur :

// Force le cookie d'experience pour ce domaine
function setCookie(name, value) {
  document.cookie =
    name + '=' + value + '; path=/; max-age=31536000; SameSite=Lax';
}

setCookie('ab_variant', 'B');
setCookie('feature_new_nav', 'on');

Si le cookie est HttpOnly, vous ne pouvez pas y toucher du tout depuis JavaScript — c'est un flag côté serveur, traité juste après. Vous pouvez le confirmer dans l'onglet Application : les cookies HttpOnly affichent une coche dans cette colonne.

Gérer les flags côté serveur

Quand la variante est décidée sur le serveur, le HTML que vous recevez est déjà la variante. Il n'y a aucune valeur côté client à basculer. Vous avez deux options honnêtes :

Envoyez un indice que le serveur respecte. Beaucoup de configurations lisent un cookie d'override non-HttpOnly comme x-force-variant ou un paramètre de requête ?ab_force=B spécifiquement pour que la QA puisse tester les branches. Demandez à votre équipe — ces overrides existent généralement, ils sont juste non documentés.
Re-habillez la variante que vous avez. Si vous ne pouvez pas obtenir le vrai balisage de la variante B, vous pouvez parfois approximer la différence visible avec une règle CSS pour des captures d'écran — mais c'est une maquette, pas un vrai test. Utilisez-la uniquement pour la revue de design, jamais pour la QA fonctionnelle.

Un override par paramètre de requête est la voie la plus propre. Si votre site supporte ?ff_override=new-checkout:true, vous n'avez même pas besoin de JavaScript — il suffit de mettre l'URL en favori.

Bloquer une variante par motif d'URL

Le vrai atout de JustZix, c'est le ciblage. Vous ne voulez pas que tous les sites soient assignés de la même manière — vous voulez que cet environnement de staging soit bloqué sur la variante B et que celui-là reste tranquille. Créez une règle avec un motif d'URL serré :

Motif d'URL :  https://staging.example.com/*
JS (document_start) :
  localStorage.setItem('exp_checkout', 'variant-b');
  document.cookie = 'ab_force=B; path=/';

Faites une règle par variante — « Bloquer paiement A », « Bloquer paiement B », « Bloquer le contrôle » — et activez-les depuis la barre d'actions. Une passe de QA à travers les trois branches devient trois clics au lieu de trois fenêtres de navigation privée et beaucoup de chance.

Vérifier que la variante a vraiment pris

Ne faites pas confiance au fait que l'override a marché juste parce que la page a l'air différente. Confirmez-le. La plupart des SDK exposent l'assignation active quelque part — affichez-la depuis la console de sortie :

// Relit ce que le SDK a decide, apres son initialisation
window.addEventListener('load', () => {
  // Exemple GrowthBook
  if (window.growthbook) {
    console.log('Active features:', window.growthbook.getFeatures());
  }
  // Generique : affiche chaque cle de storage pour la trace d'audit
  console.log('Forced storage:', { ...localStorage });
});

Associez ceci à la fenêtre Console de sortie pour que l'assignation soit visible dans l'onglet pendant que vous parcourez le flux. Si le SDK rapporte la variante que vous avez forcée, votre test est réel. S'il rapporte autre chose, votre règle s'est exécutée trop tard — passez-la à document_start.

Pièges courants

S'exécuter trop tard. Une règle à document_idle perd la course. Le SDK a déjà lu sa clé. Utilisez toujours document_start pour les overrides d'assignation.
Oublier la moitié serveur. Vous avez bloqué la variante client mais le serveur rend toujours le contrôle. Cherchez un cookie ou un paramètre d'override.
Polluer l'analytics. Les sessions forcées faussent les résultats des expériences. Utilisez un environnement de staging, ou demandez à votre équipe data d'exclure le trafic QA.
Caches périmés. Certains SDK mettent en cache la décision pendant des heures. Effacez d'abord la clé de storage concernée, puis posez votre valeur forcée.

À voir aussi

Simuler les réponses d'API en interceptant fetch — falsifiez l'endpoint des flags plutôt que la clé de storage.
Règles basées sur le temps — planifiez quelle variante est bloquée selon le jour ou l'heure.
Cas d'usage de JustZix — d'autres workflows de QA et de débogage.

Cessez de compter sur les fenêtres de navigation privée et les tirages au sort chanceux. Installez JustZix, construisez une règle par variante, et exercez chaque branche de chaque expérience à la demande.

debugging qa javascript feature-flags

Notez cet article

Aucune note — soyez le premier.