---
title: Déploiement Canary
created: 2026-06-06
updated: 2026-06-06
type: concept
tags: [devops, architecture, tech]
confidence: high
contested: false
sources: [synthesized]
---
# 🐤 Déploiement Canary

## Définition Courte
Stratégie qui **déploie progressivement** une nouvelle version à un petit pourcentage d'utilisateurs (les "canaris"), surveille les métriques, puis étend si tout va bien.

## Explication Détaillée
**Étapes typiques** :
1. Déployer la v2 sur 1% du parc.
2. Surveiller pendant X minutes (erreurs, latence, CPU).
3. Si OK, étendre à 10%, 25%, 50%, 100%.
4. Si problème à une étape, rollback instantané.
5. Une fois à 100%, décommissionner la v1.

**Critères d'analyse** :
- Taux d'erreur 5xx.
- Latence p95/p99.
- Métriques métier (conversion, rétention).
- CPU/RAM inhabituel.

**Comparaison** :
- **Blue-Green** : tout bascule d'un coup.
- **Canary** : bascule progressive, plus granulaire.
- **Feature Flags** : contrôle par user, pas par % global.

## Cas d'Usage
- Apps à fort trafic où un bug toucherait beaucoup d'utilisateurs.
- Refonte majeure (changement d'architecture).
- Modèles ML (peut-être que la nouvelle version dégrade la qualité).

## Outils Liés
- **Kubernetes** : Argo Rollouts, Flagger.
- **Istio** : traffic shifting basé sur poids.
- **AWS CodeDeploy**, **Google Cloud Deploy**.
- **LaunchDarkly**, **Flagsmith** (feature flag services).

## Pages Liées
- [[deploiement-blue-green]]
- [[feature-flags]]
- [[ci-cd]]
- [[observabilite]]
- [[chaos-engineering]]

## Questions Ouvertes
- Combien de temps faut-il observer à chaque étape ?
- Comment choisir le critère de promotion automatique vs manuel ?