Ouvrir une fonctionnalité à un sous-ensemble d'utilisateurs en premier

Vous avez un nouveau moteur de recommandation prêt. L'équipe est confiante. Les tests passent. La revue de code est terminée. Mais quelque chose vous retient de basculer l'interrupteur pour tout le monde en même temps. Et si la nouvelle logique fonctionne bien en staging mais se comporte différemment sous le trafic réel ? Et si elle ralentit la page pour les utilisateurs ayant une connexion lente ? Et si elle recommande quelque chose d'embarrassant ?

Cette hésitation est saine. La façon la plus sûre de déployer une fonctionnalité est de la faire voir d'abord à un petit groupe d'utilisateurs. Si ça marche, on élargit. Si quelque chose casse, seul ce petit groupe est impacté. Ce modèle s'appelle le déploiement progressif, et c'est l'une des utilisations les plus pratiques des feature flags en production.

L'approche la plus simple : déploiement basé sur un pourcentage

La manière la plus directe de contrôler l'exposition est par pourcentage du trafic. Imaginez que vous voulez tester cette nouvelle fonctionnalité de recommandation. Vous ouvrez votre tableau de bord de feature flags et réglez le flag à 5%. Sur cent requêtes, cinq verront les nouvelles recommandations. Les quatre-vingt-quinze autres verront l'ancienne version.

Ce pourcentage peut être augmenté progressivement. Commencez à 5%. Surveillez les taux d'erreur, les temps de réponse et les retours utilisateurs. Si tout va bien, passez à 10%, puis 25%, puis 50%. Lorsque vous êtes confiant que la fonctionnalité est stable, passez à 100% et supprimez l'ancien code.

La beauté de cette approche est que vous pouvez l'inverser instantanément. Si le taux d'erreur grimpe à 25%, vous réduisez le pourcentage à 10% ou désactivez complètement le flag. Pas de rollback. Pas de redéploiement. Juste un changement de configuration.

Quand le pourcentage ne suffit pas

Parfois, vous avez besoin de plus de contrôle qu'un simple pourcentage. Vous voudrez peut-être que des utilisateurs spécifiques essayent la fonctionnalité en premier. Testeurs internes, membres de l'équipe QA, ou clients bienveillants qui ont accepté de participer à un bêta-test. Pour cela, votre feature flag a besoin de règles de ciblage.

La règle de ciblage la plus courante est basée sur l'ID utilisateur. Vous maintenez une liste d'IDs utilisateurs autorisés à voir la nouvelle fonctionnalité. Tous les autres voient l'ancienne version. C'est utile pour un bêta-test contrôlé : vous invitez une poignée d'utilisateurs à essayer la fonctionnalité en avant-première, tandis que le reste de votre base utilisateur ne sait même pas qu'elle existe.

Une autre règle de ciblage est par région. Vous pourriez ouvrir la fonctionnalité d'abord pour les utilisateurs en Indonésie, tandis que les utilisateurs d'autres pays continuent avec l'ancienne version. C'est utile lorsque la fonctionnalité doit se conformer à des réglementations locales, ou lorsque vous voulez voir comment elle se comporte sous des conditions réseau ou des comportements utilisateur spécifiques.

Vous pouvez également cibler par type de compte, version de l'application, modèle d'appareil, ou tout attribut que votre système connaît sur l'utilisateur. Plus vous avez d'attributs, plus vous pouvez contrôler précisément qui voit quoi.

Le problème de cohérence

Lorsque vous utilisez un déploiement basé sur un pourcentage, vous devez garantir la cohérence. Le même utilisateur doit toujours voir la même version pendant une session. Si un utilisateur voit la nouvelle fonctionnalité sur un chargement de page et l'ancienne version sur le suivant, il sera confus. La fonctionnalité apparaît et disparaît aléatoirement.

La solution est de baser le calcul du pourcentage sur un identifiant stable. Hachez l'ID utilisateur ou l'ID de session, puis utilisez ce hash pour déterminer dans quel groupe l'utilisateur tombe. Tant que l'ID utilisateur reste le même, le résultat du hash reste le même, et l'utilisateur bénéficie d'un traitement cohérent.

C'est pourquoi vous ne devez jamais utiliser un générateur de nombres aléatoires pour un déploiement basé sur un pourcentage. Les nombres aléatoires changent à chaque exécution du code. Un hash d'un identifiant stable vous donne un comportement déterministe.

Déploiement progressif vs. Canary release

Vous avez peut-être entendu parler des canary releases. Dans une canary release, vous déployez la nouvelle version de votre application sur un sous-ensemble de serveurs. Le trafic est dirigé vers ces serveurs en fonction des règles du répartiteur de charge. Si les serveurs canary montrent des problèmes, vous redirigez le trafic ailleurs.

Le déploiement progressif avec des feature flags est différent. Tous les serveurs exécutent le même code. Le flag détermine qui voit la nouvelle fonctionnalité. Vous n'avez pas besoin de gérer le routage des serveurs ou la configuration du répartiteur de charge. Vous changez simplement la valeur du flag.

Le schéma suivant compare les deux approches :

flowchart TD A[Début : 5% des utilisateurs] --> B[Surveiller les métriques] B --> C{Erreurs ou problèmes ?} C -->|Non| D[Augmenter à 10%] D --> E[Surveiller à nouveau] E --> F{Stable ?} F -->|Oui| G[Continuer à 25%, 50%, 100%] F -->|Non| H[Revenir au niveau précédent] C -->|Oui| I[Revenir à 0%] I --> J[Enquêter et corriger] J --> A K[Canary release : router le trafic vers un sous-ensemble de serveurs] --> L[Surveiller les métriques des serveurs] L --> M{En bonne santé ?} M -->|Oui| N[Augmenter le trafic canary] M -->|Non| O[Rediriger le trafic ailleurs]

Cette différence est importante pour les équipes qui déploient sur de nombreux serveurs ou utilisent l'orchestration de conteneurs. Avec les feature flags, vous n'avez pas besoin de maintenir plusieurs versions de votre application en production. Chaque serveur a le même binaire. Le flag est la seule différence.

L'effet psychologique

Le déploiement progressif n'est pas qu'une pratique technique. Il change la façon dont l'équipe perçoit la livraison de logiciels. Lorsque vous savez qu'une mauvaise fonctionnalité n'affectera que 5% des utilisateurs, vous êtes plus enclin à livrer. Vous cessez de considérer les releases comme des événements à haut risque et commencez à les traiter comme des expériences graduelles.

Les utilisateurs qui se trouvent dans le premier groupe ne se sentent pas lésés. Ils comprennent qu'ils essaient quelque chose de nouveau. Certains utilisateurs aiment même être des early adopters. Et quand quelque chose tourne mal, vous pouvez désactiver le flag sans panique. Pas de rollback d'urgence. Pas d'incident mobilisant toute l'équipe. Juste un changement de configuration et une note pour enquêter.

Checklist pratique pour un déploiement progressif

Avant d'ouvrir une fonctionnalité à un sous-ensemble d'utilisateurs, parcourez cette checklist :

  • Pouvez-vous identifier les utilisateurs de manière cohérente ? Utilisez un identifiant stable comme l'ID utilisateur ou l'ID de session pour les calculs de pourcentage.
  • Avez-vous une surveillance en place ? Sachez quelles métriques surveiller : taux d'erreur, temps de réponse, problèmes signalés par les utilisateurs.
  • Pouvez-vous désactiver le flag instantanément ? Assurez-vous que le système de flag répond rapidement et ne nécessite pas de redéploiement.
  • Avez-vous défini les étapes du déploiement ? Planifiez les pourcentages : 5%, 10%, 25%, 50%, 100%. Décidez combien de temps rester à chaque étape.
  • Avez-vous un plan de rollback ? Quel seuil de métrique déclenche une désactivation du flag ? Qui prend cette décision ?

Ce qu'il faut retenir

Le déploiement progressif transforme les releases de fonctionnalités de paris tout-ou-rien en expériences contrôlées. Commencez avec un petit pourcentage ou un groupe ciblé. Surveillez les métriques. Élargissez lorsque vous êtes confiant. Fermez instantanément si quelque chose casse. Ce modèle donne à votre équipe la confiance nécessaire pour livrer plus souvent, car le risque est toujours limité à une petite partie de vos utilisateurs.