MLOps : exploitation des modèles

1) Le rôle de l'exploitation dans iGaming

Dans iGaming, les modèles affectent l'argent réel et la réglementation : interventions RG, antifrod, paiements, KYC, limites, offers et recommandations. L'exploitation est une alimentation fiable des prédictions avec des SLO garantis, la traçabilité et la sécurité.

• Des sorties et des retours prévisibles sans interruption de service.
• Cohérence des données et phic offline/online.
• Observabilité : qualité, dérive, honnêteté, intimité.
• Réduction du TCO : performances, cache, mixages GPU/CPU.
• Conformité (audit/DSAR/Legal Hold/éthique).

2) Architectures de Serving

Batch (hors ligne) : scores nocturnes/horaires (limites, segments). Avantages : moins cher, plus stable. Inconvénients : pas de réaction instantanée.
Stream (near-real-time) : traitement des événements (paris, anomalies) avec fenêtres 1-5 min.
Online (sync API) : <100-300 ms p95 pour les solutions UX/risque, la mise en cache et la dégradation.
Hybride : « baseline de batch + clarification en ligne » (exemple : risque RG en 7 jours + déclencheurs de session en ligne).

• Ensemble/Stacking avec un « modèle de gate » léger sur le chemin critique.
• Fallback-heuristique en cas de défaillance du modèle/fich.
• Circuit Breaker et rate limiting aux pics ou à la dégradation des fournisseurs.

3) Registre des modèles et gestion des versions

Registre des modèles : versions, propriétaires, date de sortie, métriques (AUC/PR, étalonnage), dataset_version, feature_set_version, restrictions d'utilisation.
Carte modèle (Model Card) : tâche, données/fiches, section fairness/privacy, zones à risque, fréquence de la rumeur.
Politique de libération : 'MAJOR. MINOR. PATCH' + plan rollback obligatoire.
Champion-Challenger : un challenger parallèle avec des rapports ; promotion automatique lorsque les critères sont remplis.

4) Fiches en ligne et cohérence

Feature Store : offline (formation) et online (inference) vitrines avec des contrats stricts.
Temps de voyage et point-in-time join pendant la formation.
Idempotent update fich et protection contre les fuites de target.
La coordination : les garanties "read-your-writes" ou SLA les livraisons (par exemple, ≤ 60 fouettait).
Politique de caractéristiques : allow/feuilles de deny, masquage, tokenization, interdiction de proxy-PII.

5) Stratégies de libération

Shadow : toute la charge de travail est → champion ; challenger reçoit une copie des demandes, les réponses n'affectent pas l'entreprise.
Canary : 1-10 % du trafic → la nouvelle version ; Comparaison KPI/métriques, auto-retour par seuil.
Bleu-vert : deux pools de serveurs/endpoints ; basculement DNS/route.
Drapeaux : réglage fin par marchés/tenants/canaux.

6) Observabilité et alerting

• Fiabilité : error rate, timeouts, p50/p95/p99 latency, QPS, saturation.
• Données/fiches : fraîcheur, exhaustivité, distributions, anomalies, omissions, schema drift.
• Qualité : étalonnage, métriques post fact (AUC/PR, uplift), réponse aux interventions.
• Dérive : aux entrées (PSI/KS) et aux sorties (score drift).
• Éthique/équité : EO/EOp-delta, disparate impact.
• Vie privée : Attack-AUC (membre/inversion) ≈ 0. 5, ε -urage (si DP).
• Business : chargeback, interventions RG, conversion des offers - avec décomposition par segments.

• p95 latitude ≤ 200 ms (scoring en ligne RG/antifrode).
• Error rate ≤ 0. 1 % 5 min. moyenne.
• Drift PSI ≤ 0. 2 par fiches clés ; EOp-delta ≤ 3 pp
• Freshness fich ≤ 60 secondes ; Passe ≤ 0. 5%.
• Étalonnage ACE ≤ 0. 02.

7) Incidents et playbooks

Niveaux Sev : P1 (blocage de paiement/erreur RG), P2 (augmentation des erreurs> seuil), P3 (dégradation de la qualité).
Auto-mitigation : passer à champion, réduire la fréquence des demandes, inclure des règles fallback, isoler les fiches « toxiques ».
Runbooks : les checklists pour « fiches obsolètes », « dérive croissante », « typisation du fied changé », « GPU épuisé ».
Post-mortem : RCA, plan fix, mise à jour des tests/seuils/contrats.

8) Expérimentation et contrôle du changement

A/B et bandit multi-armed - avec stratification par groupes clés seulement (pays/canal/appareil).
Règles éthiques d'arrêt : avec une forte augmentation des risques RG/plaintes.
Dual-run vitrine fich et modèles avant de basculer.
Versioning KPI et définitions (BI contract) pour une interprétation stable des résultats.

9) Sécurité et vie privée dans la vente

mTLS/TLS 1. 3, signature des requêtes, anti-replay (nonce/idempotency).
Secrets de Secret Manager, émission JIT, audit.
Tokénisation des entrées/logs ; interdiction des PII dans les voies.
TEE/Inference confidentielle pour les paiements VIP/AML (si nécessaire).
Politiques d'accès (RBAC/ABAC/JIT) aux dattes et aux endpoints.
DSAR/Legal Hold : une piste de solutions d'explication et de suppression par token.

10) Performance et coût

Cache (feature/score) avec TTL, en particulier pour les signaux stables.
Quantification/distillation pour accélération (INT8/FP16).
Skaling automatique : horizontal par QPS/latency, vertical par batch-size.
Hybride CPU/GPU : critique de latitude sur GPU, « masse » sur CPU.
Tracer les démarrages froids, réchauffer le modèle.
Pool de modèles et « sticky routing » par marchés/tenants pour la localisation cache.

11) Case iGaming (références)

RG-scoring : scoring en ligne à l'entrée et aux sessions ; overrides stricts (auto-exclusion), la métrique cible est EOp + étalonnage.
Antifrod/paiements : décisions d'autorisation <150 ms ; Contrôle EO FPR, agrégateurs de signaux robustes.
KYC/AML : support de fichiers thin ; PSI/MPC avec un partenaire ; Compatibilité DSAR.
Personnalisation : modèles uplift et limites de fréquence ; exclusion du risque élevé des offers agressifs.

12) Métriques et SLO d'exploitation (exemple)

13) Modèles d'artefacts

13. 1 Notes de sortie (croquis)

Modèle : 'rg _ risk @ 2. 1. 0` (MINOR)

Modifications : ajout de ficha 'loss _ streak _ 7d' ; étalonnage mis à jour

Validation : shadow 14 jours ; delta KPI ≤ 0. 3%; L'EOp-delta est normal

Rollout: canary 10% EU → 50% → 100%

Rollback : drapeau 'rg. use_v1=true`

Propriétaire/date/tiquet

13. 2 Carte modèle (fragment)

Tâche : antifrod de paiement

Données : 'payments _ gold v3. 2 ', fich set' payout _ signals v1. 7`

Métriques : ASC = 0. 89, ACE=0. 015, FPR @ opéra. seuil = 1. 2%

Fairness: EO TPR/FPR Δ ≤ 2 п.п. по «country/method»

Restrictions : Clients VIP - seulement avec examen humain

Vie privée : TEE-inference ; Logging sans PII

Revue : une fois tous les 90 jours

13. 3 Politique de SLO endpoint (fragment)

yaml endpoint: /v1/score/rg slo:
latency_p95_ms: 200 success_rate: 0. 995 max_error_burst_per_5m: 50 data:
feature_freshness_s: 60 allowed_missing_pct: 0. 5 ethics:
eop_delta_pp: 3 privacy:
attack_auc_max: 0. 55

13. 4 Runbook « Fichi est obsolète »

1. Vérifiez la larme dans Feature Store et la source du fid.
2. Changer de canal/cache de secours.
3. Réduire le trafic/activer les règles fallback.
4. Communication dans # ml-status ; L'incident P2/P1 l'ALS.
5. RCA et modifications de contrats/retraits.

14) Processus de test avant la sortie

Contrats fich : schema/enum/nullable, SLA de fraîcheur.
Données : Tests DQ, point-in-time, fuite de ciblage.
Modèle : unité/intégration, étalonnage, stress/charge.
Sécurité : secrets, mTLS, Zero-PII dans les logs.
Éthique/vie privée : fairness-chèque, attack-suite.
Observabilité : dashboards/alerts, configi SLO.
Documentation : Release Notes + plan de rollback.

15) RACI (exemple)

ML Lead (A/R) : qualité, versions, métriques.
Data Platform (R) : Feature Store, registre, orchestration, observabilité.
Domaine Owners (R) : contrats sources/fich.
Sécurité/DPO (A/R) : accès, vie privée, tokenization, TEE.
SRE/SecOps (R) : incidents, SLO, auto-skale, SOAR.
Analytics/Finance (C) : impact sur les KPI et les rapports.
Support/RG/Risk (C) : human-in-the-loop et explication.

16) Feuille de route pour la mise en œuvre

0-30 jours (MVP)

1. Model Registry + cartes pour les modèles à impact élevé (RG/paiements/antifrod).
2. Surveillance de base : latency, errors, freshness, drift entrées.
3. Shadow-lancer de nouvelles versions, canary-contours.
4. Les contrats Fich et Zero-PII dans les loges.
5. Runbooks et la chaîne # ml-status.

30-90 jours

1. Champion-Challenger et auto-promotion selon les critères.
2. Fairness/privacy-gates en CI/CD, attack-suite.
3. Mise en cache, quantification, scale automatique ; budget SLO/coût.
4. BI/ML harmonisation KPI et métriques en ligne ; Dashboards SLO.

3-6 mois

1. Des post-mortems réguliers, des modèles trimestriels.
2. Géo/tenant-isolation des endpoints, clés et fiches.
3. TEE/MPC pour les paiements d'infériorité privés/AML.
4. Automatisation complète de Release Notes à partir d'une ligne et d'un diff.
5. Audit externe des processus (lorsque la licence est requise).

17) Anti-modèles

Sortie sans plan shadow/canary et rollback.
Hors ligne/fiches en ligne incohérentes → dégradation.
Logs avec PII, pas de token-policy.
Des seuils « éternels » sans révision ; ignorer la dérive et l'étalonnage.
L'absence de solutions de risque élevé.
Des expériences sans stratification et sans règles éthiques.

18) Sections connexes

Pratiques DataOps, Contrôle d'accès, Tokenization des données, Sécurité et cryptage, Audit et versionalité, Réduction des biais, Confidentialité ML, Federated Learning, Politiques de stockage, Origine et chemin des données, Éthique des données.

Résultat

L'exploitation des modèles est une discipline d'ingénierie au niveau des services de production : contrats et versions clairs, sorties prévisibles, observation 24/7, risques d'éthique/vie privée gérés et impact transparent sur les entreprises. C'est ainsi que ML devient un produit fiable, pas « le meilleur script d'un ordinateur portable ».