En quelques versions de navigateurs, le paysage de la couleur en CSS a radicalement changé. Là où RGB et HSL régnaient sans partage, les designers et intégrateurs web découvrent aujourd’hui un nouvel allié : le modèle OKLCH, pensé dès l’origine pour coller à notre perception visuelle. Combiné à la fonction color-mix(), il ouvre la voie à des palettes plus cohérentes, des thèmes plus accessibles et des systèmes de design véritablement systématiques.
Au deuxième trimestre 2025, OKLCH (normé dans CSS Color Module Level 4) et color-mix() (CSS Color 5) dépassent le stade de l’expérimentation. Leur support est désormais majoritaire dans les navigateurs, leur adoption progresse dans les outils de création de palettes et les pipelines front-end, et les ressources spécialisées n’hésitent plus à les présenter comme la nouvelle référence du design et du graphisme web.
De HSL/RGB à OKLCH : pourquoi changer de modèle de couleur ?
Les modèles historiques comme RGB et HSL ont été conçus avant tout pour les machines ou pour la manipulation mathématique de la couleur, pas pour la perception humaine. En HSL, par exemple, un jaune et un bleu réglés à 50 % de « lightness » ne paraissent absolument pas aussi lumineux l’un que l’autre, ce qui rend la création de rampes cohérentes extrêmement laborieuse. Le manque d’uniformité perceptuelle se traduit par des dégradés bancals, des contrastes imprévisibles et des thèmes clairs/sombres difficiles à maîtriser.
OKLCH, dérivé de l’espace Oklab créé en 2020, a été pensé pour corriger ces limites. Dans ce modèle, la composante L (lightness) est calibrée pour correspondre à notre impression de luminosité : deux couleurs avec la même valeur de L paraissent, à peu de choses près, aussi lumineuses. Un delta de L constant donne un changement de clarté visuellement régulier, ce qui est exactement ce dont les designers ont besoin pour construire des échelles de couleurs maîtrisées.
Concrètement, cela signifie que des suites de valeurs comme L = 0.98, 0.92, 0.86, 0.80… produisent des steps perçus comme équidistants. Pour les palettes d’UI (fonds, boutons, bordures, états hover et focus), cette régularité change tout : chaque niveau de la rampe remplit un rôle visuel précis, sans surprises. Les guides récents consacrés à OKLCH insistent sur ce point : la couleur redevient un outil prévisible et rationnel, au service du système de design.
OKLCH dans CSS : un standard désormais exploitable en production
OKLCH n’est plus une curiosité réservée aux CSS nerds. Inclus dans CSS Color Module Level 4, il est aujourd’hui supporté par tous les grands navigateurs : Chrome et Edge à partir de la version 111, Firefox dès la 113, et Safari depuis la 15.4. Les statistiques compilées dans un guide mis à jour en 2025 font état d’un support global supérieur à 92 % au deuxième trimestre 2025, ce qui en fait une option pleinement viable pour la production.
Dans la pratique, les experts recommandent une approche de progressive enhancement très simple : définir des couleurs de base en sRGB pour les vieux navigateurs, puis surcharger avec OKLCH à l’intérieur d’un @supports (color: oklch(50% 0 0)) { ... }. Ce schéma, largement documenté sur CSS‑Tricks et d’autres blogs front‑end, permet de bénéficier des avantages perceptuels d’OKLCH sans compromettre la compatibilité.
Les signaux d’écosystème confirment cette bascule : de nombreux color pickers, générateurs de palettes et testeurs de contraste utilisent désormais OKLCH comme format par défaut. Des plateformes comme oklch.org, oklch.net, Aura Mixer ou Palettt mettent en avant des slogans explicites tels que « Why OKLCH is the future of CSS colors » ou « Modern CSS Color Redefined ». Ce n’est plus seulement une option, c’est un nouveau standard de fait pour le design de couleur moderne.
Accessibilité : OKLCH comme levier naturel pour le contraste
Dans un contexte où les exigences d’accessibilité se généralisent (WCAG, APCA, audits automatiques), la capacité à contrôler précisément le contraste n’est plus négociable. Les modèles classiques compliquent cet exercice : le rapport entre les valeurs numériques (par exemple la « lightness » HSL) et la luminance perçue reste flou, ce qui rend l’ajustement au feeling très approximatif et source d’erreurs.
OKLCH simplifie ce travail, car sa composante L est quasi linéaire par rapport à la luminance perçue. Ajuster uniquement L revient à éclaircir ou assombrir une couleur de manière prévisible, sans changer sa teinte ni sa saturation globale. Des ressources spécialisées montrent ainsi comment viser plus facilement les seuils recommandés par APCA, par exemple Lc ≥ 60 pour un texte confortable, en manipulant simplement des deltas de L.
Un guide de 2025 détaille par exemple que pour atteindre un contraste APCA confortable, on peut viser un ΔL d’environ 40 entre texte et fond dans l’espace OKLCH. Ce genre de règle simple se prête idéalement à l’automatisation : plusieurs pickers OKLCH intègrent déjà des testeurs de contraste WCAG, et certains proposent même des suggestions automatiques de correction basées directement sur les valeurs OKLCH. À terme, on peut s’attendre à voir Lighthouse, les linters et les pipelines CI/CD intégrer ce type de vérification en natif.
Wide‑gamut, P3, HDR : aligner le design web sur les écrans modernes
Un autre facteur clé dans la montée en puissance d’OKLCH est l’arrivée massive des écrans wide‑gamut. Les écrans sRGB traditionnels ne couvrent qu’environ 35 % des couleurs visibles, alors que les écrans P3 , de plus en plus courants sur les laptops et moniteurs haut de gamme , ajoutent près de 30 % de gamut supplémentaire. Le contraste entre ce que les écrans peuvent afficher et ce que nos CSS expriment réellement devient difficile à ignorer.
CSS Color 4 permet déjà de cibler ces gamuts élargis via des notations comme color(display-p3 ...). Cependant, ces notations restent peu parlantes pour les designers, très proches des triplets numériques bruts de RGB. Les experts recommandent donc d’utiliser OKLCH comme interface plus lisible et « design‑friendly » pour exploiter pleinement P3, et même, à terme, Rec.2020.
Des exemples concrets de 2025 montrent comment définir des accents P3 ou HDR en OKLCH, par exemple --accent: oklch(70% 0.24 200);. Les navigateurs se chargent ensuite automatiquement de faire le clipping vers sRGB sur les écrans plus anciens. Pour les équipes design, cela simplifie considérablement la gestion multi‑écrans : un seul set de tokens OKLCH, et une adaptation automatique en fonction des capacités matérielles de l’utilisateur.
color-mix() : une nouvelle brique pour le design systémique
En parallèle de l’essor d’OKLCH, la fonction color-mix() s’impose progressivement comme un outil incontournable du CSS moderne. Normalisée dans CSS Color 5, elle permet de mélanger deux couleurs dans un espace donné (par exemple in oklch, in oklab, in srgb), via une syntaxe du type : color-mix(in oklch, var(--brand) 80%, white). L’idée est simple, mais ses implications pour les systèmes de design sont profondes.
Les tests récents montrent que color-mix() est désormais pris en charge par les versions modernes de Chrome, Edge, Safari et Firefox, à quelques exceptions près sur des navigateurs plus anciens ou des configurations particulières. Les outils de démonstration, comme color-mix.style, affichent d’ailleurs explicitement un message « this browser doesn’t support color-mix() » quand la fonction n’est pas disponible, ce qui permet de détecter facilement les environnements non compatibles.
Pour le design web, color-mix() ouvre la porte à la génération dynamique d’états et de variantes : on peut dériver automatiquement hover, focus, disabled, variantes de thèmes clair/sombre ou overlays à partir d’un petit set de couleurs de base. En spécifiant explicitement l’espace de mélange , typiquement in oklch , on évite les dérives de teinte et les gradients « boueux » associés aux mélanges en sRGB. Les transitions restent fluides, la cohérence de marque est préservée, et les designers gardent le contrôle.
OKLCH + color-mix() : un duo qui redéfinit les design systems
La vraie révolution ne vient pas seulement d’OKLCH ou de color-mix() pris isolément, mais de leur combinaison dans les systèmes de design. Un pattern récurrent, documenté dans des articles techniques et implémenté dans plusieurs outils, consiste à définir les tokens de base d’un système en OKLCH , par exemple --brand-l, --brand-c, --brand-h, ou directement --brand en oklch() , puis à utiliser color-mix(in oklch, ...) pour dériver toutes les variantes nécessaires.
Cette approche permet de générer automatiquement des rampes de couleur pour les surfaces, des overlays semi‑transparents, des backgrounds interactifs ou des états de composants, tout en restant dans un même espace perceptuel. La possibilité de préciser in oklch dans color-mix() est centrale : elle garantit des transitions régulières, sans artefacts, à l’opposé des mélanges en sRGB qui produisent souvent des centres ternes ou des shifts inattendus de teinte.
Dans cette logique, de plus en plus de systèmes de design modernes stockent leurs design tokens de couleur en OKLCH (ou Oklab) pour assurer la cohérence entre web, mobile et outils de design. Les sites spécialisés OKLCH mettent d’ailleurs en avant l’export vers Figma, Sketch, Adobe CC et autres, tandis que la communauté Figma réclame un support natif OKLCH (en bêta depuis 2024‑2025). La couleur n’est plus un attribut figé : c’est un système paramétrique, piloté par des variables OKLCH et orchestré par color-mix().
Un écosystème prêt pour l’industrialisation
Les signaux d’adoption ne se limitent pas aux navigateurs. Le guide OKLCH de 2025 souligne que les outils de build comme PostCSS Preset‑Env et divers polyfills Oklab/OKLCH intègrent désormais nativement la transformation automatique vers sRGB pour les navigateurs plus anciens. Cela permet aux équipes de travailler directement en OKLCH dans leurs sources, tout en livrant un CSS compatible pour l’ensemble des cibles grâce à la transpilation.
Du côté des services orientés designers, des plateformes comme Palettt , un générateur de palettes « AI‑powered » , positionnent explicitement OKLCH comme supérieur à RGB/HSL pour construire des palettes UI complexes et accessibles. Le message est clair : ces nouvelles technologies ne sont plus réservées aux développeurs CSS early adopters, elles s’adressent aux designers, aux équipes produit et aux studios de branding digital.
Enfin, l’écosystème d’outils OKLCH (oklch.org, oklch.net, Aura Mixer, etc.) mise sur l’interopérabilité : export vers les principaux outils de graphisme, intégration de testeurs de contraste, presets pour les systèmes de design, documentation pédagogiques, et même des générateurs de tokens prêts à brancher dans les codebases. Tout indique que la couleur en OKLCH, enrichie par color-mix(), est en train de devenir une brique standard de l’outillage front‑end.
En 2025, parler de couleur web sans évoquer OKLCH et color-mix() devient de plus en plus difficile. Le support navigateur a franchi le seuil critique, les outils se sont adaptés, les guides et articles de référence les présentent comme « prêts pour le prime time », et les workflows de design comme de développement commencent à les intégrer par défaut. Pour le graphisme web, c’est une opportunité rare : celle de repartir sur des bases mathématiquement saines, alignées sur la perception humaine et sur les capacités des écrans modernes.
Pour les designers et développeurs, la marche à suivre est claire : commencer par introduire OKLCH via du progressive enhancement, migrer progressivement les tokens de couleur des systèmes de design vers ce nouveau modèle, puis exploiter color-mix(in oklch, ...) pour générer toute la richesse d’états et de thèmes dont les interfaces ont besoin. Loin d’être une simple tendance, l’alliance OKLCH + color-mix() s’impose comme le socle d’une nouvelle génération de design et de graphisme web, plus cohérente, plus accessible et plus durable.
