Boutique PrestaShop sur mobile : un parcours d’achat pensé pour le téléphone

Sur un téléphone, un parcours d’achat PrestaShop se corrige champ par champ et bouton par bouton : saisie automatique déclarée, clavier adapté, zones tactiles mesurées, paiement visible, contenu équivalent à celui de l’ordinateur. Le benchmark de Contentsquare, publié en mars 2026, compte 69,9 % de trafic mobile. La conversion y est supérieure de 74 % sur ordinateur, sur l’ensemble de son échantillon.

• Dans un benchmark de 99 milliards de sessions, la conversion mobile est inférieure à celle d’ordinateur
• Le navigateur peut remplir le formulaire de commande PrestaShop quand chaque champ déclare sa nature
• Les zones tactiles et le texte se jugent à des seuils mesurés, pas à l’œil
• Le paiement sur téléphone se teste de bout en bout, sur plus d’un appareil
• Un contenu replié sur mobile reste lu par Google s’il demeure équivalent
• En France, 71,15 % des sites PrestaShop passent les Core Web Vitals sur mobile
• Le prix d’une reprise mobile suit le nombre d’écrans repris
• Quatre relevés à comparer avant et après une reprise du parcours mobile
• Sources consultées
• Foire aux questions

Dans un benchmark de 99 milliards de sessions, la conversion mobile est inférieure à celle d’ordinateur

Ce benchmark porte sur 99 milliards de sessions web et d’applications, réparties sur plus de 6 000 sites. Il ne dit rien de votre boutique : calculez votre propre écart. Prenez le taux de conversion par type d’appareil dans votre outil de mesure d’audience, divisez celui de l’ordinateur par celui du mobile, retirez 1. Avec 3 % sur ordinateur et 1,8 % sur mobile, le calcul donne 0,67, soit un écart de 67 %.

Le benchmark d’ergonomie mobile de Baymard, mis à jour le 14 juillet 2026, évalue plus de 150 grands sites marchands d’Europe et des États-Unis. Il juge « médiocres » 75 % d’entre eux, et un seul atteint le niveau « bon ».

Le navigateur peut remplir le formulaire de commande PrestaShop quand chaque champ déclare sa nature

Un champ qui déclare sa nature à l’aide de l’attribut autocomplete peut être rempli par le navigateur, et son type fait apparaître le bon clavier. Le tableau reprend les valeurs de l’article web.dev sur les formulaires de paiement et d’adresse, mis à jour le 9 décembre 2020, avec la graphie address-line1 du standard HTML, que l’article écrit address-line-1.

L’article déconseille quatre pratiques. Le type number pour une carte ou un téléphone. Un numéro de carte découpé en plusieurs champs. Une liste déroulante sur mesure pour la date d’expiration, qui peut casser la saisie automatique. Un texte indicatif (placeholder) à la place d’une étiquette. Il met aussi en garde contre le champ « adresse ligne 2 », qui peut poser problème aux utilisateurs.

Inspectez chaque champ de votre formulaire avec les outils du navigateur : l’attribut est présent ou absent. Une retouche passe par les gabarits du thème, dont la page « Validation » de la documentation de PrestaShop 9 exige ceux de commande et de compte client (voir la refonte du thème).

Dans ce benchmark, Baymard relève que 93 % des sites évalués n’emploient pas de messages adaptatifs pour les erreurs de validation. Il relève aussi que 54 % n’ont ni validateur ni recherche d’adresse.

Les zones tactiles et le texte se jugent à des seuils mesurés, pas à l’œil

Le critère 2.5.8 des règles d’accessibilité WCAG 2.2, de niveau AA (intermédiaire), fixe une cible d’au moins 24 sur 24 pixels CSS. Il admet notamment une cible plus petite si un cercle de 24 pixels de diamètre centré sur elle ne rencontre ni une autre cible ni le cercle d’une autre cible trop petite. Le critère 2.5.5, de niveau AAA (le plus exigeant), monte à 44 sur 44. Mesurez dans le navigateur la croix de suppression du panier, les boutons plus et moins de la quantité, le choix du transporteur et le bouton d’ajout au panier.

Pour le texte, la page « Accessibility » de la documentation des thèmes de PrestaShop 9 fixe 14 pixels au minimum pour le texte courant. Elle demande un contraste de 4,5 pour 1 sous 18 pixels (14 en gras), et de 3 pour 1 à partir de ces tailles. Vérifiez les prix, les frais de port et les mentions de livraison, que le visiteur lit avant de payer.

Décrire mon besoin →

Le paiement sur téléphone se teste de bout en bout, sur plus d’un appareil

L’article web.dev sur les formulaires de connexion cite un bouton masqué par le clavier sur un iPhone 7 et un iPhone 8, et visible sur un iPhone 11. Essayez la commande complète sur un téléphone récent et sur un ancien, clavier ouvert, jusqu’au paiement en mode de test du prestataire.

Un bouton de paiement en un geste, sur le modèle des portefeuilles du téléphone, dépend du module de paiement. MDN classe l’API de paiement des navigateurs (Payment Request API) en disponibilité limitée : elle ne fonctionne pas dans certains des navigateurs les plus utilisés. Lisez la fiche du module pour savoir quels navigateurs et quels appareils il prend en charge. Le parcours du panier au paiement se traite dans la mission tunnel de commande.

Un contenu replié sur mobile reste lu par Google s’il demeure équivalent

Google indexe et classe un site d’après sa version mobile, explorée par son robot pour smartphone. Sa documentation admet des onglets et des accordéons pour gagner de la place, à condition que le contenu reste équivalent à celui de l’ordinateur.

Trois consignes en découlent. Ne chargez pas le contenu principal après une interaction du visiteur. Gardez les mêmes balises robots (qui autorisent ou non l’indexation), le même titre et la même description. Reportez les mêmes données structurées, en priorité Breadcrumb, Product et VideoObject.

En France, 71,15 % des sites PrestaShop passent les Core Web Vitals sur mobile

HTTP Archive relève ce taux au 1er août 2026 sur 12 427 sites PrestaShop mesurés en France. Les seuils, les trois indicateurs et leurs causes se lisent dans la mission Core Web Vitals.

Le prix d’une reprise mobile suit le nombre d’écrans repris

Le prix suit le nombre d’écrans repris : fiche produit, liste, panier, commande, compte. Il suit aussi les modules qui ajoutent leur propre interface (avis, consentement, chat, promotions). Le module de paiement compte, car le prestataire ne le contrôle qu’en partie. Le nombre d’appareils d’essai et la base du thème, enfant ou copie, pèsent enfin.

Faites écrire qui corrige un module de paiement qui cesse de s’afficher après la reprise, et que les essais de paiement précèdent la bascule.

Quatre relevés à comparer avant et après une reprise du parcours mobile

• les taux de conversion par appareil avant et après, sur des périodes comparables ;
• la liste des attributs posés sur chaque champ du formulaire ;
• les cibles tactiles mesurées, en pixels CSS ;
• le compte rendu des essais de paiement, par appareil et par navigateur.

Le message du formulaire de cette page peut indiquer l’écart de conversion entre mobile et ordinateur, le thème actif et la version de PrestaShop.

Décrire mon besoin →

Sources consultées

• Contentsquare, « Digital Experience Benchmark », pages « Conversions » et « Traffic », consulté le 14 octobre 2026.
• Baymard Institute, « Mobile UX in e-commerce », mis à jour le 14 juillet 2026, consulté le 14 octobre 2026.
• web.dev, « Payment and address form best practices » et « Sign-in form best practices », consulté le 14 octobre 2026.
• W3C, WCAG 2.2, pages « Understanding » des critères 2.5.8 (Target Size (Minimum)) et 2.5.5 (Target Size (Enhanced)), consulté le 14 octobre 2026.
• Google Search Central, « Mobile site and mobile-first indexing best practices », consulté le 14 octobre 2026.
• Google Search Central, « Understanding page experience in Google Search results », consulté le 14 octobre 2026.
• MDN Web Docs, « Payment Request API », consulté le 14 octobre 2026.
• HTTP Archive, relevé CWV de la technologie PrestaShop en France au 1er août 2026, consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « Validation » et « Accessibility », consulté le 14 octobre 2026.
• PrestaShop, guide utilisateur de la version 8, « Préférences des commandes » en français, « Orders preferences » en anglais, consulté le 14 octobre 2026.
• WHATWG, HTML Standard, section sur le remplissage automatique des champs de formulaire (attribut autocomplete), consulté le 14 octobre 2026.

Foire aux questions

Un thème responsive suffit-il pour vendre sur téléphone ?

Non. Il sert un contenu et des métadonnées identiques sur mobile et sur ordinateur, ce que Google décrit pour le responsive design. Il ne garantit ni un clavier adapté à chaque champ, ni des zones tactiles assez grandes, ni un bouton de paiement visible. Ces points se vérifient sur la boutique, appareil en main.

Une fenêtre surgissante nuit-elle au référencement ?

Pas directement. Google range l’absence d’interstitiels intrusifs parmi les aspects de l’expérience de page et précise que, hors Core Web Vitals, ces aspects n’aident pas directement un site à mieux se classer. Un bandeau qui masque le bouton d’achat pénalise d’abord le visiteur : vérifiez-le sur téléphone, avec les modules activés tels que le client les voit.

Les paiements en un geste conviennent-ils à une boutique PrestaShop ?

Cela dépend du module de paiement et des navigateurs de vos visiteurs, l’API de paiement n’étant pas disponible partout (voir plus haut). Demandez au prestataire de paiement quels appareils et quels navigateurs sont pris en charge, puis vérifiez-le par une commande en mode test.

Que mesurer pour juger le parcours mobile ?

Les quatre relevés de la section précédente, complétés par l’abandon à chaque étape de la commande. Une seule semaine de mesure mélange l’effet des retouches et celui des promotions.