Canary deployment

Un canary deployment expose une nouvelle version d’un service à une petite fraction du trafic réel (souvent 5 à 10 % au démarrage) pendant que l’ancienne version continue de servir le reste. La décision de généraliser ou de revenir en arrière se prend sur des métriques observées pendant cette fenêtre, pas sur un simple « ça a démarré sans erreur ».

Ce qui distingue un canary d’un rolling update standard

Un rolling update classique remplace progressivement les instances sans jugement intermédiaire : il avance tant que les nouvelles instances passent leurs probes de santé. Un canary ajoute une étape de décision explicite, généralement automatisée, qui compare des métriques précises (taux d’erreur, latence p99) entre l’ancienne et la nouvelle version avant d’autoriser la suite du déploiement.

Ce qu’un canary ne remplace pas

Un canary réduit le risque du code lui-même, pas celui du moment de sa visibilité : un changement de comportement business (nouveau tarif, nouveau parcours) reste géré par un feature flag, pas par un pourcentage de trafic backend. Les deux mécanismes se combinent souvent, chacun sur sa propre question.