Déploiement Blue-Green
Deux environnements de production complets, le trafic basculant de l'un à l'autre — permettant une inversion complète et instantanée si le nouvel environnement se comporte mal.
Déploiement et mise en service · Étape 05 · Notre façon de travailler
La mise en production est une décision, pas un événement.
Le développement et l'intégration produisent un logiciel vérifié — mais un logiciel vérifié n'est pas encore un logiciel en production. Cette étape gouverne comment, quand et avec quelle sécurité ce logiciel est exposé au trafic réel de production, et s'assure que les personnes responsables de son exploitation sont prêtes avant son arrivée.
Chez OpenQCore, le déploiement est considéré comme une exposition contrôlée au risque, et non comme un moment unique et irréversible. Une mise en production n'est pas "terminée" lorsque le code atteint la production. Elle l'est lorsqu'elle a été exposée progressivement, observée dans des conditions réelles, et confirmée sûre — avec un chemin de retour défini si ce n'est pas le cas.
Pas cette question
"Le code est-il prêt à être livré ?"
Plutôt cette question
"Comment exposer ce changement à de vrais utilisateurs d'une manière qui limite le rayon d'impact de tout ce que nous n'avions pas anticipé — et pouvons-nous l'annuler rapidement si nécessaire ?"
Livraison progressive · Confinement des risques · Réversibilité · Préparation · Activation
Pourquoi le déploiement suit la vérification
Vérifié ne veut pas dire éprouvé en production.
L'étape précédente confirme qu'un changement satisfait ses critères d'acceptation en test. Elle ne confirme pas comment ce changement se comporte sous une charge de production réelle, le comportement réel des utilisateurs, ou les interactions réelles avec des systèmes qui ne peuvent pas être entièrement reproduits en environnement de test. Le déploiement et l'activation existent précisément parce que cet écart est réel — et parce que le combler en toute sécurité nécessite une discipline propre.
Prêt pour le déploiement → Exposition contrôlée en production
Pourquoi la discipline de déploiement est importante
La vitesse sans réversibilité n'est pas du progrès.
Les mêmes recherches DORA présentées pendant Développement & Intégration — Accelerate (2018) de Forsgren, Humble et Kim — associent leurs métriques de débit à deux métriques de stabilité qui comptent particulièrement à ce stade.
Fréquence de déploiement
À quelle fréquence une organisation réussit à mettre en production.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps research.
Temps de restauration du service
Combien de temps il faut pour récupérer lorsqu'un déploiement dégrade la production.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps research.
Les organisations à haute performance, selon cette recherche, ne se contentent pas de déployer fréquemment — elles déploient de manière à maintenir le temps de rétablissement court en cas de problème. OpenQCore considère ces deux aspects comme un objectif unique, et non comme un compromis : les pratiques de cette étape sont conçues pour rendre le déploiement à la fois fréquent et rapidement réversible.
Stratégies de livraison progressive
Séparer la décision de publier de la décision de déployer.
Les pratiques formalisées dans l'influent Continuous Delivery (2010) de Humble et Farley distinguent le déploiement d'un changement de sa mise à disposition aux utilisateurs — distinction qu'OpenQCore considère comme un choix fondamental de conception pour la façon dont le logiciel atteint la production.
Déploiements canaris
Une nouvelle version est d'abord exposée à une petite fraction du trafic réel, observée selon des signaux définis, puis étendue seulement si ces signaux sont confirmés.
Feature Flags
Le code peut être déployé en production tout en restant inactif pour les utilisateurs — séparant l'acte d'envoyer du code de l'acte d'exposer une fonctionnalité.
Environnements de déploiement & promotion
Un changement gagne sa place en production. Il n'y est pas envoyé directement.
Un changement traverse des environnements définis — développement, préproduction et production — avec une vérification explicite à chaque promotion, et non un simple passage de tests suivi d'une mise en production directe.
Développement
Où un changement est développé et vérifié initialement en isolation.
Préproduction
Où un changement est vérifié dans des conditions, une configuration et des intégrations proches de la production.
Production
Où un changement est exposé au trafic réel — progressivement et sous surveillance.
Conception du retour en arrière et de la récupération
Le plan de retour en arrière est rédigé avant le déploiement, pas pendant l'incident.
Une stratégie de retour en arrière décidée alors que le système est déjà dégradé est une stratégie prise sous pression, avec des informations incomplètes, et souvent trop tard. OpenQCore définit le chemin de retour en arrière pour un changement avant son déploiement — pas après qu'un incident survienne.
Conditions définies de déclenchement du retour en arrière
Les signaux spécifiques qui déclencheraient un retour en arrière, convenus à l'avance plutôt que décidés sur le moment.
Compatibilité des données et de l'état
Prise en compte explicite de la sécurité d'un retour en arrière compte tenu des éventuelles modifications de données ou de schéma introduites par le déploiement.
Objectif de temps de récupération
Une cible indiquant la rapidité à laquelle le service doit être rétabli si un retour en arrière est nécessaire.
Infrastructure as Code et reproductibilité
Un déploiement qui ne peut pas être reproduit exactement ne peut pas être digne de confiance.
Les étapes de déploiement sont définies en tant que code — versionnées, relues et exécutées de manière identique à chaque fois — plutôt que réalisées manuellement en fonction de la mémoire d'une personne concernant la séquence correcte. Il s'agit d'une pratique fondamentale dans le même corpus de recherche sur la livraison continue mentionné ci-dessus : un processus de déploiement qui ne peut pas être reproduit exactement ne peut pas être vérifié et ne peut pas être automatisé en toute sécurité.
Évaluation du risque de déploiement
Chaque déploiement est évalué avant d'être exécuté, pas après.
Conformément à la modélisation des menaces introduite pendant le développement et l'intégration, chaque déploiement est évalué selon son profil de risque spécifique avant d'être exécuté.
Rayon d'impact
Combien d'utilisateurs, de systèmes ou de flux de travail seraient affectés si ce changement se comportait de manière inattendue.
Réversibilité
À quelle vitesse et de manière propre ce changement peut être annulé si nécessaire.
Exposition des dépendances
Quels systèmes ou équipes en aval sont affectés par ce déploiement, et s'ils ont été informés.
Le pipeline de déploiement progressif
L'exposition n'augmente que lorsque les preuves le justifient.
Canary (petit pourcentage) → Surveiller les signaux définis → Augmenter l'exposition → Surveiller les signaux définis → Déploiement complet. À tout moment de cette séquence, un rollback est un résultat planifié — pas une improvisation d'urgence. L'expansion vers l'étape suivante est une décision prise en fonction des éléments de preuve recueillis à l'étape actuelle, et non un comportement par défaut qui se produit automatiquement avec le temps.
Cette approche reflète le concept d'error budget, décrit dans Site Reliability Engineering de Google (2016) : une quantité définie et acceptable d'instabilité qu'un système est autorisé à 'dépenser', utilisée pour transformer le compromis entre vitesse de livraison et fiabilité en une décision explicite et mesurée plutôt qu'en une décision implicite.
Mise en capacité : documentation et préparation de l'équipe
Un système que personne ne peut exploiter n'a pas réellement été déployé.
Le déploiement est souvent considéré comme terminé dès que le logiciel fonctionne en production. OpenQCore l'estime terminé seulement lorsque les personnes chargées d'exploiter, de supporter et de dépanner ce logiciel sont effectivement prêtes à le faire.
Runbooks opérationnels
Procédures documentées pour les tâches opérationnelles courantes, les modes de défaillance connus et la façon d'y répondre.
Préparation à l'astreinte
Confirmation que les personnes chargées de répondre aux incidents disposent des accès, du contexte et des procédures d'escalade dont elles ont besoin.
Transfert de connaissances
Transfert explicite de la connaissance opérationnelle à l'équipe ou à l'organisation qui prendra en charge le système à l'avenir.
La porte de décision de déploiement
Un déploiement progresse parce que les preuves le justifient — pas parce qu'il est programmé.
Tout déploiement planifié atteint une porte de décision définie avant de se poursuivre.
Déployer
L'évaluation des risques, le plan de retour en arrière et la préparation sont tous satisfaits — le déploiement se poursuit.
Report
Un risque identifié n'a pas encore été suffisamment atténué — le déploiement attendra qu'il le soit.
Retour en arrière
Un changement déployé a déclenché une condition définie de retour en arrière — l'état précédent est restauré.
Escalader l'incident
Un déploiement a provoqué un impact nécessitant une réponse formelle à l'incident dépassant un simple retour en arrière.
Une porte de déploiement qui ne retarde jamais et ne provoque jamais de retour en arrière n'évalue pas le risque — elle se contente d'enregistrer un calendrier.
Ce que produit cette étape
Un système en production, et la capacité de l'exploiter.
Selon la portée de l'engagement, cette étape produit :
Runbook de déploiement
La procédure spécifique et reproductible utilisée pour déployer ce changement et les changements futurs similaires.
Plan de retour en arrière
Les conditions de déclenchement définies, la procédure et l'objectif de temps de récupération pour inverser ce déploiement.
Enregistrement de la promotion d'environnement
Documentation de la manière dont la modification a transité par développement, préproduction et production, et de ce qui a été vérifié à chaque étape.
Document d'évaluation des risques
Le périmètre d'impact (blast radius), la réversibilité et l'exposition des dépendances évalués avant le déploiement.
Supports d'habilitation de l'équipe
Runbooks, confirmation de préparation en astreinte et transfert de connaissances effectués avant la passation.
Rapport de déploiement progressif
Les signaux observés à chaque palier d'exposition et les éléments de preuve soutenant l'extension au déploiement complet.
Du déploiement à la surveillance et à l'optimisation
Être en production ne signifie pas être compris.
Le déploiement et la mise en condition produisent un système qui fonctionne en sécurité en production, avec les personnes responsables prêtes à l'exploiter. Ils ne produisent pas encore une compréhension continue du comportement du système dans le temps, ni un mécanisme structuré pour l'améliorer. Tel est l'objectif de l'étape suivante et finale de cette méthodologie.
Exposition contrôlée en production → Prêt opérationnel → Surveillance et optimisation
Étape 06
Surveillance et optimisation
Comprendre comment un système en production se comporte réellement, et l'améliorer en continu à partir de preuves concrètes.
Références de recherche et méthodologiques
Forsgren, N., Humble, J., & Kim, G. — Accelerate : The Science of Lean Software and DevOps (2018); Google Cloud, recherche DORA sur l'état du DevOps
Source des métriques de fréquence de déploiement et de temps de rétablissement mentionnées ci-dessus.
Humble, J. & Farley, D. — Continuous Delivery : Reliable Software Releases through Build, Test, and Deployment Automation (2010)
Source de la distinction deploy/release, du déploiement blue-green et des principes d'infrastructure en tant que code mentionnés ci‑dessus.
Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (éd.) — Site Reliability Engineering : How Google Runs Production Systems (2016)
Source du concept de budget d'erreur mentionné dans la section sur le déploiement progressif ci‑dessus.