Deux environnements sains peuvent produire un incident à eux deux. Le symptôme apparaît après une bascule apparemment réussie : une commande est confirmée deux fois, un vendeur reçoit deux messages ou un remboursement part en double. Pendant ce temps, les sondes HTTP restent vertes, car l’ancienne version et la nouvelle répondent correctement tout en exécutant les mêmes crons, files ou webhooks.
Le vrai sujet n’est donc pas seulement de déplacer les requêtes de blue vers green. Il faut transférer le droit de produire chaque effet métier. Une seule version doit décider au bon moment, et les répétitions inévitables doivent rester sans conséquence grâce à l’idempotence.
Cette contrainte est particulièrement forte sur une marketplace : panier, commande, paiement, stock, commission, notification et flux vendeur se répondent. Le socle d’une marketplace opérateur doit rendre leurs dépendances visibles avant que l’équipe choisisse sa mécanique de déploiement.
Le bénéfice du blue-green reste réel : préparer une nouvelle version à côté de l’ancienne, la tester puis réorienter le trafic permet un retour rapide. Mais le retour réseau n’efface ni une écriture en base, ni un email envoyé, ni un appel au prestataire de paiement. La stratégie doit commencer par ces irréversibilités.
Ce que la bascule de trafic protège réellement
Dans sa forme classique, blue sert la production et green reçoit la nouvelle version. Après vérification, un load balancer ou un mécanisme de routage envoie le trafic vers green. La documentation AWS sur le blue-green présente précisément ce passage entre deux environnements identiques et le retour vers blue en cas de problème.
Cette bascule protège surtout les composants adressés par ce routage. Elle ne déplace pas automatiquement un worker connecté à RabbitMQ, un consommateur Kafka, un cron Kubernetes, un webhook enregistré chez un partenaire ou une connexion longue déjà ouverte. Chacun possède sa propre frontière de transition.
Contre-intuitivement, le terme « zéro interruption » ne signifie pas « une seule version instantanément ». Une requête en vol peut terminer sur blue après que les nouvelles requêtes partent sur green. Des résolutions DNS ou des connexions persistantes peuvent prolonger la coexistence. Le contrat métier doit donc accepter une fenêtre où deux versions lisent et écrivent le même système.
Inventorier les effets avant l’infrastructure
La préparation commence par une carte des effets. Pour chaque action, l’équipe note le déclencheur, le composant qui décide, la donnée écrite, l’appel externe, l’événement émis et la compensation disponible. « Créer une commande » n’est pas une ligne unique : réserver le stock, initier le paiement, calculer la commission, notifier le vendeur et publier dans l’OMS peuvent suivre des chemins différents.
Il faut ensuite classer chaque effet. Une lecture est répétable. Une écriture interne peut être annulée ou versionnée. Un email est difficile à reprendre. Un transfert financier ou une réservation logistique peut être irréversible sans procédure métier. Cette classification fixe l’ordre des protections et des tests.
- Entrées synchrones : API acheteur, back-office opérateur, appel vendeur et callback de paiement.
- Entrées asynchrones : files, topics, imports batch, tâches planifiées et webhooks.
- Écritures partagées : base transactionnelle, PIM, OMS, index de recherche, cache et stockage de fichiers.
- Sorties externes : PSP, transporteur, ERP vendeur, email, SMS et facturation.
Sans cet inventaire, une équipe valide la nouvelle interface alors que le risque se trouve dans un traitement nocturne qui n’a jamais reçu de trafic de test.
Garantir un seul producteur actif
Le moyen le plus simple d’éviter un doublon reste de ne pas autoriser deux producteurs. Un drapeau de rôle, un lease en base, une élection de leader ou un jeton de génération désigne l’environnement actif pour une responsabilité précise. Le rôle « reçoit du trafic web » ne doit pas être confondu avec « exécute les échéances » ou « publie les messages vendeurs ».
Un verrou temporel seul peut échouer si un processus ancien continue après avoir perdu son lease. Un jeton de fencing renforce la protection : chaque prise de rôle augmente une génération, et la ressource refuse une écriture issue d’une génération antérieure. Green peut alors reprendre sans que blue termine tardivement une opération devenue obsolète.
Le changement de rôle est journalisé avec un identifiant de déploiement, un horodatage et l’acteur. Le tableau d’exploitation affiche la génération active pour les crons, les workers et les publications externes. Si ces valeurs divergent, la bascule s’arrête avant le trafic client.
Rendre commandes et paiements idempotents
L’écrivain unique réduit le risque, mais ne supprime pas les retries réseau, les retours utilisateur ni les livraisons redondantes. Chaque commande sensible reçoit une clé d’idempotence stable liée à l’intention : panier et tentative d’achat, demande de remboursement, génération d’un avoir ou acceptation d’une offre.
Le backend enregistre la clé, les paramètres significatifs et le résultat dans la même frontière transactionnelle que l’opération. Une requête répétée avec la même clé retrouve le résultat existant ; une requête qui réutilise la clé avec des paramètres différents est refusée. Les requêtes idempotentes documentées par Stripe illustrent ce principe pour répéter une création ou une mise à jour après une erreur de connexion sans déclencher une seconde opération.
La clé ne doit pas dépendre de blue ou green, sinon la même intention devient nouvelle au changement d’environnement. Elle appartient au domaine métier et traverse le load balancer. Sa durée de conservation couvre la fenêtre maximale de retry, de reprise et de rapprochement définie par l’opérateur.
Absorber webhooks et réponses tardives
Un prestataire peut encore appeler l’URL associée à blue pendant que green traite les nouvelles commandes. La terminaison du webhook doit donc être indépendante du déploiement applicatif ou partager une boîte de réception commune. L’événement reçu est authentifié, enregistré rapidement, puis traité de façon asynchrone.
Le consommateur déduplique sur l’identifiant du fournisseur et le type d’événement. Il vérifie aussi l’état courant : un événement ancien ne doit pas ramener un paiement remboursé vers « payé ». La documentation Stripe recommande de renvoyer rapidement un succès avant les traitements complexes ; cette séparation évite qu’un timeout du webhook multiplie les livraisons au moment le plus fragile.
Pour un connecteur qui ne fournit pas d’identifiant stable, la plateforme construit une empreinte prudente à partir des références métier et conserve les cas ambigus pour rapprochement. Elle ne suppose jamais que l’ordre de réception est l’ordre de production.
Basculer les consommateurs de files
Deux groupes de workers peuvent consommer la même file sans dupliquer chaque message si le broker distribue correctement les tâches. Pourtant, ils exécutent alors deux versions du code en parallèle. Le danger devient une incompatibilité de schéma, une règle de commission différente ou une interprétation divergente du statut de commande.
La stratégie choisit explicitement entre coexistence compatible et transfert contrôlé. Dans le premier cas, le message reste lisible par les deux versions et porte une version de contrat. Dans le second, blue cesse de réserver de nouveaux messages, termine ceux en vol, publie son compteur à zéro, puis green commence. Les messages non acquittés retournent à la file sans perdre leur identifiant d’idempotence.
Une file morte reçoit les messages incompris avec leur cause, leur version et l’identifiant de corrélation. Le déploiement ne se termine pas tant qu’une hausse anormale de cette file reste inexpliquée. Relancer tous les messages en erreur après la bascule est interdit sans vérifier que l’effet associé n’a pas déjà eu lieu.
Neutraliser les tâches planifiées en double
Les crons sont le piège classique : les deux environnements démarrent avec la même configuration et lancent chacun relance vendeur, clôture de panier, génération de facture ou synchronisation de catalogue. Un simple décalage de quelques secondes suffit à masquer le doublon pendant les tests.
Les tâches planifiées doivent être désactivées par défaut dans green jusqu’au transfert de rôle. Lors de la bascule, l’orchestrateur suspend les nouveaux départs sur blue, attend les exécutions non interruptibles, active la génération suivante sur green et vérifie le premier passage. Chaque tâche possède une clé composée du nom et de la période métier afin qu’un deuxième déclenchement retrouve l’exécution existante.
Un traitement long mérite un checkpoint indépendant de l’environnement. Green reprend le dernier lot confirmé, pas le processus mémoire de blue. Si la tâche ne supporte ni reprise ni compensation, elle est planifiée hors de la fenêtre de déploiement ou maintenue sur blue jusqu’à sa fin.
Faire évoluer la base sans retour impossible
Le code peut revenir en quelques secondes ; les données, beaucoup moins. Tant que blue et green partagent la base, le schéma doit être compatible avec les deux. La séquence expand-migrate-contract ajoute d’abord les nouvelles structures sans supprimer les anciennes, déploie un code capable de lire la transition, migre les données, puis retire l’ancien modèle dans une livraison ultérieure.
Renommer directement une colonne, rendre un champ obligatoire sans valeur par défaut ou changer la signification d’un statut rend le retour illusoire. Pour une modification risquée, le nouveau code peut écrire les deux représentations temporairement, avec un contrôle de divergence. La double écriture reste transitoire et observée ; elle ne devient pas une architecture permanente.
Une base green répliquée séparément apporte d’autres contraintes : délai de réplication, écriture unique et point de non-retour. Les garde-fous de bascule RDS montrent que la transition de la couche de données possède ses propres vérifications et son propre timeout. Elle ne doit pas être assimilée à la seule redirection web.
Traiter sessions, cache et fichiers
Une session stockée localement sur blue disparaît à la bascule. Elle doit être externalisée, répliquée ou rendue acceptable à recréer. Si son format change, les deux versions lisent temporairement l’ancien format, ou green invalide explicitement les sessions avec un message compréhensible.
Le cache partagé exige des clés versionnées lorsque la représentation change. Green ne doit pas écrire un objet que blue ne sait plus décoder. Un préchauffage peut réduire la latence, mais il utilise des lectures sans déclencher de mails, de réservations ou de webhooks. L’invalidation est testée dans les deux directions.
Les fichiers envoyés par les vendeurs doivent rejoindre un stockage commun ou suivre une réplication dont l’état est observable. Une URL générée par green ne peut pas pointer vers un volume absent de blue si le rollback réaffiche la fiche. Le catalogue et le PIM doivent conserver une référence stable à travers la bascule.
Observer le métier, pas seulement le HTTP
Les métriques d’infrastructure — erreurs 5xx, CPU, mémoire et latence — restent nécessaires. Elles ne détectent pas une commission calculée deux fois avec une réponse 200. La fenêtre de surveillance inclut donc commandes créées par intention, réservations par ligne, débits par tentative, messages par destinataire et transitions de statut impossibles.
Contrat d’observabilité. L’entrée porte l’identifiant de déploiement, la version applicative et l’intention métier ; la sortie expose l’objet créé et son résultat. Le service de commande est owner de la corrélation, l’API la propage, le worker la journalise et le tableau rapproche effets internes et appels externes. Une alerte se déclenche dès qu’une intention produit plus d’un paiement ou plus d’une réservation active.
Seuils de bascule. À 5 % de trafic green, l’équipe vérifie erreurs techniques, temps de réponse et indicateurs métier. Elle passe à 25 %, puis 100 %, seulement si la fenêtre définie reste saine. Toute duplication, toute divergence de statut ou une file morte supérieure à 10 messages arrête la progression, même si le SLO HTTP est respecté.
Ces chiffres illustrent un protocole et doivent être calibrés selon le volume. L’essentiel est d’attacher chaque seuil à une action : continuer, figer, revenir au palier précédent ou couper le producteur fautif.
Définir ce que rollback veut dire
Revenir au routage blue ne suffit pas. Le runbook distingue code, trafic, workers, crons, schéma, cache et intégrations. Pour chaque composant, il indique l’action, l’acteur, le délai et les données à rapprocher. Un remboursement déjà émis ne revient pas avec le code ; il appelle une compensation validée par la finance.
Le rollback possède un point limite. Tant que green utilise le schéma compatible et n’a pas lancé une migration irréversible, le retour peut être automatique. Après une transformation de données ou un changement de contrat externe, l’équipe choisit plutôt un roll-forward corrigé ou un mode dégradé. Ce choix est décidé avant le déploiement.
L’environnement blue reste disponible pendant une durée d’observation, mais ses producteurs sont neutralisés. Sa conservation a un coût de capacité et de sécurité. Une date de destruction explicite évite qu’il demeure un troisième état officieux après le succès.
Cas concret : bascule pendant des commandes
Premier scénario : une marketplace bascule à 14 h, alors que 240 paniers sont actifs et que 18 paiements attendent un retour asynchrone. Green reçoit d’abord 5 % des nouvelles sessions. Les commandes portent une clé indépendante de l’environnement, le webhook arrive dans une inbox partagée et un seul groupe de workers publie vers les vendeurs.
Second scénario : à 14 h 07, une latence externe provoque trois retries. Les clés d’idempotence ramènent chacun vers la commande initiale ; aucun second débit n’apparaît. À 14 h 12, le groupe green tente toutefois de calculer une commission avec une règle différente pour deux messages anciens. La comparaison métier déclenche le seuil d’arrêt avant le passage à 25 %.
Le trafic revient sur blue, tandis que les workers green sont suspendus. Les deux messages rejoignent la file de rapprochement avec leur version de contrat. L’équipe corrige la compatibilité, rejoue ces messages sans nouvel effet et recommence le palier. Le test prouve ici davantage que la disponibilité : il démontre la maîtrise de la coexistence.
Pour qui le blue-green convient
Cette approche convient aux applications capables de faire fonctionner deux versions compatibles en parallèle et dont le trafic peut être redirigé. Elle est pertinente lorsque le coût d’une interruption est élevé, que l’infrastructure peut doubler temporairement et que l’équipe dispose d’une observabilité assez fine pour décider vite.
Elle convient moins à une migration monolithique irréversible, à une architecture dont les données ne tolèrent aucune coexistence ou à une équipe qui ne peut pas opérer deux environnements. Un rolling update ou un canary peut alors être plus simple. La documentation Kubernetes rappelle d’ailleurs que les déploiements progressifs peuvent être suivis, suspendus et ramenés à une révision précédente ; blue-green n’est pas la seule stratégie sûre.
Erreurs fréquentes pendant la coexistence
- Tester uniquement la page d’accueil : les commandes, workers et intégrations restent hors du verdict.
- Démarrer tous les crons dans green : la première exécution planifiée crée des effets invisibles au load balancer.
- Indexer l’idempotence par environnement : la même intention devient distincte après la redirection.
- Modifier le schéma en place : blue ne peut plus relire les données produites par green.
- Déclarer le succès trop tôt : les webhooks tardifs et les batchs nocturnes n’ont pas encore traversé la nouvelle version.
- Confondre rollback et annulation : le code revient, mais les effets externes restent à rapprocher.
Matrice de décision avant la bascule
- D’abord, valider : la compatibilité de schéma, de message, de session et de cache entre les deux versions.
- Ensuite, désigner : l’environnement écrivain pour chaque cron, file et publication externe.
- Puis, tester : les retries, doublons, réponses tardives, messages anciens et requêtes en vol.
- À bloquer : toute progression si un effet métier ne possède ni idempotence ni compensation.
- À différer : la suppression d’une colonne ou d’un ancien contrat jusqu’à une livraison séparée.
- À documenter : le point de non-retour et l’action prévue après ce point.
Plan d’action pour le jour J
Avant la fenêtre : prouver la compatibilité
La CI construit green avec la même configuration de dépendances que blue, mais maintient ses producteurs désactivés. Les tests contractuels vérifient API, événements, base et cache dans les deux sens. Un trafic synthétique couvre lecture du catalogue, création de panier et parcours de commande sans déclencher d’effets externes réels.
L’équipe consigne les baselines : débit par domaine, erreurs, latence, taille des files, commandes, paiements et notifications. Elle confirme la capacité de green, le délai de retour et les responsables. Le canal d’incident, le tableau et la commande de rollback sont prêts avant l’ouverture de la fenêtre.
Pendant la bascule : transférer par responsabilité
Les tâches planifiées blue sont suspendues, les workers terminent les messages en vol et le compteur atteint zéro. Green acquiert le jeton de génération, démarre ses consommateurs puis exécute une tâche témoin idempotente. Le trafic client progresse ensuite par paliers avec une durée d’observation définie.
À chaque palier, une personne lit les indicateurs techniques et une autre les indicateurs métier. Le product owner vérifie une commande réelle autorisée de bout en bout ; l’exploitation contrôle qu’aucune version inactive ne produit encore. Un seuil franchi fige immédiatement la progression, sans attendre la fin de la réunion.
Après 100 % : garder la fenêtre de retour
Blue reste démarré mais n’exécute plus aucun effet. Les webhooks, batchs et événements tardifs sont observés pendant la durée choisie. Le rapprochement compare intentions, commandes, débits, commissions et messages. La réussite n’est déclarée qu’après le passage des traitements représentatifs.
Enfin, l’équipe retire blue à la date prévue, ferme ses accès et archive les preuves de déploiement. Le contrat ancien et les colonnes transitoires ne sont supprimés qu’après vérification des consommateurs. La rétrospective traite chaque intervention manuelle comme un défaut à comprendre, pas comme une étape normale du protocole.
Approfondir résilience et idempotence
La prévention des doubles commandes mérite son propre modèle. L’idempotence appliquée aux commandes détaille la clé d’intention, le résultat conservé et le traitement des retries.
Pour décider avec des seuils adaptés au catalogue, à la commande et au paiement, la définition de SLO par domaine évite qu’une moyenne de disponibilité masque une rupture métier critique.
Le jour où une dépendance externe tombe pendant la bascule, la conception d’un mode dégradé tenable aide à préserver une promesse explicite plutôt qu’à laisser chaque version improviser sa réponse.
Conclusion : basculer les responsabilités
Un déploiement blue-green sûr ne se résume pas à deux couleurs derrière un load balancer. Il transfère explicitement le trafic, les workers, les crons et le droit d’émettre des effets externes, tout en acceptant une période de coexistence.
L’idempotence protège les répétitions, la compatibilité des données protège le retour, et l’observabilité métier révèle ce que les métriques HTTP ne voient pas. Le rollback reste crédible seulement tant que son point limite et ses compensations sont connus.
Pour préparer cette bascule sur une plateforme transactionnelle, Dawap peut accompagner l’architecture et l’exploitation de votre marketplace, du recensement des effets jusqu’à la preuve en production.
