Initial vault setup

concepts/deploiement-canary.md

@@ -0,0 +1,55 @@
+---
+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 ?