Comment les distributions sont produites

La graine est le nombre de départ utilisé pour mélanger les cartes. Avec les mêmes paramètres, elle produit la même donne : tu peux le vérifier sur l’exemple ci-dessous. Le choix de cette graine par le serveur ne bénéficie pas encore d’une preuve indépendante.

Le mécanisme actuel

Au démarrage d’une partie ordinaire, le serveur tire une graine entière avec random_int(). Le moteur construit alors les 78 cartes et applique un mélange de Fisher–Yates alimenté par SHA-256. La version de cet algorithme porte le nom sha256-fisher-yates-v1.

À quatre joueurs, le moteur distribue 18 cartes à chacun et conserve 6 cartes au chien. La graine n’est pas envoyée dans l’état visible pendant la partie et chaque joueur ne reçoit que sa propre main.

Jeu
Tarot
Règles
1.0.0
Mélange
v1
Empreinte
SHA-256

Ce que l’empreinte relie

Une empreinte SHA-256 associe le jeu, les versions de règles et de distribution, le nombre de joueurs, le donneur, les mains par siège et le chien. Les cartes sont triées à l’intérieur de chaque main avant le calcul : l’empreinte authentifie donc l’allocation des cartes, pas leur ordre d’affichage.

Le serveur conserve aussi les paramètres de chaque donne et une chaîne d’empreintes des actions. Il peut ainsi rejouer une partie et détecter une divergence entre l’enregistrement et le moteur attendu.

Reproductible ne veut pas dire indépendant

La même graine, le même nombre de joueurs et la même version reproduisent la même allocation. Cette propriété permet de contrôler la cohérence d’un enregistrement après coup.

Mais le serveur choisit lui-même la graine et ne publie pas, avant la donne, un engagement cryptographique horodaté. Il n’existe pas non plus de contribution aléatoire fournie par les joueurs ou par une source externe. Le mécanisme actuel ne constitue donc pas une preuve indépendante que le serveur n’a pas pu choisir une graine après avoir calculé son résultat.

Enfin, la chaîne de rejeu et les paramètres des parties réelles restent des contrôles internes. Il n’existe aujourd’hui aucune interface publique permettant à un joueur de vérifier sa propre partie. Nous ne présentons donc pas ce système comme « certifié », « impossible à truquer » ou contrôlable sans faire confiance au serveur.

Un exemple déterministe public

Cet exemple utilise une graine fixée à l’avance. Il a été créé pour le test et ne provient d’aucune partie réelle.

Graine
4242
Donneur
Siège 2
Joueurs
4
Relances Petit sec
0
Répartition de l’exemple
ZoneNombre de cartes
Siège 0 18
Siège 1 18
Siège 2 18
Siège 3 18
Chien 6

Empreinte attendue

7e9bacab34bbcedf4b2794c393956cfa219189d449b4c3acf995f89bf654dda1

Le fichier contient les entrées, les quatre mains, le chien, les versions et cette empreinte. Il sert uniquement à contrôler la stabilité de l’exemple documenté.

Télécharger le JSON

Vérifier dans ce navigateur

Le bouton recharge uniquement l’exemple synthétique, reconstruit les 78 cartes depuis la graine 4242, puis compare localement les quatre mains, le chien et l’empreinte. Aucune donnée de joueur ou de partie réelle n’est utilisée.

Que confirme le résultat ?

Graine, mélange, distribution et empreinte ont des rôles différents. La graine est l’entrée numérique du calcul. Le mélange la transforme en un ordre de cartes selon une recette fixe, puis la distribution affecte ces cartes aux sièges et au chien. L’empreinte résume enfin cette allocation et son contexte : elle n’ajoute pas de hasard et ne choisit aucune carte.

Le succès du vérificateur porte sur cet exemple précis. Il confirme que les paramètres publiés régénèrent la même allocation des 78 cartes et la même empreinte. Remplacer une carte ou échanger deux mains entre leurs sièges fait échouer le contrôle. Ce résultat ne révèle cependant pas comment la graine a été choisie : l’exemple reste synthétique et n’est pas le reçu vérifiable d’une partie réelle. Un tel reçu joueur n’est pas disponible aujourd’hui.

Calcul théorique, simulation et données réelles ne sont pas interchangeables. Les probabilités partent d’un modèle uniforme brut, avant le rejet des Petits secs et les décisions de jeu. Le simulateur produit dans le navigateur des distributions pédagogiques, signale les Petits secs mais les conserve ; il ne consulte aucun historique de parties et ne reproduit donc pas la population des donnes acceptées par le moteur. Une fréquence simulée ou une courte série observée peut illustrer une fluctuation, pas certifier une distribution réelle.

Voir le calcul technique

Fisher–Yates parcourt les positions de la dernière carte à la deuxième. Pour chaque échange, SHA-256 reçoit la version de distribution, un octet nul, la graine, un autre octet nul et un compteur. Les quatre premiers octets du condensat donnent une valeur entière ; les valeurs qui créeraient un biais de modulo sont rejetées.

Après la distribution, les clés de l’objet et les cartes de chaque zone sont ordonnées de façon canonique, puis sérialisées en JSON. SHA-256 appliqué à ce JSON produit l’empreinte affichée. L’ordre des sièges reste significatif ; l’ordre des cartes à l’intérieur d’une main ne l’est pas.

Le donneur n’altère pas le mélange des cartes. Il fait partie du contexte authentifié et détermine qui parle en premier.

Petit sec et robots : deux précisions utiles

Une donne avec Petit sec est écartée

Si une main contient le Petit sans autre atout ni l’Excuse, le moteur ne joue pas cette distribution. Il recommence avec la graine suivante et passe le donneur au siège suivant. La population des donnes effectivement jouées exclut donc les Petits secs : elle n’est pas identique à l’ensemble brut de tous les mélanges possibles.

Les robots agissent après la distribution

Une table complétée par des robots utilise le même moteur de mélange et de distribution qu’une table humaine. Les décisions des robots commencent une fois les cartes attribuées ; elles ne changent ni les cartes de la donne déjà produite, ni son empreinte.

Ce qui manque pour une preuve indépendante

Une preuve plus forte demanderait un protocole de type commit–reveal avant toute distribution :

  1. le serveur publie l’empreinte d’un secret avant de calculer la donne ;
  2. les joueurs, ou une source publique extérieure, ajoutent une contribution imprévisible ;
  3. la graine finale combine ces contributions sans pouvoir être choisie après coup ;
  4. après la partie, un reçu public révèle les éléments nécessaires et un vérificateur indépendant recalcule la donne.

Ce protocole et ce vérificateur public ne sont pas déployés aujourd’hui. L’exemple ci-dessus démontre la reproductibilité du moteur actuel ; il ne remplace pas cette preuve indépendante.