Générer des nombres aléatoires — sûr et reproductible

Qu’est-ce qu’un bon générateur de nombres aléatoires fait différemment en 2026 ?

Trois choses distinguent l’aléa sérieux de l’aléa bâclé. Premièrement la source d’entropie : un générateur moderne tire depuis le pool du système d’exploitation, pas depuis un pseudo-algorithme à état interne court. Deuxièmement les mathématiques de distribution : résultats uniformément distribués sur la plage souhaitée, sans que les bords soient légèrement surreprésentés. Troisièmement l’architecture : tout reste local, parce que les nombres aléatoires pour des applications sensibles comme jetons, sels et tirages ne doivent pas passer par des mains étrangères.

Ce générateur fait les trois. La source par défaut est la Web Crypto API, qui demande au système d’exploitation des octets cryptographiquement sûrs. Le calcul de plage utilise le rejection sampling, une technique standard issue de l’implémentation aléatoire conforme NIST. Et tout l’outil tourne pure-client — min, max, quantité et résultat ne quittent jamais le navigateur.

Pourquoi Math.random() ne convient-il pas aux jetons et tirages ?

Math.random() n’est pas cryptographique. Le générateur a dans le moteur V8 — qui anime Chrome, Edge et Node.js — un bug d’état connu depuis 2015 décrit par l’équipe d’ingénierie de Betable. Nick Forte et Mike Malone y montraient qu’après environ 24 000 appels la séquence commence à entrer en collision — propriété mortelle pour un casino en ligne équitable. Même la correction ultérieure vers xorshift128+ ne rend pas le générateur sûr : son état reste petit et observable, et plusieurs équipes de recherche ont montré qu’après quelques sorties les valeurs suivantes peuvent être reconstruites.

Pour un tirage dans un groupe d’enseignants, Math.random() est plus que suffisant. Pour un jeu de quiz aussi. Mais pour un jeton de session, un sel de mot de passe, une clé d’API ou un quickpick de loterie, la source doit être cryptographique. Ce générateur rend la différence visible : en haut dans la barre de mode il est marqué « Sûr · Web Crypto », la deuxième option « Reproductible · PRNG seed » est explicitement marquée comme non sûre.

Que vaut le mode seed pour les tests et tutoriels ?

Un seed est une valeur de départ qui rend un pseudo-générateur totalement déterministe. Si on saisit le même seed, la même séquence sort. Le générateur utilise en mode seed l’algorithme Mulberry32 — une variante PRNG 32 bits compacte (Tommy Ettinger, 2017), domaine public, qui a fait ses preuves depuis des années dans les frameworks de test.

Le mode seed est utile pour les tests unitaires (« ma fonction de loterie doit, avec seed 42, livrer les numéros 4, 12, 18, 28, 35, 41 »), pour les tutoriels où tous les participants doivent voir le même résultat, et pour les démos d’analyse de données qui doivent être reproductibles. Sur le marché DACH, cette fonction est rare dans les générateurs aléatoires en ligne — beaucoup d’outils n’offrent que des tirages Math.random() sans possibilité de contrôle.

Important : le mode seed est visiblement marqué « pas pour la sécurité ». Quiconque veut générer des jetons dans le code navigateur doit impérativement rester sur crypto.getRandomValues.

Comment fonctionne exactement le preset Loto 6 parmi 49 ?

Un clic sur le preset met min à 1, max à 49, quantité à 6 et doublons à « off ». Le générateur tire alors six numéros différents dans la plage, les trie croissant et les sort en liste séparée par virgules. Le preset Eurojackpot tire en plus deux numéros étoiles dans la plage 1–12. Les deux tirages utilisent le même pool Web Crypto pour la pleine correction statistique.

Ce que ce générateur ne fait délibérément PAS : statistiques sur « numéros les plus fréquents depuis 1955 », liens vers opérateurs, évaluations de quickpick ou promesses de gains. La probabilité d’un six bons est selon la statistique officielle de la loterie de 1 sur 13 983 816 — quelle que soit la combinaison choisie et quelles que soient les statistiques regardées avant. L’outil est un générateur, pas un lead vers le jeu.

Quels formats de sortie sont pertinents pour quel cas d’usage ?

La liste est le bon choix quand vous copiez le résultat dans un chat, un e-mail ou un tableau. CSV est optimal pour Excel, Google Sheets, R, Python et tous les pipelines d’analyse de données qui importent des valeurs séparées par virgule. JSON est le choix pour développeurs web et tests d’API — le tableau passe directement dans les payloads fetch() ou les appels JSON.parse.

Pour les tirages Eurojackpot, l’outil livre une sortie structurée avec primary et extra : liste avec saut de ligne, CSV en tableau à deux lignes, JSON en objet avec numbers et extra. Cela rend le résultat lisible machine sans avoir à le retoucher.

Que se passe-t-il pour des plages de nombres particulièrement grandes ?

La plage est limitée à Number.MAX_SAFE_INTEGER — soit 9 007 199 254 740 992 valeurs possibles entre min et max. Pour chaque tirage une valeur 32 bits est tirée depuis la Web Crypto API ; pour les plages au-dessus de 2³², la valeur se répartit sur deux draws. La performance reste linéaire dans le nombre de valeurs souhaitées : 1000 valeurs dans la plage 1–10⁶ prennent moins de 10 ms sur un laptop 2026 typique.

La limite supérieure du nombre de tirages est de 1000 valeurs par clic. C’est assez pour des applications de type simulation (test Monte-Carlo, démos de distribution statistique) et en même temps assez petit pour que l’UI reste fluide même sur mobiles faibles. Qui en a besoin de plus clique plusieurs fois ou copie le résultat dans sa propre boucle.

Y a-t-il des applications pour lesquelles cet outil n’est pas pensé ?

Oui, trois. Premièrement : pas de distributions aléatoires hors de l’uniforme. Gaussienne, Poisson, bêta et autres distributions sont intéressantes pour des étudiants en statistique mais trop spécifiques — et un bon programme de statistique comme R ou numpy.random de Python le fait de toute façon mieux. Deuxièmement : pas de « vrais » nombres aléatoires depuis le bruit atmosphérique ou des sources quantiques. Pour cela l’outil devrait contacter un serveur, ce qui rompt la doctrine pure-client. Web Crypto est suffisant pour tout cas d’usage au-delà des exigences hautement scientifiques. Troisièmement : pas d’endpoint d’API ni de widget embed. Qui veut générer des nombres aléatoires dans son propre outil appelle directement crypto.getRandomValues dans son code — l’outil ici est l’UI pour utilisateurs finaux.

Qu’en est-il de la confidentialité et du RGPD ?

Min, max, quantité et résultat restent dans le navigateur. Pas de persistance localStorage, pas de cookies, pas d’analytics, pas d’aller-retour serveur. Le téléchargement CSV/JSON est créé via un objet Blob local et un déclencheur <a download> invisible — le fichier atterrit directement sur le disque dur de l’utilisateur. Qui ferme l’onglet a perdu le résultat — c’est volontaire.

Du point de vue RGPD, l’outil ne traite pas de données personnelles au sens de l’art. 4 — des numéros de loto tirés ou valeurs de dé n’en sont pas. Même si l’utilisateur saisit des ID d’employés comme plage, le traitement reste local et donc hors du champ d’application RGPD pour le traitement de données serveur. Le badge mode-sûr en haut de l’UI rend cela visible extérieurement.