Un jour, un client vous écrit que votre newsletter est illisible. Capture d’écran à l’appui : fond sombre, texte sombre, logo découpé dans un carré blanc.
Vous cherchez la matrice de compatibilité du mode sombre par client de messagerie. Vous en trouverez plusieurs. Aucune n’est publiée par un éditeur.
Ce qu’Apple documente, et c’est le seul
La source la plus précise qui existe sur le sujet est une session technique d’Apple de 2019, consacrée au mode sombre dans les contenus web. Elle traite explicitement du courrier.
Pour les messages simples, Apple applique une transformation automatique :
« Simple email messages composed directly in mail on iOS 13 are ready to go in both light and dark appearances even if they include in-line image attachments […] because of mail’s auto darkening transformations. »
Pour les emails marketing, c’est l’inverse, et la phrase est décisive :
« If you are an email template designer creating designs for a campaign that includes remotely loaded images, you will need to adopt the same styling techniques I covered earlier for web content. Without adopting the color scheme property mail will display your email message in the light appearance and will not employ any auto darkening transformations that simple email messages receive. »
Autrement dit : un email marketing avec des images distantes est rendu en mode clair par défaut, même sur un appareil en mode sombre. Aucune transformation automatique ne s’y applique.
Le récapitulatif de la session le dit une seconde fois : « rich email messages with remote images like custom email marketing campaigns will use the light color scheme by default. You can declare support for the dark color scheme in your marketing email messages and use the media query for custom color and image customizations. »
Vous devez déclarer votre prise en charge. Sans déclaration, pas de mode sombre chez Apple, et donc pas d’accident non plus.
Comment on déclare
Deux mécanismes, et il faut les deux.
La propriété CSS color-scheme, posée sur l’élément racine, annonce que le document sait vivre dans les deux apparences. Apple le formule ainsi : « Specifying the values light and dark on the root element lets the rendering engine know both modes are supported by the document. »
La requête média prefers-color-scheme permet ensuite d’écrire les règles spécifiques. Sa définition est donnée par le brouillon de travail Media Queries Level 5 du W3C :
« The prefers-color-scheme media feature reflects the user’s desire that the page use a light or dark color theme. »
Une précision de statut s’impose, parce qu’elle est presque toujours passée sous silence : Media Queries Level 5 est un Working Draft, daté du 19 février 2026. Pas une recommandation du W3C. Parler d’un standard établi serait inexact.
Le document donne d’ailleurs un conseil d’écriture que peu de gens suivent :
« The values for this feature might be expanded in the future […] As such, the most future-friendly way to use this media feature is by negation such as (prefers-color-scheme: dark) and (not (prefers-color-scheme: dark)). »
Écrire par la négation plutôt que par l’énumération. Un détail qui vous évitera une réécriture le jour où une valeur s’ajoutera.
Ce que Microsoft dit, et ce qu’il ne dit pas
La seule déclaration de Microsoft sur le sujet se trouve dans une documentation produit, et elle est d’une prudence remarquable :
« However, email rendering is controlled by each email client, like Outlook, Gmail, or Apple Mail, which may in dark mode, apply no changes, partially/fully invert colors, or override styles. »
Quatre comportements possibles, énumérés sans préciser lequel s’applique à quel client. Y compris à son propre client.
La recommandation qui suit est un aveu : « Test rendering across major clients like Outlook, Gmail, and Apple Mail, on desktop and mobile. »
Microsoft ne publie pas de spécification. Il vous demande de tester.
Quant à Google, aucune documentation officielle sur la prise en charge de prefers-color-scheme dans Gmail n’existe. Ni sur le site développeur, ni dans l’aide, ni sur le blog Workspace. Les seules traces sont des fils de forum communautaire.
Aucune source primaire trouvée. C’est le statut réel de la question, et toute matrice de compatibilité que vous consulterez repose sur des tests de prestataires, non sur des engagements d’éditeurs.
Les trois accidents classiques
Puisque personne ne publie de spécification, il faut raisonner sur les mécanismes.
Le premier accident vient de l’inversion partielle. Un client qui assombrit les fonds sans toucher aux couleurs de texte déclarées produit du texte sombre sur fond sombre. Le remède n’est pas de figer les couleurs, c’est de déclarer les deux jeux.
Le deuxième vient des logos. Un logo noir sur fond transparent devient invisible sur fond sombre. Un logo noir sur fond blanc opaque, lui, découpe un rectangle blanc au milieu de la page. Aucune des deux versions ne convient : il en faut deux, servies selon la requête média.
Le troisième vient des bordures implicites. Une zone dont la lisibilité repose sur un contraste entre deux gris très proches disparaît entièrement dès que l’un des deux gris est inversé et pas l’autre.
Ces trois accidents ont un point commun : ils rendent le message illisible sans produire la moindre erreur. Rien ne remonte, rien n’échoue, et vous ne l’apprenez que par un client.
Ce que vous faites demain matin
Regardez d’abord si le sujet vous concerne. Un email construit en texte, sur fond blanc, avec des couleurs franches et un logo qui supporte les deux fonds, traverse le mode sombre sans dommage. Ce sont les mises en page complexes qui cassent.
Si vous devez déclarer la prise en charge, faites-le complètement : la propriété color-scheme sur la racine, et un jeu de règles sous la requête média. Une déclaration à moitié faite est plus dangereuse que pas de déclaration du tout, puisqu’elle autorise le client à transformer sans que vous ayez décrit le résultat voulu.
Préparez deux versions de votre logo, et servez la seconde par la requête média. C’est le correctif qui règle le plus grand nombre de plaintes pour le moins de travail.
Et testez sur de vrais appareils, en commençant par un iPhone, parce que c’est le seul environnement dont le comportement est documenté par son éditeur. Pour les autres, vous êtes dans le domaine de l’observation, et il faut le savoir avant de promettre un rendu.
Sources
- Apple (WWDC 2019, session 511). Supporting Dark Mode in Your Web Content
- W3C (Working Draft, 19 février 2026). Media Queries Level 5, section 12.5
- Microsoft (mise à jour le 18 juin 2025). Improve email accessibility for light and dark modes, Microsoft Learn
LaFactory travaille l’emailing sur pièces : en-têtes, enregistrements DNS, journaux de rejet. Aucune promesse de taux d’ouverture, jamais. Contactez-nous pour un audit de délivrabilité.