Pourquoi HSB l'emporte sur RGB dans les jeux de devinette de couleurs

Quand on a construit Toon Tone, la décision d'interface la plus importante a été : quel modèle de couleur les curseurs représentent-ils ? RGB est le choix par défaut évident — c'est ainsi que chaque écran rend les pixels — mais c'est aussi catastrophiquement mauvais pour un jeu qui demande à des humains de deviner des couleurs. Ce billet explique pourquoi on a choisi HSB à la place, et pourquoi tout jeu de devinette de couleurs devrait faire pareil.

Les deux modèles de couleur, en 30 secondes

RGB décrit une couleur par la quantité de lumière rouge, verte et bleue qu'elle émet. Chaque canal va de 0 à 255. (255, 0, 0) est un rouge pur. (255, 255, 0) est jaune parce que la lumière rouge et verte combinée donne du jaune sur un écran. Le modèle est correct pour le matériel : c'est littéralement ce que font les sous-pixels de ton moniteur.

HSB (aussi appelé HSV) décrit une couleur par teinte (0–360°, où sur la roue chromatique), saturation (0–100, à quel point elle est vive) et luminosité (0–100, à quel point elle est claire). (0, 100, 100) est le même rouge pur. (60, 100, 100) est jaune parce que tu as tourné le cadran de la teinte de 60 degrés. Le modèle est mauvais pour le matériel mais juste pour l'intuition humaine.

Trois raisons pour lesquelles RGB est mauvais pour un jeu de devinette de couleur

1. RGB ne colle pas à la manière dont les humains décrivent la couleur

Demande à quelqu'un de décrire une couleur et il dira « un rouge plus foncé » ou « un jaune plus orangé » ou « un bleu délavé ». Personne ne dit « une couleur avec 30 % de vert en plus ». Même les designers professionnels, qui apprennent RGB dès le premier jour, parlent de couleur en termes HSB. Le vocabulaire de la couleur est un vocabulaire de teinte, de vivacité et de luminosité — trois boutons, pas trois intensités lumineuses.

Si un curseur ne colle pas au modèle mental du joueur, le joueur doit faire du calcul mental pour s'en servir. Le calcul mental pendant une tâche de rappel, c'est la pire UX possible. Les joueurs de Toon Tone doivent injecter une couleur mémorisée dans l'interface aussi vite que possible ; HSB leur permet de le faire en une étape (tourner la teinte), RGB les oblige à le faire en trois.

2. Les curseurs RGB ne se comportent pas linéairement comme ils en ont l'air

Glisse le canal rouge de 100 à 200 et l'échantillon change à peine. Glisse le vert de 100 à 200 et l'échantillon saute dans une famille totalement différente. L'œil n'est pas également sensible aux trois primaires — le vert domine la luminosité perçue, le bleu contribue le moins. Les curseurs RGB se ressemblent à l'identique mais produisent des deltas visuels très différents par unité déplacée.

Pour un jeu de devinette, cette asymétrie est fatale. Un joueur dépasse le vert de 20 et l'échantillon devient méconnaissable ; le même dépassement sur le rouge est à peine perceptible. Le score devient injuste entre teintes.

3. RGB n'isole pas les dimensions qui comptent vraiment pour les joueurs

Les joueurs qui ratent un essai veulent savoir dans quelle dimension ils se sont trompés. Avec HSB, la décomposition du score est nette : « tu as trouvé la teinte, mais tu étais 20 points trop saturé ». Voilà un retour exploitable. Avec RGB, la décomposition c'est « tu étais 14 trop haut en rouge, 22 trop bas en vert, 8 trop haut en bleu » — sans aucun sens pour un humain.

La théorie des couleurs enseigne que teinte, saturation et luminosité sont des axes perceptuels indépendants. Les axes RGB ne sont pas perceptuels — ils sont matériels. Une bonne UX apprend à l'utilisateur quelque chose sur lui-même ; HSB apprend à l'utilisateur qu'il sous-estime la saturation. RGB n'apprend rien.

Pourquoi on n'est pas partis sur Lab ou OKLab

Une question honnête sur laquelle on a bataillé une semaine. Lab et OKLab sont perceptuellement uniformes — des distances numériques égales correspondent à des différences perçues égales, ce qui rendrait le score encore plus juste que HSB. Mais il y a deux problèmes pratiques :

• Lab n'est pas intuitif. Le canal L est la luminosité, mais a et b sont des axes « vert-rouge » et « bleu-jaune » qu'aucun non-spécialiste ne comprend. Les joueurs auraient besoin d'un tutoriel rien que pour savoir dans quelle direction tirer.
• Lab a des zones hors gamut. Certains triplets Lab ne correspondent à aucune couleur RGB affichable. Des curseurs qui produisent des couleurs invalides, c'est un cauchemar d'utilisabilité.

Alors on utilise HSB pour l'interface et une métrique de distance perceptuelle pour le score en dessous — le meilleur des deux mondes.

La fonction de score, brièvement

Toon Tone note chaque essai sur une échelle de 0 à 10 en calculant une distance pondérée entre l'essai et la cible dans l'espace HSB :

score = 10 - 0,4 * |Δteinte normalisée| - 0,3 * |Δsat| - 0,3 * |Δluminosité|

La teinte est un peu plus pondérée parce que se tromper de teinte, c'est le type d'erreur le plus révélateur — une erreur de luminosité tape encore dans la famille de couleur ; une erreur de teinte veut dire que tu t'es trompé de personnage. Les poids exacts sont ajustés pour que 7,0 donne la sensation « famille trouvée », 8,5 « assez proche pour qu'un designer laisse passer », et 9,5+ « œil d'expert ».

Ce que ça veut dire pour d'autres designers de jeux

Si tu construis un jeu de devinette de couleurs, la conclusion est simple :

• Utilise des curseurs HSB pour l'UX d'entrée.
• Note avec HSB ou une métrique perceptuelle — jamais avec une distance euclidienne RGB brute.
• Affiche la décomposition par H/S/B dans la carte de résultat pour que les joueurs apprennent dans quelle dimension ils sont faibles.
• Résiste à la tentation d'ajouter un quatrième curseur pour l'alpha ou un color picker sophistiqué — trois curseurs, c'est la bonne complexité pour une tâche de rappel.

Si tu es joueur et que tu te demandes pourquoi Toon Tone semble différent des autres jeux de couleur que tu as essayés — voilà l'essentiel de la raison.

Essaie