Feature Flags : activer ou désactiver une fonctionnalité sans redéployer en production

Qu'est ce que les features flags ?

Un feature flag est un mécanisme permettant de contrôler l'activation d'une fonctionnalité via une configuration externe, sans modifier ni redéployer le code. Le code de la fonctionnalité est présent en production, mais son exécution est conditionnée par une valeur de configuration. Ce principe introduit une séparation claire entre le déploiement technique et l'exposition fonctionnelle.

Sans mécanisme adapté, activer ou désactiver une feature devient vite contraignant : conditions ajoutées dans le code, correctifs en urgence, nouveaux déploiements pour revenir en arrière… Résultat : une base de code qui s'alourdit, une maintenance plus complexe et des cycles de livraison ralentis. À mesure que les mises en production se multiplient, cette approche montre rapidement ses limites. Les feature flags s'imposent alors comme une réponse pragmatique pour garder le contrôle sur l'activation des fonctionnalités, sans compromettre la stabilité ni la cadence de déploiement.

Pourquoi utiliser les features flags ?

Dans une approche DevOps, l'objectif est simple : réduire le temps entre l'écriture du code et sa mise à disposition en production. Les feature flags s'inscrivent directement dans cette philosophie en permettant de découpler le déploiement du code de l'activation de fonctionnalités. Ils facilitent le déploiement continu, la mise en place de stratégies de release progressives et la gestion rapide des incidents. En cas de problème, un rollback instantané est possible en désactivant simplement le flag.

C'est quoi le Feature Flipping ?

Le feature flipping désigne l'action d'activer ou de désactiver une fonctionnalité via un feature flag, généralement en temps réel et sans redéploiement. C'est un levier opérationnel permettant de modifier le comportement d'une application directement en production. L'activation peut être globale, progressive, ou conditionnelle (par utilisateur, segment, région, plan tarifaire).

Cas d'usage du Feature Flipping

• Progressive rollout : déployer progressivement une fonctionnalité.
• Kill switch : désactiver immédiatement une fonctionnalité critique.
• Beta features : proposer des fonctionnalités expérimentales à un groupe restreint.
• Personnalisation par segment : activer des fonctionnalités selon le pays ou le plan tarifaire.

L'importance du contexte lors de l'évaluation d'un flag

Lorsqu'une application évalue un feature flag, elle doit fournir un contexte (utilisateur, organisation, région, etc.). Ce contexte permet d'appliquer des règles avancées et un ciblage fin.

Feature flipping : les bonnes pratiques

Quelques points importants à garder en tête :

• Un feature flag a un cycle de vie court : il doit être supprimé une fois stabilisé.

• Le nommage est critique et doit décrire clairement l'intention.

• La gouvernance¹ est essentielle pour éviter la dette technique.

  \ ¹ Gouvernance :

  • Qui crée un flag ?
  • Pourquoi il existe ?
  • Combien de temps il doit rester actif ?
  • Qui décide de l'activer ou de le supprimer ?
  • Comment il est documenté et suivi ?

Risques et limites des features flags

Les feature flags augmentent la complexité du code et peuvent compliquer le testing.

Ils peuvent générer un surcoût opérationnel et de la latence si mal optimisés.

Le débogage devient plus complexe sans traçabilité adaptée.

OpenFeature comme couche d'abstraction

OpenFeature agit comme une couche d'abstraction entre l'application et les systèmes de gestion de feature flags. L'application consomme une API standardisée, tandis qu'un provider se charge de communiquer avec le système de flags sous-jacent.

Cette approche permet d'uniformiser le feature flipping et d'éviter le verrouillage fournisseur (ex: AWS, Azure, On-premise…). Le code applicatif reste identique, quel que soit l'outil de gestion des flags utilisé, seule la partie provider sera modifiée. 

OpenFeature intégré avec un système hypothétique de gestion de flags « Flags-R-us ».

Implémentation technique

Une implémentation simple repose sur des fichiers de configuration ou des variables d'environnement. Cette approche est rapide à mettre en place mais reste limitée : elle ne permet pas de ciblage utilisateur ni de modification dynamique sans redémarrage.

Des solutions dédiées permettent de gérer les flags de manière centralisée, avec des règles conditionnelles, une propagation dynamique et des SDK côté application. Ces outils facilitent la gouvernance, le ciblage et l'observabilité.

Exemple avec OpenFeature en Angular

Dans une application Angular, OpenFeature peut être utilisé pour activer ou désactiver une fonctionnalité directement dans le code frontend.

// openfeature.service.ts
import { Injectable } from '@angular/core';
import { OpenFeature } from '@openfeature/web-sdk';

@Injectable({ providedIn: 'root' })
export class FeatureFlagService {
  async init() {
    // Initialisation du provider d'un fournisseur de feature-flags
    OpenFeature.setProvider(new MyFlagProvider());
  }

  async isNewCheckoutEnabled(userId: string): Promise<boolean> {
    const client = OpenFeature.getClient();
    return client.getBooleanValue(
      'new_checkout_flow_enabled',    // Nom du flag
      false,                          // Valeur par défaut
      { targetingKey: userId }        // Contexte
    );
  }
}

// checkout.component.ts
if (await this.featureFlagService.isNewCheckoutEnabled(this.user.id)) {
  this.useNewCheckout();
} else {
  this.useLegacyCheckout();
}

Ce pattern permet d'activer un nouveau parcours utilisateur uniquement pour certains utilisateurs ou un pourcentage de trafic.

Exemple avec OpenFeature en Java (Spring Boot)

Côté backend JavaLangage de développement très populaire !, OpenFeature s'intègre souvent via Spring Boot pour contrôler des comportements serveur.

// Configuration OpenFeature
import dev.openfeature.sdk.OpenFeatureAPI;
import dev.openfeature.sdk.Client;

@Bean
public Client openFeatureClient() {
    OpenFeatureAPI api = OpenFeatureAPI.getInstance();
    api.setProvider(new MyFlagProvider());
    return api.getClient();
}

// Utilisation dans un service
public boolean isNewPricingEnabled(String userId) {
    EvaluationContext context = new EvaluationContext(userId);
    return client.getBooleanValue(
        "new_pricing_enabled",    // Nom du flag
        false,                    // Valeur par défaut
        context                   // Contexte
    );
}

// Dans un contrôleur
if (featureService.isNewPricingEnabled(user.getId())) {
    return pricingService.newPricing();
} else {
    return pricingService.legacyPricing();
}

Ces exemples illustrent le découplage complet entre le code et la configuration d'activation, avec un ciblage basé sur le contexte utilisateur.

Les feature flags : notre avis !

Les feature flags et le feature flipping offrent un levier puissant pour concilier vitesse de livraison et maîtrise de la disponibilité des fonctionnalités. Ils permettent de mettre en place des stratégies de release progressives, des rollbacks instantanés et des expérimentations produit contrôlées, sans ralentir les équipes de développement.

Cependant, les feature flags ne sont pas une solution universelle. Leur adoption suppose un mode de fonctionnement spécifique : une culture DevOpsEnsemble de techniques permettant l'intégration, les tests et le déploiement d'une application. mature, une gouvernance claire des flags, une observabilité fine et une discipline technique pour éviter l'accumulation de dette. Sans ces pratiques, ils peuvent rapidement devenir une source de complexité et de confusion.

Avec la standardisation des pratiques et la montée en puissance des outils open-source comme OpenFeature, la gouvernance des feature flags devient un enjeu structurant pour les équipes techniques. Bien utilisés, ils constituent un accélérateur d'innovation. Mal maîtrisés, ils peuvent freiner la lisibilité du code. Comme souvent en développement, la valeur vient moins de l'outil que de la manière dont il est intégré dans les processus et la culture du projet.