Processus d'approbation des versions

1) Objectif et zone de responsabilité

Le processus d'approbation des versions permet des modifications prévisibles et sécurisées de la plate-forme sans perturber les SLO, les revenus et la conformité. Il couvre tout le chemin : de la demande de pull à la promotion complète en prod et post-monitoring.

2) Principes

1. SLO-first : la sortie n'est autorisée qu'avec des SLI verts/sans taux de croissance.
2. Petits lots et réversibilité : livraison canarique/progressive, rollback rapide.
3. Policy-as-Code : gates, SoD, fenêtres libres et classes de risque - sont vérifiées automatiquement.
4. Une source unique de vérité : artefacts/configis/drapeaux - dans Git, l'environnement est fourni par GitOps-reconsiler.
5. Audit et probabilité : Journaux WORM, piste décisionnelle, propriétaires clairs.
6. Sécurité par défaut : secrets séparés, privilèges minimaux, geo-gates.
7. Communications sans surprise : modèles préparés pour les mises à jour internes/externes.

3) Rôles et RACI

Release Manager (RM) est le propriétaire de la chaîne, du calendrier, des gates. A/R

Service Owner (SO) - le propriétaire du domaine, accepte le risque, prépare les artefacts. A/R

SRE/Platform - SLO-gates, roulements, auto-reculs. R

QA Lead - stratégie de vérification, résultats des tests. R

Sécurité/Conformité - scans, SoD, régulateur. C/A

L'ACR (Change Advisory Board) est une solution de classe normale. A

On-call IC/CL - préparation aux incidents et aux communications. R/C

Stakeholders (Biz/Support/Partners) - information. I

4) Classes de changement et chemins de négociation

Augmentation de la catégorie - au passage des limites de risque (paiements, RG, PII, limites).

5) Convoyeur de sortie et de gate (flux de bout en bout)

Étape 0. Planification et calendrier

Fenêtres Freeze (vacances/matchs), slot colla et CL, prêt des modèles de statut.

Étape 1. PR → Build

Linters/licences, SBOM, tests unit/contract, scan secret.

Étape 2. Intégration/Sécurité

E2E (fournisseurs PSP/KYC virtualisés), SAST/DAST, dependency review.

Étape 3. Staging/Répétition

Parité avec la vente, migration avec réversibilité, ficheflagi de 5 à 25 %, chèque « release drill ».

Gate A - Qualité et sécurité (obligatoire)

+ tous les tests/scans sont verts

+ les schémas/confidences sont valides, pas de « red » SLI staging

+ SoD/4-eyes pour les changements à haut risque

Étape 4. Avant-prod (livraison Canaries)

1 à 5 % du trafic par segment (tenant/geo/banque), runtime-validators, guardrails.

Gate B - SLO/Business Gate

+ pas de dégradation SLO/KRI (latence/erreurs/paiement)

+ pas de MRS/anomalies dans les métriques expérimentales

+ Comms prêt : brouillon d'état/partenaires

Étape 5. Ramp-up → 25 % → 100 % (région/tenant)

Promotion étape par étape avec des temporisateurs post-monitoring.

Étape 6. Post-surveillance (30-60 min)

Sortie Dashboard, burn-rate, plaintes/tickets, auto-fermeture/rollback en cas d'irrégularités.

6) Solutions automatisées (policy-engine)

• SLO-гейт: `deny promote if slo_red in {auth_success, bet_settle_p99}`
• PII-export: `require dual_control if config. affects == "PII_EXPORT"`
• Freeze: `deny deploy if calendar. freeze && not emergency`
• Rollback: `auto if auth_success_drop > 10% for 10m in geo=TR`

7) Artefacts de libération

Manifeste de libération (obligatoire) : objectif, classe de risque, zones (tenant/région), drapeaux, migrations, plan de roulement, plan de retrait, propriétaire, contacts.
Evidence Pack : Résultats des tests/scans, captures d'écran des dashboards staging, dry-run migrations.
Comms Kit : modèles de statut (interne/externe/partenaires), ETA/ETR.
Backout Plan : les étapes exactes du retour et les critères dans lesquels il est déclenché.

yaml release:
id: "2025. 11. 01-payments-v42"
owner: "Payments SO"
risk_class: "normal"
scope: { tenants: ["brandA","brandB"], regions: ["EU"] }
rollout:
steps:
- { coverage: "5%", duration: "20m" }
- { coverage: "25%", duration: "40m" }
- { coverage: "100%" }
migrations:
- id: "ledger_ddl_0042"
reversible: true flags:
- id: "deposit. flow. v3"
guardrails: ["api_error_rate<1. 5%","latency_p99<2s"]
rollback:
autoIf:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"

8) Canaries/Blue-Green/Feature-Flag

Canary - défaut sécurisé : petite couverture, segmentation par GEO/tenant/BIN.
Blue-Green - pour les changements lourds : changement d'itinéraire, retour rapide.
Drapeaux - pour les fiches comportementales : TTL, kill-switch, guardrails, SoD.

9) Gestion des configues et des secrets

Configurations comme données, schémas et validateurs ; GitOps est promu avec un détecteur drift.
Secrets - dans KMS/Secret Manager, accès JIT, audit et masquage.

10) Communications et pages de statut

Interne : var-rum/chat, alertes on-colls, modèles d'updates.
Externe : publications uniquement via CL, brouillons préparés à l'avance.
Partenaires (PSP/KYC/studios) : notifications ciblées lors des intégrations.
Statut : la sortie n'est pas un incident, mais dispose d'une fenêtre d'observation avec des métriques.

11) Communiqués d'urgence (Urgence)

Déclencheurs : Dégradation P1, vulnérabilité, risques d'IPI/GR.
Chemin : La solution IC + RM → un ensemble minimum de gates (linter/assembly) → canary 1-2 % → surveillance → promotion.
Obligatoire : Post-fact de l'ACR, post-mortem de l' ≤ D + 5, documentation des compromis.

12) Audit, SoD et conformité

SoD/4-eyes : modifications de l'itinéraire PSP, limites de bonus, exportations de données.
Journal WORM : qui/quoi/quand/pourquoi ; versions des politiques ; diff de sortie/drapeaux/configues.
Geo/Privacy : données et logs dans la bonne juridiction ; l'absence de PII dans les artefacts.

13) Observation et post-contrôle

Dushbord release : SLI (auth-success, bet→settle p99), error-rate, plaintes, conversion, lagas de files d'attente.
Alert : burn-rate, SRM, croissance 5xx, dégradation PSP par banques/GEO.
Rapports : CFR, MTTR release-incident, temps moyen post-monitoring, taux auto-rollback.

14) Processus KPI/KRI

Lead Time for Change (PR→prod), Change Failure Rate, MTTR release-incident.
SLO-gates pass rate, Auto-rollback rate, Freeze compliance.
Coverage of Release Drill (répétitions de steading), SoD violences (objectif 0).
Comms SLA (présence de brouillons, respect des temporisations).

15) Feuille de route pour la mise en œuvre (6-10 semaines)

Ned. 1-2 : déterminer les classes de changement, les gates et les artefacts ; Allumer les linters, SBOM, secret-scan ; calendrier des sorties et freeze.
Ned. 3-4 : GitOps pour configues, canary/blue-green, SLO-gates, modèles Comms et var-room.
Ned. 5-6 : Policy-engine (SoD/4-eyes, risk-rules), auto-rollback par métriques ; le dashboard des sorties.
Ned. 7-8 : répétitions (staging drills), intégration avec les ficheflags/incident-bot, rapports KPI/KRI.
Ned. 9-10 : Audit WORM, exercice de libération DR, optimisation CFR, apprentissage des rôles (RM/SO/CL/IC).

16) Anti-modèles

Les sorties sans réversibilité et canary → les incidents de masse.
Ignorer les gates SLO « pour la date limite ».
Configurations/drapeaux sans schémas et TTL → états « figés ».
Clics manuels en vente sans Git/audit.
Apdates publiques sans rôle CL et modèles.
Secrets dans le référentiel ; accès sans JIT et journal.
L'ACR est un frein sans données : les solutions doivent être étayées par des métriques de sortie.

Résultat

Le processus d'approbation de sortie est un cadre d'ingénierie et de gestion qui relie la qualité, la sécurité et la vitesse : les politiques en tant que code, les gates SLO, la livraison progressive, les communications transparentes et l'audit éprouvé. Cette approche réduit le CFR et le MTTR, protège les revenus et la conformité et permet aux équipes de produire de la valeur souvent et en toute sécurité.