Liste d’évaluation des fournisseurs de plateformes de loterie : cahier RFP pratique
Une demande de proposition (RFP) pour une plateforme de loterie doit décrire les flux de travail de l’opérateur, les intégrations, l’accès aux données, les contrôles, les responsabilités de livraison et les preuves d’acceptation. Distinguez les exigences obligatoires au lancement des préférences, demandez à chaque fournisseur comment elles seront livrées et testez les scénarios difficiles avant […]
Une demande de proposition (RFP) pour une plateforme de loterie doit décrire les flux de travail de l’opérateur, les intégrations, l’accès aux données, les contrôles, les responsabilités de livraison et les preuves d’acceptation. Distinguez les exigences obligatoires au lancement des préférences, demandez à chaque fournisseur comment elles seront livrées et testez les scénarios difficiles avant de vous engager. Le résultat doit être un cahier des exigences versionné, repris dans le contrat et le plan de mise en œuvre.
Cette liste aide une équipe d’achat à préparer ce document et à comparer les réponses. Elle ne classe pas les fournisseurs et ne suppose pas qu’une plateforme donnée possède déjà les capacités énumérées ci-dessous. Chaque point est une exigence à examiner et à vérifier.
1. Définissez le périmètre opérationnel avant de demander une démonstration
Partez des décisions déjà prises dans votre projet, des hypothèses encore ouvertes et des personnes autorisées à les résoudre. Consignez :
- Les produits prévus : billets de tirages externes, tirages propres, Keno, jeux personnalisés ou la combinaison précise nécessaire.
- Les marchés clients, marques, langues, devises, appareils et canaux de distribution prévus.
- Les entités et parties censées exploiter la marque, fournir la plateforme et gérer chaque service externe.
- Les phases de lancement, volumes estimés de transactions, périodes de pointe attendues et preuves à l’appui de ces estimations.
- Les systèmes ou données existants à connecter, conserver ou migrer.
- Les restrictions et exigences opérationnelles fournies par les conseillers qualifiés de l’opérateur et les contreparties concernées.
- Les hypothèses budgétaires, responsables de décision et dépendances susceptibles d’affecter les dates de livraison.
Un élément d’entrée non résolu doit avoir un responsable et une date de décision. Le consigner comme hypothèse est plus utile que de demander un devis sur un périmètre apparemment complet qui changera pendant la mise en œuvre.
Choisir une plateforme ne résout pas les autorisations de marché, les licences ou les questions fiscales. Faites définir ces exigences par les conseillers appropriés, puis traduisez-les en flux de travail, contrôles système et preuves que la RFP doit couvrir.
2. Rédigez les exigences sous forme de flux et de preuves d’acceptation
Un nom de fonctionnalité explique rarement le résultat recherché. Par exemple, « portefeuille » n’indique pas au fournisseur comment doivent fonctionner soldes, règlements, annulations d’opérations et transactions contestées.
Utilisez une matrice d’exigences reliant le parcours aux preuves que vous accepterez :
| Flux de travail | Exigence à décrire | Preuves à demander |
|---|---|---|
| Inscription et vérification | Champs requis, états de vérification d’identité, gestion des exceptions et visibilité pour l’assistance | Un parcours scénarisé couvrant vérifications réussies, incomplètes et rejetées |
| Achat de billet ou de jeu | Règles du produit, clôtures de ventes, confirmation d’achat et traitement des annulations | Un exemple traçable de la création de commande au résultat ou au règlement |
| Portefeuille et paiements | Règles de solde, dépôts, retraits, remboursements et rapprochement | Des enregistrements couvrant un paiement réussi, une tentative échouée et une annulation d’opération |
| Tirages et résultats | Source du résultat, correspondance avec le produit, traitement des corrections et règles de paiement des gains | Un parcours du résultat au règlement, avec références aux sources et journaux |
| Protection des joueurs | Limites et restrictions de compte définies pour le modèle opérationnel | Des tests montrant l’effet des restrictions sur les parcours d’achat et de paiement concernés |
| Opérations clientèle | Réclamations, interventions manuelles, permissions et escalade | Des vues par rôle et une piste d’audit pour un cas d’assistance difficile |
| Rapports et accès aux données | Champs requis, identifiants stables, formats d’export et fréquence d’accès | Des exemples de rapports et d’exports rapprochables par les finances et les opérations |
Attribuez à chaque exigence un identifiant, une priorité, un responsable de l’acceptation et une dépendance. Ajoutez une courte explication de son importance. Les responsables produit, finances, sécurité, conformité et opérations clientèle doivent pouvoir examiner leurs sections sans devoir déduire le flux attendu d’une liste de noms de modules.
Pour les exigences propres aux paiements, utilisez le guide de l’architecture de paiement des loteries avec cette matrice.
3. Rendez les réponses des fournisseurs comparables
Demandez à chaque fournisseur présélectionné d’utiliser les mêmes catégories de réponse. Elles décrivent la voie de livraison proposée, pas une note de qualité.
| Réponse | Signification attendue | Précisions nécessaires |
|---|---|---|
| Disponible dans la version indiquée | Le fournisseur peut démontrer le résultat requis dans une version identifiée du produit | Version, preuves et éventuelles limites d’exploitation |
| Configuration nécessaire | Le résultat dépend de réglages ou de travaux de configuration convenus | Qui configure, effort, validation et responsabilité continue |
| Développement spécifique nécessaire | Le périmètre proposé inclut des fonctionnalités pas encore livrées | Spécification, base de coût, dépendances, critères d’acceptation et responsabilité des changements |
| Dépendance à un fournisseur externe | Un autre fournisseur ou service est nécessaire pour satisfaire l’exigence | Partie contractante, frontière d’intégration, responsable de l’assistance et gestion des pannes |
| Non pris en charge ou hors périmètre | La proposition ne satisfait pas l’exigence | Impact sur le périmètre de lancement et toute alternative proposée |
Pour chaque ligne, demandez le responsable de livraison, l’hypothèse, la référence de preuve, le traitement commercial et la dépendance de calendrier. Gardez les questions sans réponse visibles. Une annonce de feuille de route ne doit pas être enregistrée comme une capacité livrée.
Lorsque plusieurs parties interviennent, nommez la personne ou l’équipe qui coordonnera le parcours complet. Sinon, une intégration techniquement valide peut laisser l’opérateur sans responsable des exceptions ou incidents.
4. Incluez dès le départ données, intégrations et exigences de sortie
L’accès aux données est une exigence opérationnelle autant qu’un enjeu de sortie. Précisez les enregistrements nécessaires, les personnes pouvant y accéder, les identifiants qui les relient et les modalités de livraison des exports.
Frontières d’intégration
Pour chaque connexion requise, documentez les systèmes des deux côtés, les données échangées, la temporalité des événements, l’approche d’authentification, le versionnement, la surveillance et la responsabilité de l’assistance. Décrivez ce qui doit se passer après un délai d’attente dépassé, un message tardif, une notification en double ou l’indisponibilité d’un partenaire.
Demandez une documentation représentative des interfaces et des données de test. Un logo d’intégration ou une démonstration commerciale réussie n’établit pas le comportement du flux de bout en bout prévu.
Propriété, accès et portabilité
Demandez un inventaire des enregistrements de joueurs, commandes, transactions, résultats, assistance et audit. Définissez les champs nécessaires à chaque rôle opérationnel, formats d’export, fréquence, volume attendu et traitement des corrections. Consignez l’accès en exploitation normale, pendant la mise en œuvre, un incident et la résiliation.
Distinguez propriété contractuelle, accès pratique et responsabilités de traitement des données. Faites évaluer par les parties responsables les exigences de conservation, d’accès et de transfert dans votre situation. Le guide de propriété des données des joueurs apporte d’autres questions d’achat.
Exemple : les achats fonctionnent, mais l’historique des transactions n’est pas exportable
Dans cette évaluation hypothétique, une démonstration réalise inscription, dépôt et achat de billet. Le fournisseur ne peut pas encore produire un export complet des transactions avec des identifiants stables reliant les enregistrements de joueur, commande, paiement et règlement.
Demandez au fournisseur de démontrer l’export sur des volumes représentatifs et d’expliquer les champs, délais, limites et travaux supplémentaires éventuels. Les finances et les opérations doivent vérifier si le résultat répond à leurs besoins de rapprochement et d’investigation. Si la lacune persiste, décidez si une alternative testée peut satisfaire l’exigence ou si la proposition doit rester hors de la présélection.
Traitez ce point comme une dépendance opérationnelle actuelle, non comme une question à reporter jusqu’à ce que la migration devienne urgente.
5. Précisez les attentes de sécurité, de performance et de service
Écrivez les résultats de sécurité et d’exploitation nécessaires au projet : permissions administratives, journalisation des accès, surveillance, sauvegardes, reprise, escalade de l’assistance et gestion des changements. Incluez les mesures de disponibilité et de performance, hypothèses de capacité, accessibilité et exigences de localisation.
Demandez ce qui sera mesuré, sur quelle période, par qui et avec quelles exclusions. Documentez les objectifs de reprise et les preuves attendues d’un exercice de reprise. Ne traitez pas un pourcentage de disponibilité ou un badge de sécurité comme un substitut à la compréhension du périmètre proposé et de ses dépendances.
Le Cadre de cybersécurité du NIST est une référence primaire pour structurer les discussions de risque de cybersécurité. Utilisez-le pour organiser les questions et preuves demandées ; ce guide n’affirme pas qu’un fournisseur a été évalué selon ce cadre.
Pour les données de cartes de paiement, les ressources PCI DSS du PCI Security Standards Council décrivent des exigences de sécurité techniques et opérationnelles. Demandez aux spécialistes concernés des paiements et de la sécurité d’identifier le périmètre, les responsabilités et les preuves de validation applicables à l’architecture proposée. Une intégration de paiement externe ne répond pas seule à ces questions.
6. Scénarisez la démonstration autour des exceptions
Fournissez les mêmes scénarios aux prestataires avant la séance d’évaluation. Incluez un parcours réussi et les cas révélant les passages de relais entre systèmes :
- Un cas de vérification nécessitant des informations supplémentaires et une réponse claire de l’assistance.
- Une notification de paiement arrivant tard ou plusieurs fois.
- Un achat tenté près de la clôture des ventes configurée.
- Un résultat externe corrigé ou indisponible.
- Un compte restreint tentant une transaction concernée par la restriction.
- Un ajustement manuel nécessitant un utilisateur autorisé et un enregistrement traçable.
- Un rapport ou export que les finances doivent rapprocher des enregistrements de la plateforme.
Consignez la version du produit, les hypothèses, le comportement observé et les questions non résolues. Si un scénario ne peut être démontré, convenez des preuves supplémentaires nécessaires plutôt que de le déclarer accepté.
7. Utilisez une matrice de décision qui laisse visibles les lacunes obligatoires
Fixez vos priorités avant d’examiner les propositions. Voici un modèle de registre de décision :
| Domaine de décision | À consigner | Condition de présélection |
|---|---|---|
| Résultats obligatoires | Identifiants des exigences et preuves de la voie de livraison proposée | Aucune lacune non résolue sans alternative viable explicitement acceptée |
| Responsabilité de livraison | Responsabilités de l’opérateur, du fournisseur et des parties externes | Chaque dépendance et décision d’acceptation a un responsable |
| Accès aux données et aux contrôles | Preuves d’export, permissions, journaux et rapports | L’accès opérationnel requis est démontrable et convenu |
| Exposition commerciale | Mise en place, frais récurrents, hypothèses d’usage et travaux optionnels | La proposition explique les inclusions et exclusions du périmètre chiffré |
| Mise en œuvre et assistance | Jalons, dates de dépendances, escalade et procédure d’acceptation | Le plan est cohérent avec le périmètre et les exigences des parties externes |
Notez les préférences séparément si l’équipe d’achat le juge utile. Ne laissez pas une bonne note de design ou de fonctionnalités optionnelles masquer une exigence obligatoire manquante. Conservez la qualité des preuves et les hypothèses non résolues à côté de toute note.
8. Approuvez une référence numérotée des exigences
Après clarification, figez une version listant les éléments obligatoires, reportés et rejetés ainsi que les hypothèses encore ouvertes. Utilisez les mêmes identifiants d’exigences dans la proposition, le périmètre contractuel convenu, les travaux de mise en œuvre et le dossier d’acceptation.
Pour chaque changement, consignez l’effet sur le coût, le calendrier, les dépendances et les contrôles. Définissez qui peut l’approuver et qui testera le résultat. Cela évite qu’une exigence opérationnelle importante disparaisse entre un atelier, une proposition commerciale et la liste de contrôle de version.
Avant d’envoyer la RFP
- Confirmez les données d’entrée relatives au produit, au marché, au canal et au modèle opérationnel, avec les points non résolus clairement identifiés.
- Attribuez identifiant, priorité, exigence de preuve et responsable de l’acceptation à chaque flux.
- Demandez à chaque fournisseur une réponse commune sur le statut de livraison.
- Incluez exceptions d’intégration, rapports, accès aux données, sécurité et assistance.
- Demandez le périmètre commercial complet et les dépendances derrière les dates de livraison.
- Fournissez des scénarios de démonstration et consignez les preuves observées.
- Résolvez les lacunes obligatoires avant de considérer une proposition comme prête à être sélectionnée.
- Reprenez la référence approuvée dans la mise en œuvre et la liste de mise en service.
Téléchargez le classeur de décision de l’opérateur
WhiteLotto Operator Decision Pack comprend une liste RFP fondée sur les preuves, un modèle de TCO de plateforme sur 36 mois et une feuille de contribution incrémentale pour un opérateur existant ajoutant une loterie. Les données financières commencent vierges afin d’utiliser votre propre périmètre, les conditions de la proposition et vos hypothèses. Le classeur ne contient ni prix WhiteLotto ni rendements prévisionnels.
Téléchargez WhiteLotto Operator Decision Pack (XLSX)
Utilisez le classeur pour identifier les questions de votre échange de cadrage de plateforme. N’incluez pas de dossiers de joueurs, documents d’identité ou autres données sensibles dans une demande de contact.
Utilisez le guide des prix et du TCO des logiciels de loterie pour clarifier les définitions des frais avant de comparer les réponses commerciales.
Discutez de vos exigences de plateforme avec WhiteLotto
Apportez périmètre du produit, flux requis, intégrations, besoins de données et dépendances non résolues à un échange de cadrage de plateforme. Demandez quels éléments sont disponibles dans le périmètre proposé, lesquels nécessitent une configuration ou d’autres travaux et lesquels dépendent de parties externes.
Contactez WhiteLotto au sujet du périmètre de plateforme.
Les décisions de licences, juridiques et fiscales doivent être traitées par les conseillers qualifiés appropriés. Un échange de cadrage de plateforme ne constitue pas une autorisation de marché et ne remplace pas leurs conseils.