Le déploiement a lieu lorsque le code arrive en production. La libération, c'est le moment où quelqu'un peut réellement l'utiliser. Confondre les deux est l’un des moyens les plus rapides de faire de chaque déploiement un moment un peu tendu.
Les feature flag servent à mettre de l'espace entre ces deux moments. Vous pouvez déployer aujourd'hui, lancer demain pour l'équipe interne, puis pour un client pilote, puis pour 10 % des utilisateurs. Si quelque chose ne va pas, éteignez le drapeau. Vous n'êtes pas nécessairement obligé de restaurer l'intégralité de la version.
Le drapeau n'est pas qu'un si
Techniquement, c'est souvent un if. Culturellement, c'est bien plus.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Ce petit if peut représenter un déploiement progressif, une expérimentation, une migration, un permis d'entreprise ou un kill switch opérationnel. Le problème est que si on ne la gère pas bien, cela peut aussi devenir une dette technique qui reste dans le code pendant deux ans.
Où entre OpenFeature
OpenFeature est une spécification ouverte pour évaluer feature flag avec un API commun. L'idée est simple : le code de votre application ne doit pas dépendre directement du fournisseur ou du système interne que vous utilisez pour les indicateurs.
L'application demande :
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
Le fournisseur décide d'où viennent les règles : SaaS, fichier, service interne, flagd, configuration GitOps. Si un jour vous modifiez le backend de marquage des fonctionnalités, l'application n'a pas besoin d'être réécrite partout.
Cette séparation semble être un détail architectural, mais elle se ressent au fur et à mesure que le projet grandit.
Le contexte représente la moitié de la bataille
Un drapeau d'activation ou de désactivation pour tout le monde est utile, mais limité. La livraison progressive vit dans son contexte :
- utilisateur interne ou externe ;
- plan gratuit ou entreprise ;
- village;
- organisation;
- version de l'application ;
- pourcentage de trafic stable.
La clé importante est targetingKey : elle doit être stable. Si cela change à chaque requête, un utilisateur peut se retrouver une fois dans la variante A et une fois dans la variante B. Pour une expérience c'est terrible, pour une caisse cela peut être désastreux.
Un déploiement judicieux
Un flux que j'aime est celui-ci :
- déployer sans drapeau ;
- allumage pour les développeurs et l'assurance qualité ;
- mise en marche pour un client ou locataire pilote ; Déploiement de 4, 5 % ;
- déploiement à 25% ;
- Déploiement à 100 % ;
- suppression de l'ancien code et du drapeau.
Le point souvent oublié est le dernier. Un drapeau temporaire doit avoir une date de décès. Si elle reste pour toujours, chaque futur refactor devra se demander : "mais cette branche est-elle toujours utile ?".
Kill switch : préparez-les d'abord
Le kill switch est l'indicateur qui vous sauve lorsqu'une dépendance externe commence à vous déranger, qu'un travail consomme trop de ressources ou qu'une nouvelle logique produit des erreurs étranges.
Un bon kill switch doit être :
- facile à trouver ;
- documenté dans le runbook ;
- testé occasionnellement ;
- observable lorsqu'il est activé ;
- indépendant, autant que possible, de la pièce qui pourrait se briser.
Le pire est de découvrir lors de l'accident que le drapeau existe, mais personne ne sait s'il fonctionne encore.
Observabilité ou livraison non progressive
Activer une fonctionnalité à 10 % sans regarder les métriques n'est qu'un optimisme en plusieurs étapes.
Chaque déploiement doit répondre à des questions simples :
- les erreurs ont-elles augmenté ?
- la latence a-t-elle changé ?
- les utilisateurs terminent-ils le flux ?
- y a-t-il plus de tickets ou de tentatives ?
- une variante impacte-t-elle un seul segment ?
OpenFeature prend en charge les crochets autour de l'évaluation des drapeaux. Ils sont utiles pour enregistrer les erreurs, ajouter des métriques ou lier la note à un trace.
Dénomination et propriété
Les noms comptent. new_ui ne dit rien. checkout.v2.enabled en dit beaucoup plus.
Pour chaque drapeau, je marquerais au moins :
- nom ;
- description;
- propriétaire;
- défaut sûr ;
- la raison pour laquelle il existe ;
- date ou condition d'enlèvement.
Un drapeau sans propriétaire est presque toujours un drapeau que personne ne nettoiera.
Où les évaluer
Frontend, backend ou edge ? Cela dépend.
Si l'indicateur concerne la mise en page, la copie ou l'intégration, le frontend convient. S’il s’agit d’autorisations, de facturation, de limites ou de données sensibles, cela doit être sur le backend. S’il s’agit d’expériences de routage ou de trafic élevé, l’avantage peut avoir du sens.
La règle simple : le frontend peut améliorer l’expérience, mais il ne doit pas être la seule barrière de sécurité.
Conclusion
Les feature flag bien faits changent le rapport à la production. Ils n’éliminent pas le risque, mais le réduisent et le rendent plus gérable. Vous pouvez relâcher par tranches, observer, arrêter, revenir en arrière, apprendre.
OpenFeature ajoute une base propre : un API commun, des fournisseurs interchangeables et une manière plus ordonnée de développer le système. Mais la discipline reste la vôtre : valeurs par défaut sûres, noms clairs, mesures, propriétaires et propreté.
Le meilleur drapeau est celui qui vous aide à vous libérer sereinement et qui disparaît ensuite lorsqu'on n'en a plus besoin.
##Sources