Votre refonte de marque est déployée à 9h. Le marketing met à jour trois codes hex dans Figma. À midi, vos boutons deviennent invisibles en mode sombre, vos ratios de contraste échouent WCAG 2.2, et vos propriétés CSS personnalisées se transforment en un enchevêtrement de 47 variables que personne n'ose toucher. J'ai reconstruit cet échec au moins une douzaine de fois — en assemblant des calculs HSL, en codant en dur les ajustements de luminosité, en priant pour que le prochain plugin de token de conception me sauve. Chaque système s'est fissuré au moment où le mode sombre est arrivé, ou un audit d'accessibilité a surgi, ou un client a demandé « juste une couleur de marque de plus ». La solution n'est pas un autre hook React ou une mixin Sass. C'est une architecture de couleur qui résiste au contact avec votre processus de conception réel — une qui traite l'uniformité perceptuelle, la dénomination sémantique et la commutation de mode comme des contraintes dès la première validation, et non comme des correctifs post-lancement.

2026 est différent. Non pas parce que le problème est devenu plus facile, mais parce que les outils ont enfin rattrapé la complexité. Entre les espaces de couleur OKLCH atterrissant dans tous les navigateurs majeurs, l'architecture de couleur dynamique de Material Design 3 arrivant à maturité, et les spécifications de tokens de conception atteignant le statut de recommandation candidate du W3C, nous avons enfin une pile cohérente. Cet article explique comment construire un système de couleurs qui gère le mode clair, le mode sombre, le contraste élevé, la conformité d'accessibilité et les thèmes — sans vous donner envie de basculer une table.

Table des matières

Pourquoi la plupart des systèmes de couleurs s'effondrent

La plupart des systèmes de couleurs échouent parce qu'ils commencent au mauvais endroit. Les designers choisissent une couleur de marque primaire, génèrent une palette dans Figma, et remettent les valeurs hex aux développeurs. Ces valeurs hex sont dispersées dans les fichiers de composants. Puis quelqu'un demande le mode sombre et tout s'effondre.

Le problème n'est pas les couleurs elles-mêmes — c'est l'architecture. Ou plutôt, l'absence d'une. Une palette de couleurs n'est pas un système de couleurs. Une palette vous donne un tas d'échantillons. Un système vous donne les règles sur la façon dont ces échantillons sont appliqués selon les contextes, les thèmes et les exigences d'accessibilité.

Voici ce qu'un système de couleurs de production nécessite vraiment :

  • Tokens primitifs — les valeurs de couleur brutes (votre palette)
  • Tokens sémantiques — ce que les couleurs signifient (arrière-plan, surface, texte, erreur, etc.)
  • Tokens de composants — comment les couleurs s'appliquent à des éléments UI spécifiques
  • Variantes de thème — comment tout ce qui précède change entre les modes clair/sombre/contraste élevé
  • Garanties d'accessibilité — les ratios de contraste intégrés aux relations de tokens, pas vérifiés après coup

Si l'une de ces couches manque, vous finirez par toucher un mur à un moment ou un autre. Faites-moi confiance.

Fondations de la théorie des couleurs pour le web

Avant de nous plonger dans l'implémentation, ancrons-nous dans la théorie des couleurs qui compte vraiment pour le travail UI. Je ne vais pas reprendre toute la roue chromatique — vous pouvez la trouver n'importe où. À la place, concentrons-nous sur ce qui pose problème aux gens.

Uniformité perceptuelle

Voici quelque chose qui m'a dérangé pendant des années avant de le comprendre : pourquoi une palette générée avec des valeurs de teinte HSL espacées régulièrement semble... inégale ? La réponse est l'uniformité perceptuelle. HSL traite l'espace de couleur comme mathématiquement uniforme, mais nos yeux ne le perçoivent pas de cette façon. Un décalage de 10 % de luminosité de 50 % à 40 % en bleu ressemble très différent du même décalage en jaune.

C'est pourquoi OKLCH compte tellement. En OKLCH, un changement de 10 unités en luminosité ressemble au même montant de changement indépendamment de la teinte. C'est la fondation pour générer des palettes cohérentes par programmation.

La règle 60-30-10 tient toujours

Même en 2026, le principe classique du design d'intérieur se traduit parfaitement en UI :

  • 60 % — Couleurs de surface/arrière-plan dominantes
  • 30 % — Couleurs secondaires (cartes, barres latérales, sections)
  • 10 % — Couleurs d'accent (boutons, liens, surlignages)

Votre système de couleurs devrait rendre ce ratio facile à atteindre par défaut.

Chaud vs frais et poids perçu

Les couleurs chaudes (rouges, oranges, jaunes) semblent plus lourdes et plus proches. Les couleurs froides (bleus, verts, violets) reculent. Cela affecte la façon dont les utilisateurs perçoivent la hiérarchie des informations. Votre couleur d'action primaire devrait généralement être plus chaude que votre arrière-plan pour créer un poids visuel naturel.

Apprendre de l'architecture des couleurs de Material Design 3

Material Design 3 (M3) a introduit ce qu'ils appellent « couleur dynamique » — et indépendamment de l'utilisation de Material Design lui-même, l'architecture vaut la peine d'être étudiée. L'équipe de Google a essentiellement résolu le problème du système de couleurs à l'échelle, et nous pouvons voler leurs meilleures idées.

Le concept de palette tonale

M3 génère des palettes tonales — 13 tons de 0 (noir) à 100 (blanc) pour chaque couleur clé. Chaque ton a un rôle spécifique :

Ton Utilisation typique Mode clair Mode sombre
0 Noir — —
10 Surfaces sombres — Variante de surface
20 Éléments plus sombres — Surface
30 Accent sombre Conteneur on-primary —
40 Primaire Primaire —
50 Plage intermédiaire — —
60 Accent plus clair — —
70 Éléments clairs — Conteneur primaire
80 Accent clair Conteneur primaire Primaire
90 Surfaces plus claires Variante conteneur primaire —
95 Très clair Variante de surface —
99 Près du blanc Surface —
100 Blanc Arrière-plan —

Le génie de cette approche : le mode clair et le mode sombre utilisent la même palette tonale, juste mappée différemment. Le ton 40 pourrait être votre couleur primaire en mode clair, tandis que le ton 80 est votre primaire en mode sombre. Même teinte, même palette, application complètement différente.

Rôles de couleur clé

M3 définit cinq rôles de couleur clé que j'ai trouvé fonctionnant bien même en dehors de Material Design :

  1. Primaire — Votre couleur principale de marque/action
  2. Secondaire — Couleur de soutien pour les éléments moins importants
  3. Tertiaire — Un accent supplémentaire pour l'intérêt visuel
  4. Erreur — Couleur sémantique pour les erreurs et actions destructrices
  5. Neutre — L'épine dorsale des surfaces, arrière-plans et texte

Chaque rôle obtient sa propre palette tonale. C'est cinq palettes × 13 tons = 65 couleurs de base. Cela semble beaucoup, mais vous n'exposez qu'une fraction de ces tokens sémantiques.

Choisir le bon espace de couleur : OKLCH vs HSL vs HEX

Cette décision a de vraies conséquences. Voici la comparaison honnête :

Fonctionnalité HEX/RGB HSL OKLCH
Support navigateur (2026) 100 % 100 % ~96 %
Uniformité perceptuelle Non Non Oui
Facile à lire Non Un peu Oui
Génération facile de palette Non Oui Oui
Mappage de gamut sRGB uniquement sRGB uniquement P3 + sRGB
Compatibilité CSS color-mix() Oui Oui Oui
Support des outils de conception Universel Universel Croissant

Ma recommandation pour 2026 : créer en OKLCH, distribuer en OKLCH et hex de secours. Voici pourquoi.

OKLCH vous donne trois axes intuitifs :

  • L (Luminosité) : 0 % à 100 %
  • C (Chroma) : 0 à ~0,4 (intensité de saturation)
  • H (Teinte) : 0 à 360 degrés
/* OKLCH est véritablement agréable à utiliser */
:root {
  --color-primary: oklch(55% 0.2 250);     /* Un bleu vivide */
  --color-primary-light: oklch(75% 0.15 250); /* Même teinte, plus clair, chroma légèrement moins intense */
  --color-primary-dark: oklch(35% 0.18 250);  /* Variante plus sombre */
}

Notez comment vous pouvez ajuster la luminosité et la chroma indépendamment en gardant la teinte constante. Essayez de faire ça en hex. Je vais attendre.

Pour les ~4 % de navigateurs qui ne supportent pas OKLCH en 2026, utilisez @supports avec des fallbacks hex. Les chiffres continuent de baisser de toute façon.

Tokens de conception : la source de vérité

Les tokens de conception sont des représentations nommées et indépendantes de la plateforme des décisions de conception. Ils sont le contrat entre votre outil de conception et votre base de code. En 2026, la spécification du W3C Design Tokens Community Group s'est suffisamment stabilisée pour construire dessus avec confiance.

Architecture des tokens : trois couches

Je structure les tokens de couleur en trois couches. Ce n'est pas arbitraire — c'est l'architecture viable minimale qui gère les thèmes sans devenir ingérable.

Couche 1 : Tokens primitifs (la palette)

{
  "color": {
    "blue": {
      "10": { "$value": "oklch(15% 0.05 250)", "$type": "color" },
      "20": { "$value": "oklch(25% 0.08 250)", "$type": "color" },
      "30": { "$value": "oklch(35% 0.12 250)", "$type": "color" },
      "40": { "$value": "oklch(45% 0.18 250)", "$type": "color" },
      "50": { "$value": "oklch(55% 0.20 250)", "$type": "color" },
      "60": { "$value": "oklch(65% 0.18 250)", "$type": "color" },
      "70": { "$value": "oklch(75% 0.15 250)", "$type": "color" },
      "80": { "$value": "oklch(85% 0.10 250)", "$type": "color" },
      "90": { "$value": "oklch(92% 0.06 250)", "$type": "color" },
      "95": { "$value": "oklch(96% 0.03 250)", "$type": "color" },
      "99": { "$value": "oklch(99% 0.01 250)", "$type": "color" }
    }
  }
}

Couche 2 : Tokens sémantiques (le sens)

{
  "color": {
    "primary": { "$value": "{color.blue.50}", "$type": "color" },
    "on-primary": { "$value": "{color.blue.99}", "$type": "color" },
    "primary-container": { "$value": "{color.blue.90}", "$type": "color" },
    "on-primary-container": { "$value": "{color.blue.10}", "$type": "color" },
    "surface": { "$value": "{color.neutral.99}", "$type": "color" },
    "on-surface": { "$value": "{color.neutral.10}", "$type": "color" },
    "error": { "$value": "{color.red.50}", "$type": "color" },
    "on-error": { "$value": "{color.red.99}", "$type": "color" }
  }
}

Couche 3 : Tokens de composants (l'application)

{
  "button": {
    "primary": {
      "background": { "$value": "{color.primary}", "$type": "color" },
      "text": { "$value": "{color.on-primary}", "$type": "color" },
      "hover-background": { "$value": "{color.primary-container}", "$type": "color" }
    }
  }
}

Outils qui fonctionnent en 2026

Pour la gestion des tokens et la transformation, ces outils sont éprouvés au combat :

  • Style Dictionary 4.x — La norme pour transformer les tokens en n'importe quel format de plateforme
  • Tokens Studio pour Figma — Synchronise les tokens entre Figma et votre base de code
  • Cobalt UI — Un compilateur de tokens compatible W3C-spec plus récent qui gagne en traction

J'ai eu de bons résultats en utilisant Tokens Studio pour gérer les tokens dans Figma, en les exportant au format JSON conforme au W3C, et en utilisant Style Dictionary pour les compiler en propriétés personnalisées CSS, configuration Tailwind et valeurs Swift/Kotlin. At Social Animal, nous avons intégré ce pipeline dans notre processus de construction pour plusieurs projets clients.

Implémentation avec les propriétés CSS personnalisées

C'est ici que la théorie rencontre la réalité. Les propriétés CSS personnalisées (variables CSS) sont la couche d'exécution de votre système de couleurs. C'est ce qui rend le thème, le mode sombre et les mises à jour dynamiques possibles sans envoyer du JavaScript supplémentaire.

La configuration de base

/* Couche primitive — rarement référencée directement dans les composants */
:root {
  --palette-blue-50: oklch(55% 0.20 250);
  --palette-blue-80: oklch(85% 0.10 250);
  --palette-blue-90: oklch(92% 0.06 250);
  --palette-blue-10: oklch(15% 0.05 250);
  --palette-neutral-10: oklch(15% 0.01 250);
  --palette-neutral-90: oklch(92% 0.01 250);
  --palette-neutral-95: oklch(96% 0.005 250);
  --palette-neutral-99: oklch(99% 0.002 250);
  --palette-red-50: oklch(55% 0.22 25);
  --palette-red-80: oklch(85% 0.10 25);
  --palette-red-90: oklch(92% 0.06 25);
}

/* Couche sémantique — c'est ce que les composants référencent */
:root,
[data-theme="light"] {
  --color-primary: var(--palette-blue-50);
  --color-on-primary: var(--palette-blue-99, #ffffff);
  --color-primary-container: var(--palette-blue-90);
  --color-on-primary-container: var(--palette-blue-10);
  --color-surface: var(--palette-neutral-99);
  --color-on-surface: var(--palette-neutral-10);
  --color-surface-variant: var(--palette-neutral-95);
  --color-error: var(--palette-red-50);
  --color-on-error: white;
}

Utiliser `color-mix()` pour les variations dynamiques

L'un des meilleurs ajouts récents de CSS pour les systèmes de couleurs est color-mix(). Au lieu de définir des tokens séparés pour chaque état de survol et variante d'opacité, vous pouvez les dériver :

.button-primary {
  background: var(--color-primary);
  color: var(--color-on-primary);
}

.button-primary:hover {
  /* Mélanger primaire avec blanc pour un état de survol plus clair */
  background: color-mix(in oklch, var(--color-primary) 85%, white);
}

.button-primary:active {
  /* Mélanger avec du noir pour l'état enfoncé */
  background: color-mix(in oklch, var(--color-primary) 90%, black);
}

/* Recouvrements de surface semi-transparents */
.overlay {
  background: color-mix(in oklch, var(--color-on-surface) 8%, transparent);
}

C'est extrêmement utile. Au lieu de 15 variantes d'opacité de chaque couleur, vous les calculez à l'exécution. Moins de tokens, plus de flexibilité.

Construire un mode sombre qui fonctionne vraiment

Le mode sombre n'est pas juste « échanger le blanc pour le noir ». J'ai vu cette approche produire des résultats qui fatiguent les yeux et échouent l'accessibilité trop de fois. Voici comment le faire correctement.

La stratégie de remappage

Remembrez la palette tonale de la section Material Design ? Le mode sombre remappage les tokens sémantiques à différents tons dans la même palette :

[data-theme="dark"] {
  --color-primary: var(--palette-blue-80);  /* C'était 50, maintenant 80 (plus clair) */
  --color-on-primary: var(--palette-blue-20);  /* C'était 99, maintenant 20 (plus sombre) */
  --color-primary-container: var(--palette-blue-30);  /* C'était 90, maintenant 30 */
  --color-on-primary-container: var(--palette-blue-90);  /* C'était 10, maintenant 90 */
  --color-surface: var(--palette-neutral-10);  /* C'était 99, maintenant 10 */
  --color-on-surface: var(--palette-neutral-90);  /* C'était 10, maintenant 90 */
  --color-surface-variant: var(--palette-neutral-20);
  --color-error: var(--palette-red-80);
  --color-on-error: var(--palette-red-20);
}

Voyez ce qui se passe ? Les relations s'inversent. Les couleurs primaires deviennent plus claires en mode sombre (donc elles sont visibles sur les surfaces sombres). Les couleurs d'arrière-plan basculent vers l'extrémité sombre de la palette neutre. Chaque paire avant-plan/arrière-plan maintient sa relation de contraste.

Respecter les préférences système

@media (prefers-color-scheme: dark) {
  :root:not([data-theme="light"]) {
    /* Mêmes valeurs de mode sombre qu'au-dessus */
    --color-primary: var(--palette-blue-80);
    --color-surface: var(--palette-neutral-10);
    /* ... */
  }
}

Le sélecteur :not([data-theme="light"]) est l'astuce clé. Il respecte la préférence système sauf si l'utilisateur a explicitement choisi le mode clair via un basculeur. Voici la logique du basculement :

function setTheme(theme) {
  if (theme === 'system') {
    document.documentElement.removeAttribute('data-theme');
    localStorage.removeItem('theme');
  } else {
    document.documentElement.setAttribute('data-theme', theme);
    localStorage.setItem('theme', theme);
  }
}

// Au chargement de la page, appliquer la préférence sauvegardée
const saved = localStorage.getItem('theme');
if (saved) document.documentElement.setAttribute('data-theme', saved);

Pour les frameworks comme Next.js (que nous utilisons beaucoup dans notre pratique de développement Next.js), vous voudrez injecter ce script dans le <head> pour éviter le flash du mauvais thème. Astro le gère bien aussi avec sa directive de script is:inline — quelque chose que nous exploitons dans notre travail de développement Astro.

Élévation de surface en mode sombre

Une chose que Material Design comprend bien : en mode sombre, les surfaces élevées devraient être légèrement plus claires, pas plus sombres. Cela imite le fonctionnement des ombres — dans une pièce sombre, une surface plus proche capture plus de lumière ambiante.

[data-theme="dark"] {
  --color-surface-dim: oklch(12% 0.01 250);
  --color-surface: oklch(15% 0.01 250);
  --color-surface-bright: oklch(20% 0.01 250);
  --color-surface-container-low: oklch(17% 0.01 250);
  --color-surface-container: oklch(19% 0.01 250);
  --color-surface-container-high: oklch(22% 0.01 250);
}

Ces minuscules incréments de luminosité (2-3 % en OKLCH) créent une hiérarchie d'élévation subtile mais efficace.

Accessibilité et conformité de contraste WCAG

C'est la partie où de nombreux systèmes de couleurs patchy rétroactivement les problèmes au lieu de les prévenir. Prévoyons-les.

Exigences de contraste WCAG 2.2 et 3.0

WCAG 2.2 (la norme actuelle) utilise la formule du ratio de contraste :

Niveau Texte normal (< 24px) Texte volumineux (≥ 24px / 18.66px en gras) Composants UI
AA 4,5:1 3:1 3:1
AAA 7:1 4,5:1 N/A

WCAG 3.0 (toujours en brouillon, mais pertinent pour les épreuves futures) utilise l'APCA (Advanced Perceptual Contrast Algorithm), qui est plus précis sur le plan perceptuel. L'APCA mesure le contraste différemment — il tient compte de la polarité (texte clair sur sombre vs texte sombre sur clair) et de la taille du texte de manière plus granulaire.

Pour 2026, je recommande de cibler WCAG 2.2 AA comme minimum, avec l'APCA comme vérification supplémentaire.

Intégrer le contraste dans vos paires de tokens

L'approche la plus efficace : chaque token de premier plan sémantique devrait être défini en relation avec son token d'arrière-plan correspondant, avec un contraste garanti.

Voici comment je valide cela à l'étape de construction :

// contrast-check.mjs — exécutez ceci dans votre pipeline CI/CD
import { wcagContrast } from 'culori';

const pairs = [
  { fg: 'on-primary', bg: 'primary', minRatio: 4.5 },
  { fg: 'on-primary-container', bg: 'primary-container', minRatio: 4.5 },
  { fg: 'on-surface', bg: 'surface', minRatio: 4.5 },
  { fg: 'on-surface', bg: 'surface-variant', minRatio: 3.0 },
  { fg: 'on-error', bg: 'error', minRatio: 4.5 },
];

function validateContrast(tokens, theme) {
  const failures = [];
  for (const pair of pairs) {
    const ratio = wcagContrast(tokens[pair.fg], tokens[pair.bg]);
    if (ratio < pair.minRatio) {
      failures.push(
        `[${theme}] ${pair.fg}/${pair.bg}: ${ratio.toFixed(2)} (besoin ${pair.minRatio})`
      );
    }
  }
  return failures;
}

Exécutez cela par rapport aux tokens de thème clair et sombre. Si une paire échoue, la construction échoue. Pas d'exceptions. J'ai vu des équipes sauter cette vérification « juste pour maintenant » et finir par envoyer des interfaces inaccessibles pendant des mois.

La requête multimédia `forced-colors`

N'oubliez pas le mode de contraste élevé de Windows. Elle remplace complètement vos couleurs, et vous devez vous assurer que votre UI est toujours utilisable :

@media (forced-colors: active) {
  .button {
    border: 2px solid ButtonText;
  }
  
  .icon {
    forced-color-adjust: auto; /* Laisser le système le gérer */
  }
}

Tout assembler : un système complet

Voici le flux de travail pratique auquel je suis arrivé après avoir itéré à travers de nombreux projets :

  1. Commencez par 1-3 couleurs de marque. Définissez votre teinte primaire, secondaire et éventuellement tertiaire.

  2. Générez des palettes tonales en OKLCH. Utilisez un outil comme Huetone ou construisez un simple script qui génère 11 étapes de luminosité par teinte.

  3. Définissez les mappages de tokens sémantiques. Mappez les tons aux rôles sémantiques pour les thèmes clair et sombre. Utilisez le tableau de mappage de tons M3 comme point de départ.

  4. Validez toutes les paires de contraste. Chaque token on-* doit respecter WCAG 2.2 AA par rapport à sa surface correspondante.

  5. Exportez en tant que tokens de conception JSON conforme au W3C. C'est votre source de vérité unique.

  6. Compilez en propriétés CSS personnalisées en utilisant Style Dictionary ou Cobalt UI.

  7. Implémentez le changement de thème avec les attributs data-theme et prefers-color-scheme.

  8. Ajoutez la validation de contraste à CI. Ne déployez jamais un changement de couleur sans des vérifications de contraste automatisées.

Si vous construisez un site basé sur un CMS sans tête et avez besoin d'aide pour mettre en œuvre un système de couleurs de production, c'est exactement le type de travail que nous faisons chez Social Animal. Consultez notre tarification ou mettez-vous en contact pour discuter de votre projet.

Exemple d'intégration Tailwind v4

Si vous utilisez Tailwind CSS v4 (qui utilise une configuration CSS-first), voici comment les tokens de conception se traduisent :

/* tokens.css — importé par votre configuration Tailwind */
@theme {
  --color-primary: var(--color-primary);
  --color-on-primary: var(--color-on-primary);
  --color-surface: var(--color-surface);
  --color-on-surface: var(--color-on-surface);
  --color-error: var(--color-error);
}

Puis dans votre balisage :

<button class="bg-primary text-on-primary hover:bg-primary/85">
  Commencer
</button>

Propre, sémantique et automatiquement conscient des thèmes.

FAQ

Combien de couleurs un système de couleurs de conception web devrait-il avoir ?

Un système bien structuré a généralement 3-5 rôles de couleur clé (primaire, secondaire, tertiaire, erreur, neutre), chacun avec 11-13 variations tonales. C'est à peu près 40-65 tokens primitifs. Mais vous n'exposerez que 15-25 tokens sémantiques que les composants référencent réellement. Plus ce n'est pas mieux — la clarté l'est.

Quelle est la différence entre les tokens de conception et les variables CSS ?

Les tokens de conception sont des décisions de conception agnostiques à la plate-forme stockées sous forme de données (généralement JSON). Les propriétés CSS personnalisées sont un format de sortie pour ces tokens. Le même fichier de token pourrait également générer des constantes de couleur Swift, des valeurs Kotlin ou des styles Figma. Les tokens sont la source de vérité ; les variables CSS sont une expression de cette vérité.

OKLCH est-il prêt pour la production en 2026 ?

Oui. Le support des navigateurs est d'environ 96 % mondialement en début 2026, couvrant tous les navigateurs modernes. Pour les ~4 % restants (principalement les navigateurs intégrés plus anciens), fournissez des fallbacks hex en utilisant @supports ou un plugin PostCSS comme postcss-oklab-function. Le risque est minimal.

Comment m'assurer que mon système de couleurs respecte les normes d'accessibilité WCAG ?

Intégrez la vérification du contraste dans votre pipeline de tokens de conception. Chaque paire avant-plan/arrière-plan devrait être validée par rapport aux minimums WCAG 2.2 AA (4,5:1 pour le texte normal, 3:1 pour le texte volumineux et les composants UI). Les outils comme la bibliothèque JavaScript culori, Stark pour Figma ou l'extension du navigateur axe peuvent aider. La clé est d'automatiser ces vérifications pour qu'elles s'exécutent à chaque changement.

Devrais-je utiliser directement le système de couleurs de Material Design 3 ?

Vous n'avez pas besoin d'adopter Material Design comme système de conception pour bénéficier de son architecture de couleur. Le concept de palette tonale, la structure des tokens sémantiques et la stratégie de remappage clair/sombre sont excellents indépendamment de votre style visuel. Prenez sélectivement l'architecture ; appliquez vos propres esthétiques de marque.

Comment gérer le mode sombre avec les propriétés CSS personnalisées ?

Utilisez un attribut data-theme sur l'élément racine combiné avec les requêtes multimédia prefers-color-scheme. Les propriétés CSS personnalisées sémantiques sont remappées à différentes valeurs primitives pour chaque thème. Les composants ne changent jamais — seules les valeurs de tokens changent. C'est l'approche la plus propre et évite de dupliquer les styles de composants.

Quels outils devrais-je utiliser pour gérer les tokens de conception en 2026 ?

Tokens Studio pour Figma gère le côté conception. Style Dictionary 4.x ou Cobalt UI gère l'étape de construction/transformation. Stockez votre JSON de token dans le contrôle de version aux côtés de votre code. Pour les équipes plus grandes, envisagez une plateforme de gestion des tokens de conception dédiée comme Specify ou Supernova, mais la pile open-source fonctionne très bien pour la plupart des équipes.

Quelle est la différence entre les méthodes de contraste WCAG 2.2 et APCA ?

WCAG 2.2 utilise un simple ratio de contraste de luminance (par ex. 4,5:1). APCA, proposé pour WCAG 3.0, est plus précis sur le plan perceptuel — il considère que le texte clair sur le fond sombre a besoin d'un contraste différent du texte sombre sur le fond clair, et il ajuste les exigences selon la taille et le poids de la police. En 2026, ciblez WCAG 2.2 AA pour la conformité et utilisez APCA comme vérification de qualité supplémentaire.