Déployer du code et activer une fonctionnalité sont deux décisions distinctes. Pourtant, dans de nombreuses applications PHP, elles interviennent simultanément : une nouvelle version arrive en production et devient disponible pour l’ensemble de la base d’utilisateurs. Ce modèle fonctionne pour des changements mineurs et réversibles, mais augmente le risque en présence de migrations, de nouvelles règles métier, d’intégrations externes ou d’expériences devant être validées auprès d’un groupe restreint.
Les feature flags en PHP permettent de découpler ces deux décisions. Le code peut être déployé, testé et prêt, tandis que la fonctionnalité reste inactive ou n’est activée que pour un segment défini. L’avantage ne consiste pas à accumuler des interrupteurs, mais à réduire le périmètre d’impact et à rendre l’activation réversible sans devoir publier une nouvelle version.
Le coût existe : chaque flag ajoute des états, des combinaisons possibles et une obligation de gouvernance. C’est pourquoi une mise en œuvre utile doit traiter une flag comme un élément temporaire et opérationnel du produit, avec un responsable, un objectif, une date de révision et un plan de retrait.
Le problème : déployer ne doit pas impliquer d’activer pour tous
Une livraison logicielle peut contenir des changements qu’il n’est pas souhaitable d’exposer immédiatement. Par exemple, une nouvelle manière de calculer les remises peut nécessiter une vérification auprès de quelques organisations ; un prestataire de paiement peut être intégré techniquement, mais en attente de validation commerciale ; ou un écran repensé peut nécessiter une révision par le support avant d’être activé de manière générale.
Sans flag, les alternatives sont souvent peu efficaces : maintenir une branche de longue durée, retarder le déploiement de changements déjà prêts ou publier un correctif urgent pour annuler une activation problématique. Les branches divergentes augmentent le coût des intégrations. Retarder les déploiements mélange des changements non liés. Et annuler une version complète peut également retirer des correctifs nécessaires.
Une flag bien appliquée permet de déployer d’abord avec le comportement actuel comme valeur par défaut. L’équipe active ensuite le nouveau comportement pour un segment limité, observe ses effets et étend ou annule l’exposition. Point important : une flag ne remplace ni les tests, ni la revue de code, ni un plan de réversibilité des données. Elle réduit seulement la portée d’une décision d’activation.
Quand utiliser une feature flag et quand choisir une autre solution
Utilisez une flag lorsque l’activation doit être progressive, réversible et ciblée. Elle est particulièrement pertinente pour des changements présentant un risque fonctionnel, des lancements par organisation, des activations dépendantes des autorisations, des migrations impliquant la coexistence temporaire de deux flux ou des mécanismes opérationnels permettant de limiter la charge ou de désactiver une intégration.
Toute option de configuration ne mérite pas une feature flag. Une configuration simple est préférable si elle représente une propriété stable de l’environnement, telle qu’une URL interne ou une limite technique qui n’est pas gérée par utilisateur. Une branche de produit peut convenir à une variante délibérément permanente, à condition d’assumer le coût de sa maintenance. Un déploiement séparé est adapté lorsque les composants ont des cycles de vie, des autorisations ou des besoins de mise à l’échelle indépendants.
Il est également déconseillé d’utiliser des flags pour masquer une décision produit sans échéance, pour compenser une architecture difficile à modifier ou pour éviter de convenir des exigences. Si une condition doit rester indéfiniment dans le domaine, elle doit être modélisée comme une règle métier explicite, et non comme un interrupteur provisoire.
Types de flags et risque de mélanger les objectifs
- Flags de publication : elles contrôlent la disponibilité d’une nouvelle capacité pendant que sa validation est finalisée.
- Flags de segmentation : elles activent une fonction pour des utilisateurs, organisations, forfaits ou autorisations spécifiques.
- Flags opérationnelles : elles désactivent temporairement un processus coûteux ou une dépendance externe lors d’un incident.
- Flags d’expérimentation : elles répartissent des variantes afin d’évaluer une hypothèse à l’aide de métriques définies.
Cette classification est importante, car elle détermine qui peut modifier la flag, quelles preuves sont nécessaires et à quel moment elle doit être retirée. Une flag opérationnelle peut exiger un accès restreint et une réponse immédiate. Une flag d’expérimentation nécessite une attribution stable afin qu’un utilisateur ne change pas de variante entre les requêtes. Une flag de publication doit avoir des critères clairs pour passer à une activation générale.
Évitez de mélanger les objectifs dans une seule clé. Une flag qui publie à la fois une fonction, sélectionne une variante et sert d’interrupteur d’urgence devient difficile à interpréter. En cas de défaillance, personne ne saura s’il faut ajuster le pourcentage, modifier une condition ou désactiver complètement le flux.
Modèle minimal et gouvernance d’une flag
Une flag ne devrait pas être uniquement une paire clé-valeur. Enregistrez au minimum une clé stable, une description orientée vers la décision, un propriétaire, un type, une valeur par défaut, le périmètre autorisé, la condition d’activation, la date de création ainsi que la date prévue de révision ou de retrait.
Une clé telle que checkout.new_payment_flow communique mieux son objectif que flag_42. La stabilité est importante : renommer des clés de manière informelle casse les configurations, les panneaux d’administration et les automatisations. La documentation doit permettre de savoir, sans rechercher dans l’historique du dépôt, ce que la flag modifie, quels utilisateurs elle peut affecter, quelles métriques surveiller et comment revenir à l’état sûr.
Définissez les autorisations selon le risque. L’équipe produit peut proposer l’audience et le calendrier d’une publication ; l’équipe de développement doit valider les dépendances et le comportement ; les opérations ou un rôle d’astreinte peut avoir besoin de pouvoir désactiver une intégration lors d’un incident. Les modifications doivent être auditées avec l’acteur, le moment, le changement effectué et le motif. N’accordez pas à tous les profils la capacité d’activer globalement des fonctions sensibles.
Conception technique en PHP : centraliser l’évaluation
L’erreur habituelle consiste à disperser les vérifications dans les contrôleurs, les gabarits, les commandes et les services :
if ($config['new_checkout']) {
// nouveau flux
} else {
// flux actuel
}Ce modèle paraît simple, mais il multiplie les points où une même décision peut être appliquée différemment. Centralisez l’évaluation derrière une interface du domaine ou de l’application. Le reste du code interroge une capacité, et non la source concrète de configuration.
interface FeatureDecider
{
public function enabled(string $feature, FeatureContext $context): bool;
}
if ($features->enabled('checkout.new_payment_flow', $context)) {
return $newCheckout->start($order);
}
return $currentCheckout->start($order);FeatureContext ne doit contenir que les attributs nécessaires, par exemple l’identifiant de l’organisation, l’identifiant de l’utilisateur, les autorisations et l’environnement. L’implémentation peut lire des variables d’environnement, une base de données ou un service de configuration, mais cette décision ne doit pas se diffuser dans toute l’application. Pour les tests, une implémentation en mémoire permet de déclarer l’état sans dépendre d’une infrastructure externe.
Gardez les deux chemins proches lorsque leur coexistence est temporaire et limitez la condition au point de sélection. N’enveloppez pas chaque détail du flux avec des flags ; cela rend la logique illisible et complique la suppression de l’ancien chemin. Si les deux flux partagent des étapes, extrayez ces étapes et laissez la flag choisir uniquement la stratégie qui change réellement.
Segmentation sûre et tests des combinaisons
Les critères de segmentation doivent être déterministes et cohérents. Pour les utilisateurs ou les organisations, utilisez des identifiants stables. Pour les pourcentages, appliquez une fonction déterministe à une clé stable, telle que l’identifiant de l’organisation, afin que l’attribution ne change pas aléatoirement à chaque requête. Si un utilisateur appartient à une organisation, définissez quelle identité prévaut ; généralement, l’organisation évite des expériences contradictoires entre les membres d’une même équipe.
Les autorisations exigent une règle explicite : une flag ne doit pas accorder de privilèges. L’autorisation est d’abord validée, puis il est décidé si la capacité est publiée pour ce contexte. Déterminez également les priorités : par exemple, une exclusion individuelle peut prévaloir sur une inclusion en pourcentage, et une désactivation opérationnelle globale doit prévaloir sur tout segment.
Avant l’activation, testez la matrice minimale : flag désactivée, activée, contexte inclus, contexte exclu, absence de contexte et conflits de règles. Ajoutez des tests d’intégration pour confirmer que le parcours complet répond à l’état attendu, et pas seulement l’évaluateur. Le comportement par défaut mérite un test spécifique : si la configuration n’est pas disponible ou qu’une règle est invalide, l’application doit adopter l’état sûr défini et consigner le problème.
Déploiement, réversibilité et observabilité
- Introduisez la flag avec une valeur par défaut sûre et le flux existant intact.
- Déployez le code et vérifiez qu’avec la flag désactivée, le comportement ne change pas.
- Activez-la pour un environnement contrôlé ou un segment interne autorisé.
- Étendez le périmètre par étapes définies, en examinant les indicateurs fonctionnels et techniques.
- En cas d’incident, désactivez la flag si cela rétablit un état cohérent ; en présence de changements de données irréversibles, exécutez le plan de récupération spécifique.
- Lorsque la décision est définitive, supprimez la flag et le chemin qui n’est plus pertinent.
Consignez les évaluations pertinentes sans stocker d’attributs personnels inutiles. Il est utile de conserver la clé de la flag, le résultat, la version ou la règle appliquée, l’identifiant technique pseudonymisé du contexte et la corrélation avec la requête. Cela permet de distinguer si une erreur provient du code, d’une configuration inattendue ou d’une segmentation incorrecte. Contrôlez le volume : consigner toutes les évaluations sur des chemins à fort trafic peut générer du bruit et des coûts ; privilégiez les changements d’état, les erreurs et l’échantillonnage traçable.
Retrait planifié et checklist finale
Une flag qui survit à son objectif devient une dette technique. Planifiez des révisions et traitez les flags expirées comme un travail de maintenance visible. Le retrait exige de décider du comportement final, de supprimer la branche alternative, d’effacer les tests associés au comportement écarté, de retirer les règles et les autorisations de gestion, et de mettre à jour la documentation. Ensuite, confirmez qu’il n’existe aucune référence dans le code, les tâches planifiées, les gabarits ou les automatisations.
Avant de créer une nouvelle flag, vérifiez :
- Existe-t-il une raison concrète de séparer le déploiement et l’activation ?
- Le type de flag et son propriétaire sont-ils connus ?
- La valeur par défaut est-elle sûre et testée ?
- La segmentation est-elle déterministe, autorisée et dotée de priorités définies ?
- Existe-t-il des métriques, des journaux et un critère pour étendre ou arrêter l’activation ?
- Peut-on revenir en arrière sans laisser les données ou les processus dans un état incohérent ?
- Dispose-t-elle d’une date de révision et d’un plan de suppression vérifiable ?
Avec ces conditions, les feature flags en PHP cessent d’être des conditions dispersées et deviennent un mécanisme de livraison contrôlée : utile pour le produit, compréhensible pour le développement et exploitable face aux changements à risque.
