Provably fair, définition, fonctionnement et limites
Le provably fair, généralement traduit par « équité vérifiable », permet de contrôler après une partie si son résultat correspond aux données et au calcul prévus par le jeu. Dans un protocole correctement conçu, un engagement communiqué avant la partie empêche de remplacer discrètement certaines données après coup. Cette preuve a toutefois un périmètre précis. Elle ne garantit ni un gain, ni le paiement d’un retrait, ni la fiabilité de tout le casino.
Une empreinte correcte peut accompagner un résultat incorrect. L’atelier de ce dossier le montre avec trois cas calculés localement, sans compte ni mise d’argent. Les mêmes données produisent le numéro 9, mais afficher 10 à sa place ne change pas l’empreinte du secret. Il faut donc contrôler les deux éléments, pas s’arrêter au premier.
Voir les deux contrôlesC’est quoi le provably fair au casino ?
Le principe consiste à rendre certains résultats contrôlables par le joueur plutôt qu’à lui demander de croire uniquement l’affichage de la plateforme. Celle-ci fournit les éléments nécessaires pour refaire un calcul et comparer sa sortie au résultat annoncé.
Il faut cependant regarder ce que le système rend vérifiable. La documentation de Stake, par exemple, sépare la génération des nombres de leur conversion en événements de jeu. Un nombre doit encore être transformé en carte, en case de roulette ou en autre résultat selon une règle précise.
C’est ce qui m’intéresse dans cette technologie. La discussion peut porter sur une opération que l’on reproduit, pas seulement sur une promesse. Mais le mot « équité » devient trompeur si on lui fait désigner davantage que ce que cette opération démontre.
Je parlerai donc ici de vérification du résultat, pas de certification du casino. Les implémentations diffèrent et la documentation d’un opérateur décrit son propre système, sans constituer un audit indépendant de celui-ci.
Comment fonctionne l’engagement avant la partie ?
Dans le modèle présenté ici, le serveur conserve une donnée secrète, mais en communique une empreinte avant le jeu. Une fois le secret révélé, le joueur peut vérifier qu’il correspond à cet engagement initial, puis refaire le calcul avec les autres données de la partie.
Quatre termes reviennent dans les documentations consultées.
Le server seed est la graine serveur. C’est une donnée utilisée dans le calcul, gardée secrète jusqu’à sa révélation.
Le hash est une empreinte numérique. On peut recalculer cette empreinte à partir du secret révélé. Une fonction cryptographique adaptée est conçue pour rendre extrêmement difficile la recherche d’une autre donnée produisant la même empreinte. Ce n’est pas un texte chiffré que l’on déverrouille.
Le client seed est la graine client. Il apporte une donnée côté joueur au calcul. Son rôle dépend notamment de la manière dont cette valeur est choisie et du moment où le serveur en prend connaissance.
Le nonce distingue les parties. Dans les implémentations étudiées, c’est un compteur qui augmente d’une partie à l’autre. Il n’a pas besoin d’être aléatoire et ne garantit pas que deux parties afficheront des résultats différents.
Avant la partie, l’empreinte de la graine serveur est communiquée et conservée. La contribution du joueur intervient selon l’ordre prévu par le protocole.
Graine serveur masquéePendant la partie, les données et les règles convenues déterminent le résultat. La graine serveur reste secrète pour le joueur.
Graine serveur masquéeAprès révélation, le joueur récupère la graine serveur et les paramètres de la partie.
Graine serveur révéléeAu contrôle, il compare l’empreinte avec l’engagement initial, puis le résultat recalculé avec celui qui avait été affiché.
Empreinte + résultat
Cette chronologie décrit un modèle d’engagement puis de révélation. Elle ne signifie pas que chaque jeu révèle son secret immédiatement après chaque tour.
Dans la procédure publiée par Shuffle, par exemple, la révélation de l’ancienne graine serveur intervient lors du renouvellement de la paire de graines. Vérifier après coup n’implique donc pas nécessairement vérifier dès la fin du tour.
L’ordre des opérations compte autant que les données. Si l’on récupère le secret et son empreinte uniquement après la partie, leur concordance ne démontre pas que cet engagement existait auparavant. La preuve doit aussi conserver ce qui était connu avant le résultat.
Comment vérifier un résultat provably fair ?
Une vérification complète doit suivre l’algorithme du jeu concerné. Dans le modèle retenu pour notre atelier, elle comporte deux contrôles qui répondent à deux questions distinctes.
Le secret révélé correspond-il à l’engagement initial ?
On calcule l’empreinte de la graine serveur révélée avec la fonction prévue, puis on la compare à l’empreinte conservée avant la partie.
Si les valeurs correspondent, ce contrôle établit leur concordance sous les hypothèses de sécurité de la fonction utilisée. Il ne suffit pas encore à confirmer le résultat affiché à l’écran.
Les données produisent-elles le résultat annoncé ?
On reprend la graine serveur, la graine client, le nonce et les éventuels paramètres supplémentaires. Il faut ensuite appliquer toute la chaîne de calcul, y compris la conversion en résultat du jeu.
Dans l’exemple ci-dessous, HMAC-SHA-256 combine une clé et un message. La graine serveur sert de clé. Les premières données produites sont ensuite converties en un numéro de roulette. HMAC et le simple hachage de la graine ne remplissent donc pas la même fonction.
Une démonstration sans compte ni mise
Cet exemple utilise des données fictives. Les calculs ont été exécutés localement en Python et recoupés avec Node.js. Ils reprennent la génération et la conversion Roulette décrites dans la documentation publique de Stake. L’engagement initial est simulé pour l’exercice, pas extrait d’une partie jouée sur ce site.
La graine serveur est la chaîne 0123456789abcdef répétée quatre fois. La graine client est lecasinotier-demo, le nonce vaut 7 et le curseur vaut 0. Les chaînes sont traitées comme du texte UTF-8, pas comme des octets décodés depuis l’hexadécimal.
L’empreinte SHA-256 retenue pour l’engagement est la suivante.
a8ae6e6ee929abea3afcfc5258c8ccd6f85273e0d4626d26c7279f3250f77c8e
Le message utilisé pour HMAC-SHA-256 est lecasinotier-demo:7:0. Les quatre premiers octets obtenus valent 66, 67, 158 et 213.
La conversion donne le nombre suivant, compris entre 0 inclus et 1 exclu.
u = 66 / 256 + 67 / 256² + 158 / 256³ + 213 / 256⁴
Soit environ 0,258844306. La règle Roulette documentée retient ensuite la partie entière de u × 37, ce qui donne 9. Ce nombre est un résultat de calcul, pas un montant gagné.
| Cas calculé | Résultat affiché dans l’exercice | Résultat recalculé | Empreinte conforme à l’engagement | Résultat concordant |
|---|---|---|---|---|
| Données de référence | 9 | 9 | Oui | Oui |
Dernier caractère de la graine serveur changé de f en e |
9 | 2 | Non | Non |
| Graine intacte, affichage remplacé par 10 | 10 | 9 | Oui | Non |
Le troisième cas est le plus instructif. La graine est restée intacte, son empreinte correspond toujours, mais le résultat affiché a été remplacé. Un contrôle limité au hash laisserait passer cette incohérence.
Cet atelier montre le fonctionnement de deux contrôles sur un exemple reproductible. Il ne prouve ni le déroulement d’une partie en production, ni la qualité de toute la génération aléatoire, ni la sécurité de l’opérateur. Les graines publiques et prévisibles choisies ici sont réservées à la démonstration.
Les fonctions HMAC utilisées ont aussi été confrontées à deux vecteurs de test de la RFC 4231. Cette vérification technique porte sur les calculs, pas sur un casino.
Ce que le provably fair ne prouve pas
Un résultat recalculable apporte une possibilité de contrôle. Il ne faut ni la minimiser, ni l’étendre à des éléments qu’elle n’examine pas.
Il ne démontre pas à lui seul la qualité de toute la procédure
Une empreinte peut engager le serveur sur un secret sans expliquer comment ce secret a été choisi. Pour éviter une sélection préalable avantageuse au serveur dans le modèle décrit, sa contribution doit être engagée avant qu’il connaisse une contribution du joueur qu’il ne puisse anticiper.
C’est une condition de conception, pas une qualité que l’on peut déduire d’une concordance isolée. La qualité des sources d’aléatoire, le respect de l’ordre des opérations et le traitement des parties interrompues doivent être examinés séparément.
Les standards britanniques distinguent justement plusieurs questions, notamment l’imprévisibilité des résultats, leur distribution et leur conversion conformément aux règles annoncées. Une vérification d’empreinte ne répond pas automatiquement à toutes ces exigences.
Il ne garantit pas le versement des fonds
Un résultat peut correspondre au calcul prévu sans que cela démontre la capacité de l’opérateur à payer. La vérification ne règle pas non plus un désaccord sur les conditions du compte.
Le traitement d’un retrait relève d’un autre ensemble de règles et de contrôles. Je ne considérerais jamais un résultat cryptographique concordant comme une preuve de solvabilité.
Il ne rend pas un jeu favorable au joueur
Prenons un jeu fictif avec une chance sur deux de recevoir 1,90 € au total, mise comprise, pour 1 € misé. L’autre issue ne verse rien. Son retour théorique vaut 0,50 × 1,90 €, soit 0,95 € par euro misé.
Le RTP est donc de 95 %. Même si le tirage peut être vérifié, le jeu conserve un avantage mathématique de 5 %. La preuve du tirage ne change pas le barème de paiement.
Il ne constitue pas une autorisation française
L’ANJ rappelle que les casinos en ligne ne sont pas autorisés en France. Une mention provably fair ne modifie pas ce cadre, pas davantage qu’une licence étrangère ne vaut autorisation française.
La question de la légalité d’un casino en ligne en France reste donc distincte de la technologie utilisée pour produire ses résultats.
Provably fair, RNG et RTP, trois notions différentes
Ces termes répondent à trois questions complémentaires. Les traiter comme trois labels concurrents empêche de voir ce qu’ils apportent chacun.
| Notion | Question à laquelle elle répond | Ce qu’elle ne suffit pas à établir |
|---|---|---|
| RNG | Comment les valeurs utilisées pour produire les résultats sont-elles générées ? | Qu’un joueur dispose des pièces pour refaire le calcul d’une partie |
| Provably fair | Peut-on contrôler la cohérence d’un résultat avec les engagements, données et règles du protocole ? | La fiabilité générale de l’opérateur |
| RTP | Quelle part des mises le modèle est-il conçu pour redistribuer sur le long terme ? | Le résultat de la prochaine partie |
La vérifiabilité d’un résultat ne remplace ni l’examen du générateur ni celui des règles de paiement.
Le provably fair ne remplace donc pas nécessairement un générateur de nombres aléatoires. Il peut s’appuyer sur une génération pseudoaléatoire dont le calcul devient reproductible après révélation des données.
À l’inverse, l’absence de cette fonction ne prouve pas qu’un jeu est truqué. En Grande-Bretagne, les jeux concernés doivent notamment passer par des tests réalisés par un laboratoire approuvé par la Gambling Commission. Cette forme de contrôle et la vérification d’une partie par un joueur n’ont pas le même périmètre.
Quels éléments chercher derrière une mention provably fair ?
Je commencerais par le jeu concerné, pas par le logo affiché sur la page d’accueil. Une documentation doit permettre d’identifier son périmètre, les données nécessaires et la procédure de vérification.
Pour examiner une partie déjà jouée, voici les éléments à réunir.
- Le nom du jeu, sa version et ses règles. La formule doit correspondre au résultat que vous contrôlez.
- L’engagement communiqué avant la partie. Conservez sa valeur complète avec le contexte qui permet de le rattacher à cette partie.
- Les données révélées et les paramètres utilisés. Graine serveur, graine client, nonce et paramètres supplémentaires lorsque le protocole en prévoit.
- Le calcul jusqu’au résultat final. Une fonction de hachage seule ne suffit pas si la conversion en événement de jeu reste inconnue.
- Une possibilité de contre-calcul. Un outil documenté que l’on peut examiner et exécuter hors du site permet de ne pas dépendre exclusivement de l’affichage de l’opérateur.
Si un élément manque, le constat approprié est « vérification incomplète ». Ce n’est ni une preuve automatique de fraude, ni une raison de considérer le résultat comme contrôlé.
Je trouve cette technologie intéressante lorsqu’elle transforme une affirmation en calcul reproductible. Sa limite est tout aussi nette. Une preuve vaut pour ce qu’elle examine, pas pour tout ce qui l’entoure.
Les questions qui restent
Peut-on prévoir le prochain résultat avec le provably fair ?
Dans un système correctement conçu, le joueur ne doit pas pouvoir retrouver le secret serveur à partir de son empreinte ni prévoir le résultat avec les seules informations publiques. Cette protection suppose notamment un secret suffisamment imprévisible. Une fois ce secret révélé, il ne doit plus servir à des parties dont le résultat doit rester inconnu du joueur.
Vérifier une ancienne partie n’est donc pas une méthode pour deviner la suivante.
La blockchain est-elle obligatoire ?
Non. Le hachage et HMAC peuvent fonctionner sans blockchain. Certaines conceptions peuvent utiliser des données publiques issues d’un registre distribué, mais notre démonstration n’en a pas besoin et s’exécute localement, sans cryptomonnaie.
Que faire si le résultat recalculé ne correspond pas ?
Vérifiez d’abord la version du jeu, la copie des graines, l’encodage, le nonce et les paramètres complémentaires. Dans notre atelier, traiter la graine serveur comme des octets hexadécimaux plutôt que comme du texte UTF-8 changerait le calcul.
Si l’écart persiste, conservez les données initiales, le résultat affiché, le calcul utilisé et vos échanges avec l’opérateur. Ce sont des éléments utiles pour documenter un litige, sans confondre une anomalie à examiner avec une fraude déjà démontrée.
Sources
Sources publiques consultées le 26 septembre 2026. Les documentations d’opérateurs décrivent leurs implémentations déclarées. Elles ne constituent pas une validation indépendante de leur activité.
NIST, Cryptographic hash function. Glossaire du Computer Security Resource Center. Propriétés des fonctions de hachage, résistance aux préimages et aux collisions. Source institutionnelle, date de publication de la fiche non indiquée.
Hugo Krawczyk, Mihir Bellare et Ran Canetti, RFC 2104. HMAC, Keyed-Hashing for Message Authentication, février 1997. Définition de HMAC, rôle de la clé et distinction avec un simple hachage. Référence technique primaire.
Magnus Nystrom, RFC 4231. Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512, décembre 2005. Cas de test 1 et 2, utilisés pour contrôler HMAC-SHA-256 dans les calculs de la démonstration.
Stake, documentation Provably Fair. Implementation, Conversions et Game Events. Passages utilisés, génération HMAC-SHA-256, conversion des quatre premiers octets et section Roulette Roll. Dates de publication non indiquées. Source primaire déclarative de l’opérateur, non assimilée à un audit.
Shuffle, documentation Provably Fair. Commitment Schemes et How to verify bets. Passages utilisés, engagement SHA-256, graines, compteur et révélation lors de la rotation. La seconde page affiche le 7 juillet 2026. Source primaire déclarative de l’opérateur.
Gambling Commission, RTS 7, Generation of random outcomes. Exigences techniques, dernière mise à jour affichée le 7 mai 2024. Sections 7A et 7B, imprévisibilité, distribution, conversion et respect des règles. Source réglementaire britannique, non transposable à une autorisation française.
Gambling Commission, Test Houses. Présentation des laboratoires approuvés, dernière mise à jour affichée le 16 avril 2026. Périmètre des tests et responsabilité des titulaires de licence. Source primaire du régulateur.
Autorité nationale des jeux, L’offre illégale. Page de référence de l’ANJ. Passage consacré au statut des casinos en ligne et à la portée d’une licence internationale en France. Date de publication non indiquée.