Les stratégies de déploiement
Résumé : mettre une nouvelle version en production peut se faire de cinq façons très différentes, avec des compromis nets entre coût d'infrastructure, risque encouru et rapidité de retour arrière. Cette leçon détaille recreate, rolling update, blue-green, canary release et feature flags, et vous donne une règle claire pour choisir.
1. Le problème à résoudre
Aucune stratégie n'est optimale sur les quatre contraintes. Chacune est un compromis, et c'est précisément pour cela qu'il en existe plusieurs.
2. Stratégie 1 — Recreate (tout arrêter, tout relancer)
| Critère | Évaluation |
|---|---|
| Interruption de service | Oui, complète |
| Rayon d'impact si bug | 100 % des utilisateurs |
| Temps de rollback | Lent (relancer la v1) |
| Coût d'infrastructure | Le plus faible — aucune machine en double |
| Complexité | Très faible |
Quand c'est pertinent : environnements de développement et de recette, applications internes utilisées en horaires de bureau, migrations de base de données incompatibles entre versions (parfois inévitable), applications à faible criticité.
Ne pas rejeter cette stratégie par principe. Pour un outil interne utilisé par 20 personnes en journée, un déploiement recreate à 22h est parfaitement raisonnable — et infiniment plus simple à opérer.
3. Stratégie 2 — Rolling update (remplacement progressif)
C'est la stratégie par défaut de Kubernetes et la plus répandue en 2026.
| Critère | Évaluation |
|---|---|
| Interruption de service | Aucune |
| Rayon d'impact si bug | Croissant — de 33 % à 100 % au fil du déploiement |
| Temps de rollback | Moyen — il faut refaire un rolling en sens inverse |
| Coût d'infrastructure | Faible — une seule instance supplémentaire à la fois |
| Complexité | Faible (native dans Kubernetes) |
Le piège majeur du rolling update : pendant la transition, v1 et v2 coexistent et servent tous deux du trafic. Cela impose une contrainte forte, souvent oubliée :
Ce motif expand and contract (aussi appelé parallel change) est l'une des compétences les plus valorisées en entretien DevOps senior. Beaucoup de candidats connaissent le rolling update mais ignorent cette contrainte.
4. Stratégie 3 — Blue-green (bascule instantanée)
| Critère | Évaluation |
|---|---|
| Interruption de service | Aucune |
| Rayon d'impact si bug | 100 % — mais détecté et annulé en secondes |
| Temps de rollback | Le meilleur — quelques secondes, rebascule du routeur |
| Coût d'infrastructure | Élevé — double infrastructure pendant la transition |
| Complexité | Moyenne |
L'atout décisif du blue-green : c'est la stratégie avec le rollback le plus rapide qui existe. Quand chaque minute d'incident coûte des milliers d'euros, ce coût d'infrastructure doublé se justifie immédiatement.
Sa limite : la base de données. Si bleu et vert partagent la même base (le cas quasi universel), un rollback applicatif ne défait pas une migration de schéma déjà appliquée. Le blue-green protège du bug applicatif, pas du problème de données.
5. Stratégie 4 — Canary release (déploiement progressif mesuré)
Le nom vient des canaris que les mineurs emportaient au fond : l'oiseau, plus sensible aux gaz toxiques, alertait avant que les humains ne soient en danger.
| Critère | Évaluation |
|---|---|
| Interruption de service | Aucune |
| Rayon d'impact si bug | Le meilleur — 1 à 5 % des utilisateurs seulement |
| Temps de rollback | Rapide — quelques secondes de reroutage |
| Coût d'infrastructure | Modéré |
| Complexité | Élevée — exige un routage fin et une observabilité solide |
Le prérequis absolu du canary : une observabilité de qualité. Sans métriques fiables pour comparer objectivement v1 et v2, le canary n'apporte rien — vous exposez 5 % des utilisateurs sans être capable de détecter la dégradation.
Outils qui automatisent le canary en 2026 : Argo Rollouts, Flagger, ou un service mesh comme Istio / Linkerd pour le routage pondéré.
6. Stratégie 5 — Feature flags (découpler déploiement et activation)
Cette approche est d'une nature différente des quatre précédentes : elle ne concerne pas comment le code arrive en production, mais quand la fonctionnalité devient visible.
C'est la clé qui rend le déploiement continu praticable à grande échelle. Facebook, Google et Netflix déploient des centaines de fois par jour précisément parce que déployer ne signifie plus livrer une fonctionnalité aux utilisateurs. Les deux événements sont découplés.
Le coût à connaître : la dette technique des drapeaux. Un flag oublié pendant deux ans devient un chemin de code que plus personne ne comprend et que plus rien ne teste. Discipline indispensable : tout flag doit avoir une date de suppression prévue dès sa création.
Outils courants : LaunchDarkly, Unleash (open source), Flagsmith, OpenFeature (standard CNCF émergent).
7. Le tableau comparatif complet
| Stratégie | Interruption | Rayon d'impact | Rollback | Coût infra | Complexité |
|---|---|---|---|---|---|
| Recreate | Oui | 100 % | Lent | Le plus bas | Très faible |
| Rolling update | Non | Croissant | Moyen | Bas | Faible |
| Blue-green | Non | 100 % (bref) | Le plus rapide | Élevé | Moyenne |
| Canary | Non | Le plus faible | Rapide | Modéré | Élevée |
| Feature flags | Non | Contrôlé finement | Instantané | Bas | Moyenne |
Précision importante : ces stratégies se combinent. Une configuration courante en 2026 chez une entreprise mature est rolling update pour l'infrastructure, plus feature flags pour l'activation fonctionnelle, plus canary pour les changements les plus sensibles.
8. Comment choisir — arbre de décision
Recommandation pour une équipe qui démarre : commencez par rolling update (gratuit et natif si vous êtes sur Kubernetes), puis ajoutez des feature flags pour les fonctionnalités à risque. Le canary et le blue-green viendront quand votre observabilité et votre budget le permettront.
9. Deux termes connexes à connaître
La distinction canary / A/B testing est un excellent test de compréhension : les deux découpent le trafic, mais le canary répond à « est-ce que ça casse ? » et l'A/B testing à « est-ce que ça convertit mieux ? ». Un canary dure des minutes, un A/B test des semaines.
Retenir en 30 secondes
- Cinq stratégies, chacune un compromis entre interruption, rayon d'impact, rollback et coût.
- Recreate : interruption assumée, le plus simple. Parfait pour l'interne et la recette.
- Rolling update : le défaut de Kubernetes. Attention à la rétrocompatibilité des migrations (motif expand and contract).
- Blue-green : rollback le plus rapide, mais double infrastructure.
- Canary : rayon d'impact le plus faible, mais exige une observabilité solide.
- Feature flags : découple déployer de livrer. C'est ce qui rend le déploiement continu praticable.
- Ces stratégies se combinent — rolling + feature flags est la base saine en 2026.
- Canary valide la stabilité technique, A/B testing compare l'efficacité métier.
Suivant : Les outils comparés : GitHub Actions, GitLab CI, Jenkins et les autres →