Audit des données et versionalité

1) Pourquoi est-ce nécessaire

L'audit et la versionalité créent la reproductibilité : vous pouvez expliquer n'importe quel chiffre, répéter le calcul et développer des modèles/vitrines en toute sécurité. Dans iGaming, c'est essentiel pour la finance (GGR/NET), les paiements, KYC/AML, Responsible Gaming et les rapports réglementaires.

• Trace : qui a modifié les données/schéma/logique et pourquoi.
• Reproductibilité : quelle version de données/code/modèle a donné naissance au rapport.
• Sécurité des versions : réversible (rollback) et prévisibilité des changements.
• Conformité : registres prouvables pour les organismes de réglementation et les audits internes.

2) Concepts et niveaux de versibilité

1. Version du schéma (Schema Version) : évolution des champs/types/sémantique (SEMVER).
2. Version Dataset (Dataset Version) : snapshot/tranche à un moment donné ; « la vérité » pour le rapport/l'apprentissage.
3. Version vitrine/modèle BI (Data Product Version) : formules, filtres, agrégations.
4. Version fich/modèle ML : date/code/hyperparamètres/fiches/données (end-to-end).
5. Version pipline : code de transformation, configi, dépendance.
6. Version du contrat de données : exigences pour le producteur/consommateur (schéma, SLA, qualité).

3) Audit : que loger

Qui : sujet (utilisateur/service), rôle/attributs (RBAC/ABAC).
Quoi : table/vitrine/modèle/schéma/contrat.
Quand : heure exacte, tz, id corrélatif.
Pourquoi : référence à la note tusk/ticket/release, raison.
Quoi : version de code/modèle, commit hash, image conteneur.
Comment a changé : avant/après (bou), volume de lignes (rows affected), contrôle d'intégrité (hash/signature).
Contexte : environnement (prod/stage), domaine, sensibilité des données (classe).

Les journaux d'audit sont immuables (append-only/WORM), signés et disponibles dans SIEM.

4) Politique de versatilité (recommandations)

SEMVER: `MAJOR. MINOR. PATCH`

MAJOR - Changements de schéma/sémantique incompatibles.
MINOR - ajouts réversibles compatibles (nouveaux champs/colonnes nullables, nouvelles vitrines vNext).
PATCH - corrections sans modification de contrat (quality-fix, backfill).
Procédure de suppression : fenêtre d'obsolescence, avertissements dans le catalogue/CI, date de désactivation.
Release Notes : une page par sortie : quoi, pourquoi, les risques, plan de retour.

5) Techniques dans le stockage et les flux

Time-travel/Snapshots : stockage des versions des tables ; la possibilité d'exécuter la demande « comme sur T-0 ».
SCD (Slowly Changing Dimensions) : types 1/2/3 pour les mesures (jeux, fournisseurs, joueurs).
CDC/CDF (Change Data/Capture & Feed) : changements incrémentiels pour les faits (taux, paiements, KYC).
Journal des opérations (Audit Fact) : une table de faits distincte avec des événements de modification/ajout/suppression.
Contrôle de l'intégrité : hachage des lots/fichiers, signature des paquets, rapprochement des agrégats.

6) L'évolution des schémas et des contrats de données

Le contrat est comme code : schéma, types, champ obligatoire, valeurs admissibles, SLA de fraîcheur, règles DQ.
Compatibilité : ajouté un champ → MINOR ; ont changé le type/la sémantique de la → MAJOR avec la migration et le dual-write.
Gate CI : Le circuit de changement PR est bloqué si la compatibilité de Release Notes est altérée ou non.
Répertoire/Registre : stocke les versions actives/obsolètes et les propriétaires.

7) La versionalité en BI et métriques

Vitrines certifiées « or » : sémantique KPI (GGR, ARPPU, rétention).
Dual-run : une nouvelle version de la vitrine est construite en parallèle (v2), comparaison des métriques (bandes de tolerance).
Fixation des rapports : chaque export/dashboard fait référence à 'dataset _ version' et 'definition _ version'.
Les tranches de calendrier : « dei-kat », « mois-à-date » sont enregistrées sur la version des données.

8) Versance en ML/MLOps

Registre du modèle : modèle, date, métriques de qualité, données d'apprentissage (dataset_version), versions fich (feature_set_version).
Feature Store : groupes fich versionnés ; interdiction des champs « chauds » sans version explicite.
Jeu repro : code d'entraînement (commit), environnement (Docker/conda lock), sid.
Champion-Challenger : versions parallèles en vente, rapports qualité, fairness et vie privée.
Rollback : retour rapide sur le modèle stable précédent et l'ensemble fich.

9) Rollbeck, backfill et corrections

Plan de rollback : pour chaque version MAJOR/MINEUR - étapes claires de retour.
Backfill-pleybuk : source de vérité, plage de dates, ordre de conversion, montants de contrôle, étiquettes « recomputed = true ».
Visibilité des modifications : v2 ne remplace v1 qu'après avoir passé la comparaison ; tous les rapports « historiques » continuent de faire référence à leurs versions.

10) Sécurité et conformité dans l'audit

Signature des événements/paquets : le producteur signe, le consommateur vérifie.
Assainissement PII : l'audit stocke des jetons non bruts PII.
Legal Hold : interdiction de supprimer la version/les logs pendant la période d'enquête.
DSAR : les versions trouvent et déchargent les enregistrements du sujet par token ; les photos historiques sont prises en compte.

11) Métriques et SLO

Taux de reprise : proportion de rapports reproduits à partir de la version de données/code ≥ du seuil cible.
Coverage :% des tables avec time-travel/journal d'audit activé.
Schema Compatibilité Pass : proportion de contrôles d'interopérabilité réussis dans les IC.
Dual-run Delta : écart v1/v2 dans les tolérances.
Rollback MTTR : temps de retour moyen de la version.
Audit Integrity : proportion d'événements signés et vérifiés.
Backfill Success : proportion de recalculs correctement effectués.

12) Modèles pour iGaming (cas)

Correction du RGG rétroactive : le fournisseur a recalculé le RTP - on backfill les faits sur la période, on enregistre "recomputed _ at', on publie des notes de sortie, on compare v1/v2 ; les rapports des derniers mois ne sont pas réécrits, mais marqués « version corrigée disponible ».
Règles antifrod : nous changeons la sémantique de la fiche - MAJOR, modèles et vitrines dual-run, rollback en champion en régression.
KYC/AML : ont ajouté les nouveaux statuts du fournisseur - MINOR avec nullable ; nous incluons des tests de compatibilité dans les contrats.
Signaux RG : ont précisé la logique des « séries perdantes » - MINOR + Release Notes et surveillance de l'impact.

13) Outils et artefacts (catégories)

Catalogue/Lineage/Registry : versions jeux/circuits/vitrines, propriétaires, communications, contrats.
Orchestrator & CI/CD : gets de compatibilité, double exécution, publication de notes de sortie.
Storage avec time-travel : stockage de snapshots/logs.
Signing & Checksums : signature des paquets, somme de contrôle des lots.
Registry Model/Feature : versions fich/model, rapports champion-challenger.

14) Modèles (prêts à l'emploi)

14. 1 Notes de sortie (croquis)

Version : 'payments _ gold v2. 1. 0`

Type : MINEUR (nouveaux champs 'psp _ country', 'method _ group')

Raison : unification des rapports PSP/pays

Risques : effets sur les joyaux avec la vitrine 'risk _ signal'

Validation : dual-run 14 jours, delta ≤ 0. 2 % selon GGR

Rollback : passer à 'v2. 0. 3 'à travers le drapeau de l'orchestre

Date de sortie/propriétaire/tiquet

14. 2 Passeport de version du jeu

Dataset: `game_rounds_silver`

Version : '2025-11-01T00 : 00 : 00Z' (snapshot id)

Schéma : 'schema @ 1. 7. 0 '(référence au contrat)

Source : Fid A/B (commit...)

Contrôle d'intégrité : checksum, manifeste signé

DQ : exhaustivité 99. 9%, fraîcheur ≤ 15 min

Utilisations : 'games _ perf _ gold v3. x`, `rg_signals v1. x`

14. 3 Acte d'audit du changement

Événement : mise à jour schema 'kyc _ status' → 'kyc _ status, v2'

Qui : user/service, rôle 'Data-Engineer'

Quand : '2025-11-01 09:32:10 + 02'

Pourquoi : ticket # 3421 (nouveaux statuts de fournisseur)

Diff : + 'status _ reason' (nullable), enum étendu

Contrôles : CI semver pass, contrat MINEUR

Légende : 'sig =...', hachage bou : 'sha256 =...'

14. 4 Politique de versatilité (fragment)

MAJOR : brise l'interopérabilité ; dual-write ≥ 30 jours ; plan de rollback obligatoire.
MINEUR : Compatible réversiblement ; avertissements dans le catalogue ; A/B vitrine 7-14 jours.
PATCH : fiches qualité/recalculs ; Release Notes est obligatoire.
Archivage : nous stockons ≥ N mois de snapshot pour la réglementation ; WORM pour l'audit.

15) Processus (end-to-end)

1. Initiative : ticket changement + estimation de l'impact par ligne.
2. Conception : mise à jour du contrat/schéma + Notes de sortie.
3. Validation : Contrôles de compatibilité CI, tests DQ, dual-run.
4. Déplis : par drapeau, canari ; publication de la version dans le catalogue.
5. Surveillance : delta v1/v2, KPI, plaintes.
6. Retour/Backfill : par pleybuk en cas de régression.
7. Post-mortem : en cas d'incident, mise à jour de la politique/des tests.

16) RACI (exemple)

Politiques et normes : CDO (A), Data Governance Council (R/A), DPO/Sec (C).
Contrats/schémas : Domain Owners (A), Data Stewards (R), Platform/Eng (C).
Orchestration/stockage : Platform/Eng (R), SRE (C).
BI/métriques : Analytics Lead (R), Product/Finance (C).
Versions ML : ML Lead (A), DS (R), Platform (C).
Audit/revues : SecOps (R), Audit interne (C).

17) Feuille de route pour la mise en œuvre

0-30 jours (MVP)

Activer time-travel/snapshots pour les tables critiques (payments, game_rounds, kyc).
Exécutez les journaux d'audit et la signature des paquets d'ingestion immuables.
Accepter la stratégie SEMVER et le modèle Release Notes.
Répertoire : ajouter 'owner', 'schema _ version', 'dataset _ version' aux vitrines supérieures.

30-90 jours

Entrez un double-run pour tous les MINOR/MAJOR ; comparaison automatique v1/v2.
Lier les contrats avec les gates de compatibilité CI et DQ.
Règlement backfill/rollback ; former les équipes.
Registry Model/Feature avec un ensemble complet de liens « dannyye→fichi→model→inferens ».

3-6 mois

Couverture complète par les journaux d'audit, stockage WORM, rapports pour les régulateurs.
Les notes de sortie automatisées à partir de la ligne diff +.
Rapports Repro Rate/Schema Compatibilité/Rollback MTR en dashboards.
Revues trimestrielles des versions KPI et « gel » des définitions.

18) Anti-modèles

Modification de la sémantique KPI sans nouvelle version/note de sortie.
Recalculs "silencieux" sans plan backfill et les marques "recomputed'.
Stockage des PII bruts dans les logs d'audit.
Pas de double course et remplacement instantané des vitrines.
Modèles/vitrines « éternels » sans indication de version ou de source.

19) Sections connexes

Gestion des données, Origine et chemin des données, Contrôle d'accès, Tokenization, Sécurité et cryptage, Surveillance des modèles, Éthique et DSAR, Federated Learning, Confidentiel ML.

Total

L'audit et la versatilité transforment les données et les modèles en un produit fiable : chaque changement est transparent, reproductible et réversible. Pour iGaming, c'est la base de la confiance dans les KPI, de la durabilité de la conformité et de la vitesse des versions sécurisées.