Pourquoi les modes sombres de l’IA semblent faux : inversion contre dérivation

Demandez à un assistant de code d’« ajouter le mode sombre » à un projet et lisez le diff qu’il produit. Le geste est remarquablement constant : les fonds blancs deviennent presque noirs, les gris clairs deviennent des gris foncés, le texte foncé devient du texte clair, l’accent de la marque conserve son hex exact et les ombres portées restent exactement où elles étaient. Demandez à un générateur d’images « la version en mode sombre » d’un tableau de bord et il exécute le même geste en peinture. Les deux paraissent plausibles en miniature. Aucun ne survit au contact de l’usage réel.

Les modes sombres de l’IA semblent faux parce que le modèle effectue une inversion — les valeurs du thème clair permutées vers des positions en miroir — alors qu’un thème sombre qui fonctionne est une dérivation : une seconde palette calculée à partir des mêmes couleurs de départ de la marque, avec sa propre rampe de luminosité qui monte depuis un plancher profond plutôt que depuis un plancher inversé, un chroma replanifié pour un fond sombre au lieu d’être reporté, un contraste recalculé pour chaque appariement de texte et de surface, et une nouvelle logique d’élévation dans laquelle les surfaces surélevées s’éclaircissent au lieu de projeter des ombres. Cette distinction est la colonne vertébrale de notre guide du mode sombre ; cet article porte sur ce qui se passe quand une IA entre dans la boucle.

Que fait réellement une IA quand vous lui demandez le mode sombre ?

Elle reproduit l’apparence globale des interfaces sombres sur lesquelles elle a été entraînée — pas la construction de l’une d’entre elles en particulier. C’est là la clé intuitive de tout l’échec : le modèle a vu un très grand nombre d’interfaces sombres et sait à quoi elles tendent à ressembler ; il n’a jamais exécuté les décisions qui en ont rendu une bonne. La sortie fait donc de la reconnaissance de motifs — fond sombre, texte clair, même accent — et deux choses manquent par construction. La première est le calcul : rien ne vérifie si le texte secondaire gris moyen franchit encore un plancher de contraste contre le nouveau fond, car le modèle génère des valeurs plausibles plutôt que de les vérifier. La seconde est la stabilité : chaque réponse est échantillonnée à neuf, si bien que demander « le mode sombre » deux fois renvoie deux thèmes légèrement différents — la même instabilité qui fait dériver les interfaces générées par IA hors de la marque au fil d’une session plus longue. Ce que vous obtenez, c’est une image d’un thème sombre, en code ou en pixels.

Pourquoi l’inversion produit-elle un thème cassé ?

Parce que les relations internes d’un thème clair ne survivent pas à la mise en miroir — un échec à trois visages distincts, détaillé dans Le mode sombre n’est pas une inversion :

• La logique des rôles bascule en bloc. Une bordure de thème clair se situe légèrement plus foncée que sa surface et se lit comme une ligne tracée, en creux ; inversez la luminosité et elle devient légèrement plus claire, se lisant alors comme un relief. Certaines relations doivent basculer — le texte foncé sur clair devient à juste titre du texte clair sur foncé — tandis que d’autres ne le doivent pas, et l’inversion ne sait pas faire la différence.
• L’élévation perd son signal. Les ombres se remarquent à peine sur un fond sombre — il n’y a presque plus rien de plus foncé où aller — si bien que les thèmes sombres signalent la hauteur en rendant les surfaces surélevées plus claires. L’inversion reporte les ombres, inutilement, et ne produit aucun de ces éclaircissements.
• La couleur se vide. La quantité de couleur perçue se juge par rapport à l’environnement : la même valeur de chroma se lit nettement plus terne contre un presque noir que contre le blanc, ce qui explique pourquoi les couleurs semblent délavées en mode sombre quand leurs valeurs sont reportées sans changement.

Une IA à qui l’on demande de « passer en sombre » reproduit les trois, parce que de l’extérieur un thème sombre ressemble à une inversion — les décisions qui font qu’il n’en est pas une sont invisibles dans l’artefact fini, et donc invisibles aussi dans les données d’entraînement.

Que signifie alors la dérivation ?

La dérivation conserve les couleurs de départ et relance la construction de la palette pour un contexte sombre. La rampe sombre n’est pas un miroir de la claire : elle suit sa propre courbe de luminosité, avec les paliers de classe fond qui se stabilisent autour de L ≈ 0,13–0,19 en OKLCH — une zone neutre profonde, pas le noir pur qu’un miroir produit à partir d’un point de départ presque blanc. Le chroma est replanifié plutôt que copié : relevé d’environ 20 % par rapport aux valeurs claires pour contrer l’affadissement d’un fond sombre, borné par ce que le gamut permet à chaque luminosité. Les rôles sémantiques sont redérivés plutôt que redirigés — les couleurs de texte, de bordure et d’état sont choisies contre les nouvelles surfaces, avec les planchers de contraste revérifiés là, car un appariement qui passait sur le blanc ne prouve rien sur le presque noir. Et l’élévation est reconstruite sur la convention d’éclaircissement au lieu d’ombres héritées.

Rien de tout cela n’est exotique ; c’est de l’arithmétique — et c’est précisément là l’essentiel. C’est calculable parce que la palette vit dans un modèle de couleur perceptuel : la luminosité OKLCH suit à quel point une couleur paraît réellement claire (le modèle s’appuie sur les travaux sur OKLab de Björn Ottosson), si bien que « dériver une nouvelle rampe et revérifier chaque appariement » est un calcul, pas une séance d’appréciation à l’œil. Un modèle génératif échantillonne ce qu’un thème sombre pourrait plausiblement être ; une dérivation calcule ce que votre thème sombre est.

Ouvrez une palette claire à côté de sa jumelle sombre dérivée dans Scale Composer — la même couleur de départ des deux côtés, et les différences que décrit cet article se lisent dans les valeurs : le plancher profond mais pas noir, le chroma relevé, les paliers de texte re-choisis.

Cela s’applique-t-il aussi aux images d’interfaces sombres générées par IA ?

Oui — même échec, autre médium. Demandez à un générateur d’images « le même écran, en mode sombre » et il repeint vers son a priori des interfaces sombres : des fonds noir pur, des accents qui rayonnent comme un tableau de bord de jeu vidéo, un texte d’un blanc incandescent. Ça, c’est un look, pas une dérivation — et ce n’est généralement pas le vôtre. Les négations ne le sauveront pas : ces générateurs s’accrochent souvent au nom que vous interdisez, si bien que « mode sombre mais pas noir pur » tend à s’ancrer sur le noir malgré tout. Décrivez plutôt le thème dérivé de façon positive, comme un vocabulaire de prompt : « fond gris neutre profond ; panneaux surélevés légèrement plus clairs que le fond ; texte blanc cassé doux ; le bleu de la marque un peu plus vif que dans la version claire ». Ces formulations ne sont pas des mots d’ambiance — ce sont les décisions réelles d’un thème sombre dérivé, exprimées dans un langage qu’un modèle d’image peut suivre.

Comment obtenir un thème sombre correct d’une IA ?

Répartissez le travail selon la ligne où chaque côté est fort. Dérivez la palette sombre de façon déterministe, exportez les design tokens avec les jeux de rôles clair et sombre côte à côte, et remettez le fichier à l’IA avec une seule consigne permanente : référence les rôles, n’invente jamais de valeurs. Un modèle de code est réellement bon pour appliquer un système à travers des dizaines de composants ; il dérive quand on lui demande de décider le système — la forme récurrente de tout le problème de l’IA et des systèmes de design. Pour les images, le même fichier est la source de vocabulaire : les tons du thème sombre ont eux aussi des noms et des valeurs, et ils ont leur place dans le prompt exactement comme la palette claire.

Dérivez le couple clair–sombre à partir de votre propre couleur de marque — collez une seule couleur de départ, obtenez les deux thèmes avec leur contraste revérifié, et exportez le couple en un seul fichier : la moitié déterministe du flux de travail, prête à être remise au modèle qui construira les écrans.