Feature Flag (rollout EDI contrôlé)

Le pattern qui découple le déploiement d'une nouvelle version (mapping, validateur, partenaire) de sa visibilité en production — levier essentiel d'un rollout EDI sûr et réversible.

Problème

Déployer une nouvelle version d'un mapping Walmart 850 implique historiquement un cycle complet : code review, deployment, test en pre-prod, smoke test en prod, surveillance 24-48h. Si la v2.0 produit une régression sur 0,5% des messages (cas limite mal couvert), il faut un redéploiement en urgence pour revenir à la v1.0. Le temps moyen de détection puis rollback est de plusieurs heures, pendant lesquelles des factures incorrectes sont émises. Pour un hub EDI avec dizaines de partenaires, chaque rollout est une prise de risque.

Forces

• Le code v2.0 et l'ancien comportement v1.0 doivent coexister en production pendant la période de bascule.
• Le contrôle doit être granulaire : par tenant, par partenaire, par type de message, par pourcentage de trafic.
• L'activation doit être réversible sans redéploiement, en quelques secondes.
• Les flags doivent être auditables : qui les a modifiés, quand, pour quelle raison.
• Les flags ont un coût en complexité : chaque flag est un if dans le code, à nettoyer une fois la bascule consolidée.

Solution

Encapsuler chaque nouveau comportement derrière un flag nommé, interrogeable à l'exécution : features.mapping_v2_walmart_850, features.new_validator_en16931_2025. Le code charge le flag depuis un service centralisé (LaunchDarkly, Flagsmith, Unleash, ou implémentation maison) et adopte le comportement v1 ou v2 selon la valeur. La valeur du flag peut dépendre du contexte (tenant, partenaire, message type, % de trafic, hash de messageId pour une distribution déterministe). L'activation est pilotée depuis une console centrale, auditée, avec rollback instantané.

Déploiement vs activation découplés :

   Déploiement (live)        Activation (configuration)
   ───────────────────        ───────────────────────────
                              ┌─────────────────────────┐
   v2.0 du mapping            │ feature_flag.partner=X  │
   Walmart 850 livrée         │ enabled: false          │
   en production              │ override:               │
   (code packagé)             │   tenant_a: 10%         │
                              │   tenant_b: 100%        │
                              │   tenant_c: 0%          │
                              └─────────────────────────┘
                                          ▼
   Routeur de mapping consulte le flag :
   - tenant_a : 10% des messages → v2.0, 90% → v1.0
   - tenant_b : tous → v2.0
   - tenant_c : tous → v1.0 (ancien comportement)

   Si v2.0 produit anomalies : passer tenant_a à 0% sans
   redéploiement, en quelques secondes.

Implémentation EDI

Cas concret : déployer la nouvelle version du mapping Walmart 850 v2.0 qui supporte le complément carta porte 3.0 pour le marché mexicain. Sans Feature Flag : déploiement global, risque régression sur tous les partenaires US existants. Avec Feature Flag : le flag features.walmart_850_v2 est déployé inactivé. Le code dispatcher contient : if (featureFlags.isEnabled('walmart_850_v2', { tenantId, partnerId })) { useV2Mapping() } else { useV1Mapping() }. On active le flag à 10% pour le tenant_mexico, on surveille les SLO et taux d'erreur pendant 24h. Si OK, on passe à 100% pour le tenant_mexico, puis à 10% pour les tenants US, etc. L'industrialisation suit le pattern Canary Release. Outils : LaunchDarkly (référence commerciale, intégrations multi-langage), Flagsmith (alternative open source SaaS), Unleash (full open source). Les flags doivent être éphémères : après 2-4 semaines en 100% stable, nettoyage planifié pour supprimer la branche v1 du code.

Anti-patterns

• Flag immortel : 6 mois après le 100% stable, le flag est encore dans le code. Le if devient un pourrissoir de dette technique.
• Trop de flags : 150 flags actifs simultanément. Combinatoire ingérable, tests impossibles, code incompréhensible.
• Flag dans le code mais pas dans la config : hard-codé en true ou false, perd toute valeur de pilotage runtime.
• Flag non audité : changement en production sans trace, impossible de remonter à la décision en post-mortem.
• Flag couplé à un secret : le flag bypass une vérification de sécurité — pratique dangereuse à proscrire.
• Flag sans rollout progressif : tout-ou-rien annule la moitié de la valeur du pattern.

Patterns liés

• Canary Release — le rollout progressif consomme directement les flags.
• Blue-Green Deployment — variante infrastructure, complémentaire des flags applicatifs.
• Dark Launch — variante où le flag active du code sans rendre la sortie visible.
• Circuit Breaker — pattern voisin de protection runtime, sans l'aspect rollout.
• Detour — pattern EIP voisin pour activer/désactiver des étapes optionnelles.

Sources

• Hodgson P. — Feature Toggles (martinfowler.com, 2017). La taxonomie canonique des flags (release toggle, experiment toggle, ops toggle, permission toggle) référencée dans toute la littérature. martinfowler.com — feature-toggles
• Rahman M. — Effective Feature Management, O'Reilly 2020 (LaunchDarkly). Best practices opérationnelles pour piloter feature flags à grande échelle.
• LaunchDarkly — Documentation officielle de la plateforme leader du marché. docs.launchdarkly.com
• Unleash — Documentation de l'implémentation open-source de référence. docs.getunleash.io
• Humble J., Farley D. — Continuous Delivery, Addison-Wesley 2010. Chapitre 4 §6 (Decoupling Deployment from Release) — le fondement conceptuel du pattern.
• Beda K., Burns B. — Kubernetes Patterns, O'Reilly 2019 (réf. Burns, Beda, Hightower, Kubernetes Up & Running). Les patterns de rollout K8s qui s'articulent avec les feature flags applicatifs.