Feature flag : relâchez sans retenir votre souffle

spinny:~/writing $ less openfeature-feature-flags-progressive-delivery.md

1 
2Le 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.
3 
4Les 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.
5 
6## Le drapeau n'est pas qu'un si
7 
8Techniquement, c'est souvent un `if`. Culturellement, c'est bien plus.
9 
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14 
15return oldCheckout(input);
16```
17 
18Ce 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.
19 
20## Où entre OpenFeature
21 
22OpenFeature 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.
23 
24L'application demande :
25 
26```typescript
27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {
28  targetingKey: user.id,
29  plan: user.plan,
30  country: user.country,
31});
32```
33 
34Le 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.
35 
36Cette séparation semble être un détail architectural, mais elle se ressent au fur et à mesure que le projet grandit.
37 
38## Le contexte représente la moitié de la bataille
39 
40Un drapeau d'activation ou de désactivation pour tout le monde est utile, mais limité. La livraison progressive vit dans son contexte :
41 
42- utilisateur interne ou externe ;
43- plan gratuit ou entreprise ;
44- village;
45- organisation;
46- version de l'application ;
47- pourcentage de trafic stable.
48 
49La 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.
50 
51## Un déploiement judicieux
52 
53Un flux que j'aime est celui-ci :
54 
551. déployer sans drapeau ;
562. allumage pour les développeurs et l'assurance qualité ;
573. mise en marche pour un client ou locataire pilote ;
58Déploiement de 4, 5 % ;
595. déploiement à 25% ;
606. Déploiement à 100 % ;
617. suppression de l'ancien code et du drapeau.
62 
63Le 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 ?".
64 
65## Kill switch : préparez-les d'abord
66 
67Le 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.
68 
69Un bon kill switch doit être :
70 
71- facile à trouver ;
72- documenté dans le runbook ;
73- testé occasionnellement ;
74- observable lorsqu'il est activé ;
75- indépendant, autant que possible, de la pièce qui pourrait se briser.
76 
77Le pire est de découvrir lors de l'accident que le drapeau existe, mais personne ne sait s'il fonctionne encore.
78 
79## Observabilité ou livraison non progressive
80 
81Activer une fonctionnalité à 10 % sans regarder les métriques n'est qu'un optimisme en plusieurs étapes.
82 
83Chaque déploiement doit répondre à des questions simples :
84 
85- les erreurs ont-elles augmenté ?
86- la latence a-t-elle changé ?
87- les utilisateurs terminent-ils le flux ?
88- y a-t-il plus de tickets ou de tentatives ?
89- une variante impacte-t-elle un seul segment ?
90 
91OpenFeature 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.
92 
93## Dénomination et propriété
94 
95Les noms comptent. `new_ui` ne dit rien. `checkout.v2.enabled` en dit beaucoup plus.
96 
97Pour chaque drapeau, je marquerais au moins :
98 
99- nom ;
100- description;
101- propriétaire;
102- défaut sûr ;
103- la raison pour laquelle il existe ;
104- date ou condition d'enlèvement.
105 
106Un drapeau sans propriétaire est presque toujours un drapeau que personne ne nettoiera.
107 
108## Où les évaluer
109 
110Frontend, backend ou edge ? Cela dépend.
111 
112Si 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.
113 
114La règle simple : le frontend peut améliorer l’expérience, mais il ne doit pas être la seule barrière de sécurité.
115 
116## Conclusion
117 
118Les 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.
119 
120OpenFeature 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é.
121 
122Le meilleur drapeau est celui qui vous aide à vous libérer sereinement et qui disparaît ensuite lorsqu'on n'en a plus besoin.
123 
124##Sources
125 
126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)
127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)
128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)
129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)
130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)
131

:Feature flag : relâchez sans retenir votre soufflelines 1-131 (END) — press q to close

2Le 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.

4Les 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.

6## Le drapeau n'est pas qu'un si

8Techniquement, c'est souvent un `if`. Culturellement, c'est bien plus.

10```typescript

11if (await flags.isEnabled('checkout.v2.enabled', context)) {

12 return newCheckout(input);

13}

15return oldCheckout(input);

16```

18Ce 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.

20## Où entre OpenFeature

22OpenFeature 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.

24L'application demande :

26```typescript

27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {

28 targetingKey: user.id,

29 plan: user.plan,

30 country: user.country,

31});

32```

34Le 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.

36Cette séparation semble être un détail architectural, mais elle se ressent au fur et à mesure que le projet grandit.

38## Le contexte représente la moitié de la bataille

40Un drapeau d'activation ou de désactivation pour tout le monde est utile, mais limité. La livraison progressive vit dans son contexte :

42- utilisateur interne ou externe ;

43- plan gratuit ou entreprise ;

44- village;

45- organisation;

46- version de l'application ;

47- pourcentage de trafic stable.

49La 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.

51## Un déploiement judicieux

53Un flux que j'aime est celui-ci :

551. déployer sans drapeau ;

562. allumage pour les développeurs et l'assurance qualité ;

573. mise en marche pour un client ou locataire pilote ;

58Déploiement de 4, 5 % ;

595. déploiement à 25% ;

606. Déploiement à 100 % ;

617. suppression de l'ancien code et du drapeau.

63Le 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 ?".

65## Kill switch : préparez-les d'abord

67Le 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.

69Un bon kill switch doit être :

71- facile à trouver ;

72- documenté dans le runbook ;

73- testé occasionnellement ;

74- observable lorsqu'il est activé ;

75- indépendant, autant que possible, de la pièce qui pourrait se briser.

77Le pire est de découvrir lors de l'accident que le drapeau existe, mais personne ne sait s'il fonctionne encore.

79## Observabilité ou livraison non progressive

81Activer une fonctionnalité à 10 % sans regarder les métriques n'est qu'un optimisme en plusieurs étapes.

83Chaque déploiement doit répondre à des questions simples :

85- les erreurs ont-elles augmenté ?

86- la latence a-t-elle changé ?

87- les utilisateurs terminent-ils le flux ?

88- y a-t-il plus de tickets ou de tentatives ?

89- une variante impacte-t-elle un seul segment ?

91OpenFeature 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.

93## Dénomination et propriété

95Les noms comptent. `new_ui` ne dit rien. `checkout.v2.enabled` en dit beaucoup plus.

97Pour chaque drapeau, je marquerais au moins :

99- nom ;

100- description;

101- propriétaire;

102- défaut sûr ;

103- la raison pour laquelle il existe ;

104- date ou condition d'enlèvement.

105

106Un drapeau sans propriétaire est presque toujours un drapeau que personne ne nettoiera.

107

108## Où les évaluer

109

110Frontend, backend ou edge ? Cela dépend.

111

112Si 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.

113

114La règle simple : le frontend peut améliorer l’expérience, mais il ne doit pas être la seule barrière de sécurité.

115

116## Conclusion

117

118Les 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.

119

120OpenFeature 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é.

121

122Le meilleur drapeau est celui qui vous aide à vous libérer sereinement et qui disparaît ensuite lorsqu'on n'en a plus besoin.

123

124##Sources

125

126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)

127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)

128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)

129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)

130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)

131