Comment fonctionne un tirage de tarot aléatoire en ligne ?

Un tirage aléatoire choisit une carte. Il n’établit ni prédiction, ni détection d’énergie, ni accès à une information cachée. L’interprétation proposée ensuite est un texte symbolique rédigé à l’avance, pas un diagnostic ni un conseil médical, juridique ou financier.

Vous cliquez, une carte apparaît. Entre les deux, il se passe quatre ou cinq opérations très banales, toutes exécutées dans votre navigateur.

Le hasard technique sert à désigner un numéro dans un jeu de cartes, rien de plus : il ne transforme pas une lecture symbolique en constat sur l’avenir.

Cette distinction porte tout le reste de l’article.

Autant l’annoncer tout de suite : une partie du mécanisme que nous décrivons ici relève de ce que nous voulons vérifier, pas de ce qui est déjà audité.

La primitive aléatoire du navigateur est documentée publiquement.

Le code qui la traduit en index de carte, la règle de non-répétition, le comportement en cas d’échec, la politique de navigateurs supportés et l’absence d’IA à l’exécution restent des critères d’acceptation à contrôler au déploiement, d’après notre recherche technique interne revue le 8 août 2026.

Nous préférons vous montrer où sont les trous.

Du clic à la carte : le parcours en clair

Le trajet est court.

Votre appui déclenche une demande d’octets aléatoires au navigateur, ces octets deviennent un nombre, ce nombre devient une position dans le jeu, la position est retirée des candidats restants, la carte s’affiche avec un texte déjà écrit.

Aucune étape n’a besoin d’un serveur qui décide.

Voici le même trajet, annoté, tel qu’il est prévu dans le plan de site figé d’Arcane Clair (§5.1, état au 8 août 2026) :

1. Clic → « Tirer une carte »
2. Octets locaux → le navigateur remplit un tableau d’entiers avec des valeurs aléatoires (côté client)
3. Index candidat → les octets sont ramenés à un nombre dans l’intervalle du jeu
4. Acceptation / rejet → un candidat hors intervalle utile doit être rejeté et retiré à nouveau
   • [À vérifier avant publication : arithmétique exacte du rejet, vecteurs de test]
5. Mise à jour du vivier → la carte tirée sort des candidats
   • [À vérifier avant publication : règle de non-remise, chemin d’échec / repli]
6. Affichage → carte + interprétation rédigée à l’avance

Le texte de votre question, quand vous en saisissez un, ne figure nulle part dans cette chaîne. Il ne vient pas pondérer l’étape 3, il n’ouvre pas une variante de l’étape 6. C’est un contrat produit, et nous y revenons plus bas parce qu’il demande des tests réseau pour être affirmé sans réserve.

Une remarque au passage : la première fois que nous avons dessiné ce schéma en interne, nous avions placé la question entre le clic et les octets, par simple réflexe de mise en page. C’est exactement le genre de glissement visuel qui fait croire à un lien de cause à effet là où il n’y en a pas.

Ce que fournit Crypto.getRandomValues()

L’API Crypto.getRandomValues() du navigateur remplit un tableau typé d’entiers avec des valeurs aléatoires adaptées à un usage cryptographique. Elle travaille sur des tableaux d’entiers, pas sur des flottants. Chaque appel est plafonné à 65 536 octets ; au-delà, le navigateur lève une QuotaExceededError (MDN, Crypto.getRandomValues(), section des exceptions, consulté le 8 août 2026).

Pour un tirage de tarot, on est très loin de ce plafond : quelques octets suffisent.

La disponibilité est large. Le tableau de compatibilité de MDN résume une prise en charge dans les navigateurs depuis juillet 2015 (même page, consulté le 8 août 2026).

Ce résumé ne dit pas quels navigateurs Arcane Clair supporte réellement en production : notre politique de compatibilité et le comportement sur les configurations anciennes ou avec API restreinte font partie de ce que nous devons contrôler.

Le point que la plupart des présentations sautent : « de qualité cryptographique » est une propriété de sécurité. Cela signifie que la suite produite résiste à la prédiction par un attaquant qui observerait des sorties précédentes. Cela ne dit rien sur le code écrit au-dessus.

Un générateur excellent branché sur une conversion maladroite donne une sélection déséquilibrée, et l’API n’y peut rien.

Élément du mécanisme	Propriété vérifiée	Effet visible pour vous	Ce que cela ne prouve pas	Source / date
Crypto.getRandomValues()	Tableaux typés d’entiers, plafond de 65 536 octets par appel, prise en charge navigateur résumée depuis juillet 2015	Le hasard est produit sur votre appareil, sans requête de tirage	Que le code applicatif qui l’utilise soit sans biais	MDN, Crypto.getRandomValues(), consulté le 8 août 2026
Conversion en index borné	Non vérifiée de façon indépendante	Un numéro de carte dans l’intervalle du jeu	Que la répartition sur les positions soit uniforme	Recherche technique interne, revue le 8 août 2026
Mise à jour du vivier	Non vérifiée de façon indépendante	Pas de doublon annoncé dans un tirage multi-cartes	Que la règle tienne sur tous les chemins, y compris en cas d’échec	Recherche technique interne, revue le 8 août 2026
Affichage de la carte	Rendu local	La carte apparaît sans aller-retour serveur	Que rien d’autre ne soit transmis par ailleurs	Plan de site figé §5.1, état au 8 août 2026
Texte d’interprétation	Rédigé à l’avance, aucun modèle de langage à l’exécution	Un texte stable pour une même carte	Que ce texte ait une valeur prédictive	Plan de site figé §§1.2 et 5.1, état au 8 août 2026

Transformer un entier en index sans introduire de biais

Prenons un cas chiffré, simple à suivre. Un octet donne une valeur de 0 à 255, soit 256 possibilités. Vous voulez un numéro de 0 à 21, soit 22 positions.

256 divisé par 22 fait 11 avec un reste de 14. Si vous appliquez un simple modulo 22, les positions 0 à 13 reçoivent chacune 12 valeurs d’octet possibles, les positions 14 à 21 n’en reçoivent que 11. Les premières cartes du jeu sortent un peu plus souvent.

Le générateur était irréprochable ; le résultat ne l’est plus.

L’arrondi produit des travers du même ordre : multiplier un nombre aléatoire par la taille du jeu puis arrondir écrase ou étire les positions des extrémités. Le déséquilibre est faible, invisible sur vingt tirages, mesurable sur des dizaines de milliers.

La correction usuelle s’appelle le rejet. On définit une plage utilisable qui est un multiple exact de 22, ici 0 à 219 pour un octet, et on jette toute valeur au-delà en retirant des octets. Chaque position reçoit alors le même nombre de valeurs.

Le coût est réel : dans cet exemple, les valeurs 220 à 255 sont rejetées sur les 256 possibles, soit un nouveau tirage d’octet nécessaire dans environ 14 % des cas, à peu près un sur sept.

Ce que nous ne dirons pas : que notre convertisseur en production applique ce rejet correctement et qu’il est uniforme. La revue interne du 8 août 2026 classe la conversion en index borné parmi les points non vérifiés de façon indépendante.

Pour l’affirmer, il faut publier le code de sélection et le faire tourner contre des vecteurs de test, c’est-à-dire des séries d’octets d’entrée dont on connaît la position attendue en sortie, y compris aux limites de la plage de rejet.

Tant que cette étape n’a pas eu lieu, « uniforme » est une intention, pas un constat.

C’est aussi pour cette raison qu’un badge « aléatoire cryptographique » sur une page de tirage ne vous renseigne pas. Il désigne l’étape la mieux documentée, et laisse dans l’ombre celle qui peut effectivement pencher.

Tirer sans remettre la même carte

Sur un tirage à plusieurs cartes, l’invariant est simple : une carte sortie ne peut pas revenir dans le même tirage. Concrètement, le vivier de candidats rétrécit à chaque étape. Première carte choisie parmi 22 positions, deuxième parmi les 21 restantes, troisième parmi 20.

Si le vivier n’était pas mis à jour, vous pourriez voir la même carte deux fois dans un tirage de trois, ce qui n’est pas un hasard « plus pur » mais une erreur d’implémentation.

Le jeu visé chez Arcane Clair est celui des 22 arcanes majeurs (plan de site figé §5.1). Nous le présentons comme un périmètre prévu : le contenu exact des données en production et les éventuelles exclusions doivent être confirmés avant publication définitive de cette affirmation.

Reste la question la moins glamour et la plus utile : que fait la page quand quelque chose casse ? API indisponible, tableau vide, vivier épuisé. Un repli mal conçu peut retomber sur un choix non aléatoire, ou pire, sur une carte fixe, sans que rien ne l’indique à l’écran.

Le chemin d’échec et son comportement de repli figurent dans nos critères d’acceptation au déploiement, pas dans nos acquis.

Si vous voulez un test à votre portée : lancez plusieurs tirages multi-cartes d’affilée et notez tout doublon interne. Un seul doublon dans un même tirage suffit à signaler un problème.

La question ne choisit pas la carte

Aucune question n’est obligatoire pour tirer.

Le champ de saisie est optionnel, et selon le contrat produit d’Arcane Clair (plan de site figé §§1.2 et 5.1), le texte que vous y écrivez n’entre pas dans la sélection et aucun modèle de langage ne tourne au moment du tirage.

Les interprétations sont écrites à l’avance, carte par carte.

Ce contrat n’a de valeur que s’il est observable.

Trois vérifications le rendent contrôlable : lire le code de sélection pour constater qu’il ne prend aucun texte en entrée, ouvrir l’onglet réseau du navigateur pendant un tirage pour voir s’il part une requête, et vérifier qu’aucun outil de mesure ne reçoit le contenu brut de la question ni ne le glisse dans une URL publique.

Ces contrôles sont à faire sur l’environnement déployé ; nous les annonçons comme un engagement, pas comme un audit déjà rendu.

L’effet ressenti, lui, existe bel et bien : une carte tirée après avoir formulé une question précise paraît plus ajustée. C’est votre question qui donne un cadre de lecture, pas la carte qui a « répondu ». Pour savoir où atterrissent exactement votre question et votre résultat, il y a un article dédié : vérifier où restent votre question et votre résultat.

Tester une répartition sans valider une prédiction

Notre simulateur pédagogique effectue 1 000 sélections et affiche le nombre de sorties par arcane. Il est séparé du tirage réel : il ne modifie pas votre tirage, il ne lit aucune question.

Carte simulateur de répartition

1. Entrée : aucune saisie de votre part, aucun texte de question lu ni conservé.
2. Volume fixe : 1 000 sélections pédagogiques, indépendantes de tout tirage réel en cours.
3. Logique : l’implémentation pédagogique répartit ces 1 000 sélections sur les 22 arcanes majeurs du périmètre prévu.
4. Résultat affiché : un histogramme des sorties par carte, à lire comme une illustration de la variation, jamais comme une preuve d’équité.
5. Séparation : ce simulateur n’entre à aucun moment dans le parcours de sélection d’un vrai tirage et ne le modifie jamais.

Ce que vous verrez d’abord, c’est de l’irrégularité. Sur 1 000 sélections réparties sur 22 positions, la moyenne attendue tourne autour de 45 par carte, et des écarts de plusieurs unités entre la carte la plus sortie et la moins sortie sont normaux. Un histogramme parfaitement plat serait plus suspect qu’un histogramme bosselé.

Ce que la simulation peut suggérer, en revanche : une position systématiquement basse ou haute d’un run à l’autre, ou un déséquilibre net entre le début et la fin du jeu, oriente vers un problème de conversion du type décrit plus haut.

Ce sont des indices d’implémentation, pas un verdict.

Trois questions à se poser en regardant le graphique : l’écart change-t-il de carte quand vous relancez ? les extrémités du jeu sont-elles traitées comme le milieu ? le total correspond-il bien à 1 000 ?

Un run de 1 000 sélections n’est pas une preuve d’équité. C’est un réglage de démonstration maison, choisi pour être lisible à l’écran, et il ne dit rien du tout sur la valeur prédictive d’un tirage.

Idée reçue	Ce qui est établi
« Aléatoire cryptographique » veut dire application sans biais	La propriété concerne la primitive du navigateur. Le code de conversion en index peut introduire un biais que l’API ne corrige pas.
Un bon hasard rend le tirage prédictif	Le hasard technique désigne une carte. Il n’établit aucune capacité à décrire un événement futur.
La question saisie influence la carte tirée	Selon le contrat produit, la sélection n’accepte aucun texte en entrée. Le sentiment de pertinence vient du cadre de lecture que vous posez.
Une simulation qui paraît régulière prouve l’équité	Un échantillon fini illustre une répartition. Établir l’uniformité demande le code de sélection et des vecteurs de test.

Sources

• MDN Web Docs, Crypto.getRandomValues() : tableaux typés d’entiers, plafond de 65 536 octets par appel et QuotaExceededError, résumé de compatibilité navigateur (disponibilité large depuis juillet 2015). https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues, consulté le 8 août 2026.
• Arcane Clair, plan de site figé §5.1 et §1.2 : tirage local prévu, périmètre de 22 arcanes majeurs, question optionnelle, absence de traitement analytique du texte brut. État au 8 août 2026, vérification en production requise.
• Arcane Clair, recherche technique interne (G5) : lacunes documentées sur la conversion en index borné, le tirage sans remise et le chemin d’échec. Revue le 8 août 2026 ; ces points sont des critères d’acceptation, non des faits confirmés.

Questions fréquentes

Comment les cartes sont-elles choisies en ligne ? La chaîne prévue est locale : le navigateur produit des octets aléatoires, ces octets sont ramenés à une position dans le jeu, la position sort du vivier, la carte s’affiche avec un texte rédigé à l’avance.

Aucune requête de tirage ne part vers un serveur dans ce schéma. Les tests encore nécessaires portent sur l’arithmétique de conversion, ses vecteurs de test, la règle de non-remise et le comportement en cas d’échec.

Le tirage est-il vraiment aléatoire ? La primitive l’est de façon documentée : Crypto.getRandomValues() fournit des valeurs de qualité cryptographique dans des tableaux d’entiers (MDN, consulté le 8 août 2026). La couche au-dessus, elle, n’est pas vérifiée de manière indépendante : conversion en index borné et mise à jour du vivier restent à contrôler. Nous ne pouvons donc pas affirmer aujourd’hui que la sélection déployée est uniforme.

Pourquoi deux tirages donnent-ils des cartes différentes ? Parce que chaque tirage part d’un nouvel appel aléatoire, indépendant du précédent : il n’existe aucune mémoire d’un tirage à l’autre. Une différence de résultat n’indique donc ni erreur, ni contradiction. Avant d’enchaîner, il vaut la peine de savoir quand un nouveau tirage n’ajoute plus rien.

Ma question influence-t-elle la carte ? Non, d’après le contrat produit : la question est optionnelle et la sélection ne prend aucun texte en entrée. Cette affirmation demande une vérification du code et du trafic réseau sur l’environnement déployé, et le texte brut de la question doit rester hors des outils de mesure et des URL publiques. Ce que vous ressentez comme un ajustement vient du cadre de lecture, pas de la sélection.

Un bon hasard rend-il la prédiction plus fiable ? Non. Un générateur de qualité cryptographique garantit qu’une sortie est difficile à anticiper, ce qui est une propriété de sécurité et non une capacité à décrire l’avenir. Le tirage vous propose un support de réflexion symbolique ; sa qualité technique ne change rien à son statut.

Pour suivre le parcours décrit ici sur la page elle-même : Voir comment notre tirage choisit une carte. Et si le sujet vous intéresse au-delà du mécanisme, il y a de quoi comprendre le tarot responsable.

Contenu à visée informative et culturelle. Une sélection aléatoire ne permet ni prédiction, ni détection d’énergie, ni accès à une connaissance cachée, et une primitive aléatoire solide ne prouve pas à elle seule l’absence de biais dans la conversion en index. Le périmètre de 22 cartes, l’arithmétique de rejet, la règle de tirage sans remise, le chemin d’échec, la politique de navigateurs supportés et l’absence d’IA à l’exécution demandent une vérification au déploiement. Votre question et votre résultat doivent rester en dehors des outils de mesure et des URL publiques. Ce contenu ne remplace aucun avis médical, juridique, psychologique ou financier.