Chaque indicateur de fonctionnalité doit avoir une date de suppression

L'affirmation

Un indicateur de fonctionnalité est un outil de déploiement dont la durée de vie se mesure en semaines. Un indicateur qui survit à son lancement devient une configuration permanente que personne ne comprend, et une base de code portant quarante indicateurs périmés n'est pas une application : c'est deux à la puissance quarante applications possibles, dont vous avez testé exactement une. Le correctif est procédural, pas technique : aucun indicateur n'entre dans le code sans billet de retrait, sans responsable et sans date.

À quoi servent les indicateurs, et pour combien de temps

Trois usages légitimes, avec trois durées de vie honnêtes différentes :

• Les indicateurs de lancement séparent le déploiement du code de son activation. On fusionne de petits incréments derrière l'indicateur, on l'active pour le personnel, puis pour un pourcentage, puis pour tous. Durée : de quelques jours à quelques semaines, suppression après le déploiement complet plus une semaine calme.
• Les interrupteurs d'exploitation permettent de délester ou de couper un sous-système coûteux pendant un incident — désactiver les recommandations, revenir à une page d'accueil statique. Durée : permanente, mais il devrait y en avoir moins de dix, chacun documenté dans la marche à suivre et testé chaque trimestre, car un coupe-circuit non testé échoue précisément au moment où l'on s'en saisit.
• Les indicateurs d'expérimentation soutiennent un test A/B à échéance définie. À la conclusion, la branche perdante est supprimée — pas désactivée, supprimée.

Le mode d'échec consiste à tout traiter comme la deuxième catégorie. Il est toujours plus facile de laisser un indicateur « au cas où », et chaque décision isolée se défend. La somme de ces décisions donne un système où personne ne peut dire avec assurance ce qui tourne réellement en production.

Le coût, rendu concret

Comptez les vôtres tout de suite :

grep -rEo "isEnabled\(['\"][a-z0-9_-]+" app/ | sort -u | wc -l

Répondez ensuite à trois questions pour les cinq plus anciens : qui en est responsable, que se passe-t-il si on le bascule aujourd'hui, et quand le chemin désactivé a-t-il été exécuté pour la dernière fois ? Dans la plupart de nos audits, personne dans l'édifice ne peut répondre à la troisième question pour les indicateurs de plus de six mois. Ce chemin désactivé est du code non testé, atteignable depuis la configuration de production — le même profil de risque qu'un bouton mort câblé à de l'équipement sous tension.

Les indicateurs périmés interagissent aussi. Deux indicateurs produisent quatre états ; un tunnel de paiement à six indicateurs en compte soixante-quatre, et le rapport de bogue qui finira par arriver ne se reproduira que dans un seul.

Le cycle de vie qui l'empêche

1. La création exige trois champs : un responsable, une durée prévue et un billet de retrait lié, créé dans la même demande de fusion que l'indicateur. Le billet est planifié pour le sprint suivant le déploiement complet, pas pour « plus tard ».
2. Le nom porte la date : rel_2026_09_paiement_v2. Un indicateur nommé d'après son mois de création affiche sa propre péremption à chaque revue de code.
3. Le déploiement se termine par une suppression, pas par un réglage. La définition de « terminé » inclut le retrait de l'indicateur et de l'ancienne branche. La fonctionnalité n'est pas finie tant que l'indicateur existe.
4. Un rapport mensuel énumère les indicateurs échus, du plus ancien au plus récent, envoyé au canal d'équipe. La pression sociale fait le reste ; personne ne veut occuper la première ligne trois mois de suite.

Gardez le mécanisme ennuyeux

Pour la plupart des entreprises, un système d'indicateurs devrait être une table et une consultation en cache :

CREATE TABLE feature_flags (
  key         text PRIMARY KEY,
  enabled     boolean NOT NULL DEFAULT false,
  pct_rollout smallint NOT NULL DEFAULT 0 CHECK (pct_rollout BETWEEN 0 AND 100),
  owner       text NOT NULL,
  remove_by   date NOT NULL
);

Le déploiement par pourcentage est un hachage de l'identifiant d'utilisateur comparé à pct_rollout — déterministe, pour qu'une personne ne saute pas d'une variante à l'autre à chaque requête. Mettez la table en cache trente secondes dans le processus, et la vérification ne coûte rien sur le chemin chaud.

Les plateformes hébergées d'indicateurs méritent leurs frais quand il vous faut des pistes de vérification, du ciblage par attribut ou des changements faits sans danger par des non-ingénieurs. Elles ne suppriment pas le problème de discipline ; elles offrent aux indicateurs périmés un plus joli tableau de bord où périmer. Adoptez d'abord le cycle de vie, la plateforme ensuite, s'il y a lieu.

Une règle pour les indicateurs qui gardent l'argent

Tout indicateur touchant la facturation, les prix, les taxes ou l'acheminement des paiements est journalisé à chaque lecture avec sa valeur, et son état est inscrit dans le dossier de commande lui-même. Quand la comptabilité demande en novembre pourquoi une facture de mars a été calculée à l'ancienne, « l'indicateur était probablement fermé » n'est pas une réponse. La commande indiquant pricing_v2: false en est une.

Le test d'un système sain

Demandez combien d'indicateurs existent et chronométrez la réponse. Une équipe à la culture saine répond depuis un tableau de bord en dix secondes, et le nombre est sous quinze. Une équipe qui doit fouiller le code et en trouve soixante a livré de la configuration en guise de décisions — et chacun de ces soixante est une décision qui attend encore d'être prise.