Générateur de nombres aléatoires
Générez des nombres aléatoires équitables et sans biais dans n’importe quelle plage grâce au
générateur cryptographique de votre navigateur (crypto.getRandomValues()) — avec option sans
répétition, décimales et tri. Rien n’est téléversé.
Dernière révision : 2026-06-19.
Comment fonctionne le hasard
Chaque nombre est produit par crypto.getRandomValues(), la source aléatoire
cryptographiquement sûre du navigateur — la même entropie que celle que votre système
d’exploitation utilise pour les clés de chiffrement. Elle ne peut pas être initialisée par une graine et ne
peut être ni prédite ni reproduite.
Pour les nombres entiers, nous utilisons l’échantillonnage par rejet : nous tirons une valeur
de 32 bits et écartons tout tirage qui tombe dans la petite zone « restante » qui rendrait sinon certains
nombres légèrement plus probables que d’autres. Le résultat est une distribution uniforme
— chaque valeur de votre plage est exactement équiprobable, même lorsque la plage n’est pas une
puissance de deux. C’est précisément le biais qu’introduit discrètement une approche naïve du type
Math.random() × range.
Usages courants
| Usage | Réglages conseillés |
|---|---|
| Gagnant d’un concours ou d’une tombola | Plage de 1 au nombre de participants, quantité = nombre de gagnants, Uniques activé |
| Lancer de dé | De 1 à 6 (ou de 1 à 20 pour les jeux de rôle sur table) |
| Pile ou face | De 0 à 1 (0 = face, 1 = pile) |
| Tirage de type loterie | De 1 à 49, quantité = 6, Uniques activé |
| Échantillon aléatoire sans remise | De 1 à la taille de la population, quantité = taille de l’échantillon, Uniques activé |
| Décimal aléatoire (par ex. 0–1) | Minimum 0, maximum 1, décimales 2–4 |
Bon à savoir
- Équitable pour les tirages. Comme la distribution est uniforme et sans biais, chaque participation a la même chance — idéal pour les concours, les tirages au sort avec lots et l’échantillonnage.
- Uniques ou avec répétitions. Activez Uniques pour tirer des nombres distincts (échantillonnage sans remise) ; laissez l’option désactivée pour autoriser les répétitions (tirages indépendants).
- Limites de plage. Les valeurs sont bornées entre −1 000 000 000 et 1 000 000 000, avec au plus 1 000 nombres par lot.
- Confidentiel. La génération se fait à 100 % dans le navigateur — rien n’est envoyé à un serveur, et l’outil fonctionne hors ligne.
Vrai hasard ou pseudo-hasard
Les ordinateurs sont des machines déterministes, si bien que produire un hasard authentique est étonnamment difficile. Il existe deux approches fondamentalement différentes. Un générateur de nombres réellement aléatoires (TRNG) mesure un phénomène physique imprévisible — bruit électronique thermique ou bruit de grenaille, bruit radio atmosphérique, instant d’une désintégration radioactive, ou effets quantiques comme des photons frappant une lame séparatrice — et le convertit en bits. Le hasard vient de la nature, la sortie ne peut donc être ni reproduite ni prédite, mais sa collecte est relativement lente.
Un générateur de nombres pseudo-aléatoires (PRNG) est une formule mathématique qui part d’une valeur initiale appelée graine et produit une longue suite qui semble aléatoire. Il est rapide et pratique, mais entièrement déterministe : quiconque connaît la graine et l’algorithme peut reproduire exactement la même suite, et celle-ci finit par se répéter après une longueur appelée sa période. La reproductibilité est parfois un atout — elle permet aux scientifiques de relancer une simulation à l’identique — mais c’est une faiblesse fatale dès que l’imprévisibilité compte.
Les systèmes modernes utilisent une approche hybride : une source d’entropie matérielle initialise un
algorithme pseudo-aléatoire rapide et de haute qualité. C’est exactement ce que fait votre navigateur. L’appel
crypto.getRandomValues() qui fait fonctionner cette page puise dans le réservoir d’entropie de
votre système d’exploitation, alimenté en continu par le bruit matériel, de sorte que les nombres produits ont
l’imprévisibilité d’un TRNG et la vitesse d’un PRNG.
Les algorithmes derrière les nombres pseudo-aléatoires
Tous les PRNG ne se valent pas. Des décennies de recherche ont produit des familles d’algorithmes de qualité et de vitesse très différentes :
| Algorithme | Année / auteur | Remarques |
|---|---|---|
| Congruentiel linéaire (LCG) | Depuis les années 1950 | Très rapide, état minuscule, mais statistiquement faible — les valeurs consécutives tombent sur des hyperplans détectables. Encore courant dans les fonctions rand() de base. |
| Mersenne Twister | 1997, Matsumoto et Nishimura | Période énorme de 219937−1 et bonne qualité statistique ; générateur par défaut de Python, de R et de nombreux langages — mais pas cryptographiquement sûr. |
| Xorshift | 2003, George Marsaglia | Générateurs à décalage de bits extrêmement rapides ; ils réussissent des tests exigeants lorsqu’on les combine à une étape non linéaire. |
| PCG | 2014, Melissa O'Neill | Une famille congruentielle permutée qui associe un cœur LCG rapide à un brouillage de la sortie — compacte, rapide et statistiquement excellente. |
Une idée reçue veut que le Mersenne Twister, en raison de sa période astronomique et de ses bons résultats aux tests, soit sûr pour des usages de sécurité. Ce n’est pas le cas : en observant seulement 624 de ses sorties, un attaquant peut retrouver son état interne et prédire toutes les valeurs futures. La qualité statistique et la sécurité cryptographique sont des exigences différentes, et c’est autour de cette distinction que cet outil est conçu.
Qu’est-ce qui rend un générateur « cryptographiquement sûr » ?
Un PRNG cryptographiquement sûr (CSPRNG) doit satisfaire une exigence bien plus stricte que
la simple réussite de tests statistiques. Deux propriétés le définissent. Le test du bit
suivant : connaissant tous les bits produits jusque-là, aucun algorithme efficace ne peut prédire le
bit suivant avec une probabilité meilleure que celle d’un pile ou face. Et la résistance à la
compromission de l’état : même si son état interne venait à être exposé, un attaquant ne pourrait
toujours pas reconstituer les nombres aléatoires déjà produits. Un générateur non cryptographique comme le
Math.random() de JavaScript échoue sur les deux points — il est conçu pour la vitesse dans
les jeux et les animations, son état peut être retrouvé à partir de sa sortie, et la spécification ne garantit
même aucune qualité particulière d’aléa.
L’Institut national des normes et de la technologie des États-Unis (NIST) publie la norme des conceptions
approuvées, NIST SP 800-90A, qui spécifie des générateurs déterministes de bits aléatoires
éprouvés. Le domaine porte aussi une célèbre mise en garde : un algorithme d’une version antérieure de cette
norme, Dual_EC_DRBG, s’est ensuite révélé contenir une porte dérobée probable et a été retiré
— un rappel que la conception d’un générateur, et pas seulement sa sortie, détermine si l’on peut lui
faire confiance. La source crypto.getRandomValues() utilisée ici est l’interface du navigateur
vers le CSPRNG éprouvé du système d’exploitation.
Pourquoi une plage équitable est plus difficile qu’il n’y paraît
Supposons que vous vouliez un nombre équitable de 1 à 6 et que vous disposiez d’un générateur qui renvoie un
octet aléatoire (0–255). L’approche paresseuse consiste à prendre le reste : byte % 6 + 1.
Mais 256 n’est pas un multiple de 6. Les valeurs 0–251 se répartissent exactement en six groupes de 42,
mais les quatre valeurs restantes 252–255 tombent dans les groupes de 1, 2, 3 et 4 — ces quatre
résultats sortent donc un peu plus souvent que 5 et 6. C’est le biais de modulo ; s’il est
minime pour un dé, il augmente avec la plage et peut compter pour des clés cryptographiques, de grandes
loteries ou un échantillonnage scientifique.
La solution est l’échantillonnage par rejet : on définit le plus grand multiple de la plage qui tient dans la sortie du générateur (ici, 252), puis on écarte simplement — rejet et nouveau tirage — toute valeur supérieure ou égale à ce seuil. Chaque valeur conservée correspond à exactement un résultat, donc chaque résultat est rigoureusement équiprobable. Ce générateur applique cette technique à un tirage complet de 32 bits pour chaque entier, ce qui explique que ses plages soient mathématiquement uniformes et pas seulement « à peu près » uniformes.
Pourquoi les humains sont mauvais pour produire du hasard
Il est tentant de simplement « choisir un nombre dans sa tête », mais les humains sont de très mauvais générateurs aléatoires, et c’est précisément pour cela qu’un outil comme celui-ci existe. Quand on leur demande de choisir un nombre de 1 à 10, bien plus de gens choisissent 7 que n’importe quel autre — il paraît le plus « aléatoire » parce qu’il est impair, premier et éloigné des bornes rondes. Les gens évitent aussi inconsciemment de répéter deux fois de suite la même valeur et ont tendance à alterner choix hauts et bas, car une vraie série de répétitions semble non aléatoire, alors que le vrai hasard produit sans cesse de telles séries. Ce même instinct alimente l’erreur du parieur : la croyance erronée qu’après plusieurs « face », un « pile » est « dû ». Chaque tirage indépendant est sans mémoire ; un générateur équitable produira donc volontiers des grappes et des séries qu’une personne corrigeant au jugé n’écrirait jamais. Si vous avez besoin d’un résultat impartial et défendable — pour un concours, une décision d’échantillonnage ou un départage — un tirage machine uniforme élimine entièrement ce biais humain caché.
Comment teste-t-on le hasard ?
On ne peut pas prouver qu’une suite finie est aléatoire, mais on peut soumettre un générateur à des batteries de tests statistiques qui cherchent à détecter des motifs qu’une source réellement aléatoire ne présenterait pas. La suite classique est celle des tests Diehard de George Marsaglia (étendue plus tard sous le nom de Dieharder) ; la batterie moderne la plus exigeante est TestU01 de Pierre L'Ecuyer, dont l’ensemble « BigCrush » exécute plus d’une centaine de tests. Le NIST publie sa propre suite de tests statistiques, destinée spécifiquement aux générateurs utilisés en cryptographie. Sous nombre de ces tests se trouve le modeste test du khi-deux (χ²), qui vérifie si les fréquences observées (combien de fois chaque valeur apparaît) correspondent à la distribution uniforme attendue par le seul hasard. Réussir ces tests est nécessaire mais, comme indiqué plus haut, insuffisant pour un usage cryptographique.
Les nombres aléatoires dans le monde réel
La génération de nombres aléatoires sous-tend discrètement un éventail considérable d’activités :
- Cryptographie. Clés de chiffrement, jetons de session, nonces, sels et signatures numériques dépendent tous de nombres qu’un attaquant ne peut pas deviner. Un générateur faible est ici catastrophique — des clés prévisibles peuvent être cassées purement et simplement.
- Simulation de Monte-Carlo. Les modèles de physique, de finance, de météorologie et d’ingénierie effectuent des millions d’essais aléatoires pour estimer des résultats trop complexes à calculer directement, comme la valorisation d’options ou le comportement de particules.
- Jeux et génération procédurale. Lancers de dés, mélanges de cartes, butins aléatoires et mondes entièrement générés reposent sur le hasard pour rester renouvelés et équitables.
- Échantillonnage statistique. Tirer un échantillon aléatoire et représentatif d’une population — pour des sondages, des audits ou des tests A/B — suppose que chaque membre ait la même chance d’être sélectionné.
- Loteries et tirages au sort. L’équité et la confiance du public exigent un tirage sans biais et infalsifiable, exactement la propriété que garantit l’échantillonnage par rejet.
Questions fréquentes
- Ce générateur de nombres aléatoires est-il vraiment aléatoire ?
- Il utilise l’API crypto.getRandomValues() de votre navigateur, qui puise dans le générateur de nombres pseudo-aléatoires cryptographiquement sûr (CSPRNG) du système d’exploitation — la même source d’entropie que celle des gestionnaires de mots de passe et de TLS. Contrairement à Math.random(), il est imprévisible et ne peut pas être initialisé avec une graine : les résultats ne peuvent donc être ni reproduits ni devinés. Pour les entiers, nous appliquons en plus un échantillonnage par rejet afin que chaque valeur de votre plage soit exactement équiprobable (aucun biais de modulo).
- Puis-je l’utiliser pour un concours ou une tombola en toute équité ?
- Oui. Attribuez un numéro à chaque participant (de 1 à N), réglez la plage sur 1–N, activez « Uniques (sans répétition) » si vous tirez plusieurs gagnants, puis lancez la génération. Comme chaque nombre de la plage a la même probabilité et que le tirage est sans biais, la sélection est équitable. Pour une transparence totale, vous pouvez enregistrer l’écran pendant le tirage ou générer devant les participants — rien n’est envoyé à un serveur, le résultat est donc produit en direct sur votre appareil.
- À quoi sert l’option « Uniques (sans répétition) » ?
- Désactivée, chaque nombre est tiré indépendamment, donc une même valeur peut apparaître plusieurs fois (comme lorsqu’on lance un dé à répétition). Activée, tous les nombres du résultat sont différents — pratique pour un tirage de loterie, pour désigner des gagnants distincts ou pour un échantillonnage sans remise. Si vous demandez plus de nombres uniques que la plage ne peut en contenir (par exemple 10 nombres uniques entre 1 et 5), la quantité est automatiquement ramenée à la taille de la plage.
- En quoi est-ce différent de Math.random() ?
- Math.random() est un générateur rapide et non cryptographique, prévu pour des usages comme les animations ou le mélange de listes sans enjeu ; sa sortie n’est pas garantie imprévisible et peut être biaisée lorsqu’on la ramène à une plage avec l’opérateur modulo. crypto.getRandomValues() est cryptographiquement sûr, et notre étape d’échantillonnage par rejet supprime entièrement le biais de modulo : même pour une plage qui n’est pas une puissance de deux, chaque valeur reste exactement équiprobable.
- Peut-il générer des nombres décimaux ?
- Oui. Réglez « Décimales » entre 1 et 4 et le générateur renvoie des valeurs décimales uniformément réparties sur votre plage (par exemple un nombre aléatoire entre 0 et 1 avec 4 décimales). Avec 0 décimale, il renvoie des nombres entiers en passant par la méthode sans biais réservée aux entiers.
- Des données quittent-elles mon navigateur ?
- Non. Chaque nombre est généré localement à l’aide du processeur (CPU) de votre appareil et de l’entropie du système d’exploitation (OS). Rien n’est téléversé, transmis ni journalisé, et la page continue de fonctionner hors ligne une fois chargée.