Tracking côté serveur vs côté client, expliqué pour les e-commerçants

Si vous avez cherché des outils d'analyse ou de marketing récemment, on vous a probablement dit qu'il vous fallait du « tracking côté serveur ». C'est présenté comme une solution à tout, généralement sans que personne n'explique ce que c'est ou en quoi cela diffère de ce que vous avez déjà.

Ce guide le fait en termes simples. À la fin, vous comprendrez les deux approches, là où chacune brille et échoue, et la configuration précise qui vous donne le meilleur des deux sans les inconvénients. Aucun jargon que vous n'auriez pas déjà rencontré, et aucune supposition que vous gérez des balises pour gagner votre vie.

Le tracking côté client, en un paragraphe

Le tracking côté client est la façon originelle dont l'analyse fonctionne. Vous placez un petit morceau de JavaScript sur votre site, et quand un acheteur fait quelque chose — voir un produit, ajouter au panier, acheter — ce code s'exécute dans son navigateur et envoie l'événement à Google, Meta ou ailleurs. Le navigateur fait le travail et la remontée.

C'est facile à mettre en place : collez un extrait, et les événements se mettent à circuler. Et comme il vit dans le navigateur, il voit tout ce que voit le navigateur — clics, profondeur de défilement, quelle page précédait quelle autre, combien de temps quelqu'un est resté. Cette richesse est sa véritable force, et c'est pourquoi le tracking côté client ne disparaîtra jamais totalement.

L'ennui, c'est que le navigateur est aussi l'environnement le moins contrôlable d'internet. Vous ne le possédez pas, l'acheteur si, ainsi que chaque extension et paramètre de confidentialité qu'il a installés. C'est la graine de chaque problème dont nous allons parler.

Le tracking côté serveur, en un paragraphe

Le tracking côté serveur déplace la remontée hors du navigateur vers un serveur que vous contrôlez. Au lieu que le navigateur de l'acheteur informe Google d'un achat, le back-end de votre boutique — ou un conteneur dédié comme sGTM — envoie l'événement directement, de serveur à serveur.

Comme l'événement ne dépend plus de ce que le navigateur termine son travail, il survit aux bloqueurs de publicités, aux paramètres de confidentialité, aux onglets fermés et aux connexions mobiles capricieuses. Il garde aussi vos balises et jetons d'accès hors de la page web publique, où n'importe qui pourrait sinon les inspecter. Cette fiabilité et ce contrôle sont sa force.

Voyez-le ainsi : le navigateur est la vitrine, pleine de vie et de détails mais exposée aux intempéries ; le serveur est l'arrière-boutique, plus calme et verrouillée, où vous pouvez être sûr que les comptes sont tenus avec exactitude. Vous voulez les deux, utilisés pour ce que chacun fait de mieux.

Les avantages et inconvénients en toute honnêteté

Le côté client est riche mais qui fuit. Il capte un comportement détaillé, mais une part non négligeable des événements n'arrive jamais — bloquée par les bloqueurs de publicités, raccourcie par l'ITP d'Apple, ou perdue quand une page se ferme trop tôt. Une perte de 30 à 50 % sur les événements qui comptent, comme purchase, est courante. Il expose aussi vos balises et jetons au navigateur.

Le côté serveur est fiable mais, seul, aveugle au pur comportement du navigateur. Il ne voit pas le défilement et les clics que le côté client capte si bien, et il demande davantage d'infrastructure — un conteneur, un domaine, un peu de configuration. Il est aussi plus difficile de le configurer incorrectement sans s'en rendre compte.

Aucune approche n'est complète à elle seule. C'est l'idée clé que la plupart des vendeurs sautent quand ils vous disent simplement de « passer » au côté serveur.

Si vous ne retenez qu'une chose de cet article, que ce soit cette phrase. Quiconque vous vend une décision binaire vous vend une demi-solution, et la moitié manquante est généralement celle qui vous coûte de l'argent en silence avec le temps.

Pourquoi l'hybride avec déduplication l'emporte

La bonne réponse pour presque toutes les boutiques est de faire tourner les deux. Utilisez le côté client pour la richesse comportementale et le côté serveur comme filet de sécurité fiable qui garantit que les événements qui comptent — surtout purchase — arrivent réellement.

Le piège, c'est le double comptage : si les deux canaux signalent la même vente, vos chiffres gonflent, ce qui est sans doute pire que la sous-déclaration car cela se cache à la vue de tous. La déduplication résout cela. Les deux événements portent le même event_id, et la plateforme (GA4 ou Meta) les fusionne en un seul, gardant celui qui a les meilleures données.

Le résultat est couverture et richesse sans inflation : vous voyez le comportement depuis le navigateur et vous ne perdez jamais une conversion. Cela ressemble à avoir le beurre et l'argent du beurre, mais c'est simplement utiliser chaque méthode pour la tâche où elle excelle et laisser la déduplication arbitrer le chevauchement.

Notre page côté serveur vs côté client approfondit, et le glossaire définit chaque terme employé ici.

Une note sur la confidentialité et le contrôle

Le tracking hybride n'est pas seulement plus précis, il est plus facile à exploiter de façon responsable. Comme les PII transitent par un serveur que vous contrôlez, les données personnelles comme l'e-mail et le téléphone peuvent être normalisées et hachées en SHA-256 avant même d'atteindre Google ou Meta — les plateformes reçoivent une empreinte irréversible, pas une adresse lisible.

Garder les jetons et la logique de balisage côté serveur réduit aussi votre exposition : il y a moins à lire sur votre page pour un script malveillant ou un concurrent curieux, et vous décidez exactement quels champs quittent votre boutique et lesquels non. Pour beaucoup de marchands, cette combinaison de précision et de contrôle est la vraie raison de franchir le pas.

Ce que les propriétaires de boutiques PrestaShop devraient faire

Vous n'avez pas besoin de devenir un expert en gestion de balises. Vous avez besoin d'une configuration qui déclenche des événements côté client précis, envoie des événements côté serveur correspondants via un conteneur que vous contrôlez, et les déduplique sur un event_id partagé — avec les PII hachées avant de quitter votre serveur.

C'est exactement ce que PrestaSignal installe en tant que module PrestaShop câblé à un conteneur sGTM auto-hébergé. Il conserve vos comptes GA4 et Meta existants, comble les lacunes laissées par les balises côté client, et gère la déduplication et le hachage pour vous.

Voyez comment ça marche pour les spécificités PrestaShop, ou regardez le module pour comprendre ce qui est installé. Si vous préférez que nous regardions simplement votre boutique, réservez un audit.