Opérations et gestion → Gestion des changements

Gestion des modifications

1) Désignation et principes

Objectif : Apporter des changements rapidement et en toute sécurité, en réduisant les risques d'incidents, d'interruptions de service et d'infractions réglementaires.

• Predictable & Reversible : Chaque changement est planifié, vérifiable et réversible.
• Risque : la profondeur du contrôle dépend du risque (compétence, argent, IPI).
• Small & Frequent : les petits incréments sont plus faciles à évaluer et à repasser.
• Automation first : l'infrastructure comme code, tests, validations, essais automobiles.
• Single Source of Truth : un seul RFC/ticket, un calendrier unique et un journal d'actions.

2) Portée

Code produit (backend/frontend, SDK mobile).
Infrastructure (IaC, Kubernetes/VM/CDN/Edge).
Données (schémas OBD, migrations, vitrines/ETL).
Configurations et drapeaux ficha.
Intégrations (PSP, KYC, fournisseurs de jeux).
Politiques de sécurité et d'accès.

3) Rôles et RACI

Le propriétaire de la modification (Change Owner) est Responsible.
Curateur de sortie/RelEng - coordination du train de sortie.
SRE/Ops - exploitation, gate SLO/SLA.
Sécurité/Conformité - Vérification des risques et de la conformité.
ACR (Change Advisory Board) - Approbation des changements normaux/à haut risque.
Stackholders d'entreprise/support - Informed.

4) Classification des changements

Standard (typique, pré-approuvé) : fréquent, à faible risque, par pleybuck prêt (par exemple, mise à jour du drapeau, rotation des clés).
Normal : nécessite des RFC, une évaluation, un éventuel CCS, des tests et un plan de retour.
Urgence : fixations urgentes pour les incidents P1 ; voie bureaucratique minimale, post-factuel revoyez/SAW.

5) Le cycle de vie du changement

1. Initiation (RFC) : objectif, portée, risque, services/régions touchés, plan de backout.
2. Évaluation des risques : matrice Impact × Likelihood, impact sur les SLO/conformité/coût.
3. Planification : fenêtre, dépendances, migrations, communications, tests de validation.
4. Validation : autotests, analyse statique, chèque de sécurité, performance.
5. Déploiement : stratégie progressive (voir § 8), télémétrie et gardrail.
6. Observation : burn-rate SLO, alertes, métriques d'entreprise (GGR/NGR, conversion).
7. Achèvement : acceptation du résultat, mise à jour de la documentation, post-mortem en cas de rejet.

6) RFC : composition minimale

Contexte : pourquoi changer, l'hypothèse de l'influence.
Gamme : systèmes, régions, versions clients.
Risque : matrice et scénarios de défaillance, radius blast.
Plan de déploiement : pas à pas, avec les critères « aller/stop ».
Plan de retour (Backout) : commandes/étapes, conditions de démarrage, attentes selon RTO/RPO.
Plan de test : ce qui est vérifié avant/après (fonctionnalité, performance, sécurité).
Communications : Nous informons qui, modèles de messages.
Audit : liens vers tiquets, commits, artefacts CI/CD.

7) Calendrier des changements et fenêtres

Calendrier unique : toutes les sorties, migrations, éteindre les fiches, événements externes (sport/marketing/vacances).
Fenêtres Freeze : grandes ventes/championnats/heures de pointe, rapports fiscaux.
Politique de croisement : interdire les changements conflictuels sur les mêmes voies critiques.
Vagues régionales : d'abord les régions « chaudes »/faible trafic, puis les principales.

8) Stratégies techniques de déploiement

Canary : faible part du trafic → comparaison des métriques (p95 latency, error %, conversion).
Bleu-Vert : environnements parallèles, changement de route atomique.
Livraison progressive : pourcentage-rouleau avec conditions d'arrêt automatiques.
Feature Flags : commutateurs fonctionnels, kill-switch, A/B.
Dark Launch/Shadow Traffic : vérifier les ombres sans affecter les utilisateurs.
Limites par étapes : augmentation progressive de la QPS/compétitivité.

Gardrails : arrêt automatique lorsque les seuils p95/error % sont dépassés, augmentation des retours/chargbacks, baisse des autorisations/dépôts.

9) Modifications des données et des schémas

Compatibilité : migration extensive (additive) → code qui lit à la fois l'ancien et le nouveau schéma.
Migrations en deux phases : (1) ajouter de nouveaux champs/index → (2) changer le code → (3) supprimer l'ancien.
Versionation des contrats : Système Avro/Protobuf avec registre ; back/forward compatible.
Migrations de grands volumes : batchi, pauses, idempotence, chekpoint et progrès.
Résistance aux catastrophes : test RPO/RTO, snapshots, répétitions de récupération.
Données BI : changement de vitrine/métrique - via MR/SR et dictionnaire métrique (ID, formule).

10) Gestion des configurations et des secrets

Bou as Data : Configs versionnés, validation par le circuit, promu à travers les environnements.
Secrets : rotation des clés, principes des privilèges minimums, vérification des appels.
Overrides régionaux : limites/partenaires (PSP/KYC) - par paramétrage, pas par code.

11) Conformité et audit (iGaming-contexte)

Traces de changement : qui/quand/qu'a changé (drapeaux, configis, itinéraires, migrations).
Segregation of Duthies : différents rôles pour l'auteur, revoyeur et déplieur (SOX-like).
Rapports réglementaires : fix-releases, contrôle des versions de règlement (GGR/NGR, bonus), contrôle de l'accès aux PII.
Fournisseurs : SDK/Certificats de fournisseurs, engagements SLA.

12) Communications

Modèles d'alerte : avant la sortie (quoi/quand/risques), pendant (état, % du trafic, métriques), après (résultats).
Messages externes : bannières/page de statut pour influencer les clients.
Coordination : canal # release-war-room, propriétaire de la version, fréquence des updates.

13) Mesures de l'efficacité

DORA: Deployment Frequency, Lead Time for Changes, Change Failure Rate (CFR), MTTR.
SLO Impact : part de temps dans le SLO avant/après les sorties.
Backout Rate : taux de retour par catégorie de changement.
Release Debt : migrations en cours/drapeaux de fich dans un état « suspendu ».
Business Impact : Conversion, KYC TTV, taux de réussite PSP, GGR/NGR drift lors des roulements.

14) Anti-modèles

Big-bang releases : beaucoup de changements à la fois - il est difficile de comprendre la cause de la régression.
Migrations incompatibles : supprime/renomme les champs sans double lecture.
Drapeaux sans propriétaires et délais de retrait : branches « éternelles » de la logique.
Sorties sans télémétrie et sans critères d'arrêt : « à l'œil » et détection tardive des dommages.
Ignorer le calendrier : intersections avec des événements/campagnes de pointe.
Étapes manuelles sans pleybuck et audit : variabilité et risque élevés.

15) Chèques-feuilles

Avant le début (RFC prêt)

• Les objectifs et les KPI du changement sont formulés
• Le risque et blast radius sont évalués, la classe de changement est sélectionnée
• Plan de déploiement et Backout prescrit étape par étape
• Le plan de test et les résultats sur le steidge/canara sont là
• Communications et calendrier mis à jour, Stackholders notifiés

Pendant le déroulement

• Mesures p95/error %, signaux d'affaires et logs surveillés en temps réel
• Les étapes de progrès sont confirmées par les chèques-points
• Lorsque les gardrails sont activés - auto-stop et retour

Après

• Résultats de sortie enregistrés (changelog, versions, artefacts)
• Post-mortem en cas d'anomalies (≤ 5 jours ouvrables)
• Dettes (suppression des drapeaux, migrations finales) inscrites dans le backlog avec les propriétaires

16) Mini-modèles

• Objectif/hypothèse
• Volume et impact (services, régions, données, clients)
• Risques (Impact × Likelihood) et mesures de réduction
• Plan de déroulement (étapes, % de trafic, critères go/no-go)
• Plan backout (étapes, RTO/RPO, données)
• Plan de test (fonctionnalité/performance/sécurité)
• Communications (canaux, fréquence)
• Artefacts (tiquets, PR, numéros de facture)

• Modification : "Payments-Service v2. 14 + migration psp_limits"
• Fenêtre : 2025-11-02 00 : 00-01 : 00 EET
• Régions touchées : UE, LATAM (10%→50%→100 %)
• Risques/gardrails : error%> 2 % 10 min - stop et reculs
• Contact : @ Owner, @ SRE-on-call, @ Support-lead

• Déclencheurs : p95> + 25 % 10 min, PSP success <97 %
• Étapes : (1) trafic −→ 0 % sur v2. 14; (2) commuter les drapeaux en v2. 13; (3) le retour de la migration à travers le snapshot/checkpoint ; (4) les tests de smoke ; (5) rapport.

17) Intégration avec le train de sortie

Release Train : slots fixes (par exemple 2 × par semaine), SLA sur merge-cut.
Hotfix-politique : trains/branches séparés, chemin accéléré dans la prod.
Versioning : semver, étiquettes dans les artefacts et les environnements, SBOM.

18) Résultat

La gestion des changements n'est pas un frein pour la vitesse, mais un mécanisme d'accélération sûre. Une classification axée sur les risques, un bon RFC, un déroulement progressif, des migrations de données compatibles, des communications claires et la mesurabilité de l'effet transforment les sorties en un processus gérable, répétable et vérifiable.