Arbitrages et erreurs à éviter
Les flags ont un coût : infrastructure, logique conditionnelle, tests des deux chemins, surveillance, coordination et nettoyage. Les conserver indéfiniment crée du code mort et une dette de configuration. Un mauvais défaut ou une règle modifiée par erreur peut ressusciter l’ancien comportement. Il faut donc réserver les flags aux changements dont le risque ou la valeur d’un déploiement progressif justifie ce coût, documenter leur propriétaire et prévoir leur retrait.
Le principe s’applique aussi aux applications de bureau connectées. Dans un logiciel hors ligne ou un connecteur installé sur site, un fichier de configuration peut jouer un rôle semblable, mais le fournisseur perd la capacité de modifier instantanément la valeur. Les flags peuvent alors être encore plus utiles parce que le client contrôle lui-même le moment où il installe une nouvelle version.