Pourquoi vos chiffres de commandes GA4 et PrestaShop ne correspondent pas (et comment y remédier)

Presque tous les marchands PrestaShop qui regardent de près constatent la même chose : le nombre de commandes dans GA4 est inférieur à celui du back-office. Parfois l'écart n'est que de quelques pour cent. Souvent il atteint 30 à 50 %. Dans tous les cas, cela fausse discrètement chaque décision que vous prenez à partir de ces données — attribution, budgets publicitaires, taux de conversion et le chiffre d'affaires que vous vous rapportez à vous-même.

Le back-office est la source de vérité. Il enregistre chaque commande réellement payée. GA4, en revanche, dépend d'une balise qui se déclenche dans le navigateur du client au moment exact. Quand cette balise ne se déclenche pas, la commande a tout de même lieu — GA4 n'en entend simplement jamais parler.

Une fois que vous comprenez la poignée de mécanismes derrière cet écart, la solution devient simple. Passons-les en revue, puis voyons comment combler l'écart pour de bon.

Le navigateur est un endroit hostile pour compter l'argent

Le tracking GA4 classique est côté client : un extrait JavaScript s'exécute dans le navigateur de l'acheteur et envoie l'événement purchase à Google. Cela paraît fiable jusqu'à ce que vous vous souveniez de tout ce qui peut mal tourner entre la page de confirmation de commande et les serveurs de Google.

L'acheteur ferme l'onglet avant que la page ne soit entièrement chargée. Sa connexion mobile coupe en pleine redirection. Une erreur de script ailleurs sur la page interrompt l'exécution avant que votre balise ne se lance. La page de confirmation redirige trop vite pour que la balise parte. Chacun de ces cas vous est invisible, et chacun est un événement purchase perdu.

Sur les pages de paiement — la page la plus importante de votre boutique — ces échecs se concentrent, car c'est précisément là que se rejoignent les redirections de paiement tierces, les réseaux lents et les acheteurs impatients. Les événements qui vous importent le plus sont ceux que le navigateur est le moins susceptible de livrer.

Les bloqueurs de publicités et l'ITP dévorent vos conversions

Une grande part des acheteurs utilisent des bloqueurs de publicités ou des extensions de confidentialité qui bloquent purement et simplement Google Analytics. Pour ces visiteurs, l'achat ne s'enregistre tout simplement jamais — la requête vers Google est annulée avant de quitter le navigateur. Les estimations varient selon l'audience, mais des taux de blocage d'environ 30 % sont courants, et nettement plus élevés dans les segments technophiles ou plus jeunes.

L'Intelligent Tracking Prevention (ITP) d'Apple ajoute une autre couche. Sur Safari et iOS, l'ITP plafonne la durée de vie des cookies posés par le JavaScript côté client — souvent à seulement 24 heures ou 7 jours. Un visiteur qui clique sur une publicité aujourd'hui et achète la semaine prochaine ressemble à une session toute nouvelle et non attribuée. La commande peut tout de même arriver dans GA4, mais dépouillée de la campagne qui l'a générée.

Comme Safari et iOS dominent le trafic mobile dans de nombreux marchés, ce n'est pas un cas marginal — pour beaucoup de boutiques, c'est la majorité des acheteurs mobiles. Notre glossaire explique l'ITP et les termes associés en langage clair.

L'inflation des sessions aggrave encore l'apparence de l'écart

Tandis que les bloqueurs de publicités et l'ITP réduisent vos conversions, un problème distinct gonfle vos sessions. Quand les cookies expirent prématurément, une même personne sur plusieurs visites est comptée comme plusieurs utilisateurs différents dans plusieurs sessions différentes. Votre dénominateur (les sessions) augmente tandis que votre numérateur (les achats) diminue.

Le résultat est un taux de conversion qui paraît bien pire que la réalité. Une boutique qui convertit à un sain 2,5 % pourrait afficher 1,4 % dans GA4 — non pas parce que quoi que ce soit a changé sur le site, mais parce que les mêmes acheteurs sont répartis sur davantage de sessions tandis que leurs achats disparaissent discrètement.

Les marchands « optimisent » alors contre un chiffre qui n'a jamais été exact, coupant des campagnes en réalité rentables et remettant en question un tunnel de commande qui fonctionne très bien. Le problème de données devient un problème commercial.

La TVA et les ID de transaction faussent aussi le chiffre d'affaires

Même quand une commande est suivie, le chiffre d'affaires peut être faux. Beaucoup de configurations envoient le sous-total hors taxes au lieu du montant réellement payé par le client. PrestaSignal envoie le chiffre d'affaires TVA incluse (le vrai total_paid_tax_incl) pour que GA4 corresponde à l'argent qui a atterri sur votre compte, ce qui compte dès l'instant où vous calculez le ROAS ou alimentez les enchères avec des valeurs de conversion.

L'autre tueur silencieux, ce sont les ID de transaction dupliqués ou aléatoires. Si l'événement purchase peut se déclencher deux fois — une fois à la confirmation, une fois lors d'un rechargement de page ou d'un clic sur le bouton retour — et que chaque déclenchement utilise un nouvel ID aléatoire, GA4 compte deux commandes pour une seule vente. Vous avez alors une sous-estimation due aux événements perdus et une surestimation due aux doublons, superposées l'une à l'autre, rendant le vrai chiffre presque impossible à raisonner.

La solution est un transaction_id déterministe dérivé de la référence de commande, afin que les rechargements et les nouvelles tentatives se réduisent à une seule commande, à chaque fois.

La solution côté serveur

Le tracking côté serveur sort l'événement purchase du navigateur fragile pour le placer dans le back-end de votre boutique. Quand PrestaShop confirme une commande, l'événement est envoyé de serveur à serveur — via un conteneur sGTM auto-hébergé — où les bloqueurs de publicités, l'ITP et les onglets fermés ne peuvent l'atteindre.

Comme l'événement provient de la commande elle-même, il porte le montant réellement payé et un transaction_id stable. Il n'y a pas de course contre une redirection, aucune dépendance à ce que l'acheteur garde l'onglet ouvert, aucune extension pour annuler la requête.

Les meilleures configurations adoptent un modèle hybride : un événement côté client dédupliqué pour la richesse comportementale, plus un événement côté serveur comme filet de sécurité fiable, les deux partageant un seul event_id pour que rien ne soit compté deux fois. Voyez côté serveur vs côté client pour la comparaison complète, ou lisez comment ça marche spécifiquement sur PrestaShop.

À quoi s'attendre après la correction

Une fois le tracking d'achat côté serveur en place, l'écart se réduit généralement de façon spectaculaire. Vous n'atteindrez pas toujours une correspondance parfaite au 1:1 — quelques différences sont légitimes, comme les commandes annulées ou frauduleuses filtrées, ou les commandes de test exclues de l'analyse — mais la sous-estimation structurelle de 30 à 50 % disparaît.

Ce sont les effets en cascade que les marchands remarquent le plus. Le taux de conversion revient à un chiffre crédible. Le ROAS des campagnes cesse de paraître artificiellement médiocre, vous arrêtez donc de couper celles qui gagnent. Le chiffre d'affaires dans GA4 s'aligne sur celui de votre banque, ce qui rend chaque rapport en aval — et chaque conversation avec une agence ou une marketplace — bien plus digne de confiance.

Si vous voulez voir votre propre écart mesuré face à vos vraies commandes PrestaShop, réservez un audit et nous quantifierons exactement combien GA4 manque actuellement.