Enquêtes et recherches sur Shopify et le e-commerce
Les marchands supposent qu'une vitrine lente exige d'activer de nouveaux réglages, mais le code des thèmes révèle le problème inverse : des fonctionnalités qui n'ont jamais été conçues comme des interrupteurs, si bien que la solution consiste à choisir un thème dont les chiffres Core Web Vitals de base tiennent déjà sous un trafic réel.
La plupart des marchands qui abordent le BFCM supposent que le remède à une vitrine lente se trouve dans un panneau de réglages quelque part : un interrupteur pour les animations, un bouton pour ce qui s’exécute avant l’ouverture du tiroir panier, quelque chose qu’ils peuvent désactiver dans l’éditeur de thème avant de passer à autre chose. Cet interrupteur n’existe généralement pas. Le mot apparaît peut-être dans les fichiers du thème, mais il se trouve dans une mention de licence ou une fonction JavaScript, pas dans un bloc de schéma doté d’un libellé et d’une plage de valeurs. Savoir faire la différence entre un véritable réglage et une simple occurrence fortuite du mot, voilà la vraie tâche de préparation au BFCM, et elle est plus étroite et moins souple que ne le laissent entendre la plupart des check-lists de préparation aux soldes.
Dawn, le thème de référence de Shopify, contient le mot « off » dans 78 de ses 351 fichiers à la date du commit du 2026-08-10. Cela semble faire beaucoup d’interrupteurs. Ce n’en est pas. Ces 78 fichiers incluent LICENSE.md et README.md, soit du texte juridique standard qui contient simplement le mot, ainsi que assets/animations.js et assets/base.css, qui sont des fichiers d’implémentation, pas des fichiers de réglages. Il n’existe dans le schéma de réglages de Dawn aucune section dédiée construite autour d’un contrôle d’animation activé/désactivé qu’un marchand pourrait trouver et cliquer. Si vous voulez moins de mouvement sur une page produit avant vos pics de trafic, vous ouvrez animations.js et vous modifiez la logique d’une fonction, ce qui est une tâche de développeur, pas de marchand.
Le même schéma vaut pour « before ». Le mot apparaît dans 30 des 351 fichiers de Dawn, concentré dans assets/base.css, assets/cart-disclosure-tooltip.js, assets/cart.js et assets/component-article-card.css. Là encore, il s’agit de code de style et de comportement, pas d’un réglage nommé. Un marchand qui cherche dans l’éditeur de thème quelque chose intitulé « before checkout » ou « before add to cart » ne trouvera aucun contrôle correspondant, car la présence du mot dans la base de code relève d’un hasard d’implémentation, pas d’une fonctionnalité documentée.
Horizon, le thème Shopify plus récent, affiche le mot « off » dans 138 de ses 484 fichiers, et « before » dans 77 sur 484, deux comptages supérieurs à ceux de Dawn en valeur absolue. Les fichiers sont aussi davantage centrés sur le panier : assets/anchored-popover.js, assets/cart-discount.js, assets/cart-drawer.js et assets/cart-icon.js contiennent tous « before ». Cela vous indique que les interactions panier de Horizon impliquent plus de logique conditionnelle que celles de Dawn, probablement parce que Horizon prend en charge davantage de fonctionnalités de panier d’origine. Cela ne vous dit pas qu’il existe un réglage que les marchands peuvent utiliser pour modifier ce comportement sans toucher au code. À la date du commit 8b42ace du 2026-08-31, aucune section de réglages dédiée à l’un ou l’autre de ces mots n’existe non plus dans le schéma de Horizon.
La lecture honnête de ces deux bases de code est que « désactiver quelque chose avant le BFCM » n’est une action réalisable dans l’éditeur de thème ni pour Dawn ni pour Horizon. C’est une action d’édition de code, et si votre boutique ne peut pas la mener en interne, le réglage n’existe tout simplement pas pour vous.
Puisque aucun des deux thèmes phares de Shopify n’expose le type de réglage de performance granulaire que les marchands recherchent, le levier le plus utile à l’approche d’une période de fort trafic consiste simplement à choisir un thème dont les chiffres de base sont déjà solides. Sur l’ensemble du marché, mesuré via les données terrain CrUX de juillet 2026, le thème médian valide tous les Core Web Vitals pour 85.5% des visites mobiles et 86.2% des visites desktop. Mais cette médiane masque une large dispersion.
| Appareil | Thèmes avec données suffisantes | Taux de réussite médian | Meilleur du marché | Pire du marché |
|---|---|---|---|---|
| Mobile | 247 | 85.5% | 98.6% | 46.1% |
| Desktop | 199 | 86.2% | 99.2% | 30.3% |
Un thème situé autour de 46.1% sur mobile échoue aux Core Web Vitals pour plus de la moitié de ses visiteurs réels, et aucun interrupteur d’animation ni aucune modification du tiroir panier ne comble un écart de cette ampleur. Ce sont des données terrain issues d’acheteurs réels, pas d’un test synthétique en laboratoire : elles reflètent donc de vrais appareils, de vrais réseaux et un vrai poids de page en trafic ordinaire, avant même qu’un pic BFCM n’aggrave les choses.
Les exigences du Shopify Theme Store fixent un score de performance Lighthouse moyen minimum de 60 sur les pages produit, collection et accueil d’un thème, à la fois pour desktop et pour mobile, ainsi qu’un score d’accessibilité minimum de 90 sur les mêmes pages et appareils. Un thème n’a besoin que de dépasser un score de 60 pour être référencé. Comparez cela aux taux de réussite médians réels du marché, de 85.5% sur mobile et 86.2% sur desktop, et il devient clair que l’approbation par le store est un plancher, pas une preuve d’aptitude au BFCM. Deux thèmes peuvent tous deux passer la revue du Theme Store et différer de dizaines de points dans l’expérience réelle des visiteurs.
Les prix et les notes ne tranchent pas la question non plus. Le prix médian d’un thème sur le marché est de $300, dans une fourchette de $100 à $500, et la note moyenne est de 4.53 sur 5 sur 308 thèmes, avec une médiane de 23 avis par thème. Aucun de ces chiffres n’est directement corrélé au taux de réussite aux Core Web Vitals, puisque les notes reflètent surtout la satisfaction quant au design et au support. Les thèmes de UTD figurent dans ce même classement général du marché aux côtés de tous les autres, et les marchands qui comparent les options peuvent consulter la liste complète sur themes.shopify.com/themes?q=utd, même si les faits présentés ici ne montrent pas UTD en tête sur une métrique de vitesse particulière.
Choisissez un thème selon son taux de réussite mesuré aux Core Web Vitals pour l’appareil qu’utilise réellement votre trafic, car c’est ce chiffre, et non un réglage caché, qui détermine si votre boutique tiendra sous la charge du BFCM. Si le code d’un thème ne montre aucun interrupteur dédié à ce que vous voulez désactiver, prévoyez un budget développeur pour modifier directement le fichier plutôt que de chercher un réglage qui n’a jamais été créé.
Il n'existe aucune section de réglages dédiée aux animations dans le code de Dawn à la date du commit 258f00f du 2026-08-10. Le mot « off » apparaît dans 78 de ses 351 fichiers, mais ces occurrences sont réparties entre LICENSE.md, README.md, assets/animations.js et assets/base.css, et non dans un bloc de schéma qu'un marchand pourrait basculer dans l'éditeur de thème. Si vous voulez désactiver des effets de mouvement précis, vous modifiez directement assets/animations.js, vous ne cliquez pas sur un interrupteur.
Le mot « before » apparaît dans 77 des 484 fichiers de Horizon contre 30 des 351 fichiers de Dawn, et dans Horizon ces références se trouvent dans assets/anchored-popover.js, assets/cart-discount.js, assets/cart-drawer.js et assets/cart-icon.js, tous du JavaScript lié au panier. Aucun des deux thèmes n'expose cela sous la forme d'un réglage nommé que les marchands pourraient rechercher dans settings_schema.json. L'écart de nombre de fichiers traduit davantage de code d'interaction panier dans Horizon, pas davantage de contrôle pour le marchand.
Sur 247 thèmes disposant de données mobiles suffisantes, la part médiane des visites validant tous les Core Web Vitals est de 85.5%, avec le meilleur thème du marché à 98.6% et le pire à 46.1%. Sur desktop, sur 199 thèmes disposant de suffisamment de données, la médiane est de 86.2%, le meilleur atteint 99.2% et le pire 30.3%. Tout ce qui se situe nettement sous la médiane sur l'appareil qui génère réellement le trafic de votre boutique constitue un risque réel en cas de pic, car ces données proviennent de sessions de visiteurs réelles dans CrUX pour juillet 2026, et non d'un test en laboratoire.
Passer la revue signifie que le thème a obtenu au moins 60 en performance Lighthouse sur les pages produit, collection et accueil, à la fois sur desktop et sur mobile, plus au moins 90 en accessibilité pour les mêmes pages et appareils. C'est un plancher, pas un objectif, et c'est un score de laboratoire plutôt qu'une mesure de visiteurs réels. Le taux de réussite médian réel du marché, de 85.5% sur mobile et 86.2% sur desktop, est une barre bien plus haute que le minimum Lighthouse de 60 points : l'approbation par le store à elle seule vous dit donc très peu de choses sur la préparation au BFCM.
La note moyenne du marché est de 4.53 sur 5 sur 308 thèmes, avec une médiane de 23 avis par thème, et cette note mesure la satisfaction des acheteurs quant au design et au support, pas la vitesse des pages sous charge. Les taux de réussite aux Core Web Vitals, mesurés séparément sur 247 thèmes disposant de données mobiles et 199 thèmes disposant de données desktop, vous indiquent comment le thème se comporte pour de vrais acheteurs. Un thème peut afficher une note élevée et se situer tout de même près du plancher mobile de 46.1% : vérifiez donc les deux chiffres, pas un seul.