Prise en charge de oklch() par les navigateurs en 2026

oklch() fonctionne dans tous les grands moteurs de navigateur, et ce depuis 2023 : Chrome et Edge l’ont proposé dès la version 111 (mars 2023), Firefox dans la 113 (mai 2023), et Safari encore plus tôt, dans la 15.4 (mars 2022). Pour les navigateurs à mise à jour continue en 2026, la prise en charge est pratiquement universelle. La vraie question ne porte plus sur puis-je l’utiliser mais sur et la longue traîne ? — cette population décroissante de WebViews embarqués et de navigateurs d’entreprise figés qui ne se mettent jamais à jour.

C’est la page d’état de notre guide OKLCH : les faits de version, qui reste encore exclu, et les stratégies de repli classées de la moins coûteuse aux plus structurelles. Les faits de compatibilité vieillissent par nature, et c’est pourquoi cette page affiche sa date de mise à jour comme partie intégrante de la réponse.

Quelles versions de navigateurs ont ajouté oklch() ?

Safari a pris un an d’avance — WebKit a proposé tôt les fonctions CSS Color Level 4 — et les versions Chromium et Firefox sont arrivées à quelques semaines d’écart au printemps 2023, lorsque les fonctions de couleur étaient un axe prioritaire d’Interop. Pour connaître les chiffres actuels à tout moment, le tableau de compatibilité en direct sur Can I Use suit les versions et la part d’utilisation mondiale ; à ce stade, plusieurs années de versions de navigateurs à mise à jour automatique séparent les utilisateurs d’aujourd’hui des derniers moteurs qui en étaient dépourvus.

Qui ne peut toujours pas afficher oklch() ?

Pas les navigateurs de bureau ou mobiles qui se mettent à jour eux-mêmes — cette population a tourné la page il y a des années. Les lacunes restantes se concentrent là où un moteur se retrouve figé :

• Vieux WebViews embarqués — applications et appareils qui intègrent un moteur de navigateur et ont cessé de le mettre à jour : navigateurs de smart-TV vieillissants, coques de kiosque, navigateurs intégrés aux applications sur des appareils qui ne reçoivent plus de mises à jour de l’OS.
• Parcs d’entreprise bloqués sur d’anciens navigateurs — environnements verrouillés où le service informatique a figé la version du navigateur il y a des années et valide lentement les mises à niveau.

Que cela compte ou non est une question d’audience, pas de technologie. Un site grand public verra ces environnements comme une erreur d’arrondi ; un intranet destiné à un parc figé en 2021 les verra comme la totalité de son audience. Si vous voulez que la décision repose sur des données plutôt que sur des principes, vos propres statistiques la tranchent : la part des sessions sur des moteurs antérieurs à 2023 est un chiffre que vous pouvez lire dans un rapport de navigateurs, et pour la plupart des sites publics elle est passée sous le seuil de bruit. Pour la plupart des projets en 2026, la solution de repli est donc une assurance peu coûteuse plutôt qu’une exigence — à ajouter parce que cela ne coûte presque rien, non parce que le risque est grand.

Qu’est-ce qu’on gagne à écrire oklch(), au juste ?

La version courte de l’argument : la valeur de luminosité d’OKLCH suit la clarté réellement perçue d’une couleur, si bien que les palettes peuvent être générées — des paliers placés sur une courbe de luminosité paraissent régulièrement espacés, et le contraste entre les rôles devient une propriété de l’échelle plutôt qu’un test paire par paire. Le hex peut livrer ces résultats, mais il ne peut pas exprimer le raisonnement ; oklch() garde la logique lisible dans la feuille de style.

Le gain se voit le mieux dans une palette générée : ouvrez une échelle construite nativement en OKLCH dans Scale Composer — des paliers sur une courbe de luminosité, chacun portant la valeur oklch() qu’un navigateur moderne lit directement.

Quelle est la meilleure stratégie de repli ?

Classées de la moins coûteuse à la plus structurelle :

1. Déclarations ordonnées. La cascade fait tout le travail :

.button {
  background: #2563eb;                  /* lu par tous les navigateurs           */
  background: oklch(0.546 0.215 262.9); /* l'emporte là où c'est pris en charge  */
}

Un navigateur qui ne reconnaît pas oklch() écarte la seconde déclaration comme invalide et conserve le hex ; celui qui la reconnaît laisse la dernière déclaration l’emporter. Aucun outillage, aucun coût à l’exécution, fonctionne propriété par propriété. (Les deux valeurs ci-dessus sont le même bleu — le hex n’est que son écriture en sRGB.)

2. Blocs @supports. Lorsqu’une section entière du design dépend d’une couleur à gamut étendu — une couche d’accentuation P3, par exemple — une requête de fonctionnalité regroupe la logique en un seul endroit au lieu d’apparier chaque déclaration :

@supports (color: oklch(0.5 0.1 200)) {
  /* les accents à gamut étendu vivent ici */
}

Intéressant pour de grandes sections ; excessif pour des couleurs individuelles.

3. Réglez-le dans le pipeline de tokens. Écrire les paires à la main ne tient pas au-delà d’une poignée de couleurs. La réponse structurelle consiste à générer les deux écritures à partir de la même source de palette : les exports de Scale Composer — DTCG, CSS, Tailwind v4, Figma Variables — accompagnent toujours les valeurs OKLCH d’un hex, si bien qu’un consommateur ancien lit la même palette via son écriture sRGB tandis que les moteurs modernes obtiennent la couleur en pleine précision.

Comment le livrer aujourd’hui ?

Traitez OKLCH comme la source de vérité et laissez la couche d’export produire le filet de sécurité : les navigateurs modernes lisent oklch(), tout le reste lit le jumeau hex, et personne ne maintient deux palettes. Ouvrez la vue de repli hex de cette même échelle — chaque palier apparié à son hex sRGB, exactement la paire que veut le motif des déclarations ordonnées — et la longue traîne est couverte avant même de le demander.