feat(scale): Helm chart + GitOps deployment + multi-region readiness

[Yanstart]

Cadrage stratégique 2026 (mai 2026) — PIVOT PRODUIT

Sortie du `docker-compose.yml` mono-host pour passer à un déploiement
Kubernetes scalable et reproductible.
Voir `.claude/memory/VISION_ALIGNMENT.md §0.6`.

Contexte

Aujourd'hui : `docker-compose.yml` unifié multi-profile (`core`, `auth`,
`cache`, `pacs`, `fhir`, `monitoring`, `mlops`, `dev`, `prod`). Excellent
pour dev / single-host / customer-zero. Insuffisant pour un produit multi-tenant
servant plusieurs hôpitaux à l'échelle.

Pour un produit, on a besoin de :

1. Helm chart versionné, paramétrable, déployable sur n'importe quel cluster Kubernetes
2. GitOps (ArgoCD / Flux) : changements de config = commit Git, déploiement automatique
3. HPA (Horizontal Pod Autoscaler) : scaling auto sur CPU / RAM / custom metrics
4. Multi-region readiness : architecture qui supporte la réplication géographique
5. Blue-green / canary deployment : rollout progressif sans downtime

Cible

1. Helm chart `charts/varuna/` : un chart unique paramétrable
   • `values.yaml` defaults + `values-dev.yaml`, `values-staging.yaml`, `values-prod.yaml`
   • Configuration multi-tenant : variables par tenant (storage backend, IdP, modèles ML)
2. GitOps repo : `Scripts/Deployment/gitops/` avec ArgoCD Application manifests
3. HPA :
   • Backend : scale 2-20 pods sur CPU + custom metrics (request rate, queue depth ML)
   • Triton : scale 1-N selon GPU utilization
4. Multi-region readiness :
   • Document architectural `docs/architecture/MULTI_REGION.md`
   • Decision tree : single-region master + N read regions, OR active-active multi-master
5. Canary / blue-green :
   • Argo Rollouts OU Flagger pour traffic shifting progressif
   • Métriques de validation automatique (error rate, latency P95)

Approche technique proposée

1. Helm chart :
   • Templates : Deployment, Service, Ingress, ConfigMap, Secret, HPA, NetworkPolicy
   • Hooks : pre-install (DB migration), post-install (smoke test)
   • Sub-charts : PostgreSQL, Redis, Triton (ou external dependencies)
2. GitOps :
   • ArgoCD recommandé (CNCF graduated, GitHub-friendly, écosystème mature)
   • 1 Application par environnement (dev / staging / prod / customer-zero)
3. HPA : metrics-server + Prometheus Adapter pour custom metrics
4. Documentation runbook : `docs/Admin/deployment-kubernetes.md` (provisionnement cluster, install ArgoCD, install chart, monitoring)

Acceptance criteria

• Helm chart fonctionnel `charts/varuna/`
• `helm install` réussit sur kind / minikube en dev
• `helm install` réussit sur cluster cloud (AKS, EKS, GKE) en staging
• HPA configuré pour backend + Triton
• ArgoCD Application manifests pour 4 environnements
• Document architectural `MULTI_REGION.md`
• Canary deployment avec Argo Rollouts (OU équivalent) — démo de rollout 10/50/100%
• Tests : déploiement de zero à running en < 15 min sur cluster vide
• Réversibilité : `helm uninstall` propre, sans laisser de PVC orphelins
• Documentation runbook complète

Dépendances

• Wave 13 feat(scale): multi-tenant data isolation + auth federation #354 (multi-tenant) — values per tenant
• Wave 13 feat(scale): storage S3-compatible + tiering hot/cold + multi-tenant #355 (storage S3) — bucket configuration via Helm
• Wave 13 feat(scale): DB scaling (read replicas + pgbouncer + partitioning + multi-tenant) #356 (DB scaling) — Helm sub-chart PostgreSQL HA
• Wave 13 feat(scale): ML inference scaling (Triton Inference Server + GPU pool + batch + queue) #357 (Triton ML) — Helm Triton deployment
• Wave 13 feat(scale): cache cluster + WebSocket scaling (Redis Sentinel + sticky session + message broker) #359 (cache + WS) — Redis Sentinel via Helm
• Wave 13 feat(scale): observability at scale (OpenTelemetry + log aggregation + multi-tenant SLO) #360 (observability) — sidecar OTel collector via Helm

Références

• `.claude/memory/VISION_ALIGNMENT.md §0.6`
• Helm : https://helm.sh
• ArgoCD : https://argo-cd.readthedocs.io
• Argo Rollouts : https://argoproj.github.io/argo-rollouts/
• 12-factor app : https://12factor.net