Génération d'entiers aléatoires en JavaScript : plage précise en 2025

Nombres aléatoires en JavaScript : du chaos à l'ordre

Imaginez : vous écrivez un jeu où vous devez choisir aléatoirement un coffre au trésor de 1 à 100. Ou peut-être créez-vous un test A/B qui sélectionne une variante aléatoire pour l'utilisateur. Cela semble simple, non ? Mais le diable se cache dans les détails. La question de la génération d'entiers aléatoires en JavaScript dans une plage spécifique est l'une des plus populaires sur Stack Overflow, et pour cause. Même les développeurs expérimentés trébuchent parfois sur les pièges de Math.random().

Dans cet article, nous analyserons non seulement les méthodes classiques, mais aussi les meilleures pratiques de 2025 : comment rendre le code non seulement fonctionnel, mais aussi sûr, prévisible (dans le bon sens) et performant. C'est parti !

Le classique du genre : Math.random() et ses pièges

Commençons par les bases. La fonction intégrée Math.random() renvoie un nombre pseudo-aléatoire à virgule flottante dans la plage [0, 1). Point clé : 0 est inclus, mais 1 ne l'est pas. C'est une distribution « injuste » si vous voulez obtenir des entiers.

Voici la méthode la plus courante (et la plus incorrecte) que l'on trouve souvent dans les anciens manuels :

// MAUVAIS exemple : biais de probabilité\nfunction getRandomBad(min, max) {\n  return Math.floor(Math.random() * (max - min + 1)) + min;\n}\n

À première vue, tout semble correct. Mais creusons plus profondément. Math.floor() arrondit à l'entier inférieur. Si Math.random() génère un nombre très proche de 1 (mais pas égal), la multiplication par (max - min + 1) donnera une valeur inférieure à max + 1, et Math.floor() la tronquera. Cependant, en raison de la précision limitée des nombres à virgule flottante (IEEE 754), certaines valeurs apparaissent moins souvent que d'autres. Pour une plage 0-1, cela est imperceptible, mais pour de grandes plages (par exemple, de 1 à 1 000 000), le biais devient statistiquement significatif.

Conclusion : cette formule fonctionne pour les petites plages, mais n'est pas « cryptographiquement pure » et peut entraîner un déséquilibre dans la distribution.

La formule correcte selon MDN

Mozilla Developer Network (MDN) recommande une approche plus correcte qui minimise les erreurs d'arrondi :

// Bonne méthode universelle\nfunction getRandomIntInclusive(min, max) {\n  const minCeiled = Math.ceil(min);\n  const maxFloored = Math.floor(max);\n  return Math.floor(Math.random() * (maxFloored - minCeiled + 1) + minCeiled);\n}\n

La différence est que nous convertissons explicitement les limites en entiers avec Math.ceil() et Math.floor(). Cela garantit que min et max seront traités correctement, même si vous passez accidentellement un nombre décimal. Utilisez cette méthode comme standard de base en 2025.

Alternatives : quand Math.random() ne suffit pas

Le classique Math.random() est un générateur pseudo-aléatoire (PRNG). Il est déterministe : si vous connaissez la graine initiale (seed), vous pouvez prédire toute la séquence. Pour la plupart des applications web (animations, contenu aléatoire), cela suffit. Mais il existe des scénarios où une véritable aléatoire est nécessaire :

\n
• Sécurité : génération de jetons, mots de passe, jetons CSRF.
\n
• Cryptographie : chiffrement de données côté client.
\n
• Jeux d'argent : distribution équitable des gains.
\n

Dans ces cas, crypto.getRandomValues() vient à la rescousse — un générateur cryptographiquement sûr (CSPRNG). Il utilise des sources d'entropie système et est beaucoup moins prévisible.

Génération d'entiers avec crypto.getRandomValues()

Voici à quoi ressemble une implémentation moderne en 2025 :

// Génération sécurisée d'un entier aléatoire dans la plage [min, max]\nfunction getSecureRandomInt(min, max) {\n  const range = max - min + 1;\n  // Valeur maximale multiple de range (pour éviter le biais