En 2026, le mode sombre n’est plus une fonctionnalité « gadget pour développeurs ». Les études d’usage montrent que 60 à 80 % des utilisateurs activent le mode sombre sur leur OS au moins une partie de la journée — iOS bascule automatiquement le soir avec True Tone, macOS et Windows ont leurs réglages de luminosité automatique, les power-users le gardent activé en permanence pour réduire la fatigue oculaire. Une boutique qui n’offre pas de mode sombre ne correspond plus aux attentes UX 2026, et envoie à ses visiteurs un flash blanc agressif à chaque chargement de page — particulièrement pénible le soir et sur mobile.
Shopware 6.7 ne propose pas de mode sombre natif côté storefront. Cette absence n’est pas anodine : l’implémentation propre demande de gérer plusieurs sujets techniques (anti-FOUC, persistance cross-devices, compatibilité Bootstrap, synchronisation avec d’autres composants) qui sont rarement bien faits sans plugin dédié. Ce guide détaille comment implémenter un dark mode complet et performant sur Shopware 6.7, avec les pièges techniques à éviter.
Pourquoi le dark mode est devenu un standard UX en 2026
Trois forces ont fait du dark mode une attente plutôt qu’un bonus.
L’usage OS s’est généralisé. Depuis iOS 13 (2019) et macOS Mojave (2018), le dark mode système a basculé de niche à mainstream. Les statistiques 2025 indiquent que 80 % des utilisateurs iOS et 65 % des utilisateurs Android ont activé le dark mode au moins occasionnellement, et 35 % le gardent en permanence. Sur desktop, c’est un peu moins (40-50 %), mais en croissance constante.
La fatigue visuelle est un sujet santé reconnu. Plusieurs études (notamment celles publiées par l’American Academy of Ophthalmology) ont documenté l’impact du blanc lumineux nocturne sur la qualité du sommeil et la fatigue oculaire. Le mode sombre n’est plus une préférence esthétique — c’est une pratique de confort intégrée dans les routines digitales des utilisateurs sensibles à ces sujets.
Les attentes UX se sont alignées. Les grandes plateformes (Twitter/X, Reddit, GitHub, Notion, Linear, Slack, Discord) proposent toutes un dark mode polished. Les utilisateurs s’habituent à pouvoir basculer en sombre sur n’importe quelle interface et perçoivent négativement les sites qui ne suivent pas. Pour une boutique e-commerce, c’est un signal qualité subtil mais réel — particulièrement sur les segments tech/créatif/jeune où le dark mode est presque une norme tribale.
Le retard pris par Shopware sur ce point n’est pas critique en absolu (la plateforme reste solide sur ses fondamentaux), mais elle laisse les boutiques sur une absence de fonctionnalité que les marchands modernes attendent. Combler cette absence proprement, c’est gagner sur trois axes : confort utilisateur, signal qualité perçue, et reconnaissance auprès des audiences sensibles à l’UX moderne.
Le piège du flash blanc (FOUC) — pourquoi c’est éliminatoire en UX
FOUC veut dire « Flash of Unstyled Content » — appliqué au dark mode, c’est le bref flash blanc visible avant que le JavaScript dark mode ne s’exécute et applique le thème sombre. Sur un visiteur qui a configuré son OS en dark, ce flash dure typiquement 100 à 400 millisecondes au premier chargement de page : juste le temps qu’un humain a pour percevoir l’incohérence visuelle.
Pourquoi c’est éliminatoire :
Cognitivement, le flash signale une erreur. Le cerveau humain interprète les changements visuels brusques comme des anomalies. Une page qui démarre en blanc puis bascule en sombre apparaît défaillante — même si le résultat final est correct. C’est l’inverse de ce qu’on cherche en UX premium.
Sur mobile, c’est physiquement désagréable. En usage nocturne (le moment où le dark mode a le plus d’utilité), le flash de 300 ms à pleine luminosité blanche est ressenti comme une agression visuelle. Les utilisateurs perçoivent le site comme « pas sérieux » et ferment souvent l’onglet sans plus de raison consciente.
Côté Core Web Vitals, ça abîme le LCP perçu. Le LCP (Largest Contentful Paint) mesure le moment où le plus grand élément visible est rendu. Si votre LCP est à 1,8 s mais que le flash blanc dure 300 ms additionnel, l’utilisateur perçoit en réalité 2,1 s de chargement, et son sentiment de qualité du site se dégrade.
La cause technique du FOUC est connue : la majorité des plugins dark mode appliquent le thème via JavaScript dans DOMContentLoaded — événement qui se déclenche après le premier paint du navigateur. Donc l’ordre est : (1) le HTML est rendu en mode clair par défaut, (2) le navigateur fait son premier paint, (3) le DOMContentLoaded se déclenche, (4) le JS applique le thème sombre, (5) le navigateur re-paint. Entre 2 et 5, c’est le flash blanc.
La solution est tout aussi connue : injecter un script inline minimaliste directement dans la balise head, qui lit le cookie de préférence (synchrone, ~10 lignes de JS) et pose l’attribut data-bs-theme sur l’élément racine de la page avant le premier paint du navigateur. Mais cette solution est rarement implémentée correctement sur Shopware parce qu’elle exige de modifier le base layout Twig avec un script inline — ce que peu de développeurs font naturellement.
Architecture d’un dark mode propre sur Shopware 6.7
Un dark mode complet et performant repose sur cinq composants qui doivent travailler ensemble.
Une convention CSS supportée par votre thème. Bootstrap 5.3 a introduit data-bs-theme="dark" comme convention standard, et la plupart des thèmes Shopware 6.7+ basés sur Bootstrap suivent cette convention. Les thèmes plus anciens ou les thèmes custom peuvent utiliser une classe .dark sur html ou body. Avant tout, vérifiez quelle convention votre thème utilise — c’est ce qui détermine où le mode sombre sera appliqué.
Un script anti-FOUC en début de balise head. Ce script lit la préférence du visiteur (cookie ou détection navigateur) et applique l’attribut data-bs-theme avant le premier paint. C’est le seul composant non-négociable d’une implémentation propre.
Un toggle dans le header. Bouton ou switch que l’utilisateur peut activer pour basculer entre Auto (suit le navigateur), Clair (forcé), Sombre (forcé). Le pattern 3 états est devenu standard en 2026 — pas seulement Light/Dark, mais aussi Auto pour respecter le choix OS de l’utilisateur sans avoir à recliquer chaque fois.
Une persistance par cookie. Pour que le choix persiste entre sessions, il faut un cookie navigateur (typiquement 1 an de durée, SameSite=Lax). Sans cookie, le visiteur revient toujours en mode Auto à chaque visite — ce qui annule l’intérêt de l’avoir réglé manuellement.
Une persistance customer pour les connectés. Pour les clients qui se connectent à leur compte Shopware, la préférence doit être stockée côté serveur (custom field customer) afin d’être retrouvée sur n’importe quel appareil. Sans ça, un client qui règle son mode sombre sur son téléphone arrive sur son ordinateur et redécouvre le mode clair par défaut.
L’orchestration : au login, on synchronise le cookie avec le custom field customer (cookie écrit à la valeur du customer s’il a un choix enregistré). À chaque changement via le toggle, on met à jour le cookie ET on écrit dans le custom field si l’utilisateur est connecté. Le résultat est un mode sombre « cross-devices » qui suit le client partout.
Implémentation step-by-step dans le storefront Shopware 6.7
L’implémentation suit cinq étapes ordonnées.
Étape 1 — Vérifier la convention CSS de votre thème. Inspectez votre theme/Resources/app/storefront/src/scss/ pour repérer si votre thème utilise [data-bs-theme="dark"] ou une autre convention. Si Bootstrap 5.3+ est en usage (ce qui est le cas pour les thèmes Shopware 6.6+), vous devriez trouver des règles dark via cette convention. Si non, vous devrez ajouter vos propres styles dark sous le sélecteur que vous choisirez.
Étape 2 — Ajouter le script anti-FOUC dans le base layout. Override base.html.twig dans votre thème pour ajouter, dans le block correspondant à la balise head, un script inline qui lit le cookie df-dark-mode et applique l’attribut. Le script doit être placé le plus haut possible dans la balise head, idéalement avant tout autre script ou stylesheet, pour s’exécuter avant le premier paint.
Étape 3 — Créer le composant toggle. Un composant Twig simple dark-mode-toggle.html.twig avec un bouton qui cycle entre les 3 états. L’inclure dans le block base_header_actions_wishlist du base layout, ou dans un autre block selon votre design. Le toggle doit afficher une icône représentative de l’état courant (lune pour sombre, soleil pour clair, demi-lune ou icône composite pour auto).
Étape 4 — Implémenter la logique JavaScript. Un plugin JS storefront (dark-mode-toggle.plugin.js) qui : (a) écoute les clics sur le toggle, (b) calcule le nouvel état, (c) écrit le cookie, (d) met à jour l’attribut data-bs-theme, (e) émet un événement custom df-dark-mode-changed pour que d’autres composants puissent réagir, (f) si l’utilisateur est connecté, envoie un POST vers une route Shopware pour mettre à jour le custom field customer.
Étape 5 — Plugin PHP pour le custom field customer et la route AJAX. Un plugin Shopware 6.7 standard qui : (a) crée à l’installation le custom field df_dark_mode_preference sur l’entité customer (type Select avec 3 options), (b) expose une route AJAX /df-dark-mode/save qui valide le mode reçu et écrit le custom field, (c) hooke CustomerLoginEvent pour synchroniser le cookie au login, (d) supprime proprement le custom field à la désinstallation.
L’implémentation à la main prend une demi-journée pour un dev Shopware expérimenté, plus quelques heures de tests. C’est faisable. Mais c’est aussi typiquement le genre de fonctionnalité qu’on développe une fois et qu’on déploie sur plusieurs boutiques — d’où l’intérêt d’un plugin dédié.
C’est ce que fait notre plugin DataFirefly Dark Mode : toggle 3 états dans le header, anti-FOUC garanti via script inline, persistance par cookie pour les visiteurs et custom field customer pour les connectés, synchronisation au login, événement JS pour les intégrations tierces, snippets multilingues FR/EN/DE inclus. Installation en 3 minutes, configuration par défaut éprouvée.
Persister la préférence : cookie vs custom field customer
La persistance est le sujet où la majorité des plugins dark mode font des compromis qui dégradent l’expérience.
Approche cookie seule. Le plus simple : un cookie persiste la préférence pendant 1 an. Avantages : zéro impact sur la base de données, fonctionne sans login, immédiat. Limite : la préférence est attachée à un appareil et un navigateur. Un client qui change d’appareil ou qui navigue en privée perd son réglage.
Approche custom field customer seule. La préférence est stockée sur l’entité customer côté serveur. Avantages : retrouvée sur tous les appareils du client, durable. Limite : ne fonctionne que pour les clients connectés, et nécessite une requête serveur pour lire la valeur (donc impossible à utiliser pour l’anti-FOUC qui doit être synchrone côté navigateur).
Approche hybride (la bonne). Cookie pour l’anti-FOUC et la persistance navigateur côté client, plus custom field customer pour les utilisateurs connectés. Au changement de préférence, on écrit dans les deux. Au login, on synchronise le cookie avec la valeur du custom field. Ce design hybride combine les avantages des deux et élimine leurs limites respectives.
Le détail technique qui fait toute la différence : la synchronisation au login. Sans elle, un client qui se connecte sur un nouvel appareil verra le mode par défaut au lieu de retrouver son réglage précédent. Avec elle, l’expérience est cohérente sur tous les appareils du client. C’est un détail invisible quand ça marche bien, mais immédiatement perceptible quand ça manque.
Synchroniser le dark mode avec les autres composants de la page
Une fois le dark mode en place, certains composants tiers ont besoin de savoir quel thème est appliqué pour s’adapter. Les cas les plus fréquents : graphiques Recharts ou Chart.js, iframes externes (calendrier, vidéo embed, formulaire tiers), widgets de chat live, players audio/vidéo. Sans synchronisation, ces composants restent en mode clair sur fond sombre, ce qui produit des contrastes désagréables et casse la cohérence visuelle.
La solution propre : un événement JavaScript custom émis sur document à chaque changement de thème. Le pattern standard utilise un événement nommé df-dark-mode-changed avec un payload qui expose la préférence brute (auto/light/dark) et le thème effectivement appliqué (light/dark calculé après résolution du mode auto).
Les composants intéressés écoutent l’événement avec document.addEventListener et adaptent leur rendu en conséquence : un graphique Recharts se re-render avec une palette adaptée, une iframe externe reçoit un postMessage pour basculer son thème, un player vidéo bascule ses overlays.
Cette mécanique est propre parce qu’elle découple les composants : le plugin dark mode n’a pas à connaître les composants tiers, et inversement. L’événement custom sert d’interface neutre. Le coût d’implémentation est minimal côté plugin (un dispatchEvent à chaque changement), mais le bénéfice côté intégrations tierces est important.
Conclusion : un investissement modéré, un signal qualité fort
Le dark mode sur Shopware 6.7 n’est pas un sujet techniquement très complexe pris séparément. Mais il combine plusieurs détails (anti-FOUC, persistance cross-devices, compatibilité Bootstrap, événement de synchronisation) qui doivent tous être bien faits pour que l’expérience soit propre. Un dark mode mal fait dégrade l’UX au lieu de l’améliorer — flash blanc, préférence perdue entre appareils, conflits avec le thème, contrastes cassés sur les composants tiers.
L’investissement vaut le coup parce qu’il signale aux visiteurs que votre boutique suit les standards UX 2026, et parce qu’il bénéficie de manière particulièrement marquée aux audiences sensibles à l’UX (segments tech, créatifs, power-users). Le coût est modéré (une demi-journée de dev pour la version manuelle, 49 € pour un plugin dédié), le bénéfice est durable.
Pour aller plus loin sur les sujets connexes, parcourez nos catégories Conversion & UX et Performance & Core Web Vitals. Et pour un dark mode Shopware 6.7 prêt à déployer avec anti-FOUC garanti, persistance hybride et événement de synchronisation natif, le plugin DataFirefly Dark Mode implémente l’ensemble de cet article en quelques minutes d’installation.