Qu'est-ce qu'un feature rollout ?

Qu'est-ce qu'un feature rollout ?

Un feature rollout (déploiement progressif d'une fonctionnalité) consiste à la livrer aux utilisateurs par étapes plutôt qu'à tous en même temps. On commence par l'équipe ou une petite part du trafic, on surveille le taux d'erreurs, la latence et les indicateurs métier, et on n'élargit l'audience que tant que tout reste sain. Cela sépare le déploiement du code de la mise en production de la fonctionnalité : un problème touche 1 % des utilisateurs et non 100 %, et la correction est souvent un interrupteur, pas un nouveau déploiement.

Stratégies courantes

• Déploiement par pourcentage : on active la fonctionnalité pour 1 %, puis 10 %, 25 %, 50 % et 100 % des utilisateurs, avec une pause à chaque palier. Généralement réalisé avec des feature flags.
• Canary release : une petite part du trafic va vers la nouvelle version, qui tourne à côté de l'ancienne. Martin Fowler décrit le retour arrière comme un simple réacheminement des utilisateurs vers l'ancienne version. Voir le guide du déploiement canary (en anglais).
• Déploiement par cercles : la livraison se fait par cercles d'utilisateurs successifs, par exemple l'équipe interne, puis les testeurs bêta, puis tout le monde.
• Déploiement blue/green : deux environnements en parallèle, et tout le trafic bascule de l'un à l'autre. Ce n'est pas progressif, mais le retour arrière est rapide. Le plus délicat reste le schéma de base de données : livrez-le séparément et gardez-le compatible avec les deux versions.
• Dark launch : le nouveau code s'exécute en production mais son résultat reste caché aux utilisateurs, ce qui permet d'observer la charge et le comportement avant que quiconque le voie.
• Test A/B : deux variantes en parallèle pour mesurer l'effet sur un indicateur. Il répond à « laquelle est la meilleure », pas à « est-ce sûr ».

Un exemple pas à pas

1. On fusionne le nouveau tunnel de paiement derrière un flag désactivé pour tous.
2. On l'active pour sa propre équipe et on observe pendant une journée.
3. On passe à 5 % des utilisateurs. On compare taux d'erreurs, paiements finalisés et temps de réponse p95 entre les deux groupes.
4. Si les chiffres tiennent, on passe à 25 %, 50 % puis 100 %, avec une attente à chaque palier adaptée à la vitesse à laquelle les problèmes apparaîtraient.
5. Si les erreurs ou la latence bondissent à un palier, on remet le flag à 0 % et on enquête.
6. Après une période stable à 100 %, on supprime le flag et l'ancien chemin de code.

Erreurs courantes

• Aucun critère de réussite. Décidez à l'avance quels indicateurs doivent rester dans quelles limites et qui les surveille.
• Avancer sur un calendrier. Un calendrier sans surveillance ne fait que ralentir le bug.
• Utilisateurs qui alternent entre ancien et nouveau. Utilisez une affectation persistante (sticky bucketing) pour qu'un utilisateur garde la même variante d'une session à l'autre.
• Un retour arrière qui n'est pas vraiment possible. Une migration de données exécutée derrière le flag peut ne pas être réversible. Planifiez d'abord le chemin des données, puis celui du code.
• Des flags oubliés. Chaque flag a besoin d'un responsable et d'une date de suppression.
• État désactivé jamais testé. Si l'ancien chemin est cassé, revenir en arrière ne vous sauve pas.

Feature rollouts, tests de charge et supervision

Un rollout valide un changement auprès de vrais utilisateurs, mais ce ne devrait pas être la première fois que le nouveau chemin rencontre un vrai volume de trafic. Faites un test de charge du nouveau chemin avant le premier palier. LoadFocus exécute des tests JMeter et k6 depuis 25 régions cloud, et le forfait gratuit comprend jusqu'à 10 utilisateurs virtuels. Pendant le rollout, la surveillance d'API continue de vérifier code de statut, corps et temps de réponse à intervalle régulier (toutes les 5 minutes dans le forfait gratuit), de sorte qu'une régression apparaît tant qu'un retour arrière reste peu coûteux. Voir la surveillance d'API LoadFocus.

Questions fréquentes sur les feature rollouts

Quelle différence entre feature rollout et feature flag ?

Le rollout est le processus de livraison par étapes. Un feature flag est un outil courant pour le réaliser, car il permet de changer qui voit une fonctionnalité sans déployer de code. On peut aussi faire un rollout avec du routage canary ou des cercles, sans flags.

Quelle différence entre canary et blue/green ?

Un canary release bascule les utilisateurs progressivement vers la nouvelle version. Le blue/green garde deux environnements complets et bascule tout le trafic d'un coup, l'ancien environnement servant de retour arrière rapide.

Combien de temps doit durer un rollout ?

Cela dépend du risque et du trafic. Il faut assez de trafic à chaque palier pour voir un problème : les fonctionnalités peu utilisées demandent donc des paliers plus longs. Les changements sensibles, comme les paiements ou les migrations de données, méritent des paliers plus petits et des attentes plus longues.

Que surveiller pendant un rollout ?

Le taux d'erreurs, les percentiles de latence et un ou deux indicateurs métier, comparés entre variante nouvelle et ancienne plutôt que seulement au global. Les alertes doivent être en place avant le premier palier.

Faut-il déployer progressivement toutes les fonctionnalités ?

Non. Les changements de texte et les correctifs à faible risque peuvent partir directement. Réservez les déploiements par étapes aux changements touchant paiements, données, authentification ou chemins très sollicités.