Thème clair/sombre parfait - Évitez les flashs et bugs !

Un thème clair/sombre bien pensé ne se limite pas à inverser deux couleurs. Sur une interface frontend, il influence la lisibilité, la cohérence des contrôles natifs, la perception de qualité et la façon dont le site s’aligne sur les préférences du système. Je vais montrer ici comment construire une logique robuste, comment placer le choix de l’utilisateur et quels détails évitent les défauts les plus visibles.

Ce que recouvre vraiment un thème clair et sombre

Quand je parle de thème, je ne pense pas seulement au fond de page et au texte principal. Un vrai système de couleurs touche les surfaces, les bordures, les ombres, les états de focus, les icônes, les graphiques, les formulaires et même la couleur de chrome du navigateur. Si un seul de ces éléments reste “bloqué” en mode clair pendant que le reste passe en sombre, l’interface donne immédiatement une impression bricolée.

Le point de départ est donc simple: un thème n’est pas une décoration, c’est un état d’interface. Il doit suivre la préférence de l’utilisateur quand elle existe, mais aussi rester stable d’une page à l’autre, y compris dans les composants natifs que le navigateur dessine pour nous. C’est là que beaucoup de projets frontend se trompent, parce qu’ils ne traitent que le body et oublient tout le reste.

• Le texte doit rester lisible sur chaque surface.
• Les boutons, champs et sélecteurs doivent conserver un contraste cohérent.
• Les icônes et illustrations doivent garder une intensité visuelle acceptable.
• Les éléments d’accent, comme les checkboxes, ne doivent pas jurer avec la palette.

Une fois ce périmètre posé, je peux organiser l’implémentation proprement, au lieu de courir après les corrections visuelles au cas par cas.

Je pars toujours d’une stratégie en trois couches

Dans un projet sérieux, je sépare le problème en trois couches. Cette séparation évite les contradictions et permet de savoir qui gagne quand deux signaux différents se présentent en même temps.

Je recommande presque toujours que le mode manuel l’emporte sur la préférence système, parce que c’est le seul choix explicite de l’utilisateur. Le système reste le comportement par défaut, pas une règle absolue. Cette hiérarchie paraît simple, mais elle supprime une grande partie des bugs de thème en production, et elle prépare le terrain pour la couche CSS.

Le cœur de l’implémentation côté CSS

MDN classe `prefers-color-scheme` parmi les fonctionnalités largement disponibles, donc je l’utilise sans hésiter comme base d’adaptation automatique. Le principe est direct: je déclare des jetons de couleur, puis je remplace leurs valeurs selon la préférence du système. Cela évite de dupliquer tous les sélecteurs du projet.

:root {
  color-scheme: light dark;
  --bg: #ffffff;
  --text: #111827;
  --surface: #f3f4f6;
  --border: #d1d5db;
  --accent: #2563eb;
}

@media (prefers-color-scheme: dark) {
  :root {
    --bg: #0b0f19;
    --text: #e5e7eb;
    --surface: #151a24;
    --border: #334155;
    --accent: #60a5fa;
  }
}

body {
  background: var(--bg);
  color: var(--text);
}

.card,
.modal {
  background: var(--surface);
  border-color: var(--border);
}

input[type="checkbox"],
input[type="radio"] {
  accent-color: var(--accent);
}

Le détail important ici, c’est `color-scheme: light dark;`. Cette déclaration dit au navigateur qu’il peut rendre l’interface correctement dans les deux environnements, ce qui améliore immédiatement les contrôles natifs et certains éléments de chrome. Sans ça, on se retrouve vite avec un site visuellement cohérent dans le contenu, mais incohérent dans les champs de formulaire ou les composants intégrés.

Quand je veux aller plus loin avec un code plus compact, j’utilise aussi `light-dark()` sur des cas ciblés. Je le réserve surtout aux projets où je maîtrise bien la compatibilité, car il simplifie la lecture mais ne remplace pas une bonne architecture de variables. Par exemple, un bloc simple peut rester très lisible avec cette forme:

.hero {
  background: light-dark(#ffffff, #0b0f19);
  color: light-dark(#111827, #e5e7eb);
}

Cette approche me plaît surtout quand je veux exprimer une intention très claire: une valeur pour le mode clair, une valeur pour le mode sombre, et rien de plus. Une fois cette base en place, le vrai sujet devient le moment du chargement et le comportement du sélecteur utilisateur.

Ajouter un sélecteur utilisateur sans effet de flash

Le point que web.dev insiste à corriger, c’est le flash entre deux états au premier rendu. Si le navigateur peint d’abord un thème puis que JavaScript le remplace juste après, l’utilisateur voit une transition sale et inutile. Pour l’éviter, je pose l’état du thème le plus tôt possible, avant que la page ne s’affiche vraiment.

:root[data-theme='dark'] {
  color-scheme: dark;
  --bg: #0b0f19;
  --text: #e5e7eb;
}

:root[data-theme='light'] {
  color-scheme: light;
  --bg: #ffffff;
  --text: #111827;
}

Je garde volontairement une valeur `auto` en dehors de ce snippet, parce qu’elle mérite un vrai traitement fonctionnel. Dans mon approche, `auto` signifie “reprendre la préférence système”, tandis que `light` et `dark` sont des choix explicites qui doivent survivre au rechargement. Si l’utilisateur passe en mode manuel, je ne lui redemande pas sa préférence à chaque visite.

const mq = window.matchMedia('(prefers-color-scheme: dark)');

mq.addEventListener('change', () => {
  if (localStorage.getItem(key)) return;
  root.dataset.theme = mq.matches ? 'dark' : 'light';
});

Ce mécanisme paraît banal, mais il change tout en pratique. Un bon switch de thème n’est pas seulement un bouton fonctionnel; c’est une transition sans heurt entre l’état initial, le choix de l’utilisateur et les changements éventuels du système.

Les détails qui font la différence dans l’interface

Un thème peut être techniquement correct et rester visuellement faible si les composants périphériques ne suivent pas. C’est souvent là que je trouve les défauts les plus visibles: un formulaire trop lumineux, une image trop agressive, ou un navigateur qui affiche une barre d’adresse décalée par rapport au reste.

Je teste aussi les icônes, les illustrations et les graphiques séparément, parce qu’ils racontent souvent une autre histoire que le texte. Une courbe de dashboard qui reste bleue électrique sur fond noir peut suffire à fatiguer l’œil, même si le reste de la palette est correct. C’est ce niveau de cohérence qui sépare une interface correcte d’une interface vraiment soignée.

Le passage entre les états est le vrai critère de qualité

Si je devais garder une seule règle, ce serait celle-ci: un bon thème adaptatif respecte d’abord l’utilisateur, ensuite le système, puis la charte. Le mode automatique doit être fluide, le mode manuel doit être persistant, et le navigateur doit recevoir assez d’informations pour peindre l’interface correctement dès le départ.

Au fond, le sujet n’est pas de savoir si une interface est “belle” en clair ou en sombre. Le vrai test, c’est de voir si le passage entre les deux semble naturel, stable et invisible. Quand cette bascule est propre, le thème ne détourne plus l’attention, et c’est précisément là qu’il remplit son rôle.