Stratégies de déploiement : blue-green, canary, rolling

Choisir une stratégie de déploiement revient à décider comment remplacer une version en production par la suivante sans casser le service. Cette page dresse le panorama complet des méthodes utilisées en 2026 : recreate, rolling update, blue-green, canary, shadow, feature flags et progressive delivery. Pour chacune, vous verrez le principe, un exemple concret, ainsi que ses forces et ses limites. Elle s'adresse aux développeurs et ops débutants ou intermédiaires qui veulent arrêter de déployer à l'aveugle. Vous y trouverez aussi une matrice de décision et le vrai point dur du sujet : les migrations de base de données.

Ce que vous allez apprendre

• Distinguer les grandes familles de stratégies et leur vocabulaire exact.
• Choisir la méthode adaptée à votre downtime, votre budget et votre observabilité.
• Différencier un canary technique d'un A/B testing produit.
• Gérer une migration de schéma sans interruption avec le pattern expand-contract.
• Outiller vos rollouts avec Kubernetes, Argo Rollouts, Flagger ou Spinnaker.
• Éviter les anti-patterns classiques qui transforment un déploiement en incident.

Recreate (Big Bang) : arrêt puis redémarrage, downtime assumé

La stratégie recreate, aussi appelée Big Bang, arrête toutes les instances de l'ancienne version, puis démarre la nouvelle. Entre les deux, l'application est indisponible. C'est la méthode la plus simple à comprendre et à opérer, car il n'existe jamais deux versions en parallèle : aucun risque de comportement mixte, aucune contrainte de compatibilité entre anciennes et nouvelles instances.

Le prix à payer est un downtime proportionnel au temps de démarrage. Prenez un outil de facturation interne utilisé uniquement en journée : le déployer à 3h du matin avec un recreate coûte quelques minutes d'indisponibilité que personne ne remarque. En revanche, appliquer un recreate sur une boutique en ligne en pleine journée revient à afficher une page d'erreur à tous les clients pendant le redémarrage. Réservez donc cette stratégie aux applications non critiques, aux environnements de test, ou aux cas où une migration lourde interdit de toute façon la cohabitation de deux versions.

Rolling update : remplacement progressif par lots

Le rolling update remplace les instances par petits lots plutôt qu'en une fois. Kubernetes tue quelques anciens pods, en démarre autant de nouveaux, attend qu'ils soient prêts, puis recommence jusqu'à ce que toute la flotte tourne en nouvelle version. C'est la stratégie par défaut d'un Deployment Kubernetes, et elle offre un déploiement sans interruption tant que l'application supporte que deux versions tournent côte à côte quelques minutes.

Deux paramètres pilotent le rythme. Le maxUnavailable fixe combien de pods peuvent manquer à l'appel pendant l'opération, et le maxSurge combien de pods supplémentaires peuvent être créés au-dessus du nombre désiré. Leur valeur par défaut est de 25% chacun, exprimable en nombre absolu (par exemple 2) ou en pourcentage. Ils ne peuvent pas valoir zéro simultanément, sinon Kubernetes n'aurait aucune marge pour progresser. Pour un service à 8 réplicas, maxSurge: 2 et maxUnavailable: 0 garantissent qu'aucune capacité n'est perdue pendant la mise à jour, au prix de deux pods temporaires en plus.

Le rolling update a une faiblesse : pendant la transition, les utilisateurs frappent indifféremment l'ancienne ou la nouvelle version. Si la nouvelle est boguée, la régression se répand progressivement, et le rollback consiste à relancer un rolling update inverse, ce qui prend du temps. Pour le détail des paramètres, du progressDeadlineSeconds et des rollbacks, voyez le guide dédié aux rolling updates et rollbacks Kubernetes.

Blue-Green : deux environnements identiques, bascule instantanée

Le blue-green consiste à maintenir deux environnements complets et identiques. Le bleu sert la production, le vert reçoit la nouvelle version. Une fois le vert testé et validé sans trafic réel, vous basculez le routeur ou le load balancer pour envoyer 100% du trafic vers le vert d'un seul coup. L'ancien bleu reste allumé quelques heures, prêt à reprendre le service.

L'atout majeur est le rollback immédiat : si le vert dérape, vous rebasculez vers le bleu en une commande, sans reconstruire ni redémarrer quoi que ce soit. La bascule étant atomique, il n'y a pas de fenêtre où deux versions servent le même utilisateur. Imaginez une API bancaire : vous déployez la v2 sur le vert, vous lancez votre suite de tests de bout en bout contre lui, puis vous basculez à 9h en toute confiance, avec un filet de sécurité qui ramène à la v1 en secondes.

Le défaut est évident : vous payez un coût d'infrastructure doublé pendant la fenêtre de cohabitation, puisqu'il faut faire tourner deux flottes complètes. Sur des dizaines de services, cette facture n'est pas neutre. Le blue-green suppose aussi que la base de données soit compatible avec les deux versions en même temps, un point traité plus bas.

Canary : un peu de trafic réel, puis élargissement progressif

Le canary tire son nom des canaris que les mineurs emportaient au fond pour détecter les gaz. On expose la nouvelle version à un petit pourcentage du trafic réel, typiquement 5%, pendant que le reste continue sur l'ancienne. On surveille les métriques (taux d'erreurs HTTP, latence, saturation), et si tout va bien on élargit par paliers : 5%, puis 25%, 50%, enfin 100%. Au moindre signal négatif, on annule et le rayon d'impact reste minuscule.

L'exemple parlant est un site à fort trafic. Vous routez 5% des visiteurs vers la v2 d'un microservice de recherche. Au bout de dix minutes, le taux d'erreur 500 de la v2 est comparable à la v1 et la latence p99 reste sous votre seuil : vous montez à 25%. Si à l'inverse les erreurs grimpent, seuls 5% des utilisateurs ont été touchés, et vous coupez. Le canary limite donc le rayon d'explosion d'une mauvaise version bien mieux qu'un rolling update.

En contrepartie, le canary exige un routage fin du trafic (via un service mesh ou un ingress capable de pondérer) et surtout une observabilité capable de dire, en quelques minutes, si la nouvelle version se comporte bien. Sans métriques fiables, un canary n'est qu'un rolling update déguisé. Pour poser les bases de cette surveillance, appuyez-vous sur le guide observabilité et sur les SLO, SLI et error budget qui donnent les seuils de décision.

A/B testing : router par cohorte pour une décision produit

L'A/B testing ressemble techniquement au canary, mais son objectif est radicalement différent. Ici on ne cherche pas à valider qu'une version ne régresse pas, on cherche à savoir quelle variante fonctionnelle performe le mieux auprès des utilisateurs. On route des cohortes (par pays, par segment, par tirage aléatoire) vers des variantes A et B qui proposent, par exemple, deux libellés de bouton d'achat différents.

La distinction est cruciale. Le canary observe des métriques système et vise une décision technique de mise en production. L'A/B testing observe des métriques business comme le taux de conversion ou le panier moyen, et vise une décision produit portée par les équipes marketing ou product. Un test A/B peut durer des semaines pour atteindre une significativité statistique, là où un canary se conclut en minutes. Confondre les deux mène à de mauvaises décisions : on ne coupe pas une variante parce qu'elle a 0,1% d'erreurs en plus, on la coupe parce qu'elle convertit moins bien.

Shadow / dark traffic : dupliquer sans impact utilisateur

Le shadow traffic (ou dark traffic) consiste à dupliquer le trafic de production vers la nouvelle version, sans jamais renvoyer ses réponses aux utilisateurs. La v1 répond réellement, pendant que la v2 reçoit une copie des requêtes et travaille dans l'ombre. Vous comparez alors les réponses et les performances des deux versions sur du trafic réel, sans exposer un seul client au risque.

C'est idéal pour valider une réécriture lourde. Supposons que vous remplaciez un moteur de recommandation par une version réécrite : le shadow vous permet de vérifier que la v2 tient la charge de production et renvoie des résultats cohérents, avant de lui confier le moindre client. Le piège majeur concerne les écritures. Si la requête dupliquée déclenche un débit de carte, un envoi d'email ou une insertion en base, le shadow provoque des effets de bord réels en double. Il faut donc soit se limiter aux appels en lecture seule, soit rediriger les écritures de la v2 vers une base isolée ou des mocks.

Feature flags / dark launching : découpler déploiement et activation

Les feature flags (ou feature toggles) sont des interrupteurs dans le code qui activent ou désactivent une fonctionnalité sans redéployer. Le principe déplace le curseur : déployer du code et activer une fonctionnalité deviennent deux gestes distincts. On parle de dark launching quand une fonctionnalité est livrée en production éteinte, prête à être allumée pour une fraction d'utilisateurs quand l'équipe le décide.

Le bénéfice est énorme sur le risque. Vous fusionnez et déployez du code inachevé derrière un flag désactivé, sans jamais l'exposer. Le jour du lancement, vous activez la fonctionnalité pour 1% des comptes internes, puis pour tous, d'un simple changement de configuration. En cas de problème, vous éteignez le flag en secondes, ce qui est un rollback logique bien plus rapide qu'un redéploiement. Cette technique s'articule naturellement avec les workflows Git fondés sur des branches courtes, puisqu'elle permet d'intégrer souvent sans attendre qu'une fonctionnalité soit finie.

Attention

Chaque flag est une dette technique en sursis. Un flag oublié multiplie les chemins d'exécution et rend le code illisible. Datez vos flags, tracez qui les possède et supprimez-les dès que la fonctionnalité est stabilisée.

Progressive delivery : canary automatisé avec rollback sur métriques

La progressive delivery est l'aboutissement automatisé du canary. Elle combine un déploiement canary, des feature flags et surtout un rollback automatique piloté par l'analyse des métriques. Au lieu qu'un humain surveille un tableau de bord et décide d'élargir ou de couper, un contrôleur applique une stratégie déclarative : il monte le trafic par paliers, interroge Prometheus à chaque étape, et annule tout seul si le taux d'erreur dépasse le seuil.

Deux outils dominent sur Kubernetes. Argo Rollouts remplace la ressource Deployment par une ressource Rollout personnalisée, dans laquelle vous décrivez les paliers (setWeight: 5, pause, analyse, setWeight: 25) et les requêtes d'analyse. Flagger prend l'approche inverse : il pilote vos Deployments existants sans changer vos manifestes, en s'appuyant sur un service mesh ou un ingress pour répartir le trafic, et il automatise l'analyse et la promotion. Le résultat commun est un rollout qui se gouverne seul : une régression détectée déclenche un retour arrière avant qu'un humain n'ait ouvert son écran.

Comment choisir sa stratégie : matrice de décision

Aucune stratégie n'est universellement supérieure. Le bon choix dépend de votre contexte, que l'on peut réduire à cinq questions : quel downtime puis-je tolérer, quelle vitesse de rollback m'est nécessaire, quel coût d'infrastructure puis-je payer, mon application est-elle avec état (stateful) ou sans état, et quelle observabilité ai-je réellement en place. Lisez la matrice comme un filtre : partez de la contrainte la plus forte pour votre service, elle élimine souvent la moitié des options.

Stratégie	Downtime	Rollback	Coût infra	Stateful	Observabilité requise
Recreate	Oui	Lent	Faible	Toléré	Faible
Rolling update	Non	Moyen	Faible	Sensible	Moyenne
Blue-Green	Non	Instantané	Doublé	Sensible	Moyenne
Canary	Non	Rapide	Modéré	Sensible	Élevée
Progressive delivery	Non	Automatique	Modéré	Sensible	Très élevée

Glissez pour voir

Concrètement, un outil interne sans enjeu se contente d'un recreate nocturne. Une API publique standard démarre très bien en rolling update, le défaut Kubernetes. Un service critique avec exigence de rollback en secondes justifie le blue-green malgré son coût. Un produit à fort trafic doté d'une observabilité mature gagne à passer au canary, puis à la progressive delivery. La mention stateful rappelle qu'une application avec état, une base ou une file, complique toutes ces stratégies, ce qui nous amène au vrai point dur. Ces choix se mesurent ensuite avec les métriques DORA, notamment la fréquence de déploiement et le taux d'échec des changements.

Le point dur : les migrations de base de données

La vérité que les schémas cachent est simple : on ne rollback pas une base de données comme on rollback un conteneur. Si votre nouvelle version supprime une colonne et que vous devez revenir en arrière, l'ancienne version cherchera une colonne qui n'existe plus. Toute stratégie de déploiement sans interruption suppose donc que ancienne et nouvelle version du code coexistent avec le même schéma pendant la transition. La solution est de rendre chaque changement rétrocompatible grâce au pattern expand-contract, aussi nommé parallel change.

1. Expand : vous ajoutez le nouveau sans toucher à l'ancien. Pour renommer une colonne email en contact_email, vous créez contact_email à côté, sans supprimer email. Le schéma accepte désormais les deux versions du code.

2. Migrate : vous déployez un code compatible qui écrit dans les deux colonnes et lit la nouvelle, puis vous copiez les données existantes de email vers contact_email. À ce stade, l'ancienne et la nouvelle version tournent sans se casser.

3. Contract : une fois toutes les instances passées en nouvelle version et les données migrées, un déploiement ultérieur supprime enfin la colonne email devenue inutile.

La règle d'or est de ne jamais faire une modification destructive dans le même déploiement que le code qui en dépend. Un renommage, une suppression de colonne ou un changement de type se découpent toujours en plusieurs déploiements successifs, chacun rétrocompatible avec le précédent. Cette discipline est ce qui rend réellement possibles le blue-green et le canary, car elle garantit qu'un rollback applicatif ne rencontre jamais un schéma incompatible.

Outillage

Les stratégies décrites plus haut ne s'implémentent pas à la main en production. Kubernetes couvre nativement le recreate et le rolling update via le champ strategy d'un Deployment, et gère les rollbacks avec kubectl rollout undo. C'est le socle sur lequel tout le reste s'appuie, détaillé dans le guide kubectl scale, autoscale, rollout et set. Pour un simple rolling update maîtrisé, Kubernetes seul suffit largement.

Dès que vous voulez du canary automatisé ou du blue-green piloté par métriques, il faut monter d'un cran. Argo Rollouts introduit une ressource Rollout déclarative avec analyse intégrée, idéale si vous êtes déjà sur ArgoCD et le GitOps. Flagger automatise les mêmes stratégies en pilotant vos Deployments existants sans réécrire vos manifestes, et s'intègre bien avec Flux et un service mesh. Spinnaker, plus lourd et multi-cloud, propose le blue-green et un canary analysis automatisé via son composant Kayenta, pour des organisations aux besoins de déploiement complexes. Ces outils se branchent en aval d'un pipeline CI/CD qui construit et teste l'artefact avant de déclencher le rollout.

Anti-patterns

Connaître les stratégies ne suffit pas si l'on répète les erreurs classiques qui les vident de leur sens. Les trois ci-dessous reviennent dans presque tous les incidents de déploiement, et chacune trahit une confiance mal placée dans l'automatisation ou dans la chance.

Le premier est le Big Bang le vendredi. Déployer une grosse mise à jour en fin de semaine, sans stratégie progressive, concentre le risque au pire moment : l'équipe part, l'astreinte hérite d'un incident sans contexte, et le rollback attend le lundi. Déployez tôt dans la journée et tôt dans la semaine, quand les personnes qui ont écrit le code sont encore là.

Le deuxième est le canary sans métriques. Router 5% du trafic vers une nouvelle version puis élargir au feeling, sans seuil d'erreur ni de latence défini, n'est pas un canary : c'est un rolling update lent qui donne une fausse impression de sécurité. Un canary n'a de valeur que si des métriques mesurables déclenchent la décision d'élargir ou de couper.

Le troisième est le rollback non testé. Beaucoup d'équipes documentent une procédure de retour arrière qu'elles n'ont jamais exécutée. Le jour de l'incident, elles découvrent que le rollback casse la base, qu'une migration est irréversible, ou que la commande a changé. Un rollback se répète régulièrement en préproduction, exactement comme une sauvegarde ne vaut que si sa restauration est testée.

À retenir

• Une stratégie de déploiement arbitre entre downtime, vitesse de rollback, coût d'infrastructure, statefulness et observabilité.
• Le recreate assume une interruption, réservé aux applications non critiques.
• Le rolling update est le défaut Kubernetes, piloté par maxSurge et maxUnavailable (25% chacun par défaut).
• Le blue-green offre un rollback instantané au prix d'un coût d'infrastructure doublé.
• Le canary limite le rayon d'impact mais exige une observabilité solide et un routage fin du trafic.
• L'A/B testing est une décision produit sur des métriques business, à ne pas confondre avec le canary technique.
• La progressive delivery automatise le canary avec rollback sur métriques via Argo Rollouts ou Flagger.
• Les migrations de base de données imposent le pattern expand-contract pour rester rétrocompatibles.

FAQ : questions fréquentes

Qu'est-ce qu'une stratégie de déploiement ?

Une stratégie de déploiement est la méthode qui décrit comment remplacer une version en production par une nouvelle : recreate, rolling update, blue-green, canary ou progressive delivery. Chacune arbitre entre downtime, rapidité de rollback, coût d'infrastructure et niveau de surveillance requis.

Quelle est la différence entre blue-green et canary ?

Le blue-green bascule tout le trafic d'un coup d'un environnement complet à un autre, avec rollback instantané mais coût doublé. Le canary envoie d'abord un petit pourcentage du trafic réel vers la nouvelle version, puis élargit progressivement en surveillant les métriques, sans dupliquer toute l'infrastructure.

Quelle stratégie de déploiement choisir ?

Choisissez selon quatre critères : le downtime toléré, la vitesse de rollback voulue, le budget d'infrastructure et l'observabilité disponible. Rolling update par défaut sur Kubernetes, blue-green pour un rollback instantané, canary pour limiter le rayon d'impact d'une régression, recreate seulement si l'interruption est acceptée.

Comment déployer sans casser la base de données ?

Utilisez le pattern expand-contract : d'abord ajouter les nouvelles colonnes ou tables sans toucher aux anciennes (expand), déployer le code compatible avec les deux schémas, migrer les données, puis supprimer l'ancien schéma dans un déploiement ultérieur (contract). Chaque étape reste rétrocompatible avec la version précédente du code.

Qu'est-ce que la progressive delivery ?

La progressive delivery combine un déploiement canary, des feature flags et un rollback automatique déclenché par l'analyse des métriques. Des outils comme Argo Rollouts et Flagger orchestrent l'élargissement du trafic et annulent la mise à jour si le taux d'erreur ou la latence dépassent un seuil défini.

Le canary et l'A/B testing sont-ils la même chose ?

Non. Le canary est une décision technique : valider qu'une nouvelle version ne régresse pas en la testant sur une fraction du trafic. L'A/B testing est une décision produit : router des cohortes d'utilisateurs vers des variantes fonctionnelles pour mesurer laquelle convertit le mieux. L'un surveille des métriques système, l'autre des métriques business.

Prochaines étapes

Trunk-Based Development Le modèle de branches qui débloque l'intégration continue.

Feature flags Découpler le déploiement de l'activation pour livrer sans risque.

CI/CD de bout en bout Le pipeline qui construit, teste et livre l'artefact avant tout déploiement.

GitOps Piloter les déploiements par l'état déclaré dans Git, socle d'Argo et Flux.

Rolling updates et rollbacks Kubernetes Les paramètres, progressDeadlineSeconds et rollbacks en pratique.

kubectl scale, autoscale, rollout, set Le guide opérationnel des commandes de mise à jour progressive.

SLO, SLI et error budget Définir les seuils qui pilotent un canary et arbitrent un rollback.

Métriques DORA Mesurer l'effet de vos stratégies sur la fréquence et la fiabilité des déploiements.

×

📖 Voir la documentation →