À propos de ce générateur de nombres aléatoires
Cet outil utilise crypto.getRandomValues(), la source aléatoire cryptographiquement sécurisée intégrée aux navigateurs modernes. Contrairement à Math.random(), elle est adaptée aux tirages au sort, jeux concours, tokens de sécurité — tout cas où la prédictibilité doit être exclue.
Cas d'usage courants
- Tirages au sort : définissez une plage, désactivez les doublons, générez les gagnants.
- Jeux de loto : 6 nombres entre 1 et 49, tri croissant — terminé.
- Échantillonnage : sélectionnez N éléments parmi M.
- Dés/jeux : 1–6 pour un dé classique, 1–20 pour un d20, etc.
Sans doublons
Lorsque les doublons sont désactivés, le nombre demandé ne peut excéder la plage — choisir 50 nombres uniques entre 1 et 10 est impossible. L'outil vous prévient le cas échéant.
Questions fréquentes
Quelle différence entre Math.random() et crypto.getRandomValues() ?
Math.random() utilise un PRNG interne dont l'état (64 bits dans V8) peut être reconstitué par un adversaire observant quelques sorties consécutives — ce qui permet de prédire toutes les valeurs suivantes. crypto.getRandomValues() délègue au CSPRNG du système d'exploitation (ChaCha20/AES-CTR alimenté par l'entropie matérielle du noyau), rendant toute prédiction computationnellement infaisable. Règle simple : Math.random() pour les jeux, crypto.getRandomValues() pour tout ce qui touche à la sécurité.
Peut-on utiliser ce générateur pour un tirage au sort officiel ?
Pour un tirage informel (désigner un gagnant parmi des collègues, choisir un ordre de passage), oui — notre générateur utilise crypto.getRandomValues(), ce qui garantit l'absence de biais. Pour un tirage à valeur légale en France (concours avec lots, opération promotionnelle soumise à la loi Hamon 2014), un règlement déposé chez un huissier et sa présence lors du tirage sont requis. L'outil peut servir d'aide, mais ne remplace pas la certification juridique.
Comment générer un nombre aléatoire dans une plage précise sans biais ?
Appliquer rand() % n sur un générateur classique introduit un biais si la plage du générateur n'est pas un multiple exact de n. La technique correcte est le rejection sampling : on tire un nombre, on l'accepte uniquement s'il tombe dans la zone non biaisée, sinon on recommence. Notre générateur implémente cette méthode via crypto.getRandomValues() avec rejet, produisant une distribution parfaitement uniforme quelle que soit la plage choisie.
Est-il possible de tester si un flux de nombres est vraiment aléatoire ?
Oui, par des batteries de tests statistiques : Diehard (Marsaglia), NIST SP 800-22 (référence pour la crypto), TestU01-BigCrush (le plus rigoureux). Ces tests vérifient l'uniformité, l'absence de corrélation sérielle et la distribution binaire. Attention : passer ces tests garantit la qualité statistique, pas la sécurité cryptographique. Un générateur peut satisfaire tous les tests et rester prédictible si son état interne est faible. La sécurité crypto nécessite un CSPRNG, pas seulement une bonne distribution.
Qu'est-ce que l'entropie d'un générateur et pourquoi est-ce important au démarrage ?
L'entropie mesure la quantité d'imprévisibilité disponible dans le pool du système (en bits). Au démarrage d'une machine (ou d'une VM fraîchement clonée), ce pool est peu rempli : il n'y a eu ni interruptions clavier, ni accès disque, ni bruits réseau. Si une clé cryptographique est générée trop tôt, la seed peut être faible et donc devinable. Linux 5.6+ bloque getrandom() jusqu'à avoir accumulé suffisamment d'entropie initiale. En production cloud, des outils comme VirtIO-RNG ou des démons d'entropie (haveged, jitterentropy) alimentent le pool au démarrage pour éviter ce problème.
