3 rollbacks en pleine nuit avant d’adopter les feature flags — les 7 étapes qui ont divisé nos rollbacks par 4

Trois réveils à 2 heures du matin en six mois, pour la même raison à chaque fois : une fonctionnalité livrée l’après-midi, un comportement inattendu la nuit, et un redéploiement en urgence pour revenir en arrière. À chaque fois, le code était correct pris isolément — il interagissait mal avec des données réelles que nos environnements de test ne contenaient pas.

Le troisième réveil a été celui de trop. Nous avons changé, non pas notre façon d’écrire du code, mais l’ordre dans lequel nous prenons les décisions. Sur le semestre suivant, à volume de livraisons comparable, nous sommes passés de 11 rollbacks à 3. Voici la méthode, dans l’ordre exact où elle doit être mise en place.

Étape 1 — Séparer le déploiement de l’activation

C’est le principe unique dont découle tout le reste. Dans un déploiement classique, deux événements sont confondus : le code arrive sur les serveurs, et il devient actif pour les utilisateurs. Un feature flag les dissocie.

Concrètement, le code part en production désactivé. Il est là, il est compilé, il est testé par les mêmes pipelines que le reste — mais la branche conditionnelle qui l’exécute renvoie false. L’activation devient une décision séparée, prise quand vous le voulez, et surtout annulable sans redéploiement.

Le changement de nature du risque est le vrai bénéfice. Avant, revenir en arrière voulait dire : retrouver la version précédente, relancer un pipeline complet, attendre la reconstruction, espérer qu’aucune migration de base ne bloque le retour. Entre dix minutes et une heure, sous stress, la nuit. Après, revenir en arrière veut dire : passer une valeur de true à false. Quelques secondes, sans stress, exécutable par la personne d’astreinte même si elle n’a pas écrit la fonctionnalité.

Étape 2 — Choisir le support du flag selon votre échelle réelle

Erreur classique : souscrire d’emblée à une plateforme spécialisée pour gérer trois booléens. Le bon support dépend de deux paramètres seulement — le délai de bascule visé et le nombre de flags simultanés.

• Variable d’environnement — délai de bascule : un redémarrage. Convient aux interrupteurs de configuration rarement touchés, pas à un déploiement progressif. Coût nul.
• Table en base de données avec cache mémoire de 10 à 30 secondes — délai de bascule : moins d’une minute. C’est le bon choix pour la grande majorité des équipes, jusqu’à une dizaine de flags actifs. Deux jours de mise en place, aucun abonnement.
• Service dédié — délai de bascule : quelques secondes, ciblage fin, historique d’audit, propagation multi-services. Justifié à partir d’une vingtaine de flags simultanés, de plusieurs services à synchroniser, ou d’une exigence d’audit contractuelle.

Nous avons commencé par la table en base. Nous n’avons migré vers un service dédié qu’au bout de onze mois, quand la propagation entre quatre services est devenue le point de friction. Commencer par le plus simple nous a fait gagner un an d’abonnement et, surtout, nous a permis de comprendre nos besoins réels avant de choisir.

Étape 3 — Tenir un registre, sinon rien ne tient

C’est l’étape que tout le monde saute et celle qui décide de la suite. Chaque flag doit porter, dès sa création, cinq informations :

1. Un propriétaire nommé — une personne, pas une équipe. Les équipes ne suppriment pas les flags ; les personnes le font.
2. Une intention en une phrase — ce que le flag protège, et à quelle condition il pourra disparaître.
3. Un type — déploiement progressif, interrupteur d’urgence, activation par client, ou expérimentation. Le type détermine la durée de vie attendue.
4. Une date d’expiration — obligatoire, y compris pour les interrupteurs permanents, qui sont alors simplement revus à cette date.
5. Le comportement par défaut en cas de panne — si le service de flags est injoignable, la fonctionnalité doit-elle être active ou inactive ? Cette question doit être tranchée avant l’incident, pas pendant.

Ce dernier point nous a coûté une demi-journée de dégradation. Notre cache de flags a expiré pendant une indisponibilité de la base, et notre code retournait false par défaut — désactivant au passage une fonctionnalité généralisée depuis des semaines. Depuis, la valeur de repli est explicite pour chaque flag et testée dans le pipeline.

Étape 4 — Définir la règle de ciblage, et la rendre stable

Trois modes de ciblage couvrent presque tous les besoins :

• Par pourcentage d’utilisateurs — pour un déploiement progressif classique.
• Par cohorte — comptes internes d’abord, puis clients volontaires, puis tout le monde.
• Par liste explicite de comptes — pour livrer une fonctionnalité à un client précis qui l’a demandée.

Une exigence prime sur le reste : l’affectation doit être stable dans le temps. Si vous tirez un nombre aléatoire à chaque requête, un même utilisateur verra la nouvelle version puis l’ancienne au rechargement de sa page. C’est déroutant pour lui, et cela rend toute mesure impossible.

La bonne pratique consiste à hacher l’identifiant de l’utilisateur avec le nom du flag, puis à comparer le résultat au pourcentage cible. La même personne obtient toujours la même réponse pour un flag donné, et deux flags différents ne toucheront pas les mêmes personnes — ce qui évite de concentrer toutes les nouveautés sur les mêmes utilisateurs.

Étape 5 — Instrumenter avant d’activer, jamais après

Un déploiement progressif sans mesure est un déploiement normal avec des étapes en plus. Si vous ne savez pas distinguer le comportement du groupe exposé de celui du groupe témoin, le palier à 1 % ne vous apprend rien.

Avant la première activation, trois familles de mesures doivent être en place, chacune ventilée selon l’état du flag :

• Santé technique — taux d’erreur, latence au 95^e centile, consommation de ressources. Ce sont les signaux d’arrêt.
• Indicateur métier de la fonctionnalité — ce qu’elle est censée améliorer. C’est ce qui justifie de continuer.
• Indicateur de garde — une métrique importante que la fonctionnalité ne doit pas dégrader, même si elle réussit par ailleurs. C’est le plus souvent oublié, et c’est celui qui rattrape les fausses bonnes idées.

Cet indicateur de garde nous a évité une erreur coûteuse. Une refonte de notre parcours d’inscription améliorait le taux de complétion de 9 % — un succès apparent. L’indicateur de garde, le taux de rétention à sept jours, baissait de 4 %. Nous attirions davantage de comptes moins engagés. Sans cette mesure, nous aurions généralisé une régression en la prenant pour une victoire.

Étape 6 — Dérouler par paliers, avec des critères d’arrêt écrits à l’avance

La progression que nous utilisons, et qui s’est révélée robuste :

1. Comptes internes — au moins une journée ouvrée complète. Coût nul, détecte les erreurs grossières.
2. 1 % des utilisateurs — 24 heures minimum. La durée compte plus que le pourcentage : il faut couvrir un cycle jour/nuit, les traitements planifiés et le renouvellement des sessions.
3. 5 % — 24 heures. C’est le palier où apparaissent les cas rares liés aux données réelles.
4. 25 % — 24 heures. Premier palier où la charge devient significative ; c’est là que se révèlent les problèmes de performance.
5. 100 % — avec le flag conservé actif pendant au moins une semaine avant suppression.

Chaque palier a des critères d’arrêt écrits avant le démarrage, et automatisés quand c’est possible : si le taux d’erreur du groupe exposé dépasse celui du groupe témoin d’un seuil défini, le flag revient à sa valeur précédente sans intervention humaine. Une décision prise à froid vaut mieux qu’un arbitrage à 2 heures du matin par quelqu’un qui n’a pas écrit le code.

Une règle de discipline : on ne saute pas de palier parce que « tout va bien ». C’est exactement ce que nous avons fait lors de notre unique rollback du second semestre. Tout allait bien à 5 %, nous sommes passés directement à 100 %, et le problème est apparu sur un volume que 25 % aurait révélé sans impacter tout le monde.

Étape 7 — Supprimer le flag, sinon il vous survivra

Un flag de déploiement progressif a une durée de vie utile de quelques semaines. Passé ce délai, il n’est plus un outil : c’est une branche conditionnelle morte que personne n’ose retirer parce que personne ne se rappelle ce qu’elle protégeait.

Notre règle, appliquée sans exception : la date d’expiration est renseignée à la création, et la suppression est planifiée en même temps que l’activation. Passé la date, une tâche est ouverte automatiquement et le flag apparaît en anomalie dans le registre, visible de toute l’équipe.

Supprimer un flag, ce n’est pas retirer la ligne de configuration. C’est trois opérations : retirer la condition dans le code en gardant le comportement retenu, supprimer le code de l’ancienne branche devenu inatteignable, puis retirer l’entrée du registre. Sauter la deuxième opération est la façon la plus courante d’accumuler du code mort — le flag disparaît, l’ancienne implémentation reste, et six mois plus tard quelqu’un la modifie en croyant qu’elle sert encore.

Nous avons mis quatre mois à assainir l’existant : 23 flags recensés, dont 14 auraient dû disparaître depuis longtemps, et 2 dont plus personne dans l’équipe ne savait dire ce qu’ils contrôlaient. Ceux-là, nous les avons désactivés un mardi matin en surveillant les alertes — la seule méthode honnête quand la documentation a disparu.

Les 3 pièges que nous n’avons pas évités

1. Les flags imbriqués. Deux flags qui se croisent produisent quatre chemins d’exécution, dont trois ne sont jamais testés. Nous nous interdisons désormais toute imbrication : si deux fonctionnalités interagissent, elles partagent un seul flag.
2. Les flags dans le code de migration de données. Une migration n’est pas réversible en basculant un booléen. Utilisez un flag pour l’écriture vers un nouveau schéma, jamais pour la transformation elle-même.
3. L’absence de valeur de repli explicite. Décrit plus haut : notre demi-journée de dégradation vient de là. Chaque flag doit déclarer ce qui se passe quand la source de vérité est injoignable, et ce comportement doit être testé.

Ce dispositif s’intègre naturellement à une chaîne de livraison déjà durcie. Si vos dépendances ne sont pas maîtrisées, un flag n’y changera rien : commencez par auditer vos dépendances npm en 7 étapes. Côté exploitation, nos confrères de WebGuard Agency détaillent les politiques d’accès aux consoles de production — un flag activable par n’importe qui est un interrupteur d’urgence pour vos incidents comme pour ceux d’un attaquant. Et si vos fonctionnalités embarquent des appels à des modèles d’IA, les équipes de Plug-Tech documentent les métriques spécifiques à surveiller lors d’un déploiement progressif sur ce type de brique.

Pour un projet en cours de conception, notre guide comment créer une plateforme de mise en relation détaille les arbitrages d’architecture qui rendent ce type de déploiement possible dès le départ.

Questions fréquentes