Contrôle de la qualité des données

1) Désignation et principes

Pourquoi : rapports fiables (GGR/taxes), antifrod et modèles RG, conformité-déchargement, produits et personnalisation.

• Schema-first & Contrats : toutes les sources sont tenues de publier les données contractuelles.
• DQ-as-code : règles dans le référentiel, versions, tests et revues.
• Observability-by-default : métriques/loging/linéaire.
• Privacy-by-design : minimum PII, masquage et RLS/CLS.
• Cost-aware : hiérarchisation des règles critiques, échantillonnage intelligent.

2) Taxonomie des mesures de qualité

Completeness : proportion de champs/lignes obligatoires.
Validation (Validité) : correspond aux types/gammes/annuaires.
Uniqueness (Unicité) : aucun duplicata de clés/événements.
Consistency (Cohérence) : intégrité de référence, invariants d'affaires.
Accuracy (Précision) : approche de la source « vraie » (rapprochements sommaires).
Timel..../Freshness (Actualité) : Retard matériel.
Lineage Integrity : sauvegarder l'origine/les versions des transformations.

Les KPI de qualité et de criticité (critical/major/mineur) sont définis pour chaque domaine.

3) Contrats et schémas (source de vérité)

Contrats de données : JSON Schema/Avro/OpenAPI/AsyncAPI, hébergé dans Registry.
Stabilité : Modifications compatibles backward - Ajout de nullité ; breaking est la nouvelle version + double enregistrement.
Tracabilité : dans les événements : 'event _ id', 'trace _ id', 'schema _ version', 'source'.

4) DQ-comme-code : structure des artefacts

/dq/
rules/
silver. payments. yaml gold. ggr_daily. yaml checks/
sql/
python/
policies/
severities. yaml notifications/
routes. yaml

Règles : YAML/SQL déclaratifs ;

Gravité : mapping → alert-canaux/niveaux d'escalade ;

CI : linters de circuits, tests de compatibilité, « dry-run « /simulateur.

5) Exemples de règles (YAML)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: amount_positive severity: critical type: range column: amount min: 0. 01
- name: currency_in_whitelist severity: major type: in_set column: currency set: [EUR, USD, GBP, TRY, BRL]
- name: unique_tx severity: critical type: unique columns: [transaction_id]
- name: fk_user_exists severity: critical type: foreign_key column: user_pseudo_id ref_table: dim. users ref_column: user_pseudo_id
- name: ts_monotonicity severity: minor type: temporal expression: "ts between date_sub(now(), interval 90 day) and now()"

6) tests SQL (échantillons)

L'unicité des clés

sql
SELECT transaction_id, COUNT() AS c
FROM silver. payments
GROUP BY transaction_id
HAVING COUNT() > 1;

Exhaustivité des champs obligatoires

sql
SELECT COUNT() AS nulls
FROM silver. payments
WHERE amount IS NULL OR currency IS NULL OR ts IS NULL;

Guides/consistance

sql
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON p. currency = r. code
WHERE r. code IS NULL;

7) Streaming DQ (temps réel)

Ingest-validation : schema validation, size-limits, types et enum's.
Vérification en stream : dedup '(event_id, source)', lateness allowed, validité des monnaies/montants.
Limites : erreurs critiques → DLQ + alert ; les → non critiques à taguer mais à ignorer (avec le drapeau 'dq _ flag').
Métriques : completeness/lag/dup-rate par lot.

8) Travailler avec des erreurs et des exceptions

DLQ/Quarantine : Les entrées « malades » sont conservées, disponibles pour correction.
Records d'exception : carte d'exception (owner, date limite, raison, zone).
Auto-fallback : utilisez le dernier snapshot de vitrine correct.
SLA de fermeture : critique - 24-48 h ≤ ; major - ≤ 5 esclaves. Jours.

9) Alignement avec la vie privée et la conformité

Minimisation des PII : ne pas vérifier les PII « bruts » dans les couches analytiques ; appliquez des alias.
RLS/CLS : les contrôles sont effectués en tenant compte du masquage des champs.
Régionalisation : les règles tiennent compte de la « jurisprudence » (EEE/Royaume-Uni/BR).
Legal Hold : interdiction de réécrire les archives dans le cadre de la rétention.

10) Observabilité, SLI/SLO et alertes

• Freshness p95 (Silver) : ≤ 15 min.
• Completeness (critical types): ≥ 99. 5%.
• Validity (schema): ≥ 99. 9%.
• Duplicate rate: ≤ 0. 1%.
• DQ incident MTTR: ≤ 24–48 ч.

Alerts : routage par gravité (pager pour critical), lissage (dedup alerts), « maintenance windows ».

11) Dashboards (recrutement minimum)

Carte de chaleur Freshness/Completeness par domaines et marchés.
Top N tableaux par taux d'incident et par coût de correction.
Vortex DQ : ingest → argent → or (pertes/corrections).
Carte de ligne pour les rapports critiques (réglementation/GGR/RG/AML).
Carte des schémas « obsolètes » et des clients (versions SDK/schémas).

12) Processus et RACI

R (Responsible) : Data Engineering (règles par table), Domain Owners (sémantique).
A (Accountable): Head of Data/CDO.
C (Consulté) : Compliance/Legal/DPO, Architecture, SRE.
I (Informed) : BI/Produit/Marketing/Finances/Opérations.

Cycle de vie de la règle : proposition → je revois → « démarrage sombre » → activation → surveillance → rétrospective.

13) Rapprochement et précision (Accuracy)

Montants de contrôle/transactions : ensemble avec OLTP/fournisseurs (PSP/KYC).
Comparaison à deux boucles : pipeline indépendante pour la validation sélective.
Tolérances : seuils de pourcentage par métrique (par exemple écart GGR ≤ 0. 2%).
Actes quotidiens : rapports d'audit.

14) Coût et priorité

Exécutez les règles critiques plus souvent (streaming/horloge), minor - daily.
Utilisez les échantillons et les tests materialized pour les tables lourdes.
Suivez cost/query et cost/GB, appliquez le clustering/indexation.
Allouer un budget sur le DQ dans la coupe des commandes (chargeback).

15) Modèles pour les vitrines Gold (exemple GGR Daily)

yaml table: gold. ggr_daily owner: fin-analytics slo:
ready_by_local_time: "06:00"
rules:
- name: ggr_not_negative severity: critical type: range column: ggr min: 0. 0
- name: market_known severity: major type: in_set column: market set_ref: ref. markets
- name: fx_source_present severity: major type: not_null column: fx_source
- name: completeness_by_market severity: critical type: completeness partition_keys: [event_date, market]
expected_rows_expression: "ref. expected_activity(event_date, market)"

16) Incidents de qualité : Gestion et communication

Ticketing : création automatique de tâches avec sélections et métriques attachées.
Modèles de commm : notification aux propriétaires de produits/régulateurs en cas d'impact.
Post-mortem : cause racine (schema drift, upstream bug, charge), actions CAPA, contrôle du « retour de régression ».

17) Feuille de route pour la mise en œuvre

1. Catalogue des tables critiques (Payments, Gameplay, GGR, Compliance).

2. Règles YAML pour 10-15 contrôles clés + validation CI.

3. Dushness Freshness/Completeness et alertes pour critique.

4. DLQ/Quarantine + runbook de corrections.

• Extension des règles (FK/accuracy), simulateur « dry-run », A/B inclusions.
• Intégration avec lineage, accords d'exclusion et SLA.
• Streaming DQ sur ingest pour les sources « bruyantes ».

• Auto-génération de la documentation sur les règles, métriques de coût.
• « Contours de contrôle », rétrospectives hebdomadaires.
• SDK de plateforme Rule-as-Code, registre des vérifications de domaine standard.

18) Chèque-liste avant la vente

• Contrats et schémas dans le registre, les tests d'interopérabilité passent.
• Les règles YAML sont tornadées, la severity/escalade est assignée.
• Les dashboards et les alertes sont actifs ; Les SLO sont définis et harmonisés.
• DLQ/Quarantine disponible, runbooks documentés.
• Les procédures d'exemption/actes de swerok sont harmonisées avec la législation/conformité.
• Mesures du coût des inspections et limites pour les demandes lourdes.

19) Erreurs fréquentes et comment les éviter

Données brutes sans contrats : entrez schema-first et consumer-tests.
Vérifications « manuelles » : traduire en DQ-en-code et CI.
Pas de priorité : séparez les canaux critical/major/mineur et alert.
Pas de DLQ : il n'y a rien à travailler avec les erreurs - ajoutez la quarantaine.
Ignorer le coût : Profiler les demandes, utiliser la matérialisation.
Il n'y a pas de post-mortem : les erreurs sont répétées - entrez CAPA et le contrôle des régressions.

20) Résultat

Le système de contrôle de la qualité des données n'est pas un ensemble d'inspections disparates, mais un programme géré : contrats et schémas, code DQ, observation et SLO, discipline des incidents et sverka. En suivant cet article, vous obtiendrez des données reproductibles, vérifiables et rentables suffisantes pour les rapports réglementaires, les solutions de produits et les détecteurs de risques réels.