Un client me partage son écran GA4, trois derniers mois. 71 % des sessions viennent d'un téléphone, 38 % du chiffre d'affaires aussi. Il commente lui-même, sans que j'aie rien dit : « il nous faudrait plus de trafic ». Non. Il lui faudrait garder celui qui entre déjà et repart. Ces trente points d'écart ne sont pas une fatalité du mobile : ce sont quatre écrans de tunnel de commande dessinés pour une souris, un grand écran et une connexion filaire, puis servis à un pouce sur un réseau 4G avec un clavier qui mange la moitié de la page.
Cet article regarde où la marge fuit précisément dans un tunnel mobile, ce que disent les données publiques les plus solides sur le sujet, et surtout dans quel ordre corriger quand on n'a ni budget de refonte ni assez de trafic pour tester à l'infini.
Sur mobile, on ne perd presque jamais un client parce qu'il a changé d'avis. On le perd parce qu'on lui a demandé de faire, sur six pouces et d'une seule main, ce qu'on avait conçu pour un clavier et une souris.
L'écart mobile / desktop est réel, mais ce n'est pas un problème d'intention
Commençons par le chiffre qui cadre le débat. Le benchmark 2026 de Contentsquare, construit sur 99 milliards de sessions et plus de 6 500 sites, situe le taux de conversion moyen à 3,4 % sur desktop contre 2 % sur mobile : soit un desktop qui convertit environ 75 % mieux. Sur le retail seul, l'écart tient : 3,7 % contre 2 %. Ce n'est pas une anomalie de votre site, c'est un écart de marché.
L'explication réflexe est connue : « les gens repèrent sur mobile et achètent sur ordinateur ». Elle est partiellement vraie, et complètement piégeuse, parce qu'elle transforme une friction en fatalité. Les travaux de Baymard sur le m-commerce donnent une lecture beaucoup moins confortable : 43,2 % des utilisateurs de smartphone ou de tablette déclarent avoir abandonné une commande pendant le tunnel dans les deux derniers mois, et 61 % basculent parfois ou toujours sur un ordinateur pour terminer un achat commencé sur mobile. Ce basculement n'est pas une préférence d'usage : c'est un contournement. Et un contournement, par définition, tout le monde ne le fait pas : les autres partent.
Le formulaire est le premier poste de perte
C'est le point le plus mesuré et le plus ignoré. La base de benchmark de Baymard sur les tunnels de commande relève que le checkout moyen affiche par défaut 23,48 éléments de formulaire (14,88 si on ne compte que les champs à remplir), alors que leurs tests d'utilisabilité montrent qu'un tunnel idéal tient en 12 à 14 éléments, soit 7 à 8 champs réels. Autrement dit : la plupart des sites demandent deux fois trop. Sur un ordinateur, c'est agaçant. Sur un téléphone, chaque champ supplémentaire, c'est un clavier qui se déploie, une page qui saute, un zoom involontaire, un champ qui passe sous le pouce.
Dans les raisons d'abandon relevées par Baymard hors « je regardais seulement », 18 % des acheteurs partent parce que le site exige la création d'un compte et 17 % parce que le tunnel est trop long ou trop compliqué. Le compte se propose après le paiement, sur la page de confirmation, avec le mot de passe comme seule saisie restante : jamais avant, jamais comme condition d'achat.
Le levier technique le plus rentable tient en un attribut. Un tunnel correctement balisé se remplit en un tap : la documentation web.dev sur les formulaires de paiement et d'adresse détaille les valeurs à poser (autocomplete="given-name", "shipping postal-code", "cc-number"…), avec des attributs name et id stables entre deux déploiements. C'est cette stabilité qui permet au navigateur de reconnaître le formulaire. Ajoutez un inputmode cohérent pour appeler le bon clavier, la facturation identique à la livraison par défaut, et vous venez de supprimer une trentaine de frappes sur un écran tactile.
Les coûts qui apparaissent trop tard
Sur l'ensemble des abandons de panier (dont Baymard maintient depuis des années la moyenne documentée à 70,22 %, calculée sur 50 études), 42 % relèvent du simple lèche-vitrine, et on n'y peut rien. Mais sur les autres, la première cause n'a pas bougé depuis dix ans : 40 % partent parce que les frais supplémentaires (port, taxes, frais divers) sont trop élevés ou découverts trop tard, et 12 % parce qu'ils ne pouvaient pas voir le total avant d'être engagés.
Le mobile aggrave mécaniquement ce défaut : le récapitulatif de commande est presque toujours sous le pli, replié derrière un « voir le détail » que personne n'ouvre. Le client découvre 6,90 € de livraison à l'étape trois, après avoir saisi son adresse. La correction ne coûte pas une refonte : afficher le seuil de franco de port dès la fiche produit et dans le panier, estimer le port avant de demander l'e-mail, et garder un récapitulatif dépliable persistant en haut du tunnel. Même logique pour le délai, 20 % des abandons tiennent à une livraison jugée trop lente : affichez une date, pas un nombre de jours ouvrés que personne ne convertit mentalement.
La latence d'interaction, pas le temps de chargement
On parle beaucoup de vitesse de chargement et presque jamais de vitesse de réponse. Ce sont deux choses différentes : le LCP mesure l'affichage, l'INP (Interaction to Next Paint) mesure le délai entre le tap et le moment où l'écran réagit. Le seuil recommandé est de 200 ms au 75e centile, et la documentation Google est explicite sur un point qui nous intéresse ici : les problèmes d'INP se manifestent surtout sur mobile, où un test depuis un poste de bureau donne systématiquement une image trop flatteuse.
Le symptôme est facile à reconnaître dans un enregistrement de session : tap sur « Ajouter au panier », rien ne bouge pendant 600 ms, l'utilisateur re-tape. Résultat, deux articles dans le panier ou une sortie sèche. Ce n'est pas un bug, c'est un thread principal saturé, le plus souvent par des scripts tiers (chat, outil de test, gestionnaire de tags qui a grossi sans inventaire) qui s'exécutent précisément au moment où l'utilisateur interagit. Cela recoupe une autre statistique de Baymard : 17 % des abandons sont attribués à « des erreurs ou un site qui a planté ». Sur mobile, une latence suffisamment longue est un plantage, du point de vue de celui qui tient le téléphone. Ce chantier rejoint directement celui des Core Web Vitals, qui n'est donc pas qu'une affaire de SEO.
Les six points de fuite, et l'ordre dans lequel les traiter
| Point de fuite | Ce qu'on observe | Correctif | Effort |
|---|---|---|---|
| Compte obligatoire | Pic de sorties sur l'écran de connexion | Commande invité par défaut, compte proposé après paiement | Faible |
| Frais découverts tard | Sorties à l'étape livraison, paniers élevés abandonnés | Franco et estimation de port dès la fiche produit | Faible |
| Récapitulatif invisible | Allers-retours répétés entre panier et livraison | Récap dépliable persistant en haut du tunnel | Faible |
| Paiement limité | Sorties sur l'écran de paiement, cartes refusées | Wallet (Apple Pay / Google Pay) en premier choix | Faible |
| Formulaire trop long | Chute du taux de complétion entre adresse et paiement | Descendre à 7-8 champs, autocomplete et inputmode corrects | Moyen |
| Latence au tap (INP) | Doubles ajouts au panier, re-clics visibles en session recording | Alléger les scripts tiers, différer le non-critique | Moyen |
L'ordre du tableau n'est pas décoratif : il va du correctif à faible effort et effet immédiat vers le chantier. Sur un site à trafic modeste, les quatre premières lignes se traitent en une semaine de développement et se mesurent sans A/B test, parce qu'un blocage supprimé se lit directement dans le taux de complétion d'étape.
Le paiement : moins d'étapes plutôt que plus d'options
Trois raisons d'abandon relevées par Baymard tournent autour du paiement : 19 % ne font pas confiance au site avec leur numéro de carte, 10 % voient leur carte refusée, 9 % ne trouvent pas le moyen de paiement qu'ils voulaient. Le portefeuille mobile règle les trois d'un coup : aucune saisie de carte, authentification biométrique, adresse de livraison déjà connue, et la confiance transférée à Apple ou Google plutôt qu'à un site que l'acheteur découvre. C'est, en rapport effet/effort, le meilleur investissement d'un tunnel mobile.
Le réflexe inverse, empiler cinq moyens de paiement pour couvrir tout le monde, déplace le problème sans le résoudre : l'écran s'allonge, le choix paralyse, et on rajoute de la longueur là où on voulait enlever de la friction. Un wallet en premier, la carte ensuite, éventuellement un paiement fractionné si le panier moyen le justifie. Et, autant que possible, pas de redirection hors du site : chaque saut de domaine sur mobile est une occasion de perdre la session.
L'erreur la plus coûteuse
Lancer une refonte mobile avant d'avoir regardé où les gens décrochent. Trois mois de chantier, un budget conséquent, et le plus souvent les mêmes hypothèses reconduites dans un habillage neuf. L'ordre inverse coûte dix fois moins : instrumenter le tunnel étape par étape en segmentant par appareil, regarder vingt enregistrements de sessions mobiles qui finissent en sortie, corriger les deux ou trois frictions que ça révèle, puis seulement se demander si une refonte reste nécessaire. Corollaire du même travers : ne testez pas la couleur d'un bouton quand votre tunnel affiche vingt-trois champs. À ce stade, ce n'est pas un sujet d'A/B test, c'est un sujet de chantier.
Mesurer le tunnel mobile à part, sinon on ne voit rien
Un taux de conversion agrégé ne dit rien d'exploitable. Si le mobile pèse 70 % des sessions et convertit deux fois moins, il tire la moyenne vers le bas et on conclut à un problème global, alors que le desktop, lui, va très bien. Ce qu'il faut regarder, c'est le taux de complétion étape par étape, segmenté par appareil : panier → identification → livraison → paiement → confirmation. La marche où le mobile décroche par rapport au desktop, c'est votre point de fuite, et il est rarement là où on l'imaginait. À côté du quantitatif, le qualitatif tranche vite : vingt enregistrements de session mobiles bien choisis valent trois réunions d'hypothèses.
Une précaution de mesure, enfin : depuis le consentement, une partie des parcours mobiles est modélisée plutôt qu'observée, et l'écart entre les outils s'élargit, raison de plus pour recouper avec le back-office, comme je le détaille sur ce que GA4 ne voit plus. Sur le terrain, l'enjeu est très concret : pour une billetterie événementielle que j'ai pilotée en Meta Ads, le parcours d'achat arrivait quasi exclusivement d'un téléphone. À un coût par billet autour de 2,66 €, chaque friction ajoutée entre la publicité et le paiement se paie immédiatement en coût d'acquisition : l'optimisation du tunnel et celle du média sont le même sujet, vu par deux bouts.
Au creuset : transmuter le trafic mobile en marge
Le mobile n'est pas un canal de consultation qui convertirait mal par nature. C'est devenu le canal principal, servi par des parcours dessinés pour un autre appareil, et l'écart de conversion mesure surtout cet héritage. Le plomb, ici, c'est le trafic qu'on rachète en volume pour compenser un tunnel qui fuit ; l'or, c'est exactement le même trafic passé dans un parcours qui tient dans un pouce. Baymard chiffre à 35,26 % le gain de conversion moyen encore accessible sur de grands sites par la seule qualité du tunnel de commande, c'est-à-dire sans acheter une visite de plus.
Si votre trafic est mobile et votre chiffre d'affaires desktop, l'écart est chiffrable et, pour l'essentiel, réparable. J'audite le tunnel étape par étape, appareil par appareil, et je hiérarchise les correctifs par effet sur la marge dans le cadre de mon expertise CRO, en articulation avec la mesure analytics et l'architecture e-commerce.
Votre trafic est mobile, vos ventes ne le sont pas ?
J'instrumente votre tunnel étape par étape, je compare mobile et desktop marche par marche, et je vous rends une liste de correctifs classés par effet sur la marge, pas une refonte de trois mois.