Protocole relatif aux modalités de surveillance et de ... · Protocole relatif aux modalités de...

Protocole relatif aux modalités de surveillance et de

contrôle des jeux de hasard dans les établissements de jeux de hasard de classe IV et les lieux où les paris sont engagés en vertu de l'article 43/4, § 5, de la loi du 7 mai 1999 sur les jeux de hasard, les paris, les établissements

de jeux de hasard et la protection des joueurs, notamment au moyen d'un système informatique approprié

- Texte coordonné -

Version : IV_V03 du 1er novembre 2014

Protocole informatique jeux de hasard (classe IV) Commission des Jeux de hasard Version IV_V03 1er novembre 2014

-3-

Table des matières

Page

1 CONTENU DU PRÉSENT DOCUMENT ................................................................................................ 4

2 DÉFINITIONS ET ABRÉVIATIONS ........................ ............................................................................... 5

3 CONDITIONS GÉNÉRALES (F7) .......................... ................................................................................ 7

4 CONDITIONS TECHNIQUES RELATIVES AU CABLAGE ET AUX C OMPOSANTS PASSIFS DU LAN ................................................ ...................................................................................................... 11

5 CONDITIONS TECHNIQUES RELATIVES AUX COMPOSANTS ACTI FS DU LAN .......................... 12

6 CONDITIONS TECHNIQUES RELATIVES AUX CLIENTS ET AUX SERVEURS .............................. 13

7 CONDITIONS TECHNIQUES RELATIVES AU LOCAL DESTINE AU "DATA-RACK"...................... 15

8 CONDITIONS TECHNIQUES RELATIVES A LA LIAISON DE DON NEES AVEC LA COMMISSION DES JEUX DE HASARD................................. ..................................................................................... 16

9 CONDITIONS SUPPLEMENTAIRES RELATIVES AU SYSTEME DE VIDEOSURVEILLANCE........ 17

10 CONDITIONS RELATIVES À L’INFORMATION COMPTABLE ET F INANCIÈRE (F0, F1, F2 ET F9)18

11 CONDITIONS RELATIVES À L'ENREGISTREMENT (F5)....... ........................................................... 21

12 CONDITIONS RELATIVES AU CONTRÔLE TECHNIQUE (F6 ET F 10)............................................. 22

13 CONDITIONS RELATIVES À LA DOCUMENTATION CONCERNANT LE SYSTÈME INFORMATIQUE ET LE SYSTÈME DE VIDÉOSURVEILLANCE.... ................................................... 23

14 UTILISATION DES NOUVELLES TECHNOLOGIES DE L'INFORMA TION ....................................... 24

15 NORMES CONCERNANT LA NOMENCLATURE DES FICHIERS À EN VOYER .............................. 25

16 APPROBATION ........................................ ........................................................................................... 26

17 ANNEXE 1 : DÉFINITIONS XML ......................... ................................................................................ 27

18 ANNEXE 2 : PROTOCOLE DE COMMUNICATION STANDARD..... .................................................. 32

19 ANNEXE 3 : TABLE ASCII ............................. ..................................................................................... 40

20 ANNEXE 4 : ARRÊTÉ ROYAL DU 22 DECEMBRE 2010........ ........................................................... 43


-4-

1 CONTENU DU PRÉSENT DOCUMENT

L’art. 43/7, 5° de la loi du 7 mai 1999 prévoit que la surveillance et le contrôle des établissements de jeux de hasard de classe IV et des lieux où les paris sont engagés en vertu de l'article 43/4, § 5, de la loi du 7 mai 1999 sur les jeux de hasard, les paris, les établissements de jeux de hasard et la protection des joueurs doit se faire au moyen d’un système informatique approprié.

Le présent document décrit les conditions techniques auxquelles le système précité doit répondre. Le présent protocole constitue l’exécution de l’art. 11 de l’arrêté royal du 22/12/2010 relatif aux modalités de surveillance et de contrôle des jeux de hasard dans les établissements de jeux de hasard de classe IV et les lieux où les paris sont engagés en vertu de l'article 43/4, § 5, de la loi du 7 mai 1999 sur les jeux de hasard, les paris, les établissements de jeux de hasard et la protection des joueurs, notamment au moyen d'un système informatique approprié (MB 29/12/2010).


-5-

2 DÉFINITIONS ET ABRÉVIATIONS

Abréviation Définition LAN Local Area Network : le réseau local

Client Toute unité électronique, donc tant les pc administratifs que les jeux automatiques.

Les jeux automatiques sont soit des terminaux de paris soit des machines automatiques de classe IV.

Personne obligée Tout titulaire d'une licence de classe F1 qui met à disposition, sous quelque forme que ce soit, des terminaux de paris chez un titulaire d'une licence de classe F2, ou tout titulaire d'une licence de classe F2 qui possède et exploite ses propres terminaux de paris

Tout titulaire d'une licence de classe E qui met à disposition, sous quelque forme que ce soit, des machines automatiques de classe IV chez un titulaire d'une licence de classe F2, ou tout titulaire d'une licence de classe F2 qui possède et exploite ses propres machines automatiques de classe IV

On-line Est considéré comme partie intégrante du système on-line, tout ce qui se trouve entre le client et le transfert de données vers la Commission (donc y compris l'application CPU-Switch, le cas échéant)

UTP Unshielded Twisted Pair

DHCP Dynamic Host Configuration Protocol WINS Windows Internet Naming Service

DNS Domain Name System

FTP File Transfer Protocol DVD Digital Versatile Disk

EPROM Erasable Programmable Read Only Memory Xls-file Format de fichier de Microsoft Excel.

XML Une norme du Consortium World Wide Web pour la syntaxe formelle des langages de balisage avec lequel on peut afficher des données structurées sous forme de texte brut

RJ45 Registered Jack 45

Propagation Delay Le temps nécessaire à un signal pour se rendre du point A au point B par un canal de transmission donné

TCP/IP Transmission Control Protocol / Internet Protocol

IPV4 Adresse Internet du Protocole en 4 positions

IPV6 Adresse Internet du Protocole en 6 positions SWITCH Un appareil électronique qui organise le flux des

messages entre différents segments du LAN

SSL Secure sockets layer


-6-

SSH Secure shell

HTTP Hypertext transfert protocol.

DMZ Demilitarized Zone Connection IP connection basée sur le protocol Internet

ISP Internet Service Provider IP-adres Internet Protocol adres.


-7-

3 CONDITIONS GÉNÉRALES (F7)

A/ Certification : Afin de s’assurer que le présent protocole est correctement appliqué et afin de garantir la fiabilité des données reçues, une procédure de certification obligatoire a été établie.

Toutes les personnes obligées doivent faire vérifier leur système on line par un organisme indépendant agréé par la Commission des Jeux de hasard (cfr. Art 52, loi 1999). Cet organisme contrôle la conformité de l’ENTIERETE DU SYSTEME ONLINE (câblage, éléments passifs et actifs du réseau, software utilisé, protocoles de communication utilisés, les clients et les serveurs) avec l’entièreté du protocole d’application présent, les AR concernés, les notes informatives émises par la CJH, les notes émises par le service de la Métrologie et la loi sur les Jeux de Hasard de 1999 (y compris tous les changements de cette loi). L’interface du jeu automatique doit également faire l’objet d’une certification. La fiabilité et la disponibilité de la connexion data avec les clients dans les établissements de classe F2 doit également être vérifiée. L’organisme mentionné ci-dessus contrôle aussi dans quelle mesure les fichiers XML qui sont AUTOMATIQUEMENT générés par le système on line sont fiables. Il détermine aussi dans quelle mesure et de quelle manière ces données peuvent éventuellement être influencées. Le stockage de ces données dans un fichier temporaire n'est toléré que si les données sont cryptées par une application sécurisée de façon à rendre leur modification impossible ou si le stockage se fait après l'envoi réussi du fichier XML. Les données de base (*) des machines automatiques de classe IV doivent être rassemblées en temps réel et il ne peut donc être fait appel à un fichier présent dans le système online, ceci afin d’exclure toute anomalie. Le mode d’envoi des données à la Commission des Jeux de Hasard doit aussi être examiné. La Commission des Jeux de Hasard décidera d'accepter ou non la certification sur la base du dossier reçu (et rédigé par l’organisme mentionné ci-dessus).

En ce qui concerne la date limite de remise des rapports de certification, veuillez vous référer au point 16 : approbation.

Les organismes de certification doivent établir un rapport dans une des langues nationales du Royaume dans un format qui peut être imposé par la Commission des jeux de hasard. Tous les coûts inhérents à cette certification ne sont pas supportés par la Commission des jeux de hasard.

Le détenteur de licence F1 ou E (placeur) doit de nouveau faire certifier son système s'il y a eu des changements (autres que des upgrades ou correction de bug) dans son système on-line.

Lors d'un upgrade ou d'une correction de bug, le fournisseur de software "on-line" doit transmettre à la Commission des Jeux de hasard les informations suivantes : -/ description détaillée des modifications apportées au système (pour ce qui concerne les

éléments qui peuvent avoir une influence sur les données on-line); -/ exemple de chacun des fichiers XML prouvant que les fichiers sont correctement

générés.

Ces informations doivent être envoyée par e-mail à [email protected] (avec [email protected] en CC) et en mentionnant dans le champ objet : "Upgrade Online_No de licence".

Si la Commission l'estime nécessaire, une re-certification du système sera demandée. Le nombre d'upgrades autorisés sans certification doit toutefois rester très limité.


-8-

B/ Intégrité des données : Le certificateur installe sur le serveur hébergeant le système on-line un service chargé de garantir l'intégrité du système. Ce service doit :

-/ Etre sécurisé (impossible à modifier sans que cela soit visible) ;

-/ Etre lié au serveur par une signature hardware ; -/ Calculer les signatures des fichiers critiques et les comparer aux signatures certifiées à

une cadence aléatoire ;

-/ Générer un fichier "signature" reprenant le résultat de la comparaison ainsi qu'un "timestamp" après chaque comparaison et le transmettre à la Commission via le système on-line ;

-/ Le fichier "signature" doit être crypté de manière à garantir l'authenticité de l'application qui génère ce fichier. Seule la Commission doit pouvoir décrypter ce fichier.

C/ Cashless (machines automatiques de classe IV) : L'enjeu peut être introduit dans la machine via un système cashless répondant aux exigences suivantes :

-/ les "Player cards" ne peuvent être chargées que via la caisse et les terminaux de paiement certifiés de l'établissement. Le montant chargé doit être "inscrit" d'une manière cryptée sur la carte et sur le serveur du système cashless. Lors de l'introduction de la carte, s'il n'y a pas correspondance entre le montant "inscrit" sur la carte et le montant enregistré sur le serveur cashless, un message d'erreur doit être enregistré, d'une manière sécurisée dans le système on-line et la carte doit être bloquée. Si des systèmes alternatifs offrent un même niveau de garantie (impossibilité de modifier le montant de la carte sans que cela soit facilement traçable) ils peuvent également être proposés.

-/ un fichier "log" reprenant les adresses IP de chaque connexion accédant au serveur cashless doit être enregistrées d'une manière sécurisée sur le serveur cashless (les données doivent être conservées 6 mois).

D/ Inventaire des machines automatiques de classe IV (IV_F7) En ce qui concerne la transmission des listes de stock et des mouvements :

La Commission des jeux de hasard impose l’obligation de transmettre un état mensuel des machines automatiques de classe IV exploitées et de celles en stock dans le magasin. Dans un souci d’harmonisation, le règlement suivant entre en vigueur.

Les informations demandées sont transmises au format XML vers le serveur de la Commission des jeux de hasard.

Inventaire complet à envoyer le 1er mars de chaque année -/ No d'identification du jeu (No de série de la machine automatique de classe IV) -/ No d'approbation Métrologie -/ Date du "mouvement" -/ No de licence "F2" où la dernière exploitation a eu lieu -/ No de licence "E" concerné (voir informations ci-dessous) -/ No de la vignette de taxe -/ Clé de répartition : % des revenus du titulaire de licence "F2" (exemple : 60) -/ Clé de répartition : % des revenus du titulaire de licence "E" (exemple : 40)


-9-

Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_ F7" (Seul l'élément "stock" est envoyé, pour les autres nbOfItems est mis à 0)

Remarque : Pour les appareils en magasin, le no de licence "F2" est remplacé par 000000. Si un billet de taxe est présent, son numéro doit être indiqué. Dans le cas contraire, ces chiffres doivent être remplacés par des 0 en respectant le format requis. Inventaire différentiel:

Une fois par mois (au plus tard le 5 du mois), un fichier reprenant toutes les modifications survenues le mois précédent doit être envoyé vers le serveur de la Commission.

Pour chaque mouvement de machine (install, unistall, instalAfterBuy, unistallAndSold, unistallWithKit) : -/ No d'identification du jeu (No de série de la machine automatique de classe IV) -/ No d'approbation Métrologie -/ Date du "mouvement" -/ No de licence "F2" où la dernière exploitation a eu lieu -/ No de licence "E" concerné (voir informations ci-dessous) -/ No de la vignette de taxe -/ Clé de répartition : % des revenus du titulaire de licence "F2" (exemple : 60) -/ Clé de répartition : % des revenus du titulaire de licence "E" (exemple : 40) Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F7" (L'élément "stock" reste vide : nbOfItems = 0)

Cette structure présente plusieurs listes de données : -/ La liste "install" : concerne les machines automatiques de classe IV placées dans des

établissements de jeux de hasard durant la période concernée. -/ La liste "uninstall" : concerne les machines automatiques de classe IV retirées des

établissements de jeux de hasard durant la période concernée. -/ La liste "installAfterBuy" : concerne les machines automatiques de classe IV placées

dans des établissements de jeux de hasard durant la période concernée et achetés à un autre titulaire belge de licence E.

-/ La liste "uninstallAndSold" : concerne les machines automatiques de classe IV retirées des établissements de jeux de hasard durant la période concernée et vendus à un autre titulaire belge de licence E.

-/ La liste "uninstallWithKit" : concerne les machines automatiques de classe IV exploitées dans des établissements de jeux de hasard durant la période concernée et équipés d’un Kit de transformation.

Remarque : - Pour les machines automatiques de classe IV vendues à un autre titulaire belge de

licence, le numéro de licence E de ce dernier doit être précisé (respecter le format).

- Les ventes à un acheteur étranger doivent être mentionnées à la Commission des jeux de hasard. Cette dernière actualisera mensuellement la liste de stock dans sa base de données.

- Les machines automatiques de classe IV qui sont définitivement hors de fonctionnement doivent être considérées comme vendues à un acheteur étranger.

Lorsqu’une machine automatique de classe IV est déplacée d’un titulaire F2(X) vers un titulaire F2(Y), un record de type "uninstall" (titulaire F2(X)) et un record de type "install" (titulaire F2(Y)) doit être envoyé.


-10-

Dans le cas d'une transformation (placement d'un kit), un record de type "uninstallWithKit" et un record de type "install" doit être prévus le jour même. Le but du type "uninstallWithKit" est d'informer la Commission que le numéro d'identification de la machine automatique de classe IV avant transformation est radié du parc de machines. Remarque concernant le champ No de licence "E" concerné :

Le champ "supplierLicenseId" (no de licence de l'installateur "E") est :

-/ dans le cas de la liste "uninstallAndSold" : le no de licence "E" de l'installateur qui a acheté la machine automatique de classe IV;

-/ dans le cas de la liste "installAfterBuy" : le no de licence "E" de l'installateur qui a vendu la machine automatique de classe IV;

-/ dans les autres cas : le no de licence "E" de l'installateur qui envoie le fichier. Ce champ fait double emploi avec le champ "DossierId" mais reste utile à des fins de vérification.


-11-

4 CONDITIONS TECHNIQUES RELATIVES AU CABLAGE ET AUX COMPOSANTS PASSIFS DU LAN

La personne obligée est responsable des composants passifs de son LAN et de sa documentation sous forme électronique.

Documentation (voir aussi les chapitres 5, 6, 7, 8 et 9) a. "as-built" complet pour le F1 et pour les F2-Bureaux de paris b. Un dossier "proof of concept" est suffisant pour les F2-Librairies c. Un dossier "proof of concept" pour un F2-Bureau de paris peut être présenté et négocié. Le câblage doit être réalisé suivant les normes de câblage, instructions et toutes autres réglementations concernées (AHJ : authority having jurisdiction) Toute norme de câblage est acceptée pour autant que celle-ci puisse supporter les vitesses de données (bande passante) utilisées. Pour les câblages structurés en cuivre, la norme doit être au minimum Cat5 (ANSI/TIA/EIA) ou Cat5E (CENELEC).

Normes de câblages : Internationales :

• ISO/IEC 11801 Ed.2:2002: Generic Cabling for Customer Premises

• ISO/IEC 14763: Implementation and Operation of Customer Premises Cabling Européennes :

• CENELEC EN50173: Generic Cabling Systems • CENELEC EN50173-2: Business Premises (Bureaux de paris F2) CENELEC

EN50173-3: SOHO (F2 librairies), CENELEC EN50173-5: Datacenter (F1) Américaines :

• ANSI/TIA/EIA-568B: Commercial Building Telecommunication Standard

Lorsque d'autres appareils ou périphériques sont raccordés sur des appareils actifs leur câblage doit être décrit dans le dossier "as-built" ou "proof of concept". Remarque : Les instructions concernent la sécurité des personnes et des biens, l'électricité, les bâtiments, la sécurité incendie. La cellule ICT de la Commission des Jeux de hasard prend bien évidemment ces instructions en considération.


-12-

5 CONDITIONS TECHNIQUES RELATIVES AUX COMPOSANTS ACTI FS DU LAN

La personne obligée est responsable des composants actifs de son LAN et de sa documentation sous forme électronique.

Tout composant actif (description, spécification, ...) doit être décrit dans le dossier "as-built" ou "proof of concept". Lorsque d'autres appareils ou périphériques (autres que ceux strictement nécessaires pour l'exploitation des paris ou pour le réseau des machines automatiques de classe IV) sont raccordés, une documentation complète (but de l'appareil, description, spécifications, aspects relatif à la sécurité, ...) doit être disponible dans le dossier "as-built" ou "proof of concept".


-13-

6 CONDITIONS TECHNIQUES RELATIVES AUX CLIENTS ET AUX SERVEURS

Généralités : La personne obligée est responsable de son réseau actif et de sa documentation sous forme électronique.

Les principes de bases suivants doivent être suivis : a. Le réseau de production comprenant les jeux de hasard doit être physiquement séparé

du réseau destiné à l'administration. b. Il ne peut y avoir de connexion sans fil sur le réseau de production.

1. Ces principes s'appliquent aux F1 et aux F2-Bureaux de paris ; 2. Pour les F2-Bureaux de paris et les F2-Librairies, où une intégration des services est

implémentée via une liaison à bande unique, cette séparation physique n'est pas toujours possible. Le titulaire de licence F1 doit alors soumettre le dossier de conception à la cellule ICT de la Commission des jeux de hasard pour approbation.

La personne obligée doit reprendre cette description de conception dans le dossier "as-built" F1/F2 ou dans le dossier "proof of concept". La séparation "logique" des réseaux, la séparation entre les communications internes et externes, le niveau de "sécurité", etc... de la configuration F2 doit être clairement démontrée.

• Il peut y avoir différents types d'installation mais la documentation doit clairement faire apparaître quel F2 tombe sous quel type d'installation ;

• Le F1 doit avoir un "contrôle total" du F2 pour ce qui concerne la prise des paris et l'émission des tickets ;

• L'imprimante à tickets doit être une imprimante indépendante qui sert uniquement à l'impression des tickets ;

• Si un terminal et/ou une imprimante est également utilisé pour des tâches administratives, cela doit être décrit dans le dossier "as-built" ou "proof of concept";

• L'émulation d'un terminal sur un système intelligent est autorisée ;

• Le F2 ne peut en aucun cas pouvoir générer des tickets de paris sans une connexion F1-F2 active (off-line) ;

• La Commission des Jeux de hasard doit avoir une supervision du réseau "all-to-one" complet ;

• La Commission des Jeux de hasard doit disposer des données pertinentes et pouvoir à distance contrôler le statut actif ou pas des F2.

Exigences spécifiques pour les terminaux de paris : Le serveur gérant les paris doit se trouver en Belgique dans les locaux du titulaire de licence F1 ou sous sa supervision.

Le titulaire de licence doit communiquer à la Commission des jeux de hasard l'adresse exacte du serveur.


-14-

Exigences spécifiques pour les machines automatiques de classe IV : Le serveur destiné aux machines automatiques de classe IV doit se trouver auprès du titulaire de licence "E". La communication entre les machines automatiques de classe IV et le titulaire de licence "E" peut s'effectuer :

1. Via GPRS Le titulaire de licence est responsable de l'envoi des données une fois par jour. Cela doit s'effectuer via GPRS, les données ne peuvent pas être cryptées. Chaque fabricant / placeur doit, au préalable, indiquel quel module GPRS est utilisé.

2. Via le LAN du F2 Le titulaire de licence "F" donne son autorisation, il est responsable de cette configuration et de son intégration dans le dossier "as-built" ou "proof of concept".

Protocole de communication Un protocole de communication standard est prévu, lequel uniformisera l’échange de données entre l’interface et la carte-mère des machines de jeux automatiques (voir Annexe 2)


-15-

7 CONDITIONS TECHNIQUES RELATIVES AU LOCAL DESTINE AU "DATA-RACK"

Pour le F1 : Il y a 3 possibilités : 1. Le F1 dispose de son propre datacenter ; 2. Le F1 utilise un datacenter externe ; 3. Le F1 fait usage des deux. Dans tous les cas, le datacenter doit :

-/ Satisfaire aux normes, prescriptions et reglementations existantes ;

-/ Pour les datacenter, les normes en usage sont : Tier 1, 2, 3 et 4

Pour le F2 : Pour les bureaux de paris, avec ou sans machine automatique, un dossier "as-built" complet doit être présenté tandis qu'un "proof of concept" doit être présenté et négocié.

Pour les F2-Librairies un "proof of concept" peut être utilisé s'il est valable pour toutes les installations ou pour une série (voir aussi le chapitre 4).

Un data-rack est normalement de type 19" (ou 10") et il peut être fixé au mur ou être "stand-alone". Chaque rack monté au mur doit se trouver à hauteur d'homme ou être d'accès facile pour le certificateur. Dans tous les cas, chaque rack doit pouvoir être verrouillé.

Toutes dérogations à ces règles doivent être évaluées au cas par cas.


-16-

8 CONDITIONS TECHNIQUES RELATIVES A LA LIAISON DE DON NEES AVEC LA COMMISSION DES JEUX DE HASARD

La personne obligée assure une connexion IP adéquate avec la DMZ de la Commission des Jeux de hasard, de préférence par le biais du réseau de l'ISP choisi. L'utilisation d'une adresse IP fixe et d'une largeur de bande minimum garantie est souhaitable.

La personne obligée est également chargée de l’acquisition, de l’installation et de la programmation des composants actifs requis du LAN. La personne obligée est responsable de la connexion de la liaison de données à son système informatique.

Transmission des fichiers : environnement sécurisé HTTPS. Le nouvel API, disponible en production depuis le 6 mai 2014 doit être utilisé. La transmission via FTP n'est plus autorisée.

Les informations techniques se trouvent sur la page "protocoles informatiques" du site Internet de la Commission des Jeux de hasard.

Lors de chaque transmission une validation (syntaxe XML + règles Schematron) est effectuée. Le statut de la vérification ("valid" ou "invalid") est renvoyé. Lorsque le statut est "invalid" le fichier est rejeté et donc considéré comme non reçu. Le programmeur du système de transmission de fichiers doit prendre ce statut en compte afin de prendre les mesures correctives nécessaires lorsque le statut est "invalid". Dans ce cas l'exploitant des machines de jeux doit être informé du problème et une solution technique doit être apportée.

A l'avenir, une signature digitale pourra être implémentée.


-17-

9 CONDITIONS SUPPLEMENTAIRES RELATIVES AU SYSTEME DE VIDEOSURVEILLANCE

Des caméras doivent être installées au moins aux endroits suivants : - les caisses ; - le lieu d’enregistrement et/ou de contrôle du joueur, de sorte que la constitution du fichier

des personnes enregistrées puisse être suivi ; - les terminaux de paris - les machines automatiques de classe IV.

Sur simple demande, les enregistrements demandés doivent être transmis à la Commission des jeux de hasard. Dans le cas de formats propriétaire le "viewer" adéquat doit être également fourni.

Ce viewer doit fonctionner avec toutes les versions disponibles du système d’exploitation Windows. Les images vidéo doivent posséder un framerate minimal de 12 images/seconde. La résolution minimale doit être 4SIF (525) 704 x 480 (NTSC) ou 4CIF/SIF (625) 704 x 576 (PAL). La qualité et le choix des caméras doivent tenir compte des conditions spéciales d’éclairage prévalant dans l’établissement de jeux de hasard. Pour les nouveaux systèmes de surveillance, il y a lieu d'utiliser des caméras couleurs.

Le matériel vidéo sera placé de préférence dans le data-rack. Tout autre vidéo-rack sera placé à hauteur d'homme ou rendu accessible lors des contrôles.

Dans tous les cas chaque vidéo-rack doit pouvoir être fermé et les responsabilités relatives aux accès doivent être définies.

Des adaptations peuvent être présentées, discutées et acceptées. Les enregistrements doivent être conservés pendant quatre semaines.

Les images doivent être constamment disponibles. Le titulaire de licence est tenu de notifier immédiatement, à la Commission des Jeux de hasard, tout dérangement technique survenu au niveau de la vidéosurveillance.


-18-

10 CONDITIONS RELATIVES À L’INFORMATION COMPTABLE ET FINANCIÈRE (F0, F1, F2 ET F9)

Généralités : Les informations financières doivent être communiquées à la Commission des jeux de hasard toutes les 24 heures dans le format XML. Ils doivent également être communiqués au SPF Finances (ou aux Services régionaux compétents) lorsqu'il en fait la demande.

Tous les montants doivent être mentionnés en euro cents. Ces fichiers doivent être produits automatiquement et doivent être directement transmis par le serveur de la personne obligée à la Commission des jeux de hasard.

Exigences pour les terminaux de paris : Informations financières - Détail des paris : -/ Numéro de licence F1 -/ Numéro de licence F2 (il y a un fichier par "F2") Pour chaque prise de pari : -/ Identification du terminal de pari -/ Identification de la catégorie de pari (Sport ; Event ; HorseRace ; Mixed) -/ No d'identification du ticket de pari -/ Sélections du parieur -/ Mise du parieur -/ Gain du parieur -/ TimeStamp de la prise de pari -/ TimeStamp de l'évènement sur lequel porte le pari Remarque : les champs "betTiming/start" et "betTiming/end" ne sont pas toujours chronologiques.

Dans certains cas "start" peut être postérieur à "end". Par exemple pour le Live Betting "end" peut être la date du match (ex. 20:00) et "start" la prise de paris pendant le match (ex. 20:22).

Dans cette nouvelle version des champs spécifiques : "betTiming/bet" et "betTiming/event" ont été prévus afin de supprimer cette incohérence.

Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F0" Remarque : contrairement aux autres fichiers, ces données ne doivent pas être transmises journellement. Les données relatives aux 12 derniers mois doivent être conservées par la personne obligée. Les données relatives à une plage de date fixée doivent pouvoir être transmises, de la même manière que les autres fichiers, sur simple demande de la Commission.

Informations financières - Résultats globaux du titulaire de licence F1 : -/ Numéro de licence F1 -/ Identification de la catégorie de pari -/ Total des mises -/ Total des gains attribués -/ Nombre de ticket -/ Numéro de suite du premier ticket de la journée -/ Numéro de suite du dernier ticket de la journée


-19-

Remarque : pour les "numéro de suite" la procédure est la suivante (lorsque le numérotage n'est pas unique) : -/ le F1 collecte toutes les données de ses F2 ; -/ le F1 regroupe tous les tickets dans une nouvelle table avec un nouvel index (continu et croissant) ; -/ les "numéro de suite" sont générés sur base de ce nouvel index ; -/ le F1 conserve la table de correspondance afin de permettre de retrouver les références d'un ticket

quelconque. Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier

"IV_F1"

Informations financières - Résultats globaux du titulaire de licence F2 : -/ Numéro de licence F1 -/ Numéro de licence F2 Pour chaque terminal de pari -/ Identification du terminal de pari -/ Identification de la catégorie de pari (Sport ; Event ; HorseRace ; Mixed) -/ Total des mises -/ Total des gains attribués -/ Nombre de ticket Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier

"IV_F2"

Etablissements de jeux de hasard mobiles de classe IV (bookmakers) : Pour les titulaires de licence F2 pour un établissement de jeux de hasard mobile de classe IV (bookmakers) les exigences suivantes s'appliquent : -/ Utiliser un PC pour engager des paris et enregistrer les données des paris "en temps réel"; -/ Générer un fichier Excel identique à ce qui est enregistré dans le "livre des contributions" ; -/ Conserver un double des tickets "papiers" chez le titulaire de licence pendant 7 ans afin de

permettre les contrôles éventuels (ils doivent être mis à la disposition de la CJH ou du SPF Finances (ou les Services régionaux compétents) sur simple demande).

-/ Enregistrer le "time stamp" du début de l'évènement et celui de la prise du pari. -/ Transmettre le fichier Excel, endéans les 24 h après la dernière course, au titulaire de

licence F1 ; -/ Le titulaire de licence F1 se charge de convertir ces données en XML et de les

transmettre, endéans les 24 h de la réception du fichier Excel, à la Commission des Jeux de hasard selon les modalités prévues par ce protocole.

La certification du système via le titulaire de licence F1 concerné doit avoir lieu avant le 1er janvier 2014

Remarque : ce régime d'exception sera autorisé jusqu'au 01/07/2015 (après quoi des "tickets électroniques" seront demandés).

Exigences pour les machines automatiques de classe IV : Informations financières : (*) = données de base, c'est à dire données devant être récoltées en temps réel sur la

machine ; voir exigences du point 3/ A Certification. -/ Nombre de machines concernées Pour chaque machine concernée :

-/ No d'identification du jeu (No de série) (*) -/ No d'approbation Métrologie -/ No de la vignette de taxe -/ No de licence "F2" -/ Statut de la machine : Connect ou NoConnect


-20-

-/ Total des mises de la journée -/ Total des gains de la journée -/ Résultat de la journée -/ Nombre de parties jouées (compteur global) (*) -/ Nombre d'ouverture de porte (compteur global) (*) -/ Compteur Total Bet à l'ouverture (*) -/ Compteur Total Bet à la fermeture (*) -/ Compteur Total Win à l'ouverture (*) -/ Compteur Total Win à la fermeture (*) -/ TimeStamp de l'ouverture -/ TimeStamp de la fermeture

Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F9" Remarques concernant l’envoi des données relatives aux machines automatiques de classe IV manquantes : Les données extraites lors de la fermeture doivent également servir de valeurs de départ pour l’exploitation de la journée suivante (ouverture). Pour toutes les machines automatiques de classe IV qui ne répondent pas, un polling continue à courir (p.ex. toutes les 10’).

Toutes les données collectées sont transférées, conformément au protocole, à la Commission des jeux de hasard. Si une machine automatique de classe IV ne répond pas durant plusieurs jours, les données extraites lors du dernier contact sont considérées comme étant les "données de régularisation" à transmettre pour les jours où le contact a été perdu Un fichier doit être transmis pour chaque jour. Le fichier à le statut "connect" si les données proviennent d'une transmission réelle. Le fichier à le statut "NoConnect" s'il s'agit des données de régularisation décrites ci-dessus.


-21-

11 CONDITIONS RELATIVES À L'ENREGISTREMENT (F5)

Il convient de transmettre à la Commission des jeux de hasard, toutes les 24 heures, un fichier en format XML comportant par visiteur à enregistrer (c'est à dire ceux qui prennent des paris pour plus de 1000 €) : -/ Numéro de licence F1 -/ Numéro de licence F2 Pour chaque visiteur :

-/ Nom -/ Prénom(s) -/ Lieu de naissance -/ Date de naissance -/ Profession -/ Adresse -/ Montant de la mise -/ Date de l'opération -/ Détails du pari

Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F5"

Dans le cas où l'établissement tient uniquement un registre électronique, le programme doit générer une fiche reprenant les données mentionnées ci-dessus plus la date du jour et l'heure et un numéro de suite séquentielle. Le client doit signer cette fiche lors de son enregistrement. Ces fiches doivent être conservées dans les mêmes conditions que le registre traditionnel.

Ce fichier doit être généré de façon automatique et envoyé directement à la Commission des jeux de hasard à partir du serveur de la personne obligée.

Lors du premier enregistrement, la pièce d'identité doit être immédiatement photocopiée et restituée sans délai. La photocopie de la pièce d'identité doit être conservée pendant cinq ans après le dernier enregistrement.

Lors du premier enregistrement, le joueur est tenu d’apposer sa signature sur la photocopie de la pièce d'identité.


-22-

12 CONDITIONS RELATIVES AU CONTRÔLE TECHNIQUE (F6 ET F10)

Ces informations doivent être transmises une fois par semaine (le vendredi) à la Commission des jeux de hasard :

Pour les terminaux de paris -/ Nombre de terminaux de paris concernées Pour chaque terminal de paris concernée :

-/ No d'identification du terminal de paris (No de série) -/ No de licence "F2"

Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F6" Pour les machines automatiques de classe IV (*) = données de base, c'est à dire données devant être récoltées en temps réel sur la

machine ; voir exigences du point 3/ A Certification. -/ Nombre de machines concernées Pour chaque machine concernée :

-/ No d'identification du jeu (No de série de la machine) (*) -/ No de licence "F2" -/ No d'approbation Métrologie (*) -/ Date de la dernière vérification -/ Identification de la version software (*) -/ Clés utilisées pour la Signature software (*) -/ Signature software (*)

Le fichier XML présente la structure décrite à l'annexe 1 : Définitions du fichier "IV_F10"


-23-

13 CONDITIONS RELATIVES À LA DOCUMENTATION CONCERNANT LE SYSTÈME INFORMATIQUE ET LE SYSTÈME DE VIDÉOSURVEILLANCE

La documentation suivante doit être transmise préalablement à la Commission des jeux de hasard :

Concernant le système informatique : - nom et adresse du fournisseur et/ou du fabricant ; - numéros d’identification et de série ; - description du matériel et du logiciel ; - compilateur utilisé ; - dossier technique et fonctionnel de l’application.

Concernant le système de vidéo-surveillance : - nom et adresse du fournisseur et/ou du fabricant ; - numéros d’identification et de série ; - localisation et plan du poste de contrôle ; - plan technique du système et de son fonctionnement ; - documentation technique relative aux caméras utilisées.


-24-

14 UTILISATION DES NOUVELLES TECHNOLOGIES DE L'INFORMATION

Pas d'exigence au stade actuel.


-25-

15 NORMES CONCERNANT LA NOMENCLATURE DES FICHIERS À ENVOYER

Les noms de fichiers ont la structure suivante : IV_licenceId_Fx_date*_time*.xml (* : de préférence celle de la création du fichier) Exemple : IV_012345_F5_20130517_221743.xml Remarque : Pour les fichiers F0, F2 et F5 il y a un fichier par F2 concerné. Dans ce cas, le nom de fichier doit avoir la structure suivante : IV_organiserId_Fx_F?licenceId_date*_time*.xml (* : de préférence celle de la création du fichier) Exemple : IV_012345_F2_FB001234_20130517_221743.xml


-26-

16 APPROBATION

Le présent protocole a été établi par la Commission des jeux de hasard et approuvé en sa séance du 1er octobre 2014.

Les constructeurs doivent apporter les modifications nécessaires à leur système online avant le 1er juillet 2015. La certification obtenue, au plus tard le 1er janvier 2015 pour la version protocole précédente, reste valable.

La Commission des jeux de hasard veillera scrupuleusement à la stricte application du présent protocole. Le non-respect des dates mentionnées ci-dessus peut donner lieu à des sanctions.

Le Président.

E. Marique.


-27-

17 ANNEXE 1 : DÉFINITIONS XML

Les tableaux suivants donnent un aperçu des données à transmettre en XML. Avant transmission, les fichiers doivent être validés sur base des fichiers de définition XSD et du programme de validation disponibles à l'adresse suivante : www.gamingcommission.be ; Section <La Loi> <Protocoles> <Informatique>.

Définitions du fichier "IV_F0" (Point 10) : /f0/ Field Cardinality Data type Description

protocolVersion 1 string Version du protocole (attribut de f0) = IV_V03

generalInfo/licenseId 1 int Le numéro de la licence F2 (un fichier par "F2")

generalInfo/fileDate 1 date Date du fichier

generalInfo/licenseType 1 licenseTypeType Type de licence : FB, FC, FD ou FE

generalInfo/email 1 emailType Email du responsable On-Line

generalInfo/organiserId 1 int Le numéro de la licence F1

games/nbOfItems 1 int Nombre de paris

games/ game 0 → n gameType Information détaillées pour chaque pari

gameType : /f0/games/ game/ Field Cardinality Data type Description

id 1 string Identification du terminal de pari (no de série)

gameType 1 gameTypeType Catégorie pari (Sport ; Event ; HorseRace ; Mixed)

ticketId 1 string No d'identification du ticket

gamerSelection 1 string Les sélections (elles peuvent être codées)

gamerBetAmount 1 long Mise du joueur (en eurocents)

gamerWonAmount 0 long Gain du joueur (en eurocents) (optionnel si inconnu)

betTiming/bet 1 dateTime Time Stamp prise du pari

betTiming/event 1 dateTime Time Stamp prise de l'évènement

Définitions du fichier "IV_F1" (Point 10) : /f1/

Field Cardinality Data type Description


generalInfo/licenseId 1 int Le numéro de la licence F1


generalInfo/licenseType 1 licenseTypeType Type de licence : FA


games 4 gamesType Information détaillées par catégorie de pari

gamesType : /f1/games/ Field Cardinality Data type Description


totalBetAmount 1 long Total des mises (en eurocents)

totalWonAmount 1 long Total des gains attribués (en eurocents)

nbTickets 1 long Nombre de ticket

firstTicketNb 1 integer Numéro de suite du premier ticket de la journée

lastTicketNb 1 integer Numéro de suite du dernier ticket de la journée


-28-





generalInfo/licenseType 1 licenseTypeType Type de licence : FB, FC ou FD


generalInfo/organiserId 1 int Le numéro de la licence F1

games/nbOfItems 1 int Nombre de terminaux

games/gameDetail 0 → n gameDetailType Informations détaillées par terminal

gameDetailType : /f2/games/gameDetail/ Field Cardinality Data type Description

id 1 string Identification du terminal de pari (no de série)


gamerBetAmount 1 long Total des mises (en eurocents)

gamerWonAmount 0 long Total des gains attribués (en eurocents) (optionnel si inconnu)

nbTickets 1 long Nombre de ticket





generalInfo/licenseType 1 licenseTypeType Type de licence : FB, FC ou FD


generalInfo/ organiserId 1 int Le numéro de la licence F1

guests/nbOfItems 1 int Nombre de visiteurs

guests/guest 0 → n guestType Données des visiteurs

guestType : /f5/guests/guest/ Field Cardinality Data type Description

lastName 1 string Nom

firstName 1 string Prénom

birthDay 1 date Date de naissance

birthPlace 1 string lieu de naissance

profession 1 string Profession

houseNbr 1 string Numéro

houseBox 1 string Boîte

street 1 string Rue

zipCode 1 string Code postal

city 1 string commune

country 1 string pays (2chr conformément ISO 3166-1-alpha-2 code)

betAmount 1 long Montant de la mise (en eurocents)

betDate 1 date Date de l'opération

betDetail 1 string Détails du pari


-29-



generalInfo/licenseId 1 int Le numéro de la licence F1


generalInfo/licenseType 1 licenseTypeType Type de licence : FA


terminals/nbOfItems 1 int Nombre de terminaux concernées

terminals/ terminal 0 → n terminalType Informations détaillées par terminal

terminalType : /f6/terminals/terminal/ Field Cardinality Data type Description

terminalId 1 string Le numéro d'identification du terminal de paris (no de série)

licenseId 1 int Numéro de licence F2

Définitions du fichier "IV_F7" (Point 3 D) : /f7/ Field Cardinality Data type Description


generalInfo/licenseId 1 int Le numéro de la licence E Placeur

generalInfo/manufacturerId 0 → 1 int Le numéro de la licence E Fabricant


generalInfo/licenseType 1 licenseTypeType Type de licence : E


stock 1 detailType Les appareils en magasin

install 1

detailType Les machines automatiques de classe IV placés dans des établissements de jeux de hasard durant la période concernée

uninstall 1

detailType Les machines automatiques de classe IV retirés des établissements de jeux de hasard durant la période concernée

installAfterBuy

1

detailType

Les machines automatiques de classe IV placés dans des établissements de jeux de hasard durant la période concernée et achetés à un autre titulaire belge de licence E

uninstallAndSold

1

detailType

Les machines automatiques de classe IV retirés des établissements de jeux de hasard durant la période concernée et vendus à un autre titulaire belge de licence E

uninstallWithKit

1

detailType

Les machines automatiques de classe IV exploités dans des établissements de jeux de hasard durant la période concernée et équipés d’un Kit de transformation

detailType : /f7/.../ Field Cardinality Data type Description

nbOfItems 1 int Nombre de machines concernées

item 0 → n itemType Informations détaillées par machine

itemType: /f7/.../item/ Field Cardinality Data type Description

gameid 1 string Le numéro d'identification unique du jeu (no de série)


-30-

approvalId 1 string Le numéro de l'approbation de la métrologie

operationDate 1 date Date de l'opération

operatorLicenseId 1 int Numéro de la licence F2 où la dernière exploitation a eu lieu

supplierLicenseId 1 int Numéro de licence "E" concerné (voir Point 3D)

taxNumber 1 string Numéro de la vignette de taxe

repartitionKey/operator 1 int Clé de répartition : % des revenus du "F2"

repartitionKey/supplier 1 int Clé de répartition : % des revenus du "E"



generalInfo/licenseId 1 int Le numéro de la licence E (ou F1) Placeur



generalInfo/licenseType 1 licenseTypeType Type de licence : E (ou FB)


details/nbOfItems 1 int Nombre de machines concernées

details/ detail 0 → n detailInfoType Informations détaillées pour chaque machine

detailInfoType : /f9/details/detail/ Field Cardinality Data type Description

gameId 1 string Numéro d'identification unique du jeu (no de série) (*)

approvalId 1 string Numéro d'approbation de la métrologie (*)

licenseId 1 string numéro de licence F2

taxNumber 1 string N° de la vignette de taxe pour l'année en cours

status 1 Connect/NoConnect Statut de la machine : Connect ou NoConnect

totalBetAmount 1 long Montant total des mises de la journée (en eurocents)

totalWinResult 1 long Montant total des gains de la journée (en eurocents)

dayResult 1 long Résultat de la journée (en eurocents)

nbGamesPlayed 1 long Le nombre de parties joués (compteur global) (*)

nbDoorOpen 1 long Nombre d'ouverture de porte (compteur global) (*)

totalBetBegin 1 long Compteur Total Bet à l'ouverture (en eurocents) (*)

totalBetEnd 1 long Compteur Total Bet à la fermeture (en eurocents) (*)

totalWinBegin 1 long Compteur Total Win à l'ouverture (en eurocents) (*)

totalWinEnd 1 long Compteur Total Win à la fermeture (en eurocents) (*)

opening/start 1 datetime Date et l'heure de la récolte des compteurs à l'ouverture

opening/end 1 datetime Date et l'heure de la récolte des compteurs à la fermeture

(* = données de base, c'est à dire données devant être récoltées en temps réel sur la machine ; voir exigences du point 15 A Certification)



generalInfo/licenseId 1 int Le numéro de la licence E (ou F1) Placeur



-31-


generalInfo/licenseType 1 licenseTypeType Type de licence : E (ou FB)


details/nbOfItems 1 int Nombre de machines concernées

details/detail 0 → n detailInfoType Informations détaillées par machine

detailInfoType : /f10/details/detail/ Field Cardinality Data type Description

gameId 1 string Le numéro d'identification unique du jeu (no de série) (*)

approvalId 1 string No d'approbation du modèle (*)

licenseId 1 int Numéro de licence F2

lastCheckDate 1 date Date de la dernière vérification

gameSoftwareVersion 1 string Identification de la version software (*)

gameKeys 1 string Clés utilisées pour la signature software (*)

eprom 1 string Signature software (*)

(* = données de base, c'est à dire données devant être récoltées en temps réel sur la machine ; voir exigences du point 15 A Certification)


-32-

18 ANNEXE 2 : PROTOCOLE DE COMMUNICATION STANDARD

De plus, un protocole de communication standard est prévu , lequel uniformisera l’échange de données entre l’interface et la carte-mère des machines à sous automatiques.

A. But : Ce document décrit un protocole de transmission de données entre des machines de jeu et une interface de réseau dans une configuration master - slave où toute communication est amorcée par l'interface de réseau et la machine de jeu envoie une réponse en retour. Toutes les fonctions sont communes pour tous les jeux ce qui signifie que le protocole doit être respecté par toutes les machines de jeu et que l'interface de réseau ne peut pas utiliser des fonctions réservées. Les instituts d'approbation vérifieront que la machine de jeu respecte ce protocole.

B. Terminologie. Dans ce document, les termes suivants sont utilisés avec les descriptions ci-dessous : Jeu : Tout type de terminal de jeu qui est soit une machine de jeu autonome soit un

membre d'un jeu multi joueurs.

Interface : l'interface réseau qui demande l'information au jeu.

Master : utilisé pour décrire l’interface Slave : le terminal de jeu en tant qu’autonome ou membre d'un jeu multi joueurs.

C. Connexion physique entre l’interface et le jeu. Le lien physique est une connexion RS-232 à la norme V24 et définie comme suit : -/ Baud Rate: 9600 bps -/ Data Bits: 8 -/ Parity: None -/ Stop Bit: 1 -/ RTS/CTS hardware handshaking supporté en option.

D. Règles de conversion de données. Dans ce document, un nombre avec le terme '0x' représente un nombre hexadécimal, un nombre sans préfixe est un nombre décimal, un caractère ASCII imprimable est inclus dans des cotations simple (') et une chaîne de caractères est incluse dans des cotations doubles ("). Une table de conversion des valeurs décimales et hexadécimales ASCII est reprise dans l'ANNEXE 3. D.1. Conversion d’une série ou d’un caractère:

Chaque caractère est codifié suivant la table ASCII. Exemple: pour envoyer la chaîne test 1, 6 bytes doivent être envoyées et les notations valables sont : “test 1” - ‘t’ ‘e’ ‘s’ ‘t’ ‘ ‘ ‘1’ - 0x74 0x65 0x73 0x74 0x20 0x31

D.2. Conversion de nombre:

Tous les nombres sont exprimés dans leur valeur hexadécimale et transmis en codant chaque octet hexadécimal dans leurs 2 octets d'ASCII respectifs où la majuscule est utilisée pour les valeurs A à F ; Exemple: pour transmettre 0x07: envoyer les 2 bytes 0x30 0x37

Pour transmettre la valeur compteur 45 836 472 = 0x02BB68B8:

Envoyer les 8 bytes 0x30 0x32 0x42 0x42 0x36 0x38 0x42 0x38


-33-

D.3. Termes utilisés:

Dans la description de la série de commandes et de réponses, on utilisera les termes suivants :

STX: valeur hexadécimale 2 = 0x02 CD: commande envoyée et codée en 2 bytes selon D.2.

DATA: terme général pour la série de données et la série de numéros codes suivant D.1. et D.2.

CS: checksum de 1 byte codé sur 2 bytes selon D.2. CS est l'octet le moins significatif de la somme de tous les octets de données qui vont (exclu) de l'octet de début STX (exclu) jusqu’à la somme et octet de fin EOT.

EOT: Valeur hexadécimale 4 = 0x04

D.4. Format date / heure :

Les dates et heures doivent être formatées de la manière suivante : Date : aaaa/mm/jj. Heure : hh:mm:ss (format 24 h)

E. Communication prototype. Toutes les communications seront initialisées par une commande envoyée du master au slave utilisant un paquet de 4 octets contenant l'octet de début STX, l’identificateur de commande CD et l'octet d'arrêt EOT.

Chaque fois que le slave reçoit une commande, il envoie en retour une réponse composée de l'octet de début (STX), la commande de réception CD, les DONNÉES, le checksum CS et l'octet d'arrêt (EOT). Si le slave (jeu) ne répond pas après 100ms, la chaîne de commande est envoyée de nouveau par le master. Dans le cas où il n'y a toujours aucune réponse endéans les 100 ms, le master réenvoie la série de commandes de nouveau après 1s, ensuite après 10s si toujours aucune réponse et finalement après 100s si toujours aucune réponse du slave. Après 5 essais échoués, le statut du slave (jeu) devient 'offline'. Le master peut continuer à contrôler le slave en envoyant des fonctions. Si le slave répond valablement, le statut 'offline' est annulé. Si la commande n'est pas reconnue par la machine de jeu, il renvoie une commande nulle utilisant le format STX "00" CS EOT .

F. Définition des commandes. Toutes les commandes, qui ne sont pas définies dans la table ci-dessous sont des commandes réservées ne peuvent pas être allouées.


-34-

CD Description Rb(*1) 0x00 Null 6 0x01 Get game identification (identification jeu) 31 0x02 Get general counters (compteurs généraux) 70 0x03 Get ‘Credit in’ counter (compteur “Cash in”) 14 0x04 Get ‘Credit out’ counter (compteur “Cash out”) 14 0x05 Get ‘Hand pay’ counter (compteur “comptant”) 14 0x06 Get ‘Total bet’ counter (compteur “total In”) 14 0x07 Get ‘Total win’ counter (compteur “total Out”) 14 0x08 Get number of played games (nombre de parties

jouées) 14

0x09 Get number of interrupts (nombre d’interruptions) 14 0x0A Get ‘Door open’ counter (compteur “ouverture de

porte”) 14

0x0B Get ‘Change in’ counter (compteur “change in”) 14 0x0C Get ‘Change out’ counter (compteur “change

out”) 14

0x0D Get game software version 16 0x0E Get checksum (signature software) 17 0x0F Download eID-logfile 10+Len 0x80 Get F9 Data 200 0x81 Get F10 Data 118

(*1) = Nombre d'octets de retour du slave au master pour une commande donnée

La machine doit obligatoirement répondre aux commandes 0x80, 0x81 et 0x0F. Les autres commandes sont optionnelles.

G. Description détaillée de la série des retours du slave Dans ce qui suit, le terme 'TxPrototype' signifie la description mnémonique de la commande envoyée du master au slave et le terme 'TxCmd' donne la série de commandes, le terme 'RxPrototype' signifie la réponse prototype du slave au master.

"Exemple" donne un exemple typique de la série reçue et le terme 'Hex' montre le retour de la série exprimée en tant que valeurs hexadécimales.

G.0. 0x00: Null TxPrototype: STX “00” EOT TxCmd: STX 0x30 0x30 EOT RxPrototype: STX “00” “CS” EOT Exemple: 0x02 0x30 0x30 0x36 0x30 0x04

G.1. 0x01: Visualisation de l’identification du jeu Rend le numéro d’approbation de la Métrologie sous un format B-xx-xxxxxx/xx suivi du séparateur ‘;’ et le numéro de série du jeu codé en 10 charactères completé par des ‘0’ à gauche. Si le numéro de série ne peut pas être transmis pour des raisons techniques, le jeu retourne la chaîne nulle “0000000000” TxPrototype: STX “01” EOT TxCmd: STX 0x30 0x31 EOT RxPrototype: STX “01” “B-xx-xxxxxx/xx;ssssssssss” “CS” EOT Exemple: STX “01” “B-03-007004/01;V1234567R0” “1B” EOT


-35-

Hex: 0x02 0x30 0x31 0x42 0x2D 0x30 0x33 0x2D 0x30 0x30 0x37 0x30 0x30 0x34 0x2F 0x30 0x31 0x3B 0x56 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x52 0x30 0x31 0x42 0x04

G.2. 0x02: Visualisation des compteurs généraux Les compteurs sont des nombres hexadécimaux de 32 bits codés en 8 octets comme décrit au paragraphe D.2. Les compteurs sont donnés dans l’ordre suivant : Credit in , Credit out , Hand pay , Total bets , Total wins , Number of played games , Number of game interrupts , Number of door open events. Les cinq premiers compteurs, qui donnent les montants sont exprimés en Euro cent. TxPrototype: STX “02” EOT TxCmd: STX 0x30 0x32 EOT RxPrototype: STX “02” “credit in” “credit out” “handpay” “total bets” “total wins”

“games” “interrupts“ “door” “CS” EOT Exemple: STX “02” “0000002F” “0000001A” “00001234” “00005678”

“12343210” “00000012” “00009876” “98765432” “0D” EOT Hex: 0x02 0x30 0x32 0x30 0x30 0x30 0x30 0x30 0x30 0x32 0x46 0x30 0x30 0x30

0x30 0x30 0x30 0x31 0x41 0x30 0x30 0x30 0x30 0x31 0x32 0x33 0x34 0x30 0x30 0x30 0x30 0x35 0x36 0x37 0x38 0x31 0x32 0x33 0x34 0x33 0x32 0x31 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x32 0x30 0x30 0x30 0x30 0x39 0x38 0x37 0x36 0x39 0x38 0x37 0x36 0x35 0x34 0x33 0x32 0x30 0x44 0x04

G.3. 0x03: Visualisation du compteur ‘Credit in’

Le compteur ‘Credit in’ est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant total introduit dans la machine via le monnayeur, le système cashless ou autre et exprimé en Euro cent. TxPrototype: STX “03” EOT TxCmd: STX 0x30 0x33 0x36 0x33 EOT RxPrototype: STX “03” “credit in” “CS” EOT Exemple: STX “03” “0000002F” “FB” EOT Hex: 0x02 0x30 0x33 0x30 0x30 0x30 0x30 0x30 0x30 0x32 0x46 0x46 0x42 0x04

G.4. 0x04: Visualisation du compteur ‘Credit out’ Le compteur ‘Credit out’ est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant total payé par le jeu via le hopper, le handpay ou autre système et exprimé en Euro cent. TxPrototype: STX “04” EOT TxCmd: STX 0x30 0x34 0x36 0x34 EOT RxPrototype: STX “04” “credit out” “CS” EOT Exemple: STX “04” “0000001A” “F6” EOT Hex: 0x02 0x30 0x34 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x41 0x46 0x36 0x04

G.5. 0x05: Visualisation du compteur ‘Hand pay’ Le compteur ‘Hand pay’ est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant payé manuellement et exprimé en Euro cent. Parfois, ce compteur est également appelé ‘Drop’ ou ‘Keyout’ TxPrototype: STX “05” EOT TxCmd: STX 0x30 0x35 EOT RxPrototype: STX “05” “handpay” “CS” EOT Exemple: STX “05” “00000010” “E6” EOT Hex: 0x02 0x30 0x35 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30 0x45 0x36 0x04


-36-

G.6. 0x06: Visualisation du compteur ‘Total bet’ Le compteur ‘Total bet’ est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant total des mises sur le jeu et exprimé en Euro cent. TxPrototype: STX “06” EOT TxCmd: STX 0x30 0x36 EOT RxPrototype: STX “06” “total bet” “CS” EOT Exemple: STX “06” “00000010” “E7” EOT Hex: 0x02 0x30 0x36 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30

G.7. 0x07: Visualisation du compteur ‘Total win’ Le compteur ‘Total win’ est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant total de l’argent gagné sur le jeu et exprimé en Euro cent. TxPrototype: STX “07” EOT TxCmd: STX 0x30 0x37 EOT RxPrototype: STX “07” “total win” “CS” EOT Exemple: STX “07” “00000010” “E8” EOT Hex: 0x02 0x30 0x37 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30 0x45 0x38 0x04

G.8. 0x08: Visualisation du nombre de parties jouées Le compteur ‘Number of played games’ est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur est incrémenté au début de chaque nouvelle partie. TxPrototype: STX “08” EOT TxCmd: STX 0x30 0x38 EOT RxPrototype: STX “08” “games” “CS” EOT Exemple: STX “08” “00000010” “E9” EOT Hex: 0x02 0x30 0x38 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30 0x45 0x39 0x04

G.9. 0x09: Visualisation du nombre d’interruptions Le compteur ‘Number of interrupts’ est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur est incrémenté à chaque interruption de jeu. TxPrototype: STX “09” EOT TxCmd: STX 0x30 0x39 EOT RxPrototype: STX “09” “interrupts” “CS” EOT Exemple: STX “09” “00000010” “EA” EOT Hex: 0x02 0x30 0x39 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30 0x45 0x41 0x04

G.10. 0x0A: Visualisation du compteur ‘Door open’ Le compteur ‘Door open’ est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2.counter. Ce compteur est incrémenté chaque fois que la porte principale est ouverte. TxPrototype: STX “0A” EOT TxCmd: STX 0x30 0x41 EOT RxPrototype: STX “0A” “Door” “CS” EOT Exemple: STX “0A” “00000010” “F2” EOT Hex: 0x02 0x30 0x41 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30 0x46 0x42 0x04


-37-

G.11. 0x0B: Visualisation du compteur ‘Change in’ Le compteur ‘Change in’ est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant en Euro cent introduits dans le changeur de monnaie. TxPrototype: STX “0B” EOT TxCmd: STX 0x30 0x42 EOT RxPrototype: STX “0B” “changein” “CS” EOT Exemple: STX “0B” “00000032” “F7” EOT Hex: 0x02 0x30 0x42 0x30 0x30 0x30 0x30 0x30 0x30 0x33 0x32 0x46 0x37 0x04

G.12. 0x0C: Visualisation du compteur ‘Change out’ Le compteur ‘Change out’ est un nombre de 32 bit hexadécimal codé en 8 bytes comme décrit au paragraphe D.2. Ce compteur donne le montant en Euro cent payé suite à l’introduction d’un billet de banque introduit dans le changeur de monnaie. TxPrototype: STX “0C” EOT TxCmd: STX 0x30 0x43 EOT RxPrototype: STX “0C” “changeout” “CS” EOT Exemple: STX “0C” “00000032” “F8” EOT Hex: 0x02 0x30 0x43 0x30 0x30 0x30 0x30 0x30 0x30 0x33 0x32 0x46 0x38 0x04

G.13. 0x0D: Visualisation du software du jeu La version du software est une série de 10 caractères, complété de ‘0’ essentiels du côté gauche. L’exemple ci-dessous représente la version “V1.00.01”. TxPrototype: STX “0D” EOT TxCmd: STX 0x30 0x44 EOT RxPrototype: STX “0D” “vvvvvvvvvv” “CS” EOT Exemple: STX “0D” “00V1.00.01” “78” EOT Hex: 0x02 0x30 0x44 0x30 0x30 0x56 0x31 0x2E 0x30 0x30 0x2E 0x30 0x31 0x37

0x38 0x04

G.14. 0x0E: Visualisation du checksum du software Cette commande permet de visualiser la clef du software et le checksum en utilisant cette clef. La clef est composée de 3 bytes et envoie un caractère de 6 ASCII en utilisant le tableau de conversion décrit dans le chapitre D.2. Le checksum est un nombre de 2 bytes converti comme décrit dans le paragraphe D.2. Les deux séries sont séparées par un point-virgule (";"). Les 3 bytes de la clé sont calculés à partir du numéro de la semaine et de l’année en cours. Le premier chiffre du numéro de la semaine constitue le premier byte ; le deuxième chiffre du numéro de la semaine constitue le deuxième byte ; les deux derniers chiffres du millésime de l’année en cours constituent le troisième byte. Le numéro de la semaine est calculé sur base de la norme ISO 8601 qui prévoit que la semaine no 1 est la semaine qui contient le premier jeudi de l’année. Exemple : pour la date 20/02/2006 ; soit la semaine 08 de 2006, clé1 = 0 ; clé 2 = 8 ; clé3 = 6

TxPrototype: STX “0E” EOT TxCmd: STX 0x30 0x45 EOT RxPrototype: STX “0E” “key;checksum” “CS” EOT Exemple: STX “0E” “2AB792;F378” “EF” EOT Hex : 0x02 0x30 0x45 0x32 0x41 0x42 0x37 0x39 0x32 0x3B 0x46 0x33 0x37

0x38 0x45 0x46 0x04


-38-

G.15. 0x0F: Download eID-logfile Pour la carte “exploitant”, la date de naissance doit être 01/01/1900 ; Flag : 0 = Carte (joueur) acceptée ; 1 = Carte exploitant ; 2 = Carte refusée ; Fichier LogFile limité aux 1000 derniers records;

Commande pour le download : 0x0F

TxPrototype: STX "0F" EOT TxCmd: STX 0x30 0x46 EOT RxPrototype: STX "0F" "FileLength" "LogFile" "CS" EOT Remarques:

FileLength est le nombre de bytes du fichier LogFile exprimé en 16 bits, codé selon D.2 en 4 bytes (exemple 1000 records de 31 bytes : 0x37 0x39 0x31 0x38)

Chaque identité est enregistrée dans le LogFile en suivant la norme : 04/11/2009;15:47;28/03/1983;0 CR LF (soit 31 bytes) A la demande de la CJH une transmission "manuelle" du fichier doit être possible.

G.16. 0x80: Get F9 Data Cette commande permet de transmettre toutes les données nécessaires à la création du fichier F9. Remarque : cette commande doit provoquer la remise à zéro des compteurs "Total bet (journalier)", "Total Win (journalier)" et "Nombre de jeux (journalier)" (si les compteurs journaliers ne sont pas transmis, leur remise à zéro n'est pas obligatoire). Les compteurs supplémentaires "Total bet (global)", "Total Win (global)" et "Nombre de jeux (global)" ne peuvent pas être remis à zéro.

TxPrototype: STX “80” EOT TxCmd: STX 0x38 0x30 EOT RxPrototype: STX “80”

";Identificatienummer ; (codé selon D.1 - 10 chr complétés par des ‘0’ à gauche) NoSuite; (codé selon D.1 – 10 chr complétés par des ‘0’ à gauche) TotalBetJournalier; (codé selon D.2 – hexadécimal 32 bits) TotalBetGlobal; (codé selon D.2 – hexadécimal 32 bits) TotalWinJournalier; (codé selon D.2 – hexadécimal 32 bits) TotalWinGlobal ; (codé selon D.2 – hexadécimal 32 bits) NbrPartieJournalier; (codé selon D.2 – hexadécimal 32 bits) NbrPartieGlobal; (codé selon D.2 – hexadécimal 32 bits) CleRepartition; (codé selon D.1 – format "000/000") ("F2" / "E") NoLicenceF2; (codé selon D.1 – format "FB000000") NoApprobation; (codé selon D.1 – format "B-00-000000/00") TotalBetOuverture; (codé selon D.2 – hexadécimal 32 bits) TotalWinOuverture; (codé selon D.2 – hexadécimal 32 bits) TotalBetFermeture; (codé selon D.2 – hexadécimal 32 bits) TotalWinFermeture; (codé selon D.2 – hexadécimal 32 bits) DateOuverture; (codé selon D.1 – format "aaaa/mm/jj") HeureOuverture; (codé selon D.1 – format "hh:mm:ss") DateFermeture; (codé selon D.1 – format "aaaa/mm/jj") HeureFermeture; (codé selon D.1 – format "hh:mm:ss") NbrDoorOpen;" (codé selon D.2 – hexadécimal 32 bits) “CS” EOT


-39-

G.17. 0x81: Get F10 Data. Cette commande permet de transmettre toutes les données nécessaires à la création du fichier F10. TxPrototype: STX “81” EOT TxCmd: STX 0x38 0x31 EOT RxPrototype: STX “81”

“ ;NoIdentification ; (codé selon D.1 - 10 chr complétés par des ‘0’ à gauche) NoSuite; (codé selon D.1 - 10 chr complétés par des ‘0’ à gauche) NoApprobation; (codé selon D.1 – format "B-00-000000/00") DateApprobation; (codé selon D.1 – format "aaaa/mm/jj") DateDernVerif; (codé selon D.1 – format "aaaa/mm/jj") DateSignatureSoft; (codé selon D.1 – format "aaaa/mm/jj") HeureSignatureSoft; (codé selon D.1 – format "hh:mm:ss") ResultatSignatureSoft; (codé selon D.2 – format “key ; checksum” Vb.

2AB792;F378) VersionSoftware; (codé selon D.1 - 10 chr complétés par des ‘0’ à gauche) NoLicenceF2;” (codé selon D.1 – format "FB000000") “CS” EOT


-40-

19 ANNEXE 3 : TABLE ASCII

Decimal Octal Hex Binary Value Description

000 000 000 00000000 NUL (Null char.)

001 001 001 00000001 SOH (Start of Header)

002 002 002 00000010 STX (Start of Text)

003 003 003 00000011 ETX (End of Text)

004 004 004 00000100 EOT (End of Transmission)

005 005 005 00000101 ENQ (Enquiry)

006 006 006 00000110 ACK (Acknowledgment)

007 007 007 00000111 BEL (Bell)

008 010 008 00001000 BS (Backspace)

009 011 009 00001001 HT (Horizontal Tab)

010 012 00A 00001010 LF (Line Feed)

011 013 00B 00001011 VT (Vertical Tab)

012 014 00C 00001100 FF (Form Feed)

013 015 00D 00001101 CR (Carriage Return)

014 016 00E 00001110 SO (Shift Out)

015 017 00F 00001111 SI (Shift In)

016 020 010 00010000 DLE (Data Link Escape)

017 021 011 00010001 DC1 (XON = Device Control 1)

018 022 012 00010010 DC2 (Device Control 2)

019 023 013 00010011 DC3 (XOFF = Device Control 3)

020 024 014 00010100 DC4 (Device Control 4)

021 025 015 00010101 NAK (Negative Acknowledgement)

022 026 016 00010110 SYN (Synchronous Idle)

023 027 017 00010111 ETB (End of Trans.

024 030 018 00011000 CAN (Cancel)

025 031 019 00011001 EM (End of Medium)

026 032 01A 00011010 SUB (Substitute)

027 033 01B 00011011 ESC (Escape)

028 034 01C 00011100 FS (File Separator)

029 035 01D 00011101 GS (Group Separator)

030 036 01E 00011110 RS (Record Separator)

031 037 01F 00011111 US (Unit Separator)

032 040 020 00100000 SP (Space)

033 041 021 00100001 ! (exclamation mark)

034 042 022 00100010 " (double quote)

035 043 023 00100011 # (number sign)

036 044 024 00100100 $ (dollar sign)

037 045 025 00100101 % (percent)

038 046 026 00100110 & (ampersand)

039 047 027 00100111 (single quote)


-41-

040 050 028 00101000 ( (left/opening parenthesis)

041 051 029 00101001 ) (right/closing parenthesis)

042 052 02A 00101010 * (asterisk)

043 053 02B 00101011 + (plus)

044 054 02C 00101100 , (comma)

045 055 02D 00101101 - (minus or dash)

046 056 02E 00101110 . (dot)

047 057 02F 00101111 / (forward slash)

048 060 030 00110000 0 (character 0)

049 061 031 00110001 1 (character 1)

050 062 032 00110010 2 (character 2)

051 063 033 00110011 3 (character 3)

052 064 034 00110100 4 (character 4)

053 065 035 00110101 5 (character 5)

054 066 036 00110110 6 (character 6)

055 067 037 00110111 7 (character 7)

056 070 038 00111000 8 (character 8)

057 071 039 00111001 9 (character 9)

058 072 03A 00111010 : (colon)

059 073 03B 00111011 ; (semi-colon)

060 074 03C 00111100 < (less than)

061 075 03D 00111101 = (equal sign)

062 076 03E 00111110 > (greater than)

063 077 03F 00111111 ? (question mark)

064 100 040 01000000 @ (AT symbol)

065 101 041 01000001 A (character A)

066 102 042 01000010 B (character B)

067 103 043 01000011 C (character C)

068 104 044 01000100 D (character D)

069 105 045 01000101 E (character E)

070 106 046 01000110 F (character F)

071 107 047 01000111 G (character G)

072 110 048 01001000 H (character H)

073 111 049 01001001 I (character I)

074 112 04A 01001010 J (character J)

075 113 04B 01001011 K (character K)

076 114 04C 01001100 L (character L)

077 115 04D 01001101 M (character M)

078 116 04E 01001110 N (character N)

079 117 04F 01001111 O (character O)

080 120 050 01010000 P (character P)

081 121 051 01010001 Q (character Q)

082 122 052 01010010 R (character R)

083 123 053 01010011 S (character S)

084 124 054 01010100 T (character T)


-42-

085 125 055 01010101 U (character U)

086 126 056 01010110 V (character V)

087 127 057 01010111 W (character W)

088 130 058 01011000 X (character X)

089 131 059 01011001 Y (character Y)

090 132 05A 01011010 Z (character Z)

091 133 05B 01011011 [ (left/opening bracket)

092 134 05C 01011100 \ (back slash)

093 135 05D 01011101 ] (right/closing bracket)

094 136 05E 01011110 ^ (caret/cirumflex)

095 137 05F 01011111 _ (underscore)

096 140 060 01100000 `

097 141 061 01100001 a (character a)

098 142 062 01100010 b (character b)

099 143 063 01100011 c (character c)

100 144 064 01100100 d (character d)

101 145 065 01100101 e (character e)

102 146 066 01100110 f (character f)

103 147 067 01100111 g (character g)

104 150 068 01101000 h (character h)

105 151 069 01101001 i (character i)

106 152 06A 01101010 j (character j)

107 153 06B 01101011 k (character k)

108 154 06C 01101100 l (character l)

109 155 06D 01101101 m (character m)

110 156 06E 01101110 n (character n)

111 157 06F 01101111 o (character o)

112 160 070 01110000 p (character p)

113 161 071 01110001 q (character q)

114 162 072 01110010 r (character r)

115 163 073 01110011 s (character s)

116 164 074 01110100 t (character t)

117 165 075 01110101 u (character u)

118 166 076 01110110 v (character v)

119 167 077 01110111 w (character w)

120 170 078 01111000 x (character x)

121 171 079 01111001 y (character y)

122 172 07A 01111010 z (character z)

123 173 07B 01111011 { (left/opening brace)

124 174 07C 01111100 | (vertical bar)

125 175 07D 01111101 } (right/closing brace)

126 176 07E 01111110 ~ (tilde)

127 177 07F 01111111 DEL (delete)


-43-

20 ANNEXE 4 : ARRÊTÉ ROYAL DU 22 DECEMBRE 2010

22 DECEMBRE 2010. - Arrêté royal relatif aux modalités de surveillance et de contrôle des jeux de hasard dans les établissements de jeux de hasard de classe IV et les lieux où les paris sont engagés en vertu de l'article 43/4, § 5, de la loi du 7 mai 1999 sur les jeux de hasard, les paris, les établissements de jeux de hasard et la protection des joueurs, notamment au moyen d'un système informatique approprié ALBERT II, Roi des Belges,

A tous, présents et à venir, Salut. Vu la Constitution, l'article 108;

Vu la loi du 7 mai 1999 sur les jeux de hasard, les paris, les établissements de jeux de hasard et la protection des joueurs, l'article 43/7, 5, inséré par la loi du 10 janvier 2010;

Vu l'avis de la Commission des jeux de hasard, donné le 2 décembre 2009; Vu l'avis de l'Inspecteur des Finances, donné le 15 février 2010;

Vu l'accord du Secrétaire d'Etat au Budget, donné le 28 avril 2010;

Vu la communication à la Commission européenne 2010/0287/B, du 7 mai 2010, en application de l'article 8, paragraphe 1er, de la Directive 98/34/CE du Parlement européen et du Conseil du 22 juin 1998 prévoyant une procédure d'information dans le domaine des normes et réglementations techniques et des règles relatives aux services de la société de l'information;

Vu l'avis 48.251/2 du Conseil d'Etat, donné le 1er juin 2010, en application de l'article 84, § 1er, alinéa 1er, 1°, des lois sur le Conseil d'Etat, coordonnées le 12 janvier 1973; Sur la proposition du Ministre de la Justice, du Ministre des Finances, de la Ministre de la Santé publique, du Ministre pour l'Entreprise, de la Ministre de l'Intérieur et du Secrétaire d'Etat adjoint au Ministre de la Justice,

Nous avons arrêté et arrêtons :

Article 1er. Dans le présent arrêté royal, il convient d'entendre par :

1° LAN : le réseau local; 2° Client : toute unité électronique, donc tant les pc administratifs que les jeux

automatiques; 3° UPS : Uninterruptable Power Supply.

Art. 2. Tous les établissements de jeux de hasard de classe IV prévoient un LAN, lequel est connecté avec un LAN de la Commission des jeux de hasard.

Tous établissements de jeux de hasard permanents de classe IV disposent d'un système de vidéosurveillance.

Les titulaires de licence F1 sont responsables de l'élaboration et l'exploitation du réseau afin de lier tous les établissements de jeux de hasard de classe IV (titulaires de licence F2) et les lieux où les paris sont acceptés, visés à l'article 43/4, § 5, de la loi du 7 mai 1999 sur les jeux de hasard, les paris, les établissements de jeux de hasard et la protection des joueurs, à leur serveur central.


-44-

Art. 3. Tous les coûts liés à l'achat du matériel, à l'obtention des licences de logiciels et aux loyers dus sont à charge des titulaires de licence F1.

Art. 4. Un serveur central unique relié à tous les clients via le LAN est prévu comme configuration du matériel. Il est prévu un logiciel de base de données, de nature à garantir suffisamment la qualité, l'intégrité, la robustesse et l'accès simultané multiple.

Art. 5. Il convient d'informer correctement le personnel et les joueurs de l'existence et du fonctionnement du système de vidéosurveillance visé à l'article 2, alinéa 2. Les enregistrements sont conservés dans un local séparé auquel peuvent uniquement accéder les membres du personnel désignés, les membres de la Commission des jeux de hasard et de son secrétariat, ainsi que des personnes externes à la Commission qu'elle désigne nommément. Les enregistrements, effectués sur un support au choix, doivent être conservés pendant quatre semaines et mis à la disposition de la Commission des jeux de hasard sur simple demande de celle-ci.

Lorsque des irrégularités ou des infractions au jeu sont constatées et filmées ou en cas de dérèglement important du système de vidéosurveillance, la Commission des jeux de hasard en est informée immédiatement. Elle se prononce sur la procédure à suivre et sur l'utilisation des enregistrements. Aucun enregistrement ne peut être effacé ou détruit avant sa décision.

Les enregistrements relatifs au jeu, à l'enregistrement et aux caisses doivent avoir lieu dès l'ouverture de la salle de jeu jusqu'à la clôture de toutes les opérations et à la fermeture de la salle de jeu. Les autres enregistrements sont effectués sur une base permanente, sans interruption.

Art. 6. La Commission des jeux de hasard a la garantie, à l'aide d'un code source et d'un code objet, que le logiciel qu'elle a approuvé fonctionne réellement. A cet effet, elle peut à tout moment demander une recompilation afin de vérifier si le code source officiel a bien été compilé.

Art. 7 . Tous les clients sont reliés en permanence au système informatique et plus particulièrement au serveur et à la banque de données centraux. Un UPS adapté avec une autonomie de deux heures est prévu pour le serveur central. Lorsque la connexion entre un jeu automatique et le LAN se coupe ou rencontre un problème quelconque d'ordre mécanique ou technique qui dure plus de vingt-quatre heures, le jeu est arrêté compte tenu des règles de fonctionnement en matière d'arrêt et de relance de jeux automatiques.

Lorsque le serveur central est en panne pendant plus de vingt-quatre heures, tous les jeux sont arrêtés. Une procédure de back-up et de recovery est approuvée par la Commission des jeux de hasard ainsi que la preuve d'exécutions de tests bimensuelles.

Art. 8. L'installation ainsi que toute modification, de quelque nature que ce soit, du système informatique doivent préalablement avoir été approuvées par la Commission des jeux de hasard.


-45-

Art. 9. L'accès au serveur central, aux postes de travail et aux programmes est réglé par un système de mots de passe qui est soumis à la Commission des jeux de hasard avant son introduction.

Le système informatique et le système de vidéosurveillance sont installés dans des locaux séparés. L'accès est uniquement autorisé après une procédure de contrôle d'accès qui est soumise à la Commission des jeux de hasard avant son introduction.

Art. 10. Le système informatique est protégé contre les interférences électromagnétiques et électrostatiques ainsi que contre les ondes radioélectriques.

Art. 11. § 1er. La Commission des jeux de hasard rédige un protocole contenant les éléments suivants : 1. Contenu du présent document; 2. Définitions et abréviations; 3. Conditions générales; 4. Des conditions techniques relatives au câblage et aux composants passifs du LAN; 5. Des conditions techniques relatives aux composants actifs du LAN; 6. Des conditions techniques relatives aux clients et aux serveurs; 7. Des conditions techniques au local destiné au data-rack; 8. Des conditions techniques relatives à la liaison de données avec la Commission des

jeux de hasard; 9. Des conditions supplémentaires relatives au système de vidéosurveillance; 10. Des conditions relatives à l'information comptable et financière; 11. Des conditions relatives à l'enregistrement; 12. Des conditions relatives au contrôle technique; 13. Des conditions relatives à la documentation concernant le système informatique et le

système de vidéosurveillance; 14. Utilisation des nouvelles technologies de l'information; 15. Des normes concernant la nomenclature des fichiers à envoyer; 16. Approbation.

§ 2. Ce protocole est communiqué à tous les titulaires d'une licence de classe IV au plus tard une semaine après son approbation par la Commission des jeux de hasard.

Toute modification du protocole est communiquée aux titulaires d'une licence de classe IV au plus tard une semaine après son approbation par la Commission des jeux de hasard.

Art. 12. Le présent arrêté entre en vigueur le 1er janvier 2011, à l'exception de l'article 2, alinéa 2, qui entre en vigueur le 1er janvier 2012.

Art. 13. Le Ministre qui a la Justice dans ses attributions, le Ministre qui a les Finances dans ses attributions, le Ministre qui a la Santé publique dans ses attributions, le Ministre qui a l'Entreprise dans ses attributions, le Ministre qui a l'Intérieur dans ses attributions et le Ministre qui a la Loterie Nationale dans ses attributions sont chargés, chacun en ce qui le concerne, de l'exécution du présent arrêté.

Donné à Bruxelles, le 22 décembre 2010. ALBERT


-46-

Par le Roi :

Le Ministre de la Justice, S. DE CLERCK

Le Ministre des Finances, D. REYNDERS La Ministre de la Santé publique, Mme L. ONKELINX

Le Ministre pour l'Entreprise, V. VAN QUICKENBORNE

La Ministre de l'Interieur, Mme A. TURTELBOOM Le Secrétaire d'Etat adjoint au Ministre de la Justice, C. DEVLIES

Protocole relatif aux modalités de surveillance et de ... · Protocole relatif aux modalités de...

Documents

Transcript of Protocole relatif aux modalités de surveillance et de ... · Protocole relatif aux modalités de...