Pourquoi déployer à 100% est un piège
La plupart des équipes déploient à 100% des utilisateurs dès le premier jour. La raison est pragmatique : les environnements de staging ne reproduisent pas la charge de production, les bêta-testeurs ne se comportent pas comme les vrais utilisateurs, et maintenir deux chemins de code parallèles ajoute de la complexité.
Le problème, c'est que la production est le seul environnement où vous découvrez ce que vous avez manqué. Et au moment où vous savez que quelque chose cloche, 100% de vos utilisateurs sont déjà impactés.
Les déploiements progressifs inversent ce compromis. Vous exposez une tranche contrôlée de trafic au nouveau code, observez un comportement réel sous charge réelle, et ne progressez que lorsque vous avez confiance.
L'échelle de déploiement
Une échelle de déploiement typique ressemble à ceci :
| Étape | Audience | Objectif |
|---|---|---|
| 0,1% | Équipe interne | Détecter les crashes évidents avant toute exposition externe |
| 1% | Utilisateurs canary | Valider sous charge réelle, détecter les régressions de performance |
| 10% | Adopteurs précoces | Collecter des signaux comportementaux, valider les métriques |
| 50% | Majorité | Vérification finale avant exposition complète |
| 100% | Tout le monde | Le flag devient la valeur par défaut, le code peut être nettoyé |
Chaque étape a une porte : vous n'avancez que si vos métriques clés tiennent.
Ce qu'il faut mesurer à chaque étape
Les métriques importantes dépendent de ce que la fonctionnalité touche. Un tunnel de checkout a des modes de défaillance différents d'un algorithme de recommandation. Mais il y a des signaux universels à surveiller :
Taux d'erreur — votre taux d'erreur p99 à 1% ne doit pas diverger significativement de la baseline. Si c'est le cas, arrêtez.
Latence — surveillez p95 et p99, pas seulement la moyenne. Les moyennes masquent les régressions de latence en queue de distribution.
Métriques business — taux de conversion, rétention, revenu par session, selon ce que la fonctionnalité est censée influencer.
Charge infra — CPU, mémoire, nombre de requêtes en base. Les nouvelles fonctionnalités introduisent souvent des requêtes N+1 invisibles en staging.
Le bucketing déterministe est essentiel
Un déploiement n'est significatif que si le même utilisateur reçoit systématiquement la même expérience. Si un utilisateur voit le nouveau checkout sur un chargement de page et l'ancien sur le suivant, vos métriques sont du bruit.
Signal utilise un bucketing déterministe par hash :
bucket = hash(userId + flagKey) % 100
Le même ID utilisateur mappe toujours vers le même bucket. Pas de sessions, pas de routage sticky, pas d'affinité serveur. Cela fonctionne sur plusieurs instances, des fonctions serverless et un scaling horizontal de pods.
Combiner déploiement progressif et ciblage
Le déploiement progressif et les règles de ciblage se composent. Vous pouvez déployer à 10% des utilisateurs — mais uniquement ceux sur le plan enterprise :
const enabled = await signal.isEnabled('checkout-v2', {
userId: user.id,
plan: user.plan,
country: user.country,
});Cela permet une exposition progressive au sein d'un segment spécifique — publier une fonctionnalité aux clients enterprise avant le tier gratuit, ou à une région spécifique avant un déploiement global.
Quand marquer une pause (et quand rollback)
Marquer une pause n'est pas un échec. C'est le signal qui fonctionne comme prévu.
Rollback immédiat si :
- Le taux d'erreur augmente de plus de 1-2% par rapport à la baseline
- La latence p99 augmente significativement
- Une métrique business critique chute de façon statistiquement significative
Pause et investigation si :
- Les métriques évoluent dans la mauvaise direction mais le changement est faible
- Vous voyez des patterns anormaux dans les logs qui ne se reflètent pas encore dans les agrégats
- Les coûts d'infrastructure sont plus élevés que prévu
Le rollback de Signal est un basculement de flag — il prend effet en moins de 50ms sur toutes les instances connectées. Pas de redéploiement, pas de bridge d'incident, pas de commit de rollback.
Nettoyer après le ship
Une fois qu'une fonctionnalité atteint 100% et a été stable pendant un cycle de release, le flag est du code mort. Supprimez-le.
Les flags morts s'accumulent vite. Une base de code avec des centaines de flags permanents devient illisible. La discipline de traiter la suppression du flag comme faisant partie du cycle de la fonctionnalité est aussi importante que la stratégie de déploiement elle-même.