Feature flag

Un feature flag (ou feature toggle, drapeau de fonctionnalité) est une condition dans le code dont la valeur provient de la configuration au moment de l’exécution : si le flag est activé pour cet utilisateur ou cet environnement, on prend le nouveau chemin, sinon l’ancien. Il sépare le déploiement du code de la mise à disposition d’une fonctionnalité. Le code peut rester en production désactivé, puis être activé pour les utilisateurs internes, puis pour 10 % des clients, puis pour tout le monde, et être désactivé à nouveau en quelques secondes si quelque chose tourne mal.

Exemple

if (flags.isEnabled('new-checkout', { userId: user.id })) {
  return renderNewCheckout(cart);
}
return renderLegacyCheckout(cart);

Le service de flags (un produit commercial, une solution open source ou une table dans votre propre base de données) décide de la valeur pour chaque utilisateur, souvent par pourcentage ou selon un attribut.

Ce que cela implique pour les tests

Chaque flag double le nombre de chemins possibles dans cette portion de code. Un testeur doit savoir :

• Quels états de flags partent ensemble en production. Testez la combinaison qui sera réellement active en production, pas seulement « tout activé ».
• Les deux côtés de chaque flag actif. L’ancien chemin reste du code de production tant que le flag n’est pas supprimé : les suites de régression doivent donc le couvrir.
• La bascule elle-même. Activer ou désactiver le flag en cours de session ne doit ni corrompre les données ni bloquer un utilisateur au milieu d’un parcours.
• Le contrôle dans les tests. Les tests automatisés doivent fixer explicitement la valeur des flags, par exemple via une API réservée aux tests, un cookie ou une surcharge de configuration, plutôt que dépendre de l’état actuel de l’environnement partagé. Sinon, quelqu’un qui bascule un flag casse des exécutions de tests sans rapport, ce qui ressemble exactement à de l’instabilité (flakiness).

test('new checkout shows delivery slots', async ({ page, context }) => {
  await context.addCookies([
    { name: 'ff_new-checkout', value: 'on', url: 'https://staging.example.com' },
  ]);
  await page.goto('https://staging.example.com/checkout');
  await expect(page.getByRole('heading', { name: 'Choose a delivery slot' })).toBeVisible();
});

Le nom du cookie n’est ici qu’une illustration ; utilisez le mécanisme de surcharge fourni par votre système de flags.

Erreurs courantes

Les flags jamais supprimés représentent le principal coût à long terme : branches mortes, combinaisons que plus personne ne comprend, et anciens chemins qui se dégradent en silence. Traitez chaque flag de release comme temporaire, avec un responsable et une date de suppression, et supprimez la branche abandonnée et ses tests une fois le déploiement terminé.