Réponse courte
Un catalogue de jeux utilisé pour les achats, l’intégration et l’exploitation doit être davantage qu’une liste d’affichage de fournisseurs et de titres. Il doit au minimum indiquer ce qu’identifie l’enregistrement, sa provenance, la version concernée, son statut actuel et la personne qui l’a revu, avec sa date. Langue, devise, marché cible, certification et statut de mise en production exigent aussi des champs distincts ; ils ne peuvent être réduits à un indicateur ambigu « disponible ».
Le catalogue actuel est un instantané au niveau des noms, daté du 7 août 2026 : 11 fournisseurs et 1 194 noms de jeux. Il sert à la découverte initiale et à la gouvernance du catalogue, mais ne contient ni codes de jeu, versions, modèles mathématiques, couvertures, démos, champs d’API, certifications ni disponibilité en temps réel. Il ne permet donc pas d’établir qu’un jeu précis est disponible pour un projet. Le nombre et la date ne prouvent ni fourniture en temps réel, ni activation en production, ni droits de tiers, ni disponibilité sur un marché cible.
Pourquoi une liste de noms n’est pas encore un catalogue produit
Les noms indiquent les entrées collectées, mais ne relient pas de façon fiable un enregistrement à une API, un changement de version, un résultat de test ou un marché cible. Noms dupliqués, titres renommés, habillages différents et jeux de même type aux modèles mathématiques différents peuvent rendre la correspondance par nom inexacte.
La gouvernance ne consiste pas à remplir chaque champ à tout prix ; elle rend chaque décision traçable à un enregistrement doté d’une source, d’une date et d’un responsable. Lorsqu’une valeur manque, l’état approprié est en attente de vérification, et non une estimation fondée sur une page tierce, un nom de fichier ou une expérience antérieure.
Modèle de données minimal
Ces champs peuvent résider dans plusieurs tables, mais leur signification et leur responsabilité doivent être préservées.
| Groupe de champs | Champs minimaux | Question traitée | Orientation |
|---|---|---|---|
| Identité stable | catalog_record_id, provider_id, provider_game_code, game_name, game_type |
Que cet enregistrement identifie-t-il de manière unique ? | Utiliser des identifiants stables |
| Provenance | source_ref, source_type, source_snapshot_at, source_hash |
D’où vient l’information, quand et peut-elle être vérifiée ? | Conserver source et date |
| Version du jeu | game_version, math_model_version, client_build, release_note_ref |
Quel logiciel et modèle mathématique ont été vérifiés ? | Lier à la version livrée |
| Version d’intégration | provider_api_version, aggregator_version, integration_version |
Quelle chaîne d’interface correspond à cette version ? | Enregistrer la topologie complète |
| Cycle de vie | record_status, status_reason, effective_from, effective_to |
Où se situe l’enregistrement dans son cycle de vie ? | Utiliser des états contrôlés |
| Statut d’environnement | staging_status, production_status, demo_status, last_verified_at |
Qu’a-t-on réellement vérifié dans chaque environnement ? | Séparer chaque environnement |
| Dimensions de support | language_codes, currency_codes, device_scope |
Langues, devises et appareils vérifiés ? | Ne pas les déduire du titre |
| Marché et certification | market_code, operator_scope, certificate_ref, certificate_scope, certificate_status |
Quelle preuve couvre cet objet, cette version et ce périmètre ? | Cartographier chaque marché |
| Droits et restrictions | content_rights_scope, territory_restriction, usage_restriction, evidence_ref |
Quelles limites d’affichage, démo, distribution ou usage ? | Stocker les droits séparément |
| Responsabilité et revue | data_owner, reviewer, updated_at, next_review_at, change_reason |
Qui maintient et confirme l’enregistrement, et quand le revoir ? | Préserver responsabilité et calendrier |
Ne réutilisez pas trois identifiants différents comme s’ils ne faisaient qu’un
catalog_record_idest l’identité interne stable d’un enregistrement et doit rester traçable lorsque son nom d’affichage change.provider_game_codeest l’identifiant de jeu utilisé par le fournisseur ou l’interface en amont ; il doit provenir d’un document d’interface ou de livraison vérifiable.- Un slug de page ou un alias marketing ne sert qu’à la présentation. Il ne doit pas devenir la clé primaire des transactions, de la certification ou de la correspondance des versions.
Provenance, statut, version, mises à jour et responsabilité
1. La provenance doit être traçable
Pour chaque importation, conservez le type de source, l’emplacement ou la référence documentaire, l’instantané et le lot d’importation. Si une source est remplacée, conservez la période d’effet de l’ancien enregistrement au lieu d’écraser son historique. Une page tierce peut suggérer des données candidates, mais ne doit pas constituer l’unique preuve des droits, de la version ou de la disponibilité actuelle.
2. Le statut doit identifier son objet et sa dimension
| Statut | Signification | Ce qui peut être déclaré publiquement |
|---|---|---|
draft |
L’enregistrement existe mais l’identité ou la provenance critique n’a pas été revue | Ne pas publier |
pending_verification |
Des documents candidats existent mais les preuves sont incomplètes | Indiquer seulement que la vérification est en cours |
verified_current |
Une version et un environnement sont vérifiés à une date donnée | Indiquer seulement le périmètre vérifié |
suspended |
Désactivé temporairement après expiration de preuve, incident ou restriction | Ne pas présenter comme disponible |
retired |
Non maintenu ou remplacé par une version récente | Conserver l’historique, omettre du catalogue actuel |
« Enregistré dans le catalogue », « vérifié en préproduction », « activé en production » et « disponible sur le marché cible » sont des états distincts. Aucun n’implique les autres.
3. Les changements de version doivent déclencher une revue d’impact
Tout changement de jeu, modèle mathématique, RGS, agrégateur, contrat d’API, règles de devise, ressources linguistiques ou exigences du marché cible doit déclencher une revue d’impact. Reliez son résultat aux preuves de test ou de certification mises à jour ; une conclusion sur une ancienne version ne se prolonge pas automatiquement.
4. Chaque mise à jour exige une chaîne de responsabilité
- Le responsable des données importe ou propose un changement avec sa provenance et son motif.
- Les contrôles automatisés valident identifiants stables, champs requis, doublons et états contrôlés.
- Les responsables technique, métier ou conformité examinent les champs de leur périmètre.
- L’approbation crée une version ou actualise la période d’effet sans effacer les preuves historiques.
- Une date de revue, une source invalide ou une version critique renvoie l’enregistrement à l’état en attente de vérification.
- Les pages publiques ne lisent que les champs et états approuvés pour l’affichage.
Priorités lors de l’évolution d’un catalogue
Ne générez pas directement des centaines de pages détaillées à partir d’une liste de noms. Suivez l’ordre de valeur décisionnelle :
- Ajoutez les identifiants stables des fournisseurs et jeux, la provenance et les responsables.
- Ajoutez la version de jeu, celle d’interface et le statut de préproduction requis pour une intégration réelle.
- Pour les jeux entrant dans une évaluation de marché, ajoutez marché, entité exploitante, langue, devise, objet et périmètre de certification.
- Ajoutez couvertures, démos et descriptions seulement après confirmation des droits sur les éléments et des sources.
- Créez un contenu détaillé uniquement si un projet réel le requiert et si les preuves sont suffisantes.
Ce que fournit le catalogue actuel
- Un instantané du 7 août 2026, au niveau des noms, avec 11 fournisseurs et 1 194 noms de jeux ;
- les noms des fournisseurs et jeux pour une première consultation et discussion du périmètre de contenu ;
- ni inventaire temps réel, ni liste de production, ni dépôt de versions, de droits ou de certifications ;
- le cadre de gouvernance de cet article pour les champs, états et responsables à mettre en place.
Limites à garder à l’esprit
- Aucun jeu répertorié n’est promis comme appelable, jouable, lançable ou disponible en production.
- Le catalogue ne prouve ni autorisation du fournisseur, ni droits d’utilisation des éléments, ni autorisation de marché cible, ni validité de certification.
- Langue, devise, connectivité d’interface et inclusion au catalogue n’établissent pas la légalité sur le marché.
- N’inventez pas codes de jeu, RTP, versions, modèles mathématiques, couvertures, liens de démo ou identifiants de certificat.
FAQ
Un nom de jeu présent dans le catalogue signifie-t-il qu’il peut être intégré immédiatement ?
Non. Il indique seulement qu’une entrée figure dans la source sous-jacente. Il faut encore vérifier le code de jeu fournisseur, l’interface et la version de jeu, le statut d’environnement, les droits commerciaux et les conditions du marché cible.
Pourquoi enregistrer séparément la version du jeu et celle du modèle mathématique ?
Une mise à jour visuelle ou client peut ne pas modifier le modèle mathématique ; un changement de modèle peut exiger de nouveaux tests et une nouvelle revue de certification. Des champs séparés identifient l’objet réellement couvert par les preuves existantes.
Les champs manquants peuvent-ils être remplis automatiquement depuis les sites des fournisseurs ?
Les pages publiques peuvent servir de pistes candidates, à condition de conserver la source et de placer la valeur en attente de vérification. N’utilisez-la pour une décision de projet qu’après confirmation par le document applicable, l’interface active ou le responsable compétent.
À quelle fréquence mettre le catalogue à jour ?
Ne vous fiez pas à un calendrier fixe seul. Un changement de source, une sortie de version, un incident de statut, l’expiration d’une preuve ou une évolution des règles de marché doit également déclencher une revue.
Lectures associées et prochaines étapes
- Comprendre la frontière d’une API de slots multi-fournisseurs
- Évaluer un fournisseur d’API de slots à partir de preuves
- Construire une matrice marché–jeu–version–certification
- Utiliser une terminologie cohérente pour les API de slots
- Pages principales : catalogue de jeux et référence publique de l’API.
Avant d’utiliser la section « Contactez-nous », préparez le marché cible, les fournisseurs ou le périmètre de jeux proposés, le modèle de portefeuille et les environnements attendus. AG pourra alors indiquer les champs de catalogue et preuves à vérifier pour ce périmètre. Cela ne promet ni fourniture, ni droits, ni admission en production.
Sources et périmètre
Le décompte du catalogue s’applique uniquement à l’instantané du 7 août 2026. Un projet précis doit toujours vérifier le statut de l’enregistrement, les droits d’affichage et les preuves relatives au marché cible.
Transformer ce guide en plan de projet ?
Ce contenu aide à préparer une évaluation. Il ne remplace pas la confirmation technique, contractuelle, de certification ou de droit local applicable au projet.