Cet article présente une méthode d’achats et de gouvernance de projet. Il ne constitue pas un avis juridique et ne remplace pas un examen professionnel de conformité pour un marché cible.

En bref

« L’API renvoie le jeu », « le produit prend en charge cette langue ou cette devise » et « il existe un rapport de laboratoire » ne peuvent, chacun isolément, prouver qu’un jeu peut être lancé sur un marché cible. Une unité de vérification fiable comprend au minimum :

marché × jeu × version du jeu × version du modèle mathématique × objet et périmètre de certification × devise × langue × version de la topologie d’intégration × périmètre de l’entité exploitante

Lorsque le jeu, la version, le modèle mathématique, le RGS ou l’agrégateur, la plateforme, l’entité exploitante, la marque ou le domaine change, une conclusion antérieure peut ne plus s’appliquer. L’objectif de la matrice n’est pas d’étiqueter un contenu comme « légal dans le monde entier ». Elle relie chaque décision de lancement du projet à un objet défini, un périmètre, des preuves actuelles et un responsable désigné.

Pourquoi les six dimensions principales ne peuvent pas être fusionnées

Dimension Question à vérifier Erreur fréquente
Marché Quel pays ou périmètre réglementaire, quelle entité exploitante, marque et domaine ? Traiter « mondial » ou « Amérique latine » comme un périmètre exécutable
Jeu Quels sont le code de jeu du fournisseur et l’ID stable d’enregistrement de catalogue ? Faire correspondre uniquement le nom d’affichage ou le skin
Version Quelles sont les versions du jeu, du modèle mathématique, du RGS, de l’agrégateur et de la plateforme ? Considérer toutes les versions d’un même titre comme équivalentes
Certification Qui a testé quel objet, quelles exigences et quel périmètre, et les preuves sont-elles actuelles ? Traiter une norme de laboratoire ou un seul rapport comme un laissez-passer mondial
Devise Quelles devises et précisions s’appliquent à l’affichage, aux mises, au règlement et au reporting ? Traiter la prise en charge technique d’une devise comme une autorisation de marché
Langue Quelles langues s’appliquent aux règles destinées aux joueurs, à l’aide, à l’interface et aux communications opérationnelles ? Traiter une traduction comme la preuve de préparation au marché

La langue, la devise et la connectivité API sont des dimensions produit et techniques nécessaires, mais elles ne constituent pas la légalité sur un marché. Inversement, l’autorisation d’une entité exploitante sur un marché ne prouve pas que chaque jeu, version ou topologie d’intégration satisfait aux exigences.

Un processus de vérification par couches

Couche 1 : connectivité technique

Confirmez les versions d’interface, identités, modèle de portefeuille, rappels, manches et chemin de transaction entre le fournisseur, le RGS ou l’agrégateur, et la plateforme dans l’environnement spécifié. La connectivité montre que les composants testés peuvent interagir. Elle ne dit rien, à elle seule, sur les droits de contenu ou l’admission sur un marché.

Couche 2 : identité et version du contenu

Identifiez un jeu à l’aide de son code de jeu fournisseur, plutôt que de son nom d’affichage. Enregistrez la version du jeu, la version du modèle mathématique, la build client, les notes de modification et la date de vérification. Un skin, un clone ou un jeu du même type ne peut pas hériter d’une autre conclusion sans preuves.

Couche 3 : langue et devise

Vérifiez séparément le texte de l’interface, les règles du jeu, le contenu d’aide, la précision des mises et du règlement, les rapports et le traitement des exceptions. Réussir une vérification de langue ou de devise signifie seulement que le périmètre fonctionnel testé a été validé — pas la dimension de marché.

Couche 4 : objet et périmètre de certification

Enregistrez l’ID du rapport ou certificat, l’organisme émetteur ou de test, les exigences, l’objet testé, la version, la topologie d’intégration, l’état actuel et les déclencheurs de nouveau test. Confirmez que l’organisme choisi est actuellement reconnu sur le marché cible et que son périmètre reconnu couvre l’objet du projet.

Couche 5 : périmètre opérationnel et de marché

Les responsables appropriés doivent vérifier les règles du marché cible, l’entité exploitante, la marque, le domaine, les droits de contenu, les restrictions et les enregistrements réglementaires actuels. Ne substituez pas des déclarations génériques d’un fournisseur, d’un agrégateur ou d’un laboratoire à une conclusion spécifique au projet.

Couche 6 : décision de production du projet

Les responsables techniques, de contenu, de certification, commerciaux et de conformité valident leurs domaines respectifs. Ce n’est que lorsque chaque couche requise dispose de preuves actuelles que l’enregistrement du projet peut devenir approved_for_project. Cet état n’est ni permanent ni mondial.

Un modèle de matrice

Utilisez une ligne pour une combinaison précise. Si un jeu possède deux modèles mathématiques ou deux versions de RGS, utilisez deux lignes.

Groupe de champs Champs suggérés Règle de saisie
Périmètre du projet market_code, operator_entity, brand, domain_scope Nommez l’objet précis ; n’écrivez jamais « mondial »
Identité du jeu provider_id, provider_game_code, catalog_record_id Liez au catalogue par des ID stables
Versions game_version, math_model_version, rgs_version, aggregator_version, platform_version Réévaluez l’impact après chaque changement
Certification certificate_or_report_id, test_body, requirements_ref, tested_object, scope, status Conservez la couverture, pas seulement un PDF
Localisation currency_code, language_code, rules_language Enregistrez séparément la vérification technique et celle du contenu
Preuves evidence_ref, issued_at, last_verified_at, next_review_at Préservez la source et la date
Décision decision_status, conditions, owner, approved_at S’applique uniquement à cette combinaison de projet

Utilisez des états de décision contrôlés tels que :

  • evidence_missing : un objet ou une source critique est absent ;
  • pending_review : les éléments sont arrivés, mais le responsable n’a pas terminé l’examen ;
  • conditional : le travail ne peut se poursuivre que sous les conditions énoncées ;
  • approved_for_project : l’approbation s’applique uniquement à la combinaison de cette ligne ;
  • expired_or_recheck : les preuves ont expiré ou un changement a déclenché un nouvel examen ;
  • withdrawn : une décision de projet a été retirée, son motif historique étant préservé.

Évitez un booléen unique sans périmètre tel que legal, certified ou available.

Exemple du Brésil : traduire les règles de source primaire en champs de matrice

Les points suivants illustrent la méthode de vérification. Ils ne constituent pas une conclusion d’admission pour un projet quelconque.

  • La FAQ technique du Secrétariat des prix et paris (SPA) du ministère brésilien des Finances distingue les objets de preuve pouvant comprendre le système de paris, le RGS ou l’agrégateur, l’intégration entre la plateforme, le RGS ou l’agrégateur et le fournisseur de jeux, les jeux individuels et les studios de jeux en direct. Enregistrez chaque objet et connexion plutôt que d’écrire seulement « plateforme certifiée ».
  • Le point 71 de la FAQ de la SPA traite des preuves de conformité pour les jeux, skins ou jeux clonés et des certificats d’intégration. Il indique également que la SPA ne fournit pas de liste publique unique de jeux certifiés qui remplacerait la vérification de projet. Conservez le rapport et sa couverture pour chaque jeu ou groupe applicable.
  • Le point 94 de la FAQ inclut des composants critiques tels que les RGS et les agrégateurs dans la discussion sur la certification d’intégration. Lorsqu’un composant ou une version change, réévaluez si les preuves existantes couvrent la nouvelle topologie.
  • Le point 84 de la FAQ concerne la langue des informations fournies aux joueurs. La langue appartient à la matrice, mais un texte en portugais à lui seul n’établit toujours pas l’entité exploitante, la version du jeu ou la topologie d’intégration.
  • Vérifiez à la fois la liste actuelle des organismes de certification reconnus par la SPA et le périmètre de chaque organisme. L’apparition sur la liste ne signifie pas que chaque rapport émis par l’organisme couvre chaque objet ou version.

Exemples du Royaume-Uni et de GLI : norme, tests et décisions de marché diffèrent

Les normes techniques de la UK Gambling Commission pour les jeux à distance identifient des obligations pour les titulaires de licence concernés, tandis que sa stratégie de test organise les exigences autour des procédures de test, des tests annuels de jeux, du suivi du RTP et des mises à jour majeures et mineures. Cela illustre pourquoi un nouveau test après un changement de version dépend des règles actuelles du marché cible et de la véritable catégorie du changement. AG ne peut pas fournir une réponse mondiale universelle.

GLI-19 peut constituer une référence de laboratoire ou un élément des discussions de test. Elle ne constitue pas, à elle seule, une admission dans une juridiction et ne remplace pas le périmètre de reconnaissance d’un régulateur, l’autorisation de l’entité exploitante, la version précise du jeu ou les preuves d’intégration du projet. Conservez séparément « norme technique utilisée » et « preuve acceptée par le marché cible ».

Changements déclenchant une nouvelle vérification

Au minimum, faites passer une ligne à expired_or_recheck lorsque l’un des éléments suivants change :

  • le logiciel du jeu, le modèle mathématique, l’utilisation du RNG ou les règles du jeu ;
  • le RGS, l’agrégateur, la plateforme ou une version d’interface critique ;
  • le modèle de portefeuille, le flux de transaction, la précision de la devise ou la langue des informations aux joueurs ;
  • le périmètre du rapport, la reconnaissance de l’organisme de test ou la validité des preuves ;
  • l’entité exploitante, la marque, le domaine, les droits de contenu ou les règles du marché cible.

Les termes tels que « mise à jour majeure », « mise à jour mineure » et « changement de composant critique » doivent suivre les règles actuelles du marché cible, le périmètre de l’organisme de test et les enregistrements de changement. Ne les classez pas à partir d’un seul numéro de version.

Note de périmètre non vérifié pour RTP 0–1000 Cette plage numérique nécessite des définitions de son unité et de sa signification, de la version du modèle mathématique, des autorisations d’accès, du matériel de test et de certification, du marché cible et de la présentation. Elle ne doit pas être considérée comme une conclusion RTP vérifiée pour une version de jeu ou de marché, ni comme une promesse relative à un résultat individuel ou au rendement d’un joueur.

Ce qui peut actuellement être évalué sur ce site

  • Cet article fournit une méthode par couches couvrant le marché, le jeu, la version, la certification, la devise et la langue.
  • Le catalogue de jeux actuel est un instantané au niveau des noms et ne peut pas, à lui seul, remplir la matrice.
  • Le matériel API public aide à définir la topologie d’intégration, mais les protocoles de production, les autorisations et les versions de projet nécessitent toujours confirmation.
  • Les exemples de la SPA du Brésil, de l’UKGC et de GLI — ainsi que la note de périmètre RTP 0–1000 — n’établissent pas la certification ou l’admission sur un marché pour un projet.
  • Les sources primaires ne sont citées que pour expliquer les champs de matrice et les étapes de vérification.

Limites à garder à l’esprit

  • Cette page ne promet pas qu’AG, un fournisseur, un jeu ou une version est autorisé ou certifié pour un marché.
  • Une norme de laboratoire, un certificat, une langue, une devise, une API connectée ou un catalogue fournisseur ne prouve pas une admission mondiale.
  • Ceci ne constitue pas un avis juridique pour le Brésil, le Royaume-Uni ou une autre juridiction ; les règles et périmètres de reconnaissance actuels doivent être revérifiés au moment de la décision.
  • Aucune disponibilité en temps réel, date de lancement fixe, performance, SLA ou périmètre d’approvisionnement commercial n’est promis.

FAQ

Pourquoi examiner le chemin d’intégration si le fournisseur possède un certificat de jeu ?

Un certificat de jeu peut ne couvrir qu’un objet et une version de jeu spécifiés, alors que la fourniture implique aussi un RGS, un agrégateur et une plateforme. Un marché cible peut exiger des preuves pour l’intégration du système ou des composants ; comparez donc l’objet du rapport avec la topologie réelle.

La prise en charge de la devise et de la langue locales signifie-t-elle que le marché peut être desservi ?

Non. Ce sont des dimensions techniques et de contenu. L’entité exploitante, le périmètre de la marque ou du domaine, les droits de contenu, la version du jeu, la certification et les règles de marché nécessitent une confirmation distincte.

Un rapport GLI-19 peut-il être utilisé sur tous les marchés ?

Cela ne peut pas être présumé. GLI-19 est une référence de norme de laboratoire. La question de savoir si un marché accepte les preuves, quel objet et quelle version elles couvrent, et si des preuves supplémentaires sont nécessaires dépend des règles actuelles et du périmètre du projet.

Une mise à niveau du jeu invalide-t-elle un ancien certificat ?

Le seul numéro de version ne permet pas de répondre. Enregistrez les modifications réelles, puis utilisez les règles du marché cible, le périmètre du rapport et les exigences de l’organisme de test pour décider si une évaluation d’impact, des tests complémentaires, une réémission ou une nouvelle approbation sont nécessaires.

Lectures associées et prochaines étapes

Avant d’utiliser la section « Contactez-nous », préparez le marché cible, le périmètre de l’entité exploitante ou de la marque, les jeux et versions candidats, la topologie d’intégration, les devises et les langues. AG peut alors organiser les preuves spécifiques au projet qui nécessitent encore une vérification. La fourniture d’éléments ou l’achèvement d’un test technique ne constitue pas une promesse d’admission sur le marché.

Sources et périmètre

Pages associées :

Sources réglementaires et normes primaires :

La page RTS de l’UKGC indiquait une date de mise à jour au 29 janvier 2026, sa stratégie de test au 31 octobre 2025, et l’index de la FAQ de la SPA au 21 mai 2026. Les éléments cités étaient accessibles le 9 août 2026. Les règles, organismes reconnus et périmètres changent ; revérifiez les sources primaires avant une décision de projet.

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.

Contacter AG GAME