« C’est aléatoire » est une affirmation, pas un fait. Deux choses doivent être vraies pour qu’une sélection soit équitable : la source des nombres ne doit pas être prévisible, et chaque option doit être également probable.
Les deux sont réalisables, les deux sont fréquemment ratées, et elles échouent indépendamment. Un outil peut avoir une excellente source aléatoire et une mise en correspondance biaisée, ou une mise en correspondance parfaitement uniforme alimentée par des nombres prévisibles.
D’où vient le hasard
Le hasard véritable vient de processus physiques qui ne sont pas déterminés par un état antérieur :
- La désintégration radioactive — le moment où un atome se désintègre ne peut pas être prédit
- Le bruit thermique — des fluctuations aléatoires de tension dans une résistance
- Le bruit atmosphérique — la friture de fond issue de l’activité des éclairs
- La mesure quantique — des résultats réellement indéterminés
Un ordinateur ne peut pas les observer directement. Ce qu’il fait, c’est échantillonner un générateur matériel — /dev/urandom et ses équivalents — qui est lui-même amorcé par des 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 produisant une séquence qui ne fait que sembler aléatoire.
next = (previous × multiplier + increment) mod modulusLa propriété critique n’est pas subtile. Si vous connaissez l’algorithme et la graine, vous pouvez calculer chaque valeur que la séquence produira jamais. Pas approximativement — exactement. C’est pourquoi Math.random(), utilisé par la plupart des sites web, ne convient à rien d’important : sa sortie est déterminée par l’état interne, et récupérer cet état à partir des sorties observées rend chaque résultat futur prévisible.
Le juste milieu qui tranche la question
Les plateformes modernes n’utilisent pas d’entropie matérielle brute à chaque appel. Elles utilisent un PRNG cryptographiquement sûr — déterministe, mais amorcé par de l’entropie matérielle et conçu de sorte que l’observation des sorties ne révèle pas l’état.
| TRNG matériel | CSPRNG | PRNG ordinaire | |
|---|---|---|---|
| Basé sur l’entropie physique | Oui | Oui | Non |
| Déterministe étant donné l’état | Non | Oui | Oui |
| La sortie révèle l’état | Non | Non | Oui |
| Adapté à un tirage au sort | Oui | Oui | Non |
Un CSPRNG est déterministe exactement au sens où chaque logiciel que vous utilisez est déterministe. Ce qui le rend acceptable, c’est que son état n’est pas récupérable à partir de ce qu’il a déjà émis.
Les navigateurs l’exposent via crypto.getRandomValues(). C’est la source qu’utilisent les tirages ici.
L’uniformité est un problème distinct
Avoir une bonne source ne suffit pas. La mise en correspondance entre un nombre aléatoire et un choix peut encore être biaisée, et c’est l’erreur que commettent la plupart des outils.
L’approche naïve — projeter un flottant aléatoire de 0 à 1 sur l’intervalle — biaise le bas de l’échelle. Avec 40 noms, certaines valeurs aléatoires tombent au-delà de la fin du dernier compartiment, et si elles sont ramenées plutôt que rejetées, le premier nom ressort légèrement plus souvent que le dernier.
Le biais est assez petit pour que personne ne le remarque, ce qui est précisément pourquoi il survit dans la plupart des implémentations.
L’approche correcte est l’échantillonnage par rejet : tirez, et si le résultat tombe dans le dernier compartiment incomplet, rejetez-le et retirez. La distribution devient exactement uniforme, donc chaque entrée a une chance de 1/N — y compris dans un tirage de 40 noms où une implémentation par flottant mis à l’échelle donne au premier nom une probabilité très légèrement supérieure.
La même technique apparaît dans le générateur d’identifiants courts ici, où le taux d’acceptation est de 252/256 et le biais résultant d’environ deux parties sur dix millions. Assez petit pour être négligeable, et assez petit pour qu’une implémentation négligente soit passée inaperçue — ce qui est exactement pourquoi il vaut la peine de le mesurer.
Trois défaillances humaines qui ne sont pas celles de l’outil
Le sophisme du joueur. Après cinq faces de suite, le revers semble dû. Chaque tirage est indépendant. La pièce n’a aucune mémoire d’avoir été injuste, et la probabilité correcte après cinq faces reste exactement 1/6 par face.
L’illusion de regroupement. Les séries dans des données aléatoires semblent structurées parce que vous les cherchez. Trois résultats identiques d’affilée arrivent bien plus souvent que l’intuition ne le suggère. Et des données réellement aléatoires paraissent irrégulières sur de courtes séries — une séquence qui semble parfaitement régulière a plus de chances d’être fabriquée que d’être authentique.
Le paradoxe des anniversaires. Dans un groupe de 23 personnes, deux partagent probablement un anniversaire. C’est de l’arithmétique, pas de la psychologie, mais cela illustre pourquoi les gens estiment si mal le hasard : les probabilités individuelles sont minuscules et elles se multiplient.
Le fil conducteur est qu’une seule observation ne prouve rien, dans un sens comme dans l’autre. Un tirage qui semblait bizarre est aussi peu informatif qu’un tirage qui semblait net.
Les deux défaillances qui comptent le plus en pratique
Après avoir retracé le mécanisme, il vaut la peine de nommer ce qui va réellement de travers quand une sélection est contestée — et aucune des deux ne concerne la source.
L’opérateur a annulé le résultat. Relancer, corriger à la main, sauter un nom absent en cours de tirage. Un générateur parfait avec un résultat modifié reste un résultat modifié, et c’est visible pour quiconque a regardé.
Le vivier n’était pas le vivier publié. Ajouter un nom, ou en exclure un discrètement, change la sélection quel que soit l’algorithme.
Les deux sont des défaillances de processus, et les deux sont ce qu’un tirage enregistré empêche. C’est pourquoi l’enregistrement avec la liste des participants dans le cadre vaut plus que n’importe quelle propriété technique : il exclut les deux.
Où ce niveau de rigueur est justifié
Pour choisir un déjeuner, rien de tout cela n’importe. N’importe quel générateur produit un déjeuner acceptable.
Cela devient déterminant quand il y a un enjeu, une réputation ou une dimension juridique :
- Tirages au sort et concours. Un résultat vérifiable est le but
- Attribution de tâches ou de fonctions. Les gens inspecteront le processus
- Randomisation scientifique et clinique. La norme du domaine est un hasard documenté, amorcé et reproductible
- Contextes réglementaires et d’audit. Un hasard documenté est souvent une exigence, pas une préférence
Les exigences dans tous ces cas sont les mêmes quatre, et elles sont courtes : le vivier est fixe et publié, les pondérations sont publiées s’il en existe, la source n’est pas prévisible, et le résultat est enregistré avec le vivier visible.
Comment le vérifier vous-même
Vous ne pouvez pas auditer un CSPRNG dans un onglet de navigateur, mais vous pouvez raisonner sur le mécanisme, et cela suffit.
Demandez quelle est la source. Si la réponse est « une fonction aléatoire », demandez s’il s’agit de celle qui est prévisible. crypto.getRandomValues() est une réponse précise et vérifiable.
Demandez comment l’uniformité est obtenue. Si la réponse implique de projeter un flottant sur un intervalle sans mentionner l’échantillonnage par rejet, la mise en correspondance est probablement biaisée. Légèrement, mais de façon mesurable.
Demandez ce que l’opérateur aurait pu changer. Si rien, le résultat est défendable. Si un nom pouvait être sauté ou le tirage relancé, il ne l’est pas — quelle que soit la source.
La page d’équité détaille l’implémentation sur ce site. Cela vaut la peine d’être lu une fois si vous choisissez un outil pour une décision qui sera remise en question.