Contexte : Une nouvelle version d'une API doit être testée progressivement sur une portion limitée du trafic en production. Le Problème : Les mises à jour classiques RollingUpdate ne permettent pas de diriger un pourcentage précis du trafic vers la nouvelle version. Contraintes : Utiliser uniquement des objets natifs Kubernetes (Deployment, Service). Aucun outil externe comme service mesh. Livrable attendu : Concevoir une architecture permettant un déploiement canary via deux Deployments distincts et une gestion de répartition contrôlée du trafic.