Création site e-commerce : thème Shopify ou design sur mesure ?

Pour la plupart des petites boutiques suisses, la création d'un site e-commerce se résume vite à une seule décision de départ : partir d'un thème Shopify prêt à l'emploi, ou commander un design sur mesure. Les données sur le marché des thèmes et sur la performance des plateformes donnent une réponse moins tranchée que les conseils habituels — « investissez toujours dans un design sur mesure » d'un côté, « un thème suffit à tout le monde » de l'autre : un thème est un point de départ raisonnable pour la plupart des petites boutiques, et un design sur mesure commence à se justifier dès qu'un thème bloque réellement un processus métier précis ou une mesure de performance vérifiable. Cet article se limite au design et à la structure de la page — le droit suisse, le choix de la plateforme, le coût et le SEO ont déjà leurs propres articles plus détaillés sur ce site, vers lesquels nous renvoyons plutôt que de les répéter.

Création d'un site e-commerce : ce qui doit exister quel que soit le design

Avant de toucher à la mise en page de l'accueil, trois éléments doivent exister quel que soit l'aspect de la boutique :

• Conditions générales de vente — elles ne lient le client que s'il a pu en prendre connaissance avant de commander : placez le lien juste à côté du bouton de commande. Leur contenu a aussi une limite : la loi fédérale contre la concurrence déloyale (LCD, art. 8) interdit les clauses qui créent, au détriment du consommateur, une disproportion notable et injustifiée entre les droits et les obligations des parties.
• Informations autour de la commande — la même loi (LCD, art. 3 al. 1 let. s, en vigueur depuis le 1er avril 2012) oblige quiconque vend par voie électronique à indiquer de manière claire et complète son identité et son adresse de contact, y compris l'adresse e-mail, à décrire les étapes techniques menant à la conclusion du contrat, à fournir les moyens de détecter et de corriger les erreurs de saisie avant l'envoi de la commande, et à confirmer sans délai la commande du client par courrier électronique. Pour les produits physiques, les vendeurs européens s'appuient sur le GPSR pour une obligation d'information de sécurité dédiée ; si le droit suisse de la sécurité des produits (la loi sur la sécurité des produits, LSPro) impose une obligation équivalente pour la vente à distance n'a pas pu être confirmé dans le cadre de cette recherche — traitez-le comme une question ouverte à vérifier juridiquement, pas comme un fait établi.
• Une page sur les retours — en Suisse, il n'existe aucun droit légal de retourner une commande en ligne (voir plus bas), donc cette page relève de votre propre politique volontaire plutôt que d'un minimum légal : retours et garantie en Suisse en détaille le mécanisme. Il suffit ici que cette page existe et soit facile à trouver depuis le pied de page.

Il reste une page qu'on oublie facilement en concevant un site : une politique de confidentialité et de cookies, distincte des conditions générales, parce que la loi fédérale révisée sur la protection des données (nLPD, RS 235.1, en vigueur depuis le 1er septembre 2023) impose d'informer les personnes des données collectées et de leur finalité — que la boutique collecte des données uniquement pour traiter les commandes ou aussi pour l'analytique et le marketing. Son contenu exact dépend des technologies de suivi réellement activées (Consent Mode, pixels publicitaires) — un sujet pour un article à part, pas pour celui-ci.

Nous couvrons l'ensemble des obligations à remplir pour créer une boutique en ligne en Suisse dans notre guide créer une boutique en ligne — cet article y renvoie plutôt que de répéter les mêmes obligations. La fiche produit elle-même a son propre ensemble d'obligations (identification du produit, photos, prix pendant les promotions), que nous détaillons dans notre article sur la fiche produit.

Thème : ce qu'il apporte, et où sont ses limites

Un thème prêt à l'emploi résout en quelques minutes ce qu'un développement sur mesure met des semaines à faire : la mise en page de l'accueil, les fiches produit, le panier et le checkout, la réactivité, l'accessibilité de base. Le Shopify Theme Store propose sa propre collection de thèmes gratuits à parcourir (24 le jour de la consultation), et ses 1 278 thèmes payants coûtaient de 100 à 500 USD (consulté le 6 octobre 2026) — affichés en USD sur le Theme Store lui-même, contrairement à la page de tarifs principale de Shopify, qui ajuste les prix selon la localisation du visiteur. C'est une lecture ponctuelle d'une place de marché vivante, pas un tarif officiel annoncé par Shopify, car l'assortiment et les prix d'une telle place de marché changent en permanence. WooCommerce et PrestaShop fonctionnent sur le même mécanisme — thèmes gratuits dans le dépôt propre à la plateforme, thèmes payants sur des places de marché séparées — mais une fourchette de prix actuelle et précise pour ces deux plateformes ne faisait pas partie de cette recherche, donc nous ne donnons pas de chiffre pour elles ici.

La limite du thème est fonctionnelle, pas seulement visuelle : un bon thème gère un processus d'achat typique, mais si votre boutique en a un atypique — un configurateur de produit, un modèle B2B complexe avec des prix par client, une intégration que le thème n'a jamais anticipée — c'est précisément là que le thème commence à gêner plutôt qu'à aider. Ce que coûte l'ensemble de la boutique, pas seulement le thème, est détaillé dans notre article sur le prix d'un site e-commerce, et les plateformes et leurs tarifs sont mis côte à côte dans notre comparatif des plateformes e-commerce — si vous n'avez pas encore choisi de plateforme, commencez par là, pas ici.

Thème et performance : la dette technique qu'on ne voit pas

Un thème universel doit servir des boutiques très différentes à la fois, donc il peut faire tourner en même temps un éditeur visuel, une couche de compatibilité avec d'anciennes versions et de la place pour un nombre quelconque d'applications tierces — c'est le mécanisme par lequel un thème peut nuire aux Core Web Vitals, au LCP en particulier, avant même que vous ajoutiez votre propre contenu. Le HTTP Archive Web Almanac 2025 (chapitre « Ecommerce », données de juillet 2025, publication janvier 2026) mesure la part de sites avec un « bon » résultat Core Web Vitals — LCP, INP et CLS tous validés au 75e percentile — par plateforme : Shopify 76 % sur mobile et 76 % sur desktop, PrestaShop 50 % sur mobile et 54 % sur desktop, WooCommerce 35 % sur mobile et 33 % sur desktop. Le chapitre qualifie le LCP de « facteur le plus différenciant » entre plateformes, et c'est justement là que WooCommerce peine (45 % de bons résultats sur desktop, 39 % sur mobile), alors que l'INP et le CLS s'en sortent mieux (88 % et 85 % de bons résultats sur mobile ; sur desktop, INP 99 % mais CLS seulement 68 %).

À garder à l'esprit avec ces chiffres : ce sont des données globales, au niveau de la plateforme — tous les sites détectés sur un moteur donné, sans aucune ventilation par pays, Suisse comprise — pas une évaluation d'un thème ou d'une installation précise. Une boutique WooCommerce bien configurée, débarrassée des extensions inutiles, peut obtenir un meilleur score que la moyenne de sa plateforme, et une boutique Shopify négligée, chargée de dizaines d'applications, peut faire moins bien. Les chiffres montrent un écart entre plateformes, pas sa cause dans une boutique précise — « plus il y a de scripts et d'extensions non consolidés sur une page, plus il est difficile d'obtenir un bon LCP » est notre lecture du mécanisme, pas un résultat mesuré, et ce n'est un verdict sur aucune plateforme en particulier.

L'édition précédente de ce même chapitre du Web Almanac montre qu'un mauvais score de plateforme n'est pas un verdict définitif — c'est un état qui change d'une édition à l'autre. L'édition 2024 (données antérieures, publiée le 11.11.2024) relevait pour WooCommerce un résultat LCP de « seulement 34 % » sur mobile — plus bas, même, que les 39 % de l'édition 2025 — mais sur la même période d'autres plateformes ont nettement progressé (données mobile) : Tiendanube est passée de 28 % de bons résultats LCP en 2022 à 61 % en 2024, et Squarespace de 33 % à 60 % de sites avec un bon résultat Core Web Vitals global sur la même période. La conclusion pratique : la performance d'un thème n'est pas une caractéristique figée d'un moteur pour toujours — un mauvais score LCP il y a deux ans ne signifie pas un mauvais score aujourd'hui, et l'inverse est vrai aussi.

Si le thème bloque un processus ou une mesure de performance que vous vérifiez avec notre test de vitesse de site web, et que les corrections à l'intérieur du thème ne suffisent plus, l'étape suivante n'est généralement pas « un autre thème », mais une autre architecture — voir la section suivante.

Design sur mesure : quand ça se justifie

Un développement sur mesure a du sens quand un processus précis ou une métrique de performance précise compte plus que la rapidité du lancement — pas comme choix par défaut « parce que c'est plus joli ». C'est une décision qui coûte plus de temps et de travail que de configurer un thème, donc elle se prend sur la base d'une contrainte précise et nommée (ce configurateur ne fonctionne pas, cette intégration n'existe pas, ce résultat Core Web Vitals ne s'améliore pas malgré l'optimisation), pas sur une impression générale que « le thème a l'air trop générique ».

La forme la plus radicale d'un design sur mesure est le headless — découpler le front-end (construit, par exemple, sur Next.js) du moteur de la plateforme e-commerce, qui devient alors un simple backend de données et de commandes. Cette architecture donne un contrôle total sur ce qui arrive réellement dans le navigateur — donc sur la performance — au prix de certaines choses qu'un thème offrait gratuitement : des intégrations prêtes à l'emploi avec les applications de la boutique d'applications de la plateforme, des mises à jour de sécurité gérées par l'éditeur du moteur, et une mise en place simple pour qui n'a pas sa propre équipe de développement. Ce compromis — contrôle total au prix de la commodité et de la maintenance gérée par le fournisseur — est la raison pratique pour laquelle le headless ne se justifie qu'une fois qu'un thème ne suit plus réellement, pas comme montée en gamme par défaut. Quand cette étape se justifie et quand elle est disproportionnée, nous le traitons à part dans notre article sur l'e-commerce headless ; comment mesurer et améliorer les Core Web Vitals eux-mêmes — que vous restiez sur un thème ou passiez au headless — est expliqué dans Core Web Vitals d'une boutique en ligne.

Structure de la page d'accueil et de la navigation

Que la page soit construite par un thème ou un projet sur mesure, quelques éléments structurels valent la peine d'exister dans chaque boutique, parce qu'ils découlent de la logique du parcours d'achat, pas de la mode :

• Une proposition de valeur visible sans défiler — le client doit savoir immédiatement ce qu'il achète et chez qui, sans avoir à faire défiler la page d'accueil.
• Une navigation par catégories visible — une structure de catégories stable et prévisible, accessible depuis chaque sous-page, pas seulement depuis l'accueil.
• Un champ de recherche visible — placé à un endroit fixe et évident de l'en-tête ; ce que doit faire le moteur de recherche lui-même et comment le mesurer, nous le détaillons dans notre article sur le moteur de recherche e-commerce.
• Des signaux de confiance près du haut de la page — informations sur le paiement sécurisé (TWINT, cartes), la politique de retour et des avis clients réels, pas cachés tout en bas.
• Un pied de page avec les liens légaux — conditions générales, politique de confidentialité, coordonnées de contact et page de retours, toujours au même endroit prévisible.

Cet ensemble de sources n'a pas fait apparaître d'étude UX précise et nommée sur la navigation de la page d'accueil des boutiques en ligne — la liste ci-dessus décrit un mécanisme, pas une citation d'étude, et elle vaut mieux comme point de départ pour vos propres tests d'utilisabilité que comme benchmark fermé et vérifié. En pratique, aucun de ces points n'est propre à un seul type de projet — un thème et un projet sur mesure livrent la même liste, seulement avec un coût de modification différent : dans un thème on réordonne les sections via l'éditeur de thème, dans un projet sur mesure via le code — mais la liste des exigences elle-même ne change pas. Si la page a aussi des filtres et des listes de produits, leur UX et leur effet sur le SEO (la navigation à facettes en particulier) sont un sujet à part — côté UX dans notre article sur le moteur de recherche e-commerce, côté SEO technique dans notre article sur le référencement e-commerce.

Mobile ou desktop — deux mesures distinctes, pas une seule

Deux mesures mobiles différentes parlent de deux choses différentes, et ne devraient pas être additionnées. StatCounter pour la Suisse, septembre 2026 : desktop 51,69 %, mobile 46,64 %, tablette 1,68 % des pages vues dans le panel propre à StatCounter (consulté le 5 octobre 2026) — c'est du trafic de navigation en général, pas spécifiquement d'achat, et ce n'est pas un recensement de la population complète, seulement les données du panel d'une seule entreprise.

Un second type de mesure — sur quel appareil quelqu'un finalise réellement un achat, par opposition à l'appareil sur lequel il navigue en général — pose une question différente sur un échantillon différent. Nous n'avons pas de chiffre suisse confirmé pour cela dans le cadre de cette recherche, donc nous ne mettons pas de chiffre à côté ici. La conclusion pratique tient malgré ce chiffre manquant : la boutique doit bien fonctionner sur le téléphone comme sur l'ordinateur, et « bien » ne veut pas dire « de façon identique » — il est utile de tester le checkout et les formulaires spécifiquement sur téléphone, étant donné la part déjà importante de la navigation qui s'y déroule.

Accessibilité d'un thème — contrôles de base

La Suisse n'est pas liée par l'European Accessibility Act de l'UE, et cette recherche n'a pas pu confirmer si, ni dans quelle mesure, la loi suisse sur l'égalité pour les personnes handicapées (LHand) impose une obligation d'accessibilité numérique contraignante à une boutique en ligne privée, ni quel serait le délai ou l'autorité de surveillance d'une telle obligation — traitez cela comme une question juridique ouverte, pas tranchée, et vérifiez-la séparément avant de publier une affirmation précise (le hub UX e-commerce couvre les autres sujets de cette rubrique). Ce qui n'est pas en question, c'est que l'accessibilité reste une bonne pratique et une mesure de réduction de risque indépendamment du cadre légal, les WCAG 2.2 faisant office de standard technique de facto que la plupart des auditeurs et outils vérifient. Voici seulement la liste des contrôles de base à faire sur le thème lui-même, avant de passer à un audit d'accessibilité complet. Entre parenthèses figurent les critères de succès correspondants des WCAG 2.2 (recommandation du W3C du 12 décembre 2024). Un contenu conforme aux WCAG 2.2 est aussi conforme aux WCAG 2.0 et 2.1 — l'inverse n'est pas vrai.

• Le contraste du texte — au moins 4,5:1 pour le texte normal et 3:1 pour le texte de grande taille (1.4.3), en particulier dans les variantes de couleur du thème que l'auteur du thème n'a jamais testées pour cela.
• Un HTML sémantique — des titres dans une hiérarchie logique, des boutons en <button>, pas des <div> avec un gestionnaire de clic (1.3.1, 4.1.2).
• Un texte alternatif (alt) sur les photos de produits, pas seulement sur l'image principale de la boutique (1.1.1).
• Une navigation complète au clavier — on peut parcourir la navigation, les filtres et le formulaire de commande sans souris (2.1.1).
• Un état de focus visible sur les liens, boutons et champs de formulaire, pour qu'une personne naviguant au clavier voie où elle se trouve (2.4.7).
• Des étiquettes de champ — un label associé à chaque champ du formulaire de commande, pas seulement un texte indicatif qui disparaît dès qu'on clique dans le champ (3.3.2).
• La taille des cibles tactiles — au moins 24 × 24 pixels CSS, ou un espacement suffisant autour des cibles plus petites (2.5.8), ce qui compte pour les boutons de variante et de quantité sur mobile.

Comment choisir — check-list

• Vous avez vérifié qu'un thème typique prêt à l'emploi gère vraiment votre processus de vente (configurateurs, prix B2B, intégrations atypiques), au lieu de supposer qu'il « s'adaptera d'une manière ou d'une autre ».
• Vous avez des conditions générales, les informations requises autour de la commande et une page de retours visibles depuis chaque sous-page, pas seulement l'accueil.
• Vous avez mesuré les Core Web Vitals de votre installation précise de thème (pas la moyenne de la plateforme) avant de décider de passer à un design sur mesure.
• Vous avez testé le checkout et les formulaires réellement sur téléphone, pas seulement en redimensionnant une fenêtre de navigateur sur ordinateur.
• La navigation, la recherche et les signaux de confiance sont visibles sans défiler, et le pied de page a l'ensemble complet des liens légaux.
• Vous avez passé en revue les contrôles d'accessibilité de base ci-dessus avant de décider qu'un thème « suffit ».

Si vous préférez prendre cette décision avec quelqu'un qui évaluera votre thème précis et votre installation précise, pas seulement une moyenne de plateforme, parlons-en — c'est aussi l'un des points de la check-list UX d'une boutique en ligne.