Safari assombrit maintenant les sites qui ne l'ont jamais demandé, et votre page ne peut pas le savoir

Quelqu’un vous dit que les couleurs de votre site ont l’air incorrectes. Délavées, ou inversées, ou le graphique au milieu de la page est un rectangle blanc vif sur un fond sombre par ailleurs. Vous ouvrez la même page sur le même modèle de téléphone et tout est exactement comme vous l’aviez conçu.

Ils ne se trompent pas et vous non plus. Depuis le 3 novembre 2026, il y a un tiers dans cette conversation, et la chose importante à savoir à ce sujet n’est pas qu’elle change vos couleurs. C’est que votre page est délibérément empêchée de le découvrir.

Qu’est-ce que le mode sombre adaptatif

Le mode sombre adaptatif est arrivé dans Safari 27.3 beta. La description de WebKit est en une phrase : « Lorsqu’il est activé par un utilisateur, Safari adapte les sites web clairs et les présente en version sombre. »

La raison qu’ils donnent est un écart entre deux chiffres, et il vaut la peine de les citer car ils expliquent pourquoi cela allait de toute façon se produire : « Près de 40 % des chargements de pages web proviennent d’utilisateurs en mode sombre, et pourtant seuls 10 % des chargements de pages le prennent en charge. »

C’est un choix de l’utilisateur et non du vôtre. Quelqu’un naviguant avec une apparence système sombre arrive sur une page claire, Safari propose un aperçu, et il appuie sur Essayer. À partir de là, les pages claires apparaissent en sombre pour lui. Il n’y a aucune bannière sur la page et rien dans vos analyses qui indique que cela s’est produit.

Comment il décide s’il faut modifier votre page

Il y a deux chemins et un seul d’entre eux vous concerne.

Si votre page déclare la prise en charge du mode sombre, rien ne se passe du tout. Une page contenant <meta name="color-scheme" content="light dark"> dans son HTML, ou color-scheme: light dark en CSS, est laissée exactement comme écrite. Vous avez dit à Safari que vous gérez le mode sombre vous-même, et il vous croit.

Pour tout le reste, il regarde. Il analyse la page, estime si elle est principalement claire ou sombre, et laisse seules les pages qui ont une apparence sombre. Une page avec une apparence claire est transformée.

La transformation elle-même est une matrice de couleur qui inverse la luminosité tout en préservant la teinte, de sorte qu’un fond blanc devient sombre et le texte sombre devient clair sans que tout se transforme en négatif photographique. Pour le texte, il vise un ratio de contraste WCAG 4.5:1.

La partie qui produit les bogues est ce qu’elle ne transforme pas

Une inversion complète serait facile à comprendre. Ce n’en est pas une, et les exceptions sont d’où viennent les rapports.

• Les dégradés CSS clairs sont transformés, de sorte qu’un dégradé que vous avez soigneusement accordé est recalculé.
• Les images SVG sont inspectées et leurs couleurs transformées si nécessaire. Les images bitmap sont principalement laissées seules, mais leurs histogrammes de pixels sont analysés et les logos simples en noir et blanc sont inversés.
• Les masques et mix-blend-mode peuvent être désactivés. Le raisonnement de WebKit est que ces effets produisent des résultats indésirables sur un élément dont les couleurs ont été transformées, de sorte que dans certains cas, le mode sombre adaptatif les désactive plutôt que de les transformer.
• <canvas> est laissé complètement inchangé, car le contenu du canevas est, selon leurs termes, « difficile à prévoir ».

Lisez les deux derniers ensemble et vous avez un défaut que personne n’a écrit. Un graphique rendu dans un canevas conserve son fond blanc tandis que chaque pixel autour devient sombre. Une superposition composée arrête de composer. Les deux sont invisibles pour vous et évidentes pour la personne qui regarde l’écran.

Votre page n’est pas autorisée à savoir

C’est la partie qui compte si vous essayez de comprendre ce que quelqu’un voit, et c’est une décision de conception délibérée plutôt qu’une lacune.

La position d’Apple est qu’un paramètre détectable est une surface d’empreinte numérique, donc :

Safari empêche les sites web de détecter quand le mode sombre adaptatif a été appliqué. Le JavaScript qui interroge les couleurs CSS obtiendra les couleurs d’origine, pas les couleurs transformées.

C’est absolu, et la solution de contournement évidente est fermée dans le même paragraphe : « Toute image dessinée dans un canevas s’affiche sous sa forme d’origine. » Faire une capture d’écran de votre propre page dans un canevas renvoie la version que vous avez écrite, pas la version affichée.

Donc getComputedStyle vous remet vos propres valeurs. Un point de terminaison de diagnostic qui rapporte les couleurs calculées rapporte votre feuille de style. Une demande « collez vos styles calculés » au rapporteur renvoie la même chose. Chaque instrument que vous possédez est du mauvais côté de la transformation, ce qui est une forme familière : la page ne peut pas se voir elle-même, et le seul témoin est un humain regardant un écran.

Refuser de participer, et le hic à ce jour

Deux déclarations, faisant des choses opposées.

color-scheme: light dark indique que vous prenez en charge le mode sombre et que vous le gérerez. Le mode sombre adaptatif vous laisse alors tranquille. C’est celui à utiliser si vous avez ou avez l’intention de construire un vrai thème sombre, et le conseil de WebKit est de le déclarer dans l’en-tête HTML plutôt que de l’injecter plus tard avec JavaScript, de sorte que la page s’affiche correctement dès que possible.

color-scheme: light only, ou <meta name="color-scheme" content="light only">, indique que la page ne doit être affichée qu’en mode clair et refuse carrément la transformation.

Le hic vaut la peine d’être connu avant de l’expédier comme correctif : WebKit note que le mot-clé only « n’est pas pris en charge dans Safari 27.3 beta 1 ». C’est une bêta, la fonction est explicitement décrite comme évoluant au cours de cette bêta, et l’échappatoire documentée ne fonctionne pas encore dans la première version de celle-ci.

Quoi demander à la personne qui l’a signalé

La question ordinaire « quel navigateur et quelle version » ne vous y mènera pas. Quelqu’un qui a appuyé sur Essayer il y a plusieurs semaines ne le considère pas comme un paramètre qu’il a modifié, pas plus qu’il ne signalerait la luminosité de son écran.

Deux questions fonctionnent. Est-ce que cela a l’air mal dans une fenêtre privée ? et est-ce que cela a l’air mal sur un appareil différent ? Les deux changent la réponse si le mode sombre adaptatif est impliqué, et aucun ne nécessite que le rapporteur sache ce que c’est.

Mieux encore, c’est une image. L’écart entre ce que votre code décrit et ce qu’un écran montre est exactement l’écart qu’une capture d’écran ferme, et dans ce cas, c’est la seule chose qui peut, car la page elle-même a été placée du mauvais côté de la question.

C’est la deuxième fois en un an qu’une version de Safari a changé le sens d’un rapport de bogue plutôt que ce qu’une page peut faire, après les modifications de rapport dans Safari 27.

Ce qu’il faut en retenir

Un navigateur édite maintenant vos couleurs au nom de l’utilisateur, décide au cas par cas les éléments à éditer, désactive certains de vos effets pour ce faire, et cache toute l’opération à votre code pour une bonne raison.

Si vous avez un thème sombre, déclarez-le et cela ne s’applique jamais à vous. Si vous ne le faites pas, le choix réaliste est de le laisser se produire et de vérifier que vos canevas et vos modes de fusion survivent, ou de déclarer light only et de guetter la bêta qui le prend en charge. Ce qui n’est pas disponible, c’est de le découvrir de l’intérieur de la page, ce qui signifie que le rapport suivant « les couleurs ont l’air mal » est celui auquel vous devriez croire.

L’annonce de WebKit, avec les exemples et la liste complète de ce qui est et n’est pas transformé, est Introducing Adaptive Dark Mode.