Mis à jour 10 juillet 2026

OKLCH vs HSL : pourquoi HSL ment sur la luminosité

La différence qui compte entre OKLCH et HSL, c’est le sens du mot « luminosité ». Le L de HSL est une fraction géométrique des valeurs RGB d’une couleur ; le L d’OKLCH mesure la luminosité réellement perçue de la couleur. Deux couleurs HSL qui partagent « 50 % de luminosité » peuvent différer radicalement en luminosité perçue — deux couleurs OKLCH de même L paraissent très proches d’une luminosité égale.

Les deux modèles décrivent la couleur avec trois valeurs et un angle de teinte, ce qui les fait paraître interchangeables. Cet article démonte pourquoi ils ne le sont pas ; le reste de la série sur les modèles de couleur se trouve dans notre guide OKLCH.

Comment deux couleurs peuvent-elles partager une même valeur de luminosité sans se ressembler du tout ?

Comparez hsl(60, 100%, 50%) et hsl(240, 100%, 50%) dans n’importe quel sélecteur de couleur. La première est un jaune — si clair qu’il survit à peine sur un fond blanc. La seconde est un bleu profond, assez sombre pour porter du texte blanc. Toutes deux revendiquent 50 % de luminosité.

Mesurez en OKLCH les six teintes d’angle de HSL à « 100 %, 50 % », là où le L suit la perception, et l’écart devient visible en chiffres :

Entrée HSLHexLuminosité perçue (L OKLCH)
hsl(60, 100%, 50%) — jaune#ffff000,97
hsl(180, 100%, 50%) — cyan#00ffff0,91
hsl(120, 100%, 50%) — vert#00ff000,87
hsl(300, 100%, 50%) — magenta#ff00ff0,70
hsl(0, 100%, 50%) — rouge#ff00000,63
hsl(240, 100%, 50%) — bleu#0000ff0,45

Six couleurs, une seule valeur de luminosité HSL — et un écart de luminosité mesuré de 0,45 à 0,97, soit plus de la moitié de l’axe entier. Le jaune à « 50 % » se situe près du blanc ; le bleu à « 50 % » se situe plus près du noir.

Que mesure réellement HSL ?

HSL date de la fin des années 1970, conçu comme une manière plus conviviale de piloter les valeurs RGB — géométriquement, un cylindre enroulé autour du cube RGB, comme l’expose en détail l’article Wikipédia sur HSL et HSV. Sa luminosité relève d’une pure arithmétique de canaux : prenez la plus haute et la plus basse des trois valeurs RGB, puis faites-en la moyenne. #ffff00 (255, 255, 0) et #0000ff (0, 0, 255) donnent tous deux une moyenne de 50 %, donc HSL les rapporte comme également clairs.

Rien dans ce calcul ne fait intervenir un œil — et les yeux pondèrent le spectre de façon très inégale. La vision humaine est bien plus sensible à la lumière dans la région vert-jaune qu’à l’extrémité bleue ; on appelle cet effet l’efficacité lumineuse. Un écran qui pousse son canal bleu à pleine puissance ne délivre qu’une fraction de la luminosité perçue que la même puissance délivre via le vert. Le jaune (rouge plus vert à fond) tombe près du pic de la courbe de sensibilité ; le bleu tombe près de son bord. C’est le cœur intuitif du problème : HSL compte l’énergie RGB, mais la luminosité est une expérience produite par un système visuel qui a de fortes préférences quant à la longueur d’onde. Un modèle qui ne consulte jamais l’observateur rapportera de travers ce que l’observateur voit.

OKLCH est calibré dans le sens inverse : il part de mesures de la perception et remonte vers les maths, de sorte qu’un L égal est conçu pour signifier « paraît également clair » d’une teinte à l’autre.

Pourquoi cela casse-t-il les rampes et le contraste ?

Un chiffre de luminosité trompeur coûte peu quand vous ajustez une seule couleur isolément. Les dégâts apparaissent dans tout flux de travail qui compare la luminosité d’une teinte à l’autre :

  • Les rampes se tassent et deviennent boueuses. Générez une palette de 10 paliers en faisant descendre la luminosité HSL de 95 % à 20 %, et chaque teinte se déforme différemment : les jaunes restent délavés sur toute la moitié haute, les bleus plongent tôt dans le sombre, les tons moyens dérivent vers le gris. Les palettes générées ainsi demandaient généralement une passe de correction manuelle par teinte.
  • Le contraste ne se lit pas dans les chiffres. Le contraste de texte accessible dépend de l’écart de luminosité perçue entre le texte et le fond. Quand le L ne suit pas la perception, « ces deux valeurs sont séparées de 40 points » ne prédit rien — une association qui passe dans une teinte échoue dans une autre, et vous en êtes réduit à tester les paires une par une.

Les deux échecs ont une même racine : le flux de travail suppose que le chiffre de luminosité est comparable d’une teinte à l’autre, et en HSL il ne l’est pas.

À quoi ressemble un axe de luminosité honnête ?

Une démonstration nette utilise les deux teintes que HSL traite le plus différemment — le jaune et le bleu — placées sur la même courbe de luminosité OKLCH. Ouvrez les deux rampes côte à côte dans Scale Composer : le troisième palier de la rampe jaune et le troisième palier de la rampe bleue partagent leur luminosité mesurée, visiblement, et le motif tient tout du long des deux échelles. Le chroma diffère — le jaune et le bleu peuvent porter des quantités d’intensité colorée différentes à une luminosité donnée — mais la luminosité descend au même rythme.

Rampes OKLCH jaune et bleue côte à côte sur la même courbe de luminosité, chaque paire de paliers s'accordant en luminosité perçue du presque-blanc au presque-noir

Produire cela avec HSL exigerait une table de correction construite à la main pour chaque teinte, parce que son axe de luminosité signifie quelque chose de différent dans chaque teinte. En OKLCH, c’est simplement ce qui se passe quand deux rampes partagent une même courbe de luminosité.

Quand HSL reste-t-il acceptable ?

HSL est trompeur précisément là où la cohérence entre teintes compte — ce qui laisse une vraie place là où elle ne compte pas. Pour un ajustement ponctuel et rapide — assombrir un seul état de survol, atténuer un badge, se promener dans les teintes d’un sélecteur — HSL est pratique et sans danger, parce que rien en aval ne dépend de la comparaison de ses chiffres entre teintes. Les ennuis commencent quand on bâtit des systèmes dessus : palettes générées, contraste calculé, thèmes sombres dérivés des thèmes clairs. Là, la distorsion de luminosité s’accumule à chaque étape.

Une règle qui marche : HSL pour retoucher des couleurs individuelles, OKLCH pour tout ce qui les génère ou les compare.

Comment ancrer la différence ?

Les chiffres établissent la preuve ; voir bouger les axes en fait une intuition. Prenez une rampe dans Scale Composer et faites glisser le décalage de teinte du bleu vers le jaune, puis en sens inverse. En HSL, un balayage de teinte équivalent ferait osciller la luminosité perçue vers le haut et vers le bas. Ici, la courbe de luminosité reste immobile : chaque palier conserve sa luminosité tandis que la teinte seule tourne à travers la palette. Après un balayage complet avec la luminosité fixée en place, « même L signifie même luminosité » cesse d’être une affirmation de spécification et devient quelque chose sur quoi vous pouvez compter en concevant.

Continuer la lecture