Quand les utilisateurs peuvent-ils vraiment utiliser cette nouvelle fonctionnalité ?

Vous venez de déployer une nouvelle fonctionnalité en production. L'équipe est soulagée. Le ticket est marqué comme terminé. Mais ensuite les questions commencent : "Peut-on déjà l'annoncer ?" "Faut-il attendre l'équipe marketing ?" "Et si ce cas limite qu'on a oublié se manifeste sous le trafic réel ?"

Ce moment est plus courant que la plupart des équipes ne l'admettent. Le code est sur le serveur, mais personne n'est sûr que les utilisateurs doivent réellement le voir. Et cette incertitude révèle une lacune que beaucoup d'équipes ne réalisent exister que lorsque quelque chose tourne mal.

Déployer n'est pas publier

Voici une distinction qui change votre façon de penser la livraison de logiciels : déployer du code et publier une fonctionnalité sont deux choses différentes.

Déployer, c'est l'action de mettre du nouveau code sur un serveur. Publier, c'est le moment où un utilisateur peut réellement voir et utiliser cette fonctionnalité. Dans de nombreuses équipes, ces deux événements se produisent en même temps par défaut. Le code monte, la fonctionnalité apparaît. Mais ils n'ont pas à être liés.

Imaginez que vous gérez une application utilisée par des milliers de personnes. Vous venez d'ajouter une fonctionnalité de recherche plus rapide. Le code est déployé sur tous les serveurs. Mais après la mise en ligne, la fonctionnalité provoque un pic de charge serveur. Les utilisateurs commencent à subir des pages lentes. Certains ne peuvent même pas ouvrir la page d'accueil. Vous avez maintenant un sérieux problème : vous devez revenir en arrière sur l'ensemble de l'application, même si une seule fonctionnalité est cassée. Ou vous devez écrire un correctif, refaire tout le processus de déploiement, et espérer que ça marche cette fois. Les utilisateurs sont impactés pendant tout ce temps.

Cette situation est évitable si vous pouvez séparer le moment où le code arrive sur le serveur du moment où une fonctionnalité devient visible pour les utilisateurs. Vous pouvez déployer du code qui contient déjà la nouvelle fonctionnalité, mais garder cette fonctionnalité désactivée. Ce n'est qu'après avoir confirmé que tout est sûr que vous l'activez.

Le diagramme de séquence suivant illustre comment un feature flag crée un intervalle de sécurité entre le déploiement du code et sa publication aux utilisateurs :

Feature Flags : un interrupteur dans votre code

Le mécanisme pour cette séparation s'appelle un feature flag. Un feature flag est un interrupteur conditionnel dans votre code qui détermine si une fonctionnalité spécifique doit s'exécuter. Vous pouvez modifier la valeur de cet interrupteur sans déployer de nouveau code. Mettez à jour une configuration, et la fonctionnalité s'active ou se désactive dans l'application en cours d'exécution.

Voici un exemple simple. Au lieu d'appeler directement la nouvelle logique de recherche, vous l'enveloppez dans une vérification :

if feature_flags.is_enabled("fast_search"):
    results = fast_search(query)
else:
    results = old_search(query)

Quand fast_search est désactivé, l'application exécute l'ancien chemin de code. Quand vous l'activez, la nouvelle logique prend le relais. Aucun déploiement nécessaire pour le changement.

Cela vous donne le contrôle sur le moment où les utilisateurs commencent à utiliser une fonctionnalité. Vous pouvez déployer quand vous voulez sans craindre que les utilisateurs soient immédiatement impactés par du travail inachevé. Vous pouvez tester la fonctionnalité en production avec un ensemble limité d'utilisateurs d'abord. Vous pouvez désactiver une fonctionnalité problématique en quelques secondes sans revenir en arrière sur l'ensemble de l'application.

Ce que les Feature Flags permettent

Une fois les feature flags en place, plusieurs schémas pratiques deviennent possibles.

Déploiement progressif. Au lieu de publier une fonctionnalité à tous les utilisateurs d'un coup, vous pouvez l'activer pour 1 % des utilisateurs, puis 10 %, puis 50 %. Si quelque chose tourne mal à 10 %, vous le détectez avant que cela n'affecte tout le monde. C'est particulièrement utile pour les fonctionnalités difficiles à tester en staging car elles dépendent de schémas de trafic réels ou du volume de données.

Canary releases. Vous pouvez router un petit groupe d'utilisateurs vers la nouvelle fonctionnalité pendant que tous les autres restent sur l'ancien comportement. Surveillez les taux d'erreur, la latence et le comportement des utilisateurs. Si le groupe canary ne montre aucun problème, étendez le déploiement. Si des problèmes apparaissent, désactivez-le immédiatement.

Kill switch. Quand une fonctionnalité cause des problèmes inattendus en production, vous pouvez la désactiver instantanément. Pas besoin de revert les commits, pas besoin de rebuild et de redéployer. Il suffit de basculer le flag. Cela réduit la pression sur l'équipe car vous savez que vous pouvez toujours couper rapidement.

Tester en production. Cela semble risqué, mais c'est en fait plus sûr que l'alternative. Avec les feature flags, vous pouvez activer une fonctionnalité d'abord pour les utilisateurs internes ou les bêta-testeurs. Ils exercent la fonctionnalité avec des données et des workflows réels. Vous détectez les problèmes avant que la fonctionnalité n'atteigne la base d'utilisateurs plus large.

Publications coordonnées. Parfois, une fonctionnalité doit être mise en ligne à un moment précis pour des raisons commerciales. Peut-être que l'équipe marketing a prévu une campagne. Peut-être que la fonctionnalité est liée à une échéance réglementaire. Avec les feature flags, vous pouvez déployer le code des jours ou des semaines à l'avance et l'activer au moment exact où il doit être disponible.

Le coût des Feature Flags

Les feature flags ne sont pas gratuits. Ils ajoutent de la complexité à votre codebase. Chaque flag introduit une branche conditionnelle qui doit être testée. Si les flags s'accumulent au fil du temps, le code devient plus difficile à lire et à maintenir. Les anciens flags toujours activés ou toujours désactivés créent des chemins de code morts qui confondent les futurs développeurs.

Il y a aussi le coût opérationnel. Vous avez besoin d'un moyen de gérer les configurations de flags dans tous les environnements. Vous devez décider si les flags sont évalués au niveau du serveur, au niveau de l'utilisateur, ou à une autre granularité. Vous devez vous assurer que les changements de flags se propagent rapidement et de manière fiable.

L'erreur la plus courante que les équipes commettent est de traiter les feature flags comme permanents. Un flag doit avoir un cycle de vie clair : il est introduit pour un objectif spécifique, il reste actif pendant le déploiement de la fonctionnalité, et il est supprimé une fois que la fonctionnalité est entièrement publiée et stable. Les flags qui restent dans le code pour toujours deviennent une dette technique.

Checklist pratique pour utiliser les Feature Flags

Si vous décidez d'adopter les feature flags, voici une courte checklist pour garder les choses sous contrôle :

• Commencez par une implémentation simple. Un fichier de configuration JSON ou une variable d'environnement suffit pour les petites équipes. Évitez de sur-ingénier le système de flags avant de comprendre vos besoins.
• Nommez les flags clairement. Utilisez des noms qui décrivent la fonctionnalité, pas le détail d'implémentation. fast_search est mieux que search_v2_algorithm.
• Supprimez les flags après que la fonctionnalité est stable. Fixez un rappel ou créez un ticket pour nettoyer le code du flag une fois le déploiement terminé.
• Testez les deux états du flag. Assurez-vous que vos tests couvrent le comportement quand le flag est activé et quand il est désactivé. Un flag qui casse l'ancien chemin de code est pire que pas de flag du tout.
• Enregistrez les évaluations de flags. Lors du débogage de problèmes de production, vous devez savoir quels flags étaient actifs pour quels utilisateurs à quel moment.
• Limitez le nombre de flags actifs. Trop de flags rendent le code difficile à raisonner. Si vous avez des dizaines de flags actifs en même temps, demandez-vous si vous utilisez des flags pour des choses qui devraient être de la configuration permanente.

À retenir

La prochaine fois que votre équipe termine une fonctionnalité, posez cette question : "Le code est-il déployé, ou la fonctionnalité est-elle publiée ?" Si la réponse est la même par défaut, vous passez à côté d'une opportunité de livrer plus sûrement et avec moins de stress. Les feature flags vous donnent la capacité de séparer ces deux événements. Ils vous permettent de déployer selon votre calendrier et de publier quand vous êtes prêt. Commencez par un flag pour votre prochaine fonctionnalité risquée. Voyez comment cela change la façon dont votre équipe pense à la livraison.