Générateur de nombres aléatoires

Désigner un gagnant, tirer des lignes pour un contrôle ponctuel, lancer des dés, alimenter un jeu de données de test : c’est toujours la même demande, obtenir des nombres dans une plage, de manière équitable. Le générateur ci-dessus fait exactement cela, avec une option pour les tirages sans remise.

Comment ça marche

Définissez le min et le max (tous deux inclus, tous deux entiers) ainsi que le nombre de valeurs voulues, de 1 à 1 000. Choisissez ensuite entre deux comportements :

• Avec répétitions (par défaut) : chaque valeur est tirée indépendamment, donc les doublons sont possibles et, sur une petite plage, probables. C’est ce qu’il vous faut pour des dés, des simulations et tout ce qui modélise des événements indépendants.
• Valeurs uniques : les valeurs sont tirées sans remise, si bien qu’aucun nombre n’apparaît deux fois. L’outil construit la plage complète, la mélange avec l’algorithme de Fisher–Yates et prend les n premières. Si vous demandez plus de valeurs uniques que la plage n’en contient, il vous indique combien sont réellement possibles au lieu de boucler indéfiniment.

Les saisies sont validées plutôt que corrigées en silence : un min supérieur au max, une borne non entière ou une quantité hors limites produit un message. Régénérer tire une nouvelle série, et Tout copier place les valeurs dans le presse-papiers sous forme de liste séparée par des virgules.

Un aléa de qualité cryptographique

C’est plus important qu’il n’y paraît. Le générateur s’appuie sur crypto.getRandomValues() de la Web Crypto API, et non sur Math.random().

Math.random() est un générateur pseudo-aléatoire rapide, initialisé à partir d’une source non spécifiée. Il convient parfaitement pour ajouter du jitter à une animation ou mélanger un carrousel. Il ne convient pas dès que quelqu’un a intérêt à prédire le résultat, car son état interne peut être reconstitué à partir d’un nombre modeste de sorties observées ; cela a été démontré sur de vrais moteurs de navigateur. Un tirage au sort avec lot à la clé, un jeton, une tombola, un audit par échantillonnage que quelqu’un pourrait contester : tous exigent une source cryptographiquement sûre, et c’est précisément ce que fournit getRandomValues().

Le mélange compte aussi. Fisher–Yates est la seule façon non biaisée de permuter une liste en temps linéaire ; le one-liner bien connu array.sort(() => Math.random() - 0.5) produit une distribution dont le biais est mesurable, parce que les tris par comparaison supposent un comparateur cohérent, ce que celui-ci n’est pas.

Tout s’exécute localement. Ni votre plage, ni la quantité demandée, ni les résultats ne quittent le navigateur.

Quand ne pas l’utiliser

Mots de passe et clés. Un nombre aléatoire n’est pas un mot de passe. Utilisez le générateur de mots de passe, qui puise dans un espace de caractères bien plus vaste, ou le générateur d’UUID pour des identifiants qui doivent être uniques plutôt qu’imprévisibles. Ne construisez jamais un secret en concaténant des nombres tirés dans une plage que vous avez choisie.

Tests reproductibles. Un aléa cryptographique ne peut pas être initialisé avec une graine, et c’est tout l’intérêt ; mais c’est aussi ce qui en fait le mauvais outil pour des données de test que vous devez régénérer à l’identique. Utilisez un PRNG initialisé avec une graine dans le test lui-même, ou figez les valeurs dans une fixture. Un test dont l’entrée change à chaque exécution est un test qui échoue par intermittence, pour des raisons que personne ne peut reconstituer. Les fondamentaux du test expliquent où le déterminisme a sa place et où l’aléatoire des tests basés sur les propriétés apporte vraiment quelque chose.

Tout ce qui exige une piste d’audit. L’outil ne conserve aucune trace. Pour un tirage qui doit pouvoir être vérifié après coup, il vous faut une procédure documentée et une graine ou un engagement publiés, pas un onglet de navigateur.

Les nombres aléatoires en sécurité

Un aléa prévisible est une cause racine récurrente des incidents de sécurité : identifiants de session, jetons de réinitialisation de mot de passe, nonces CSRF et vecteurs d’initialisation ont tous été cassés à cause de générateurs qui n’avaient jamais été conçus pour résister à la prédiction. La règle est simple et absolue : tout ce qu’un attaquant gagnerait à deviner doit provenir d’un CSPRNG (crypto.getRandomValues() dans le navigateur, SecureRandom en Java, secrets en Python), et tout le reste peut utiliser le générateur rapide. Les fondamentaux de la sécurité de l’information traitent de l’entropie et de la place de ces primitives ; l’OWASP Top 10 couvre les catégories où un aléa faible se manifeste réellement.