Stratégies de déploiement : rolling, canary, multi-cloud

Déployer sans couper : les stratégies

Remplacer la version N par N+1 pendant que des utilisateurs sont là — sans blanc, sans erreur 500 :

• rolling update (le défaut Kubernetes / serverless) : on remplace les instances progressivement, l'ancienne sert jusqu'à ce que la nouvelle soit ready. Prérequis : un readiness probe honnête (« le modèle est chargé, la DB répond ») distinct du liveness — servir avant d'être prêt = 500 pendant le rollout ;
• blue-green : deux environnements complets, on bascule le trafic d'un coup (rollback = re-bascule instantanée) ;
• canary : la nouvelle version reçoit d'abord X % du trafic, on surveille les métriques, on élargit si sain (le champion/challenger du cours ML monitoring, appliqué au déploiement) ;
• shadow : la nouvelle version reçoit une copie du trafic sans servir les réponses — mesurer sans risque (on l'a vu pour valider un modèle).

Compagnon indispensable des deux derniers : le feature flag, qui découple déployer le code de l'activer — le code part en prod éteint, on l'allume progressivement. (Nuance : le projet étudié a fait le choix inverse assumé — « pas de feature flag, pas de futurisme » — parce que son cycle est court et son équipe petite. Le bon choix dépend du contexte.)

Le déploiement multi-cloud (le cas réel)

Le projet copilot déploie l'API sur AWS (ECR/ECS) et le front sur GCP (Cloud Run) — deux clouds pour une app. Pourquoi ce n'est pas de la folie :

1. chaque composant sur le cloud qui l'exécute le mieux (ou le moins cher, ou là où l'équipe a l'expertise) ;
2. des cycles de release découplés : le front et l'API se livrent indépendamment, à leur rythme ;
3. reliés par un contrat clair (l'API HTTP) et un dépôt de changelogs de déploiement qui trace ce qui tourne où (avec ArgoCD côté prod pour réconcilier l'état désiré).

Le prix : deux chaînes de déploiement à maîtriser, deux consoles, une observabilité à agréger. Un choix qui se justifie par composant, pas par principe.

La release comme décision consciente

Détail culturel important : chez le projet étudié, la mise en prod est un bouton manuel (release:api crée le tag, déclenche la chaîne), pas un push automatique. Sur un produit B2B, on choisit quand embarquer quoi — la CI garantit que c'est mergeable, l'humain décide que c'est le moment. C'est le tien aussi, dans tes skills de MEP : la CI dit « vert », toi tu dis « go ».