Liste de contrôle des tests, de la sécurité, de la certification et des SLA de plateformes de loterie
Une liste de contrôle de sécurité et de disponibilité d’une plateforme de loterie doit relier chaque exigence à un test, à un responsable qui en répond et aux preuves de la version que vous exploiterez. Partez du produit prévu, des exigences applicables, des accords de paiement et du contrat. Commandez les travaux indépendants assez tôt […]
Une liste de contrôle de sécurité et de disponibilité d’une plateforme de loterie doit relier chaque exigence à un test, à un responsable qui en répond et aux preuves de la version que vous exploiterez. Partez du produit prévu, des exigences applicables, des accords de paiement et du contrat. Commandez les travaux indépendants assez tôt pour corriger les constats et refaire les tests. Négociez ensuite des niveaux de service mesurables pour l’ensemble du parcours client, et pas seulement pour un serveur qui répond à un contrôle de santé.
Rapports RNG, tests d’intrusion, certificats et engagements de disponibilité répondent à des questions différentes. Aucun ne remplace les autres. Utilisez la liste d’évaluation des fournisseurs pour comparer les propositions et téléchargez WhiteLotto Operator Decision Pack (XLSX) pour consigner exigences, lacunes de preuves et décisions.
Distinguez tests, certification et assurance opérationnelle
Créez une matrice d’exigences : obligation et source, composant, version, environnement, norme requise, évaluateur admissible, prérequis, livrable et responsable de l’acceptation. Identifiez ce que couvrent les preuves du fournisseur et ce qui reste propre à votre déploiement. L’assurance qualité interne soutient ce travail, mais ne remplace pas l’évaluation indépendante requise.
| Périmètre | Questions à tester | Preuves à demander |
|---|---|---|
| Jeu et RNG | Où intervient l’aléatoire : générateur, correspondances, règles du jeu et traitement des résultats. | Rapport identifiant composants testés, versions, méthodes et exclusions. |
| Plateforme et intégrations | Acceptation des billets, clôture des ventes, demandes en double, règlement, ingestion des résultats et rapprochement. | Résultats des tests système pour les intégrations configurées et les cas de panne. |
| Cybersécurité | Authentification, accès privilégiés, API, configuration, vulnérabilités et gestion des incidents. | Évaluation au périmètre défini, registre des constats et preuves de nouveaux tests indépendants. |
| Sécurité des paiements | Flux de données de cartes, systèmes influençant ces flux et répartition des responsabilités. | Périmètre PCI confirmé et preuves de validation applicables. |
| Exploitation du service | Disponibilité, reprise, escalade de l’assistance et intégrité des transactions. | Définitions du SLA, preuves de surveillance et résultats d’exercices de reprise. |
Le catalogue des normes GLI distingue les normes d’évaluation des jeux et de la sécurité. Une entrée au catalogue ne prouve pas qu’un produit particulier est certifié. Confirmez la norme exacte et les preuves acceptées pour votre exigence ; ne supposez pas qu’un certificat couvre toute configuration ou utilisation.
Sélectionnez les prestataires indépendants avant la fenêtre de lancement
Vérifiez compétences pertinentes, accréditation ou reconnaissance si nécessaire, indépendance, conflits, sous-traitants et disponibilité. Une mise en relation avec un laboratoire ne démontre pas son admissibilité et ne garantit pas l’acceptation de son rapport. Convenez par écrit du périmètre, des méthodes, des exclusions, des éléments d’entrée, de la confidentialité, des usages permis des conclusions, des frais de nouveaux tests et des livrables.
Pour les paiements, le PCI SSC décrit PCI DSS comme protégeant les données des comptes de paiement, y compris pour les entités susceptibles d’affecter l’environnement des données de titulaires de cartes. N’assimilez pas l’externalisation de l’encaissement à l’absence de responsabilités. Cartographiez les flux réels et confirmez votre périmètre et votre voie de validation applicables avec la contrepartie de paiement concernée et un évaluateur qualifié.
Rattachez les résultats des tests à la version déployée
L’ingénierie doit tenir un manifeste de version couvrant identifiants ou empreintes de compilation, dépendances, configuration, infrastructure, jeux et intégrations. Consignez l’environnement de test et expliquez les différences avec la production. Donnez aux évaluateurs un accès journalisé et limité dans le temps ; minimisez les données et utilisez des canaux de transfert sécurisés approuvés.
Le registre des preuves doit relier chaque constat à la version concernée, sa gravité, son responsable, l’action corrective, le contrôle temporaire, le nouveau test et la décision de clôture. Conservez en sécurité les rapports et constats défavorables, y compris dans les synthèses destinées à la direction. La sécurité répond des corrections techniques ; la conformité vérifie la couverture des exigences ; la gestion des versions vérifie que le déploiement correspond aux preuves. Nommez les personnes pouvant accepter le risque résiduel sans écarter une exigence externe.
Un constat critique près du lancement
Si un test d’intrusion révèle un accès à des comptes privilégiés, isolez l’environnement concerné, évaluez l’exposition et impliquez les responsables sécurité, ingénierie, conformité et juridique. Corrigez la cause profonde et examinez les composants liés. Obtenez des preuves de nouveaux tests indépendants ; ne réduisez pas la gravité pour préserver la date. Retardez ou réduisez le périmètre du lancement si les conditions d’acceptation autorisées ne peuvent être remplies.
Réservez du temps pour les questions de périmètre, les corrections et les nouveaux tests, pas seulement pour l’évaluation initiale. Un changement ultérieur de bibliothèque d’authentification peut affecter sessions, permissions et notifications de paiement : évaluez son impact et demandez aux spécialistes concernés si des tests ciblés ou plus larges sont nécessaires.
Transformez les annonces de disponibilité en SLA opérationnel
Un SLA est une définition contractuelle, pas une certification. Précisez parcours couverts, périodes de mesure, lieux de surveillance, calcul et exclusions. La disponibilité se calcule couramment en divisant le temps admissible moins l’indisponibilité comptabilisée par le temps admissible. Pour une période illustrative de 30 jours, 99,9 % autorise 43,2 minutes d’indisponibilité comptabilisée. Ce pourcentage dit peu sur une panne juste avant la clôture des ventes de billets.
| Sujet | Demandez au fournisseur |
|---|---|
| Service couvert | La disponibilité inclut-elle connexion, confirmation des billets, API et accès administratif ? Comment les pannes partielles sont-elles comptées ? |
| Dépendances et exclusions | Comment sont classées les pannes de paiement ou de flux de tirages ? Quels préavis et limites s’appliquent à la maintenance ? |
| Réponse aux incidents | Quelle gravité déclenche une escalade permanente ? Accusé de réception, mises à jour et rétablissement ont-ils des objectifs distincts ? |
| Reprise | Quels RTO et RPO sont proposés pour chaque service critique ? Quel exercice les démontre ? |
| Preuves et recours | Qui reçoit les mesures et rapports d’incident ? Comment sont traités litiges, avoirs et manquements répétés ? |
L’objectif de délai de reprise (RTO) est le délai cible pour rétablir le service ; l’objectif de point de reprise (RPO) est la limite cible de perte de données exprimée en temps. Un calendrier de sauvegarde ne prouve à lui seul ni l’un ni l’autre. Demandez délais de reprise observés, points de données restaurés, prérequis et exceptions. Les chiffres présentés sont des exemples d’achat, non des engagements de service WhiteLotto. Incluez les responsabilités de tests et de reprise dans votre comparaison des prix de logiciels.
Testez les pannes et la restauration, pas seulement le trafic normal
La confirmation du billet est perdue
Un client transmet une commande, mais la réponse dépasse le délai d’attente. Testez si une nouvelle tentative réutilise l’identité de la requête, vérifie son statut et évite un billet ou un débit en double. Consignez la transaction acceptée, la décision de clôture des ventes et le résultat du rapprochement. Une page d’accueil réactive ne doit pas masquer un parcours d’achat défaillant.
La restauration de la base réussit, mais les enregistrements divergent
Utilisez un exercice isolé autorisé pour restaurer les enregistrements et comparer commandes, références de paiement, soldes et états des billets. Vérifiez événements manquants ou dupliqués, rejeu des intégrations, continuité d’audit et tâches en attente. Vérifiez la disponibilité des clés et dépendances sans exposer de secrets. Convenez de la personne qui rapproche les écarts avant de rouvrir les ventes ; ne créez pas de transactions clients réelles pour l’exercice.
Assemblez le dossier de preuves du lancement
- Matrice des exigences et confirmation de l’admissibilité de l’évaluateur.
- Architecture versionnée, flux de données, manifeste de version et dossier d’équivalence avec la production.
- Rapports de tests, certificats, exclusions de périmètre, conditions de validité et permissions d’usage des conclusions.
- Constats, corrections, nouveaux tests indépendants et décisions autorisées sur les risques résiduels.
- Définitions du SLA, contacts d’escalade, résultats de reprise et procédures de rapprochement.
- Responsables d’acceptation de la version, contrôles continus et règles de réévaluation déclenchées par les changements.
Après le lancement, suivez échéances, correctifs, incidents et changements de bibliothèques, RNG, paiements ou infrastructure. Évaluez si les preuves couvrent toujours la version, même sans date d’expiration imprimée. Le Cadre de cybersécurité du NIST soutient la gestion continue des risques de cybersécurité ; un certificat n’est pas une surveillance continue. Explicitez les responsabilités lorsque vous comparez livraisons en marque blanche et clé en main.
Questions fréquentes
Un rapport RNG prouve-t-il la sécurité de la plateforme ?
Non. Il traite du périmètre d’aléatoire annoncé, pas de tous les comptes, intégrations ou contrôles opérationnels. Il ne prédit pas les tirages futurs.
Une promesse de disponibilité peut-elle remplacer les tests de reprise ?
Non. Demandez des preuves de restauration et de rapprochement testés, avec des objectifs RTO et RPO définis.
Cette liste confirme-t-elle les certifications de WhiteLotto ?
Non. Demandez des preuves actuelles pour le périmètre proposé. Ce guide ne revendique aucune certification WhiteLotto et ne garantit ni disponibilité, ni délai de reprise, ni limite de perte de données.
Échangez sur l’adéquation technique
Explorez la solution de plateforme WhiteLotto, puis contactez WhiteLotto pour discuter de l’adéquation technique. Apportez périmètre du produit, inventaire des intégrations, exigences de preuves et niveaux de service proposés pour documenter les responsabilités et questions ouvertes.
Les tests ont un périmètre limité et ne peuvent garantir sécurité, approbation ou conformité future. L’acceptation des preuves appartient à l’autorité ou à la contrepartie concernée ; licences et conseils professionnels constituent des chantiers distincts. Il s’agit d’un guide d’achat technique, non d’un conseil juridique.