Moteur de catalogue de contenu

Le moteur de catalogue est le noyau des vitrines de jeux et des sélections promotionnelles sur le front : il recueille et normalise les métadonnées des fournisseurs (RGS), fournit des recherches/filtres/classements, applique les règles d'accessibilité par pays et par marque, stimule la personnalisation et les places promotionnelles, puis donne des réponses rapides via l'API avec un SLO prévisible.

1) Objectifs et principes

Lectures rapides : p95 ≤ 100-150 ms pour une requête catalogue/recherche.
Vérité et fraîcheur : pertinence garantie des attributs clés (disponibilité, jackpots, statuts de fournisseurs).
Flexibilité : collections éditoriales et slots promotionnels sans sortie.
Conformité : règles de géo/âge/contenu, licences, restrictions de jeu responsable.
Multi-tenant/région : isolation des marques et respect de la résidence de données.
Observabilité : métriques de qualité d'émission, A/B, conversion en jeu/pari.

2) Modèle de domaine (minimum)

• Game est un jeu/produit fournisseur.
• Provider - RGS/studio.
• Variant est une variante d'un jeu (volatilité, lignes, limites, serveur).
• Collection est une sélection éditoriale/automatique (par exemple, « Nouveautés », « Jackpots »).
• Placement - position fixe/bannière/mystère sur la page/dans la fente.
• Capability/Feature - attributs du jeu (free spins, buy feature, jackpot).
• JurisdictionRule - Règles d'accessibilité/restrictions.
• Signaux - signaux comportementaux/opérationnels (popularité, CTR, revenu).
• Asset est un média (icônes, affiches, vidéos de démonstration) avec des options pour les appareils/densités.

Clés : 'game _ id' (stable intérieur, non égal à provider_game_id), 'tenant _ id', 'region', 'locale'.

3) Ingest et la normalisation

1. Adaptateurs Source : intégrations avec RGS/studios (catalogues, fiches, RTP, étiquettes).

2. Sanitize & Map : mapping de champs externes en un seul dictionnaire (ACL), validation et déduplication.

3. Enrich : localisations, catégories, étiquettes sémantiques, classements des limites d'âge.

4. Modération : drapeaux de contenu (NSFW/symboles religieux/sujets sensibles) sur les marchés.

5. Publish : événements 'GameUpserted/ProviderStatusChanged' → projection du catalogue.

Idempotence : tous les messages avec 'source _ id' + 'version _ ts' ; la répétition est traitée sans effets secondaires.
Schéma d'évolution : 'schema _ version' dans les adaptateurs + migration des muppers.

4) Schéma normalisé (simplifié)

json
{
"game_id": "g_3f92",
"tenant_id": "brand_eu",
"provider": { "id": "pr_evolution", "name": "Evolution" },
"title": { "en": "Lightning Roulette", "de": "Lightning Roulette" },
"capabilities": ["live","roulette","multiplier","bonus"],
"rtp": 97.3,
"volatility": "high",
"limits": { "min": 0.1, "max": 1000.0, "currency": "EUR" },
"jurisdiction": {
"allowed": ["MT","EE","DE"],
"blocked": ["NL","BE"],
"age_rating": 21
},
"assets": {
"tile": { "1x":"...", "2x":"..." },
"poster": { "web":"...", "mobile":"..." }
},
"tags": ["new","jackpot"],
"release_date": "2025-09-12",
"status": "active",
"variants": [{ "id":"v1","server":"eu-central-1","rtp":97.3 }]
}

5) Recherche, filtres, facettes

Index : texte intégral par nom/synonymes, facettes par 'provider', 'capabilities', 'volatilité', 'rtp _ bucket', 'tags'.
Filtres : juridiction/région/langue/appareil/âge, actif/certifié seulement.
Synonymes/stemming : carte de termes personnalisés (« livres », « fruits », « boules »).
Erreurs typographiques : recherche tolérante (edit distance ≤1 -2) avec limitation de longueur.

6) Classement : Signaux et formule

• Freshness (heure de sortie).
• Popularity (lancements/heure, joueurs uniques).
• Qualité (CTR du catalogue au jeu, maintien 1/7 jour).
• Business (boosts marketing, transactions, slots promotionnels).
• Conformité (baisses douces pour le contenu sensible si nécessaire).
• Player-fit (compatibilité profil/préférences).

score = w1freshness + w2popularity + w3ctr + w4player_fit + w5boost

Les poids sont contrôlés par la configuration/les expériences ; tous les signaux sont normalisés à [0 ; 1].

7) Personnalisation

Mémoire courte : les derniers lancements et genres, RYW - l'utilisateur voit immédiatement de nouvelles actions.
Longue mémoire : embeddings de jeux et profils de joueurs (genres de jeux/volatilité/sessions).
Sécurité : la personnalisation ne viole jamais les règles de compétence/âge.
Fallback : s'il y a peu de signaux, un classement neutre + des collections éditoriales.

8) Collections et jeux promotionnels

• Auto : règle/requête (par exemple, 'capabilities contains'jackpot 'AND release_date> = NOW () -30d').
• Éditorial : liste manuelle avec ordre et délais.
• Places : positions fixées sur les pages (hero, row-1-slot-3), A/B, ciblage par segments/juridictions.
• Échéancier et priorités : 'starts _ at/ends _ at', priorité des conflits, prévisualisation avant publication.

9) Conformité et politique d'accessibilité

Géo/juridiction : liste blanche/noire des pays/régions, vérification des licences/certificats.
Classement par âge : âge minimum, avertissements, dissimulation pour les marchés incompatibles.
Thème/symbole : drapeaux de contenu sensible par pays (religion, alcool, etc.).
Jeu responsable : masquage/rétrogradation pour les joueurs avec des limites/temps d'arrêt.
Audit : un journal invariable des changements de disponibilité avec des raisons.

10) Multi-tenant et multi-région

Toutes les données sont marquées par 'tenant _ id' et 'region'.
Isolement : quorums/entrepôts par région ; les projections croisées régionales ne sont que des agrégats.
Fairness : quotas d'ingest/publications per tenant pour que la marque « bruyante » ne retarde pas les autres.

11) Contour architectural

Noyau Write du catalogue (CP) : Normalisation + événement transactionnel outbox.
Projections/Modèles de lecture (EC) : indices de recherche, collections matérialisées, compteurs de popularité.

• Edge/CDN pour les pages/images « froides ».
• Cache en mémoire pour les requêtes chaudes (key = filtres + page + tenant + région).
• Ficheflagi : laminage des règles de classement/collections sans libération.

12) API (REST/GraphQL, exemples)

REST

GET /v1/catalog?tenant=brand_eu&region=EE&locale=ru
&filter=jackpot,true&sort=score_desc&page=1&size=24
→ 200 { items:[...], facets:{...}, as_of:"2025-10-31T12:10:02Z" }

GraphQL (fragment)

graphql query Catalog($tenant:String!,$region:String!,$q:String,$filters:Filters){
catalog(tenant:$tenant, region:$region, q:$q, filters:$filters){
items { gameId title provider { name } score badges assets { tile } }
facets { providers { key,count } capabilities { key,count } }
freshnessMs
}
}

• Retournez toujours 'as _ of/freshnessMs', paging, facettes.
• Pour personnaliser, un marqueur de session (RYW) sans PII.

13) Signaux et flux de données

Popularité : incréments lors du lancement des jeux → des baquets de minutes → des agrégats dans la projection.
CTR/conversion : click-compteurs/lancements sur les listes de lecture/collections.
Statuts opérationnels : fournisseurs de soins de santé (SGRR), jackpots/limites (streaming d'événements).
Marketing-boost : coefficients de temps pour les jeux/catégories/fournisseurs.

14) Observabilité et SLO

• `catalog_p95_ms`, `catalog_p99_ms`, `error_rate`.
• 'Index _ freshness _ ms', 'ingest _ lag _ ms'.
• 'ctr', 'click-to-launch', 'collection _ coverage' (% de sortie des collections).

• `lift_ctr`, `lift_conversion`, «explore vs exploit» доля.

• % de règles géo/âge correctement appliquées, nombre de blocs/heure.

Alert : croissance de 'ingest _ lag _ ms', chute du CTR sur les collections clés, dégradation du fournisseur (marques dans l'émission).

15) Performances et mise en cache

Stratégie : Demandes chaudes - Cache 30-120 avec clé par filtre ; les blocs personnels sont courts TTL (10-30 s) ou sans cache.
Handicap : par événement 'GameUpserted/AvailabilityChanged/PlacementUpdated'.
Pagination : curseurs stables pour éviter de « sauter » les cartes lors de la mise à jour des signaux.

16) Travailler avec les médias

Profils de rendu : dimensions/densités pour web/mobile/TV.
Optimisation : WebP/AVIF, lazy-load, sprite/atlas pour les tuiles.
Sécurité du contenu : scan, filigrane, interdiction inline-PII.

17) Tests

Contract/Schema tests pour adaptateurs et API.
Tests relationnels : ensembles de demandes en or → résultats attendus/ordre.
Personnalisation : hors ligne AUC/NDCG + online A/B avec métriques de garde (temps de jeu, dépôts, signaux RG).
Chaos : dégradations des fournisseurs, surtensions d'ingest, retards d'indexation.

18) Pleybooks (runbooks)

1. Index> SLO : arrêter les collections secondaires, augmenter la priorité ingest, simplifier temporairement le classement.
2. Fournisseur « rouge » : abaisser/cacher ses jeux, soulever des collections alternatives.
3. Saut d'erreur API : vérifier le cache/backend, activer les temps de garde, réduire la taille des pages.
4. Disponibilité incorrecte : abaisser la dernière règle, inclure une « liste blanche » des marchés critiques, vérifier les changements.
5. Sortie de classement : rollout canarien (5 % → 25 % → 50 % → 100 %), retour sur CTR/conversion.

19) Erreurs typiques

Mélanger les schémas externes des fournisseurs avec le modèle interne (pas d'ACL).
L'absence de 'as _ of/freshness' → le débat sur le répertoire « obsolète ».
Personnalisation contraire aux règles de juridiction.
La seule formule de classement « magique » sans décomposition des signaux et A/B.
Grandes pages sans cache et curseurs → p99 « tirent ».
Dual-write dans l'index et OLTP au lieu d'événements + projections.

20) Chèque-liste avant la vente

• Dictionnaire normalisé des champs et ACL pour tous les fournisseurs.
• Idempotent ingest, outbox/inbox, DLQ et redrave.
• Projections de catalogue et index de recherche avec SLO de fraîcheur.
• Classement avec poids contrôlé, décomposition des signaux et A/B
• Règles de conformité (géo/âge/sujet) et audit du changement.
• Multi-tenant/région : isolation des données, fairness, residency.
• API avec 'as _ of', facettes, curseurs ; cache et invalidation par évènement.
• Métriques p95/p99, ingest/indexation, CTR/conversion ; alerte.
• Pleybooks d'incidents ; sorties canaries et ficheflags.
• Tests de pertinence, contrats, chaos et personnalisation.

Conclusion

Le moteur de catalogue est un « moteur de recherche + système de règles + vitrine » au-dessus du contenu du jeu. Une ACL forte, des données normalisées, des projections pour des lectures rapides, des signaux de classement transparents, une personnalisation avec des métriques de garde et une stricte conformité transforment le catalogue en un levier de croissance durable et mesurable - sans surprise dans la production et sans compromis avec les régulateurs.