Vrai aléatoire vs pseudo-aléatoire : ce qui compte vraiment

Vous appuyez sur un bouton, un nombre apparaît, et on le suppose aléatoire. La question à se poser est ce qui l’a produit — car l’une des deux réponses est vérifiable et l’autre non.

D’où vient le vrai hasard

Le vrai hasard vient de processus physiques qui ne sont pas déterminés par un état antérieur :

• Désintégration radioactive — l’instant exact où un atome se désintègre ne peut pas être prédit
• Bruit thermique — fluctuations aléatoires de tension dans une résistance
• Bruit atmosphérique — le bruit de fond de l’activité orageuse
• Mesure quantique — des résultats véritablement indéterminés

Ce ne sont pas des approximations du hasard. Ils sont aléatoires, au sens où aucune connaissance du passé ne détermine le résultat.

Ce qu’un ordinateur fait à la place

Un ordinateur ne peut observer aucun de ces phénomènes directement, donc un générateur matériel les échantillonne. Les octets bruts proviennent de quelque chose comme /dev/urandom ou de la source équivalente du système d’exploitation, elle-même initialisée à partir de processus physiques. C’est un vrai générateur de nombres aléatoires.

Le cas bien plus courant est un générateur de nombres pseudo-aléatoires : un algorithme déterministe qui produit une suite qui semble simplement aléatoire.

next = (previous × multiplier + increment) mod modulus

La propriété critique n’est pas subtile. Si vous connaissez l’algorithme et la graine, vous pouvez calculer chaque valeur que la suite produira un jour. Pas approximativement — exactement.

C’est pourquoi Math.random(), que presque tous les sites web utilisent, ne convient pas pour tout ce qui compte. Sa sortie est déterminée par un état interne. Récupérez cet état à partir des sorties observées et chaque tirage futur devient prévisible.

L’exemple le plus souvent cité est que l’état complet d’un générateur congruentiel linéaire peut être reconstruit à partir de quelques sorties consécutives. Mersenne Twister, la valeur par défaut en Python, a besoin de 624 sorties pour être reconstruit — et 624 est un nombre que vous atteindrez en quelques secondes.

Xorshift et les générateurs rapides similaires ont la même propriété sous une autre forme : excellente qualité statistique, entièrement prévisibles si vous avez l’état.

Le juste milieu qui compte vraiment

C’est la partie que la plupart des explications sautent, et c’est celle qui décide de la réponse en pratique.

Les plateformes web modernes n’utilisent pas /dev/urandom brut à chaque appel. Elles utilisent un générateur pseudo-aléatoire cryptographiquement sûr — un algorithme déterministe, mais initialisé à partir d’entropie matérielle et conçu pour que l’observation des sorties ne permette pas de reconstruire l’état.

La distinction mérite d’être précisée, car les deux sont souvent confondus :

Un CSPRNG est déterministe au même sens que chaque logiciel que vous utilisez est déterministe. Ce qui le rend acceptable, c’est que l’état n’est pas récupérable à partir de ce qu’il a déjà émis.

Les navigateurs exposent exactement cela via crypto.getRandomValues(). C’est la source dans laquelle RandomSelect puise.

L’équité est une seconde question

L’uniformité est facile à rater même avec une bonne source. Un d6 est simple : six valeurs également probables. Un d7 ne l’est pas, et « choisir 1 nom parmi 40 » non plus.

L’approche naïve — projeter un nombre à virgule aléatoire de 0 à 1 sur l’intervalle — biaise le bas de l’échelle. Avec 40 noms, le premier sortirait légèrement plus souvent que le dernier, car certaines valeurs aléatoires tombent au-delà de la fin du dernier compartiment et sont écartées de façon inégale.

L’approche correcte est l’échantillonnage par rejet : tirez, et si le résultat tombe dans le dernier compartiment incomplet, écartez-le et retirez. La distribution devient exactement uniforme.

C’est facile à négliger car le biais est faible. En pratique, l’implémentation rejette les valeurs hors plage et retire, donc chaque entrée a exactement une chance de 1/N — y compris dans un tirage de 40 noms, où une implémentation par projection de flottant donnerait au premier nom une probabilité très légèrement supérieure.

La même technique apparaît dans le générateur d’ID courts, où le commentaire du code note le taux d’acceptation et le biais résultant d’environ deux parties sur dix millions. Assez faible pour être négligeable, et assez faible qu’une implémentation négligente serait passée inaperçue — ce qui est exactement l’intérêt de le mesurer.

Ce que cela signifie en pratique

Pour choisir où déjeuner, rien de tout cela ne compte. N’importe quel générateur produit un déjeuner acceptable.

Pour un tirage au sort, une attribution de poste ou tout ce qui porte une réputation, la question est de savoir si le résultat aurait pu être anticipé. Avec Math.random(), il pourrait, en principe. Avec crypto.getRandomValues(), il ne peut pas — ce qui est la différence entre « nous disons que c’était aléatoire » et « le mécanisme le rend tel ».

Il y a un point connexe et souvent confondu à propos de l’animation. Sur une roue qui tourne, le résultat est fixé avant que la roue ne commence à bouger ; l’animation se déroule vers lui. Certains lecteurs y voient une preuve de manipulation. C’est l’inverse : parce que le résultat est déjà déterminé et ne peut pas être influencé par le moment, il n’y a aucune entrée à exploiter. Le visuel est une mise en scène au-dessus d’une valeur déjà fixée.

Le tester vous-même

Un exercice rapide qui ne nécessite aucun code : lancez un dé vingt fois et notez les résultats. Cherchez ensuite les séries.

Vous en trouverez. Trois six d’affilée arrivent environ une fois tous les cinquante lancers. Ce n’est pas le signe que le dé est pipé — c’est à quoi ressemble un processus équitable quand on examine un petit échantillon.

Lancez ensuite cent fois et comptez chaque face. Les écarts se resserrent. Personne ne converge, car il n’y a jamais eu de déficit à combler : c’est ce que signifie l’indépendance quand on regarde d’assez près.

Où en lire plus

La page d’équité de ce site détaille l’implémentation réelle, y compris l’étape d’échantillonnage par rejet. Elle vaut la peine d’être lue une fois, surtout si vous choisissez un outil pour une décision qui sera contestée.

Le résumé pratique est court : un outil qui utilise crypto.getRandomValues() et rejette les tirages hors plage fait ce qu’il faut, et vous n’avez pas besoin de le croire sur parole — vous pouvez raisonner sur le mécanisme à la place.