Comment détecter les problèmes de conversion mobile dans WooCommerce

Deux faits que tout propriétaire de boutique WooCommerce solo peut voir dans son tableau de bord analytique :

• Le mobile représente 70 à 78 % de votre trafic.
• Le mobile convertit à environ 60 % du taux du bureau.

L’arithmétique : si vous avez 10 000 visites mobiles/mois qui convertissent à 1,8 % et 3 000 visites bureau/mois à 3,0 %, le mobile génère 180 commandes et le bureau 90. Le mobile est déjà votre plus gros moteur de chiffre d’affaires — mais un gain d’un point de pourcentage sur mobile vaut deux fois ce que le même gain vaudrait sur bureau.

C’est ce calcul qui fait du CRO mobile l’investissement le plus rentable pour une boutique Woo solo. Le problème, c’est que presque chaque article sur « l’optimisation mobile WooCommerce » dans les SERP est une liste de 25 tactiques. Ce qui n’aide pas quand on ne sait pas quel problème mobile est le sien.

Cet article est le diagnostic, pas la liste. Quatre problèmes mobiles classés par méthode de détection, un flux à deux onglets que vous pouvez exécuter en 5 minutes, et les cinq goulets d’étranglement mobiles étayés par la recherche, par ordre de priorité.

Ce que cet article répond

• Le ratio CR mobile/CR bureau comme point de départ du diagnostic.
• Les 4 problèmes mobiles, chacun avec sa règle de détection (sans GA4).
• L’audit mobile en 5 minutes à deux onglets, avec uniquement le rapport Appareils et le rapport Pages de Statnive.
• Les 5 goulets d’étranglement de conversion mobile étayés par la recherche, par ordre de priorité.
• Les 4 anti-modèles mobiles que les SERP recommandent toujours — et la recherche qui les réfute.

Commencez par le ratio : CR mobile ÷ CR bureau

Ouvrez vos rapports WooCommerce → Commandes. Filtrez par plage de dates (les 30 derniers jours sont raisonnables pour une boutique solo). Triez les commandes par appareil source — la plupart des thèmes WooCommerce le consignent dans les métadonnées de commande, et si ce n’est pas le cas, la fonctionnalité Order Attribution de WC 8.5+ s’en charge.

Calculez :

mobile_orders ÷ mobile_visitors = mobile_CR
desktop_orders ÷ desktop_visitors = desktop_CR
mobile_CR ÷ desktop_CR = your ratio

D’où viennent vos visiteurs ? Ouvrez Statnive → rapport Appareils. La répartition par type d’appareil vous donne mobile_visitors et desktop_visitors.

Chiffres de référence (d’après les données de référence Dynamic Yield publiées via Oberlo, octobre 2024) :

• Conversion e-commerce sur bureau : 3,85 %
• Tablette : 3,49 %
• Mobile : 2,85 %
• Mobile ÷ bureau ≈ 0,74

Certaines sources rapportent des ratios aussi bas que 0,50 à 0,55 pour le prêt-à-porter, l’électronique et la bijouterie. La bonne référence est le ratio de votre boutique comparé à son propre historique, pas un référentiel universel. Suivez le ratio chaque mois ; c’est votre indicateur le plus important de santé mobile.

Les 4 problèmes mobiles, chacun avec sa méthode de détection

Voilà le cadre de diagnostic. La plupart des articles « CRO mobile » sautent directement aux correctifs ; la vraie victoire est de savoir lequel des problèmes vous concerne.

Problème 1 — Du trafic qui n’atteint jamais le checkout

Détection : dans le rapport Appareils de Statnive, les sessions mobiles sont à moins de 15 points de pourcentage du nombre de sessions bureau, mais dans WooCommerce Analytics → Commandes, les commandes mobiles sont en dessous de 30 % du volume attendu d’après la part de trafic.

Ce qui se passe : les visiteurs mobiles arrivent, regardent peut-être une page et rebondissent — ils n’atteignent jamais /cart ni /checkout. Le tunnel fuit au sommet.

Où regarder ensuite : Statnive → Pages → Pages d’entrée, triées par Nombre d’entrées. Identifiez les pages d’entrée à dominante mobile (croisez avec le rapport Appareils). Si ces entrées ont un nombre de sorties élevé, vous avez un problème mobile en haut de tunnel — généralement une page lente, un hero non optimisé pour le mobile, ou un CTA au-dessus de la ligne de flottaison invisible sur un viewport de 375 px.

Problème 2 — Du trafic qui atteint le panier/checkout mais échoue

Détection : les visiteurs mobiles atteignent bien /checkout (visible dans votre rapport Pages) mais les commandes mobiles restent proportionnellement faibles. Le tunnel fuit en bas.

Ce qui se passe : le visiteur a mis un produit au panier, a peut-être même commencé le checkout, puis a abandonné en cours de formulaire. C’est le schéma classique de Baymard : frais de livraison supplémentaires révélés trop tard (39 % des abandons aux États-Unis), création de compte obligatoire (19 %), formulaire de checkout trop long (18 %), incompatibilité avec le moyen de paiement.

Où regarder ensuite : ouvrez /checkout sur votre boutique depuis un navigateur mobile à viewport 375 px. Parcourez-le. Comptez les champs. Chronométrez le formulaire. Comparez à la checklist mobile-checkout de Baymard.

Problème 3 — Rebond mobile sur la page produit

Détection : dans le rapport Pages de Statnive, vos meilleures pages d’entrée PDP ont des nombres de sorties élevés. Dans le rapport Appareils, le mobile est dominant. Il n’existe pas aujourd’hui de « filtre par appareil sur Pages » facile dans l’interface (solution de contournement plus bas), c’est donc une inférence à deux onglets.

Ce qui se passe : les visiteurs mobiles arrivent sur votre page produit, ne trouvent pas le bouton d’achat sans scroller, ou sont confrontés à des saccades de galerie d’images, ou attendent trop longtemps que la page se charge.

Où regarder ensuite : ouvrez votre meilleure PDP depuis un véritable appareil mobile (pas un navigateur de bureau ramené à 375 px — les vrais téléphones ont un clavier, du tactile et des bizarreries Safari ITP que l’émulation bureau masque). Chronométrez le LCP avec Google PageSpeed Insights. Vérifiez que le bouton « Ajouter au panier » est visible au-dessus de la ligne de flottaison sans scroller. Vérifiez que la galerie d’images est swipable sans saccades.

Problème 4 — Le mauvais public dès le départ

Détection : la part de trafic mobile est élevée, mais la source du trafic est un canal spécifique (souvent le social payant sur Meta) et le taux de rebond dépasse uniformément 75 % sur toutes les pages d’entrée mobiles.

Ce qui se passe : les annonces ciblent des personnes qui ne veulent pas de ce que vous vendez, ou la création publicitaire ne correspond pas à la page de destination. L’UX mobile de votre boutique est bonne ; le ciblage en amont est cassé.

Où regarder ensuite : Statnive → Sources → filtrez sur la source/médium UTM de la campagne suspecte. Comparez le rebond et la durée à la moyenne du site. Si la campagne échoue à la règle de santé du canal (rebond au-dessus de la moyenne + durée en dessous de la moyenne), le problème est la campagne, pas l’UX mobile. Voyez le playbook sur les sources de trafic pour le diagnostic complet.

L’audit mobile en 5 minutes à deux onglets

C’est le flux de travail. Pas de GA4. Pas de tableau de bord Lighthouse. Pas d’outil de heatmap. Deux onglets de navigateur et votre admin WooCommerce.

Onglet 1 — Rapport Appareils de Statnive :

• Quelle est votre part mobile dans le total des sessions ? (Devrait être 60 à 80 % pour la plupart des boutiques Woo grand public.)
• Quel est votre taux de rebond mobile par rapport à votre taux de rebond bureau ? (Calculez l’écart en points de pourcentage.)
• Quels navigateurs dominent sur mobile (Safari mobile vs Chrome Android) ?

Onglet 2 — Rapport Pages de Statnive :

• Triez par Nombre d’entrées décroissant. Ce sont aussi vos pages d’atterrissage mobiles (le mobile est majoritaire dans le trafic).
• Triez par Nombre de sorties décroissant. Notez toute page /product/, /cart/ ou /checkout dans le top 5.

Onglet 3 — WooCommerce Analytics → Commandes :

• Filtrez sur les 30 derniers jours. Notez le nombre de commandes attribuées au mobile.
• Calculez : mobile_orders ÷ (mobile_sessions de l'onglet 1) = CR mobile.
• Idem pour le bureau.
• Calculez le ratio. Comparez à la référence 0,60 à 0,75.

Règle de décision :

Ratio	Interprétation	Action
0,70+	Dans la fourchette normale	Maintenir — aucun correctif mobile urgent
0,50 à 0,69	Léger sous-rendement	Commencez par le Problème 3 (rebond mobile sur PDP)
0,30 à 0,49	Problème matériel	Exécutez les 4 détections ; généralement Problème 2 ou 4
< 0,30	Catastrophique	Probable Problème 4 (mauvais public) ET Problème 1 combinés

Cinq minutes, sans outil tiers, réponse défendable.

Mise en garde honnête : le rapport Pages ne peut pas être filtré par type d’appareil dans l’interface actuelle de Statnive — le croisement est manuel, pas automatisé. Un endpoint filtré par appareil est sur la feuille de route. D’ici là, le flux à deux onglets est le substitut opérationnel.

Les 5 goulets d’étranglement mobiles étayés par la recherche, par ordre de priorité

Une fois que vous avez identifié quel problème vous concerne, voici la file de priorité des correctifs. Chacun est ancré sur une recherche précise, pas sur des intuitions.

Goulet 1 — LCP mobile (Largest Contentful Paint) au-dessus de 2,5 secondes

Preuve : l’étude Deloitte/55/Google « Milliseconds Make Millions » (fin 2019, avant les Core Web Vitals) : une amélioration de 0,1 seconde de la vitesse mobile a produit un gain de conversion retail de 8,4 % et un gain de panier moyen de 9,2 % sur 30 millions de sessions et 37 sites de marques. L’étude précède le signal Core Web Vitals formel, mais l’effet reste largement cité.

Comment mesurer : Google PageSpeed Insights. Saisissez votre meilleure page d’entrée mobile. Notez le LCP mobile (pas bureau). Visez ≤ 2,5 secondes ; les mises à jour des seuils LCP de 2026 placent le « bon » à ≤ 2,0 secondes.

Comment corriger : optimisation des images (WebP/AVIF), lazy-loading sous la ligne de flottaison, plugin de cache serveur (WP Rocket, Cache Enabler), réduction du JavaScript sur les pages d’atterrissage.

Goulet 2 — CTA au-dessus de la ligne de flottaison invisible sur 375 px

Preuve : recherches de Baymard sur la PDP mobile — le CTA principal doit être accessible sans scroller sur un viewport de 375 px (la largeur iPhone SE / iPhone Mini). D’après la recherche du Nielsen Norman Group sur l’attention, 57 % du temps de visionnage se passe au-dessus de la ligne de flottaison sur les sites responsives modernes.

Comment mesurer : ouvrez votre meilleure PDP dans Chrome DevTools en 375×667. Voyez-vous le bouton d’achat sans scroller ? Non = problème.

Comment corriger : réduisez la hauteur de l’image hero, remontez le bloc titre-et-prix, assurez-vous que le CTA est dans la zone du pouce (en bas à droite pour un pouce droitier).

Goulet 3 — Friction de la galerie d’images produit

Preuve : corrélation Baymard : la capacité de parcourir fluidement toutes les images produit est corrélée à environ 0,6 avec le taux d’ajout au panier. Les modes de défaillance les plus courants : le zoom ne fonctionne pas, le swipe est laggy, la galerie n’affiche qu’une image sans indication qu’il en existe d’autres.

Comment mesurer : sur un vrai téléphone (pas d’émulation bureau), ouvrez une PDP. Swipez toutes les images. Essayez de zoomer. Si quelque chose bégaye ou ne fonctionne pas, corrigez-le.

Comment corriger : passez à un thème/plugin avec une galerie mobile éprouvée (Astra, Botiga, Storefront 4.x, Kadence). Testez spécifiquement sur Safari iOS.

Goulet 4 — Formulaire de checkout trop long, exigence de mot de passe, captcha

Preuve : recherches Baymard sur le tunnel de checkout : le checkout médian sur grand site comporte 14,88 champs ; descendre au minimum produit un gain de conversion de 25 à 35 % dans les contextes spécifiquement mobiles. 24 % des abandons aux États-Unis citent la création de compte obligatoire ; 19 % citent spécifiquement l’exigence de mot de passe.

Comment mesurer : comptez les champs obligatoires visibles sur /checkout en mobile. Si > 8, vous êtes au-dessus de l’optimum. Vérifiez si la création de compte est obligatoire.

Comment corriger : WooCommerce → Réglages → Comptes et confidentialité → activez « Autoriser les clients à passer commande sans compte ». Désactivez les champs optionnels (société, ligne d’adresse 2, notes de commande, souvent téléphone) dans WooCommerce → Réglages → Avancé → Compte et confidentialité. Assurez-vous que chaque champ a le bon inputmode pour que les claviers mobiles s’optimisent (numérique pour le code postal, e-mail pour l’e-mail).

Goulet 5 — Mauvais fournisseur de paiement

Preuve : la recherche de Stripe sur l’adoption d’Apple Pay suggère un gain de conversion mobile de 8 à 15 % quand Apple Pay est disponible, variable selon la catégorie et la région. D’après les données de Stripe et PayPal, les acheteurs mobiles préfèrent le paiement en un toucher à la saisie manuelle de carte.

Comment mesurer : ouvrez /checkout sur iPhone. Y a-t-il un bouton Apple Pay visible ? Sur Android, Google Pay ? Si seul « carte bancaire » apparaît, vous avez un problème de friction au paiement.

Comment corriger : activez Apple Pay + Google Pay via WooPayments, Stripe ou Square. L’installation du plugin prend 5 minutes ; l’activation d’Apple Pay nécessite une étape de vérification de domaine qui ajoute 15 minutes supplémentaires.

Quatre anti-modèles mobiles à éviter

Ils apparaissent dans chaque article « optimisation mobile WooCommerce ». La recherche les démonte.

1. « Rendez votre site responsive — c’est ça, l’optimisation mobile. » D’après le Nielsen Norman Group, le design responsive est un point de départ, pas une stratégie. Le responsive garantit que le site se charge sur mobile ; il n’optimise pas l’expérience pour la saisie au pouce, les réseaux plus lents ou les priorités de viewport plus petites.
2. « Ajoutez une pop-up uniquement mobile pour capturer des e-mails. » D’après la règle de Google sur les interstitiels intrusifs (2017), les interstitiels mobiles plein écran peuvent déclencher une pénalité de classement. D’après les recherches UX mobile de Baymard, les pop-ups mobiles ont un coût d’abandon de 23 à 31 % par rapport à leurs équivalents bureau. Utilisez plutôt des formulaires inline sur les pages sans intention commerciale ; ne mettez pas de pop-up sur la PDP, le panier ni le checkout.
3. « Des menus hamburger partout. » D’après la recherche de NN/g sur le menu hamburger, les menus cachés réduisent la découvrabilité d’environ 50 %. La navigation primaire essentielle au mobile (catégorie, panier, recherche) doit être visible, pas cachée derrière un hamburger. Le hamburger est acceptable uniquement pour la navigation secondaire.
4. « Mobile-first signifie des polices plus petites pour faire tenir plus de contenu au-dessus de la ligne de flottaison. » D’après WCAG 1.4.4, le texte doit pouvoir être redimensionné à 200 %. Apple HIG préconise un corps de texte minimum de 17 pt ; Material Design préconise 16 sp. Des polices plus petites violent l’accessibilité et réduisent la conversion chez les plus de 40 ans (50 %+ des acheteurs mobiles) qui ont une déficience visuelle légère.

Pièges mobiles spécifiques à WooCommerce

Trois faits liés au thème et aux plugins qui changent la lecture de vos données mobiles.

1. Le checkout par blocs > le checkout par shortcode sur mobile, à la fois pour l’UX et pour la propreté de l’analyse web. Le checkout par blocs a été redesigné mobile-first, avec moins de champs visibles et une meilleure gestion du clavier. Si vous êtes encore sur le checkout par shortcode en 2026, la migration est le correctif mobile le plus rentable que vous puissiez faire.
2. AMP pour WooCommerce est invisible pour Statnive. Les pages AMP sont servies depuis le cache de Google et exécutent un runtime JavaScript restreint. Le traceur de Statnive ne se déclenche pas sur les pages AMP, donc le trafic AMP apparaît à zéro dans votre analyse web. Le correctif n’est pas d’ajouter une intégration AMP (AMP est de facto abandonné) ; le correctif est de désactiver AMP et de s’appuyer sur l’optimisation des Core Web Vitals.
3. La disponibilité d’Apple Pay/Google Pay varie selon la passerelle. WooPayments (Automattic) : les deux, natif. Stripe : les deux, avec vérification de domaine unique pour Apple Pay. PayPal Payments : Apple Pay via le flux PayPal, pas natif Apple. Square : régional, États-Unis/CA/UK/AU uniquement. Vérifiez la documentation de votre passerelle avant de promettre « Apple Pay au checkout » aux clients.

Ce que le Rapport Revenu v1.0.0 ajoute — et ce qu’il ne couvre toujours pas

Depuis la v1.0.0, le Tunnel Panier-vers-Achat du Rapport Revenu couvre le décrochage de checkout principal — Produit vu → Ajouté au panier → Checkout démarré → Achat finalisé, côté serveur depuis WooCommerce. Vous pouvez voir immédiatement le goulet mobile au niveau d’une étape.

Deux limites plus fines subsistent, formulées honnêtement :

1. Par sous-étape à l’intérieur de /checkout. Le tunnel de Statnive s’arrête à « Checkout démarré » / « Achat finalisé ». Savoir si les visiteurs mobiles ont abandonné spécifiquement à la sélection de livraison, au choix de paiement ou à la revue de commande n’est pas exposé — un événement checkout_step est un ajout futur.
2. Analyse par interaction d’image. Les visiteurs mobiles ont-ils swipé 1 image ou les 5 ? Vous parcourez votre propre PDP sur un vrai téléphone. Le suivi d’événements par interaction n’est pas dans la v1.0.0.

Pour le diagnostic phare mobile-vs-bureau, le cadre des 4 problèmes + l’audit à deux onglets + la file de priorité des 5 goulets continuent de piloter la priorisation. Le Rapport Revenu ajoute le classement par impact sur le chiffre d’affaires : un correctif mobile sur un article du Top Produits vaut plus que le même correctif sur une PDP de longue traîne.

Que faire ensuite

1. Ouvrez le rapport Appareils de Statnive. Calculez votre part mobile et votre rebond mobile.
2. Ouvrez WC Analytics → Commandes. Calculez votre ratio CR mobile ÷ CR bureau.
3. Utilisez le tableau de décision ci-dessus pour identifier lequel des 4 problèmes est le vôtre.
4. Appliquez le correctif de Goulet le mieux étayé pour ce problème.
5. Attendez 30 jours. Mesurez les commandes absolues avant vs après. Conservez si le gain ≥ 20 %.

Pour la boucle CRO hebdomadaire plus large, voyez le pilier sur l’Analyse web respectueuse de la vie privée pour le CRO WooCommerce. Pour les calculs de perte absolue sur les pages de sortie, voyez Pages d’entrée et de sortie. Pour les décisions de qualité de canal qui alimentent votre trafic mobile, voyez Sources de trafic WooCommerce sans GA4.