Le problème de la merge queue
Les branches de fonctionnalités à longue durée de vie résolvent un problème — isoler le travail en cours — en en créant plusieurs autres.
Plus une branche vit longtemps, plus elle diverge du trunk. Les conflits de merge s'accumulent. Les pipelines CI qui passaient le premier jour échouent au quatorzième parce que d'autres changements ont atterri entre-temps. Le merge lui-même devient un événement de plusieurs heures qui bloque l'équipe.
Dans une équipe de quatre ingénieurs, trois branches à longue durée de vie signifient trois univers parallèles d'état qui doivent finalement être réconciliés. Le coût de réconciliation croît de façon non linéaire avec l'âge des branches et la taille de l'équipe.
Trunk-based development + feature flags
L'alternative est de livrer des fonctionnalités incomplètes en production — désactivées par défaut.
// Le code est livré le jour 1. Le flag est désactivé pour tout le monde.
const { enabled } = useFeatureFlag('new-recommendations');
if (enabled) {
return <NewRecommendations userId={userId} />;
}
return <LegacyRecommendations userId={userId} />;La branche a une courte durée de vie — mergée sur le trunk en un jour ou deux. La CI passe en continu. La fonctionnalité devient une préoccupation runtime, pas une préoccupation de gestion de source.
Ce que ça change
L'intégration est continue. Chaque ingénieur merge sur le trunk quotidiennement. Les conflits sont petits et détectés tôt. Il n'y a pas de "semaine d'intégration" en fin de sprint.
Le déploiement est découplé de la release. Déployer le code et publier la fonctionnalité sont des événements séparés. Vous pouvez déployer le lundi et publier le jeudi, après validation QA en production.
Le rollback est instantané. Si quelque chose casse après activation, vous basculez le flag. Pas de git revert, pas de cherry-pick, pas de redéploiement. Le fix prend effet en moins de 50ms.
Les tests se font en production. Votre environnement de staging n'a pas le trafic, les données ou la charge infra de production. Avec les feature flags, vous testez en production en activant un flag pour les utilisateurs internes seulement avant toute exposition externe.
Le feature flag comme contrat
Un feature flag n'est pas juste un on/off. C'est un contrat entre l'équipe qui livre la fonctionnalité et l'équipe qui gère la release.
Ce contrat définit :
- Qui le flag cible (tous les utilisateurs, des segments spécifiques, un pourcentage de déploiement)
- Quelle est la valeur par défaut (doit toujours être le comportement sûr et existant)
- Quand le flag sera nettoyé (fait partie des critères d'acceptation de la fonctionnalité)
Rendre ce contrat explicite — via une UI de gestion, un audit log, et des états de cycle de vie définis — c'est ce qui différencie une plateforme de feature flags d'un fichier de configuration.
Le coût caché des déploiements sans flags
Les équipes qui n'utilisent pas de feature flags sous-estiment souvent le coût de leur approche actuelle parce qu'il est distribué invisiblement :
- Heures d'ingénierie dépensées sur les conflits de merge
- Incidents causés par des combinaisons non testées de changements en cours
- Cycles de release lents parce que la QA ne peut tester que des fonctionnalités complètes
- Rollbacks qui nécessitent un redéploiement et un pipeline de 10 minutes
Les feature flags n'éliminent pas cette complexité. Ils la déplacent vers une couche où elle peut être contrôlée, observée et actionnée plus rapidement.
Quand ne PAS utiliser un feature flag
Les feature flags ne sont pas gratuits. Chaque flag ajoute une branche à la logique de votre application et un overhead de modèle mental.
Ne pas flaguer :
- Les changements d'infrastructure sans effet visible pour l'utilisateur
- Les correctifs de bugs qui doivent être déployés immédiatement
- La configuration qui appartient aux variables d'environnement
Flaguer :
- Les nouvelles fonctionnalités visibles par l'utilisateur qui nécessitent un déploiement contrôlé
- Les expériences de performance que vous voulez mesurer avec un groupe de contrôle
- Les refactorings à haut risque pour lesquels vous voulez une option de rollback rapide