Feature flag

Feature flag : Interrupteur qui active une fonctionnalité pour tout ou partie des utilisateurs sans nécessiter une nouvelle livraison.

Entrée de la famille « Technique » du glossaire. Elle s’adresse à un porteur de projet qui doit rédiger, comparer ou recetter, pas à un spécialiste du sujet.

Pourquoi Feature flag compte sur un projet mobile

Feature flag se manifeste quand le réseau est mauvais, quand la charge monte ou quand l’application tourne en arrière-plan. Ce sont exactement les moments qu’une recette en salle de réunion ne reproduit pas.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

Ce que ça devient dans un cahier des charges

Un cahier des charges sérieux relie « Feature flag » à un critère de recette : une phrase que l’on peut cocher ou refuser, pas une intention.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les intégrations tierces, nommées, avec leur documentation et leurs limites d’appel.
• La sauvegarde des données : fréquence, durée de rétention, restauration réellement testée.
• La supervision : quelles alertes, vers qui, sous quel délai d’intervention.
• Le sort des données à la fin du contrat, format d’export compris.

Le niveau de détail à viser est celui qui permet à deux prestataires différents de chiffrer la même chose. En dessous, les écarts de prix ne veulent rien dire.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Comment le vérifier à la recette

À la recette, Feature flag se vérifie une fois avant la mise en ligne, puis à chaque version. Ces sujets se dégradent sans prévenir.

• Couper le réseau en pleine utilisation et regarder ce que l’application affiche.
• Tester sur une connexion lente, pas seulement sur le Wi-Fi du bureau.
• Lire les journaux d’erreurs de la première semaine de production.

Un prestataire sérieux propose ces contrôles de lui-même. Quand ce n’est pas le cas, c’est au client de les inscrire au cahier de recette.

Erreurs fréquentes

Les mêmes causes reviennent d’un projet à l’autre, quel que soit le prestataire et quelle que soit la taille du budget.

• Recetter uniquement sur le Wi-Fi du bureau, puis découvrir le comportement réel en mobilité.
• Oublier le mode dégradé : ce que l’application affiche quand le serveur ne répond pas.
• Laisser les intégrations tierces sans limite d’appel ni conduite à tenir en cas de panne du fournisseur.
• Sortir la supervision et les alertes du périmètre pour tenir le budget initial.
• Ne relier le sujet à aucun critère de recette : ce qui ne se vérifie pas ne se livre pas.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• API REST
• Webhook
• Notification push
• Lien profond
• Mode Doze

Questions fréquentes

Qu’est-ce que « Feature flag » ?

Interrupteur qui active une fonctionnalité pour tout ou partie des utilisateurs sans nécessiter une nouvelle livraison. Le mot est employé tel quel par les équipes francophones. C’est celui à utiliser dans les échanges avec une agence, y compris quand la traduction française existe.

Qui vérifie que c’est bien fait ?

Le client, à la recette, avec un critère écrit à l’avance. À défaut, personne : ces sujets ne se voient pas à l’écran, et un utilisateur ne signale que leurs conséquences.

Par où commencer quand le sujet est nouveau ?

Par les parcours et les règles de gestion, pas par les outils. Le guide du cahier des charges donne l’ordre dans lequel poser les questions à une agence.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.