Roue de Décision

La roue de décision choisit aléatoirement une option dans une liste et transforme un petit choix en processus visible et partagé. Elle sert en classe, activités d’équipe, choix de repas, ordre de présentation, petits tirages, brainstorming et situations où plusieurs options sont acceptables. Son intérêt est de réduire la fatigue décisionnelle et de rendre la sélection transparente. Elle ne remplace pas le jugement lorsque les options ont des risques, coûts, règles d’équité ou responsabilités différents. Pour des tirages sérieux, liste des participants, pondération, exclusions et traçabilité doivent être définies avant de lancer la roue afin que le résultat reste explicable. Elle convient surtout aux décisions à faible enjeu.

La roue est un dessin Canvas 2D combiné à un tirage aléatoire déterministe. Chaque segment est rendu avec ctx.beginPath(); ctx.moveTo(cx, cy); ctx.arc(cx, cy, r, startAngle, endAngle); ctx.fill() où N options égales occupent chacune un arc de 2π/N radians — quinze segments donnent donc 24° d'arc chacun, ce qui explique aussi que la saisie soit limitée à 15 pour garder les libellés lisibles. Le segment gagnant est déterminé AVANT l'animation : un entier non signé 32 bits est tiré avec crypto.getRandomValues(new Uint32Array(1))[0], réduit modulo N, et cet entier constitue la réponse. L'animation calcule ensuite une rotation cible de fullSpins × 2π + (2π − winnerIndex × sliceAngle − sliceAngle/2) pour que le pointeur en haut du canvas se retrouve aligné sur le centre du segment choisi, puis effectue une interpolation dans requestAnimationFrame avec une courbe d'assouplissement telle que easeOutCubic, f(t) = 1 − (1−t)³, ou easeOutBack pour le léger dépassement qui imite une roue physique ralentissant. crypto.getRandomValues est le CSPRNG de Web Crypto (spécifié dans l'API Web Crypto), alimenté par le pool d'entropie du système, donc contrairement à Math.random le tirage ne peut pas être prédit en lisant l'état de la page. Les variantes pondérées construisent un tableau de probabilités cumulées de longueur N et effectuent une recherche binaire du tirage aléatoire en O(log N). Les sorties sont entièrement visuelles et éphémères — rien n'est journalisé, donc toute piste d'audit (horodatage, liste d'options, capture d'écran) doit être saisie en externe avant le rafraîchissement de la page.

• Rendu Canvas : chaque segment est ctx.arc(cx, cy, r, startAngle, endAngle) avec sliceAngle = 2π / N — 15 options donnent 24° par segment, ce qui est le plafond pratique de lisibilité.
• Le tirage du gagnant utilise crypto.getRandomValues(new Uint32Array(1))[0] % N — CSPRNG Web Crypto, alimenté par l'entropie du système, adapté aux tirages uniques équitables mais PAS aux loteries reproductibles (pas de piste d'audit).
• L'animation s'exécute dans requestAnimationFrame au taux de rafraîchissement de l'écran (typiquement 60 Hz) avec easeOutCubic f(t) = 1 − (1−t)³ ou easeOutBack pour un léger dépassement — la courbe est cosmétique, le gagnant est déjà choisi.
• La rotation finale est targetRotation = fullSpins × 2π + (2π − winnerIndex × sliceAngle − sliceAngle/2) pour que le pointeur supérieur atterrisse sur le centre du segment, pas sur son bord.
• Le mode options pondérées construit un tableau de sommes préfixées des poids et utilise la recherche binaire pour mapper un nombre uniforme aléatoire à un segment en O(log N) — équivalent à un échantillonnage par inverse-CDF.
• Le biais de modulo est négligeable lorsque N ≤ 15 et que le tirage couvre 2³² valeurs (biais ≈ N / (2 × 2³²) ≈ 1,7×10⁻⁹), donc aucune boucle de rejet-échantillonnage n'est nécessaire.
• Chaque tour est i.i.d. — des tours consécutifs peuvent répéter la même option et c'est un comportement uniforme correct, pas un bug ; la déduplication entre tours nécessite un enregistrement externe.