Mener une analyse du tunnel de paiement sur les étapes qui fuient vraiment

Qu'est-ce qu'une analyse du tunnel de paiement ?

Contrairement à un tunnel de conversion à l'échelle du site, une analyse du tunnel de paiement mesure seulement le segment entre le moment où un acheteur s'engage à acheter et celui où la commande est confirmée. Tout ce qui précède, la navigation, la recherche, la comparaison, la construction du panier, reste en dehors. Ce rétrécissement est tout l'intérêt. Un acheteur qui atteint le paiement a déjà décidé de dépenser de l'argent : chaque sortie après ce point est donc une perte causée par votre propre interface plutôt qu'une perte d'intérêt.

La mécanique générale de construction et de lecture d'un tunnel, le séquencement des étapes, les tunnels ouverts contre fermés, les fenêtres de conversion et le choix de compter des utilisateurs ou des sessions, s'applique ici sans changement et est détaillée dans le fonctionnement de l'analyse de tunnel. Cette page reste sur ce qui est propre au paiement : quelles étapes existent, lesquelles fuient, et comment les instrumenter pour que les chiffres veuillent dire quelque chose.

Quelles sont les étapes d'un tunnel de paiement ?

Google normalise les noms d'événements de tout le parcours d'achat dans sa documentation ecommerce GA4, ce qui fait du paiement l'un des rares tunnels où vous n'avez pas à inventer votre propre vocabulaire. Les événements, dans l'ordre documenté :

Étape	Événement GA4	Dans le tunnel de paiement
L'acheteur voit une liste de résultats	view_item_list	Non
L'acheteur choisit un article dans la liste	select_item	Non
L'acheteur consulte la fiche produit	view_item	Non
L'acheteur ajoute l'article au panier	add_to_cart	Non
L'acheteur ouvre le panier	view_cart	Frontière
L'acheteur démarre le paiement	begin_checkout	Oui, étape 1
L'acheteur soumet les informations de livraison	add_shipping_info	Oui, étape 2
L'acheteur soumet les informations de paiement	add_payment_info	Oui, étape 3
La commande est confirmée	purchase	Oui, étape 4
La commande est remboursée	refund	Après le tunnel

Quatre étapes, c'est la forme honnête de la plupart des tunnels de paiement, et il faut résister à la tentation d'en ajouter à moins que ces étapes supplémentaires ne soient de vrais écrans sur lesquels un acheteur peut abandonner. Découper add_shipping_info en saisie d'adresse et choix du mode de livraison vaut le coup s'il s'agit de pages distinctes. Cela n'en vaut pas la peine si ce sont deux blocs de champs sur une même page, parce que la "chute" qui en résulte est un artefact du moment où vos balises se déclenchent plutôt qu'un acheteur qui s'en va.

La ligne view_cart est marquée comme frontière à dessein. Savoir si le panier appartient au tunnel est la décision qui change le plus votre chiffre de tête, et c'est la raison pour laquelle taux d'abandon de panier et taux d'abandon de paiement sont deux métriques aux dénominateurs différents, une distinction creusée dans comment se calcule le taux d'abandon de panier.

Où se concentre l'abandon dans un tunnel de paiement ?

Entre begin_checkout et add_shipping_info, dans presque toutes les boutiques qui ont regardé. Ce premier écran est celui où le prix total devient réel, où la création de compte est habituellement exigée, et où l'acheteur découvre la longueur du formulaire qui l'attend.

La revue de 50 études distinctes par le Baymard Institute situe le taux d'abandon de panier moyen documenté à 70.22%, un chiffre mis à jour pour la dernière fois le 22 septembre 2025. La partie la plus utile de ces travaux est la ventilation des raisons invoquées, mesurée auprès d'acheteurs qui avaient réellement l'intention d'acheter :

Raison invoquée pour abandonner le paiement	Part
Frais supplémentaires trop élevés (livraison, taxes, commissions)	40%
Livraison trop lente	20%
Pas assez confiance dans le site pour y saisir sa carte	19%
Création de compte obligatoire	18%
Processus de paiement trop long ou trop compliqué	17%
Erreurs ou plantages du site	17%
Politique de retour insatisfaisante	13%
Impossible de voir ou de calculer le coût total dès le départ	12%
Carte refusée	10%
Pas assez de moyens de paiement	9%

Baymard note séparément que 42% des acheteurs en ligne américains ont abandonné simplement parce qu'ils regardaient sans être prêts à acheter, et exclut ce groupe des pourcentages ci-dessus. Cette exclusion est ce qui rend la liste actionnable : il ne reste que des gens qui voulaient terminer la commande et se sont arrêtés quand même.

Reportez ces raisons sur les quatre étapes et la forme du problème devient concrète. Frais supplémentaires, totaux masqués, création de compte forcée et longueur du formulaire atterrissent tous sur l'étape 1. Vitesse de livraison et couverture des moyens de paiement atterrissent sur les étapes 2 et 3. Les refus atterrissent sur l'étape 4, où ils relèvent de la configuration de paiement plutôt que du design. Avant de comparer vos propres chiffres à tout cela, lisez les réserves rassemblées dans ce que mesurent vraiment les benchmarks de tunnel publiés, parce que les définitions d'étapes varient assez d'une étude à l'autre pour déplacer un pourcentage de plusieurs dizaines de points.

Où se situe chaque motif cité

Étape 1 : begin_checkoutCoûts supplémentaires, total caché, compte obligatoire, formulaires longs

Étapes 2 et 3 : livraison et paiementLivraison lente, méthodes de paiement insuffisantes

Étape 4 : purchaseCartes refusées, un problème de configuration

Comment mettre en place une analyse du tunnel de paiement ?

L'instrumentation d'abord, le rapport ensuite. Un tunnel bâti sur des événements qui se déclenchent au mauvais moment produit des réponses fausses et assurées, qu'aucune analyse ne répare après coup.

1. Déclenchez un événement par écran sur lequel un acheteur peut partir. Si votre paiement tient en trois pages, il vous faut trois événements plus purchase. S'il tient sur une page unique avec des sections en accordéon, déclenchez add_shipping_info et add_payment_info à la fin de chaque section plutôt qu'au chargement de la page, sinon le tunnel affichera 100% de complétion d'étape et aucun enseignement.
2. Sortez purchase de la page de remerciement si une redirection peut la sauter. Les pages de paiement hébergées, les parcours par wallet et l'authentification bancaire ramènent tous l'acheteur quelque part que vous ne contrôlez pas entièrement. Un événement purchase qui ne se déclenche que sur une URL de confirmation de commande sous-comptera chaque commande où l'acheteur a fermé l'onglet après avoir payé. Envoyez-le côté serveur depuis le webhook de commande et vous obtenez le vrai dénominateur.
3. Réglez le tunnel sur fermé plutôt qu'ouvert. Le paiement est authentiquement séquentiel : un acheteur qui apparaît à add_payment_info sans être passé par add_shipping_info est un bug de balisage qu'il vaut mieux faire remonter qu'un chemin légitime à compter.
4. Choisissez une fenêtre de conversion plus courte que celle par défaut. Le paiement est une activité de quelques minutes, pas de plusieurs jours. Une fenêtre de 30 jours créditera un purchase survenu une semaine après un begin_checkout abandonné, ce qui masque l'abandon que vous cherchiez à mesurer.
5. Segmentez avant d'interpréter. Au minimum, découpez par appareil et par invité contre connecté. Le paiement mobile et le paiement desktop partagent rarement le même goulot d'étranglement, et la création de compte forcée n'apparaît comme un effondrement de l'étape 1 que dans le segment invité.
6. Consignez les définitions d'étapes à côté du rapport. Un tunnel dont l'étape 2 a changé de définition en mars montrera une falaise en mars qu'aucun changement de code n'a causée, et six mois plus tard personne ne se souviendra pourquoi.

L'étape 2 est celle qui démolit silencieusement le plus d'analyses. Une boutique dont le prestataire de paiement fonctionne par redirection peut sous-déclarer ses commandes finalisées dans de larges proportions, puis passer un trimestre à optimiser une étape qui n'a jamais été cassée.

Que ne vous dit pas une analyse du tunnel de paiement ?

Elle ne vous dit pas pourquoi. Un tunnel vous donne un emplacement exact et aucune cause, ce qui est la limite de tout rapport fondé sur un comptage d'étapes et la raison pour laquelle un chiffre d'abandon est une question plutôt qu'une réponse. Le chiffre de 40% pour les frais inattendus est un résultat d'enquête sur le panel de Baymard, pas un diagnostic de votre boutique, et le prendre pour tel conduit des équipes à supprimer des frais de livraison qui n'étaient pas le problème.

Deux choses transforment une chute localisée en cause. La première est un découpage par segment assez fin pour l'isoler : si l'effondrement de l'étape 1 n'apparaît que sur Safari mobile, la cause est probablement un problème de rendu ou de remplissage automatique plutôt qu'un problème de prix. La seconde est de regarder ce que les gens ont réellement fait sur cet écran, et c'est là que le session replay justifie sa place face au reporting agrégé.

Elle ne vous dit pas non plus combien vaut la fuite. Une chute de 12% à add_payment_info dans une boutique au panier élevé vaut plus qu'une chute de 30% à begin_checkout dans une boutique au panier faible, et les deux ne deviennent comparables qu'une fois multipliées par ce que vaut une commande type. Classer les correctifs par pourcentage plutôt que par revenu récupéré est la façon la plus courante dont une analyse correcte produit la mauvaise feuille de route.

Questions fréquentes

L'abandon de paiement est-il la même chose que l'abandon de panier ?

Non, et la différence est le dénominateur. L'abandon de panier mesure les acheteurs qui ont ajouté un article sans acheter, sa base est donc tous ceux qui ont atteint add_to_cart. L'abandon de paiement mesure les acheteurs qui ont démarré le paiement sans acheter, sa base est donc tous ceux qui ont atteint begin_checkout. La seconde base est bien plus petite et bien plus engagée, ce qui explique que les taux d'abandon de paiement soient toujours inférieurs aux taux d'abandon de panier pour une même boutique.

Quels événements GA4 un tunnel de paiement doit-il utiliser ?

Google documente begin_checkout, add_shipping_info, add_payment_info et purchase comme la portion paiement du parcours ecommerce, avec view_cart juste avant et refund après. Utiliser ces noms plutôt que des noms personnalisés permet à n'importe quel outil de reporting qui comprend l'ecommerce GA4 de lire votre tunnel sans couche de correspondance.

Combien d'étapes un tunnel de paiement doit-il avoir ?

Autant qu'il y a d'écrans sur lesquels un acheteur peut abandonner, soit généralement trois ou quatre. Ajouter des étapes qui correspondent à des blocs de champs plutôt qu'à des écrans crée des chutes qui reflètent le calage des balises plutôt que le comportement. Si vous ne savez pas décrire ce qu'un acheteur aurait fait pour sortir entre deux étapes, ces deux étapes n'en font qu'une.

Pourquoi mon tunnel affiche-t-il plus d'achats que de paiements démarrés ?

Le plus souvent parce que purchase part d'une source que begin_checkout ne voit pas : un webhook de commande côté serveur, une commande répétée passée via un lien de panier sauvegardé, ou un renouvellement d'abonnement. Vérifiez si les événements d'achat portent un identifiant de session ou d'utilisateur correspondant, et excluez du tunnel les renouvellements et les commandes créées par un administrateur s'ils ne passent jamais par l'interface de paiement.

Le tunnel de paiement doit-il compter des utilisateurs ou des sessions ?

Des sessions, pour la version que vous regardez chaque semaine. Le paiement est une activité d'une seule traite : un tunnel à portée de session répond donc à la question que vous posez vraiment, à savoir combien de gens parmi ceux qui viennent de démarrer le paiement sont allés au bout. Un tunnel à portée utilisateur créditera un achat fait deux jours plus tard contre l'abandon d'origine et fera paraître la fuite plus petite qu'elle n'est.

Que vérifier en premier quand une étape de paiement chute brutalement ?

Un déploiement, avant toute chose. Les falaises soudaines sur une seule étape viennent bien plus souvent d'une balise cassée, d'un sélecteur modifié ou d'une erreur JavaScript sur un écran que d'un changement de comportement des acheteurs. Comparez le compte brut d'événements de cette étape à celui de l'étape précédente, regardez si la chute se limite à un navigateur ou à une classe d'appareils, et ne commencez à raisonner sur les prix, les formulaires ou la confiance qu'après avoir écarté l'hypothèse que l'événement a simplement cessé de se déclencher.

La page panier fait-elle partie du tunnel de paiement ?

Pas officiellement. view_cart se situe à la frontière, juste avant begin_checkout, la première des quatre étapes du tunnel. L'inclure ou non est la décision qui fait le plus bouger votre taux d'abandon global, parce qu'elle change le dénominateur. C'est pour cette raison que le taux d'abandon de panier et le taux d'abandon de paiement donnent des chiffres différents pour la même boutique.

Quel est le taux moyen d'abandon de panier selon Baymard ?

L'analyse de Baymard Institute portant sur 50 études distinctes situe le taux moyen documenté d'abandon de panier à 70,22 %, chiffre mis à jour le 22 septembre 2025. La liste des motifs cités exclut les 42 % d'acheteurs américains qui ont abandonné simplement parce qu'ils ne faisaient que regarder. Ce qui reste dans la répartition des motifs cités, ce sont des acheteurs qui voulaient réellement finaliser leur commande et qui ont quand même abandonné.

Quelle doit être la durée de la fenêtre de conversion d'un tunnel de paiement ?

Plus courte qu'une fenêtre par défaut de 30 jours, parce que le paiement est une activité de quelques minutes, pas de plusieurs jours. Une fenêtre de 30 jours attribue un achat survenu une semaine après un begin_checkout abandonné, ce qui masque l'abandon que vous cherchez justement à mesurer. Réglez la fenêtre sur la durée réelle de votre tunnel de paiement.

Quel est le motif d'abandon de paiement le plus cité ?

Les coûts supplémentaires révélés trop tard, comme la livraison, les taxes ou les frais, cités par 40 % des acheteurs dans l'étude de Baymard, la part la plus élevée de tous les motifs. Cela touche l'étape 1, begin_checkout, où le prix total devient concret pour la première fois. La lenteur de livraison (20 %) et la méfiance envers le site pour les données de carte (19 %) suivent.