Depuis des années, le débat « côté serveur ou côté client » fait partie de ces sujets auxquels la réponse est réellement « ça dépend », au grand désespoir de tout le monde. Voici une explication claire, sans argumentaire commercial, accompagnée d’un tableau honnête que vous pourrez envoyer à votre CTO.
Ce que recouvre réellement chaque approche
Le tracking côté client s’exécute dans le navigateur du visiteur. Un petit script se lance, relève ce qui s’est passé (page vue, clic, profondeur de défilement), puis envoie directement ces informations à un endpoint de collecte. Le tracking côté serveur s’exécute sur votre infrastructure. Le navigateur envoie un minimum de données à votre serveur (ou à un worker edge léger), qui décide ensuite quelles données transmettre et à quelle destination.
Aucune approche n’est intrinsèquement plus « respectueuse de la vie privée » ou plus « précise » que l’autre. Toutes deux peuvent l’être ou non, selon leur configuration. Ce qui change, c’est l’emplacement du point de contrôle — et la part de la réalité qui vous parvient.
Le tableau honnête des compromis
| Critère | Côté client | Côté serveur |
|---|---|---|
| Effort de mise en place | Faible — il suffit de coller un snippet | Plus élevé — un service et une petite couche de routage |
| Résistance aux bloqueurs de publicité | Faible — le script est bloqué à la source | Forte — endpoint propriétaire sur votre propre domaine |
| Perte de données sur les navigateurs modernes | Significative (Safari ITP, bloqueurs, modes de protection contre le tracking) | Faible — vous maîtrisez la surface |
| Latence au premier affichage | Ajoute une requête tierce | N’ajoute rien si le collecteur est mis en cache à l’edge |
| Contrôle des données qui quittent votre infrastructure | Ce que décide le script du fournisseur | Ce que vous décidez |
| Facilité de débogage | Onglet Réseau des DevTools | Journaux serveur — une autre compétence, mais des données plus complètes |
| Coût à grande échelle | Faible, jusqu’à ce que le fournisseur vous fasse passer au forfait supérieur | Une petite facture edge / functions dont vous voyez réellement le montant |
| Identification B2B au niveau de l’entreprise | Fonctionne, mais reste fragile | Solution idéale — le serveur peut résoudre en privé l’adresse IP → entreprise |
Cette dernière ligne est celle sur laquelle les équipes B2B devraient s’attarder le plus. L’identification côté client dépend d’un script qu’une part croissante des visiteurs bloque entièrement ou neutralise fortement. Côté serveur, la logique d’identification se trouve sur votre propre infrastructure, où elle ne peut pas être désactivée silencieusement par une mise à jour du navigateur.
La place de l’identification au niveau de l’entreprise
L’identification au niveau de l’entreprise est une tâche naturellement adaptée au côté serveur. Le navigateur doit seulement envoyer une très petite requête à un endpoint propriétaire sur votre propre domaine. Cet endpoint s’exécute à l’edge (généralement en moins de 20 ms en Europe), résout en privé l’adresse IP en entreprise et ne renvoie rien qui révèle au client ce qui s’est passé. L’expérience utilisateur reste inchangée. Les bloqueurs sont contournés. Le parcours des données reste dans un périmètre que vous contrôlez.
Ce n’est pas une astuce. C’est simplement la conséquence du transfert de la question « quelle entreprise est à l’origine de cette visite ? » du client vers un service que vous exploitez. Rien ne change dans la navigation du visiteur ; c’est votre capacité à obtenir la réponse qui change.
Ce que le côté serveur n’est pas
Le tracking côté serveur n’est pas un moyen de contourner le consentement. Si une activité de traitement nécessite un consentement, celui-ci reste obligatoire, quel que soit l’endroit où le code s’exécute. Ce que le côté serveur change, c’est la perte de données et le contrôle — pas la base juridique.
Un mot sur les performances
On craint souvent que le « tracking » ralentisse les pages. Dans les configurations modernes, cette inquiétude appartient au passé. Un loader bien conçu ne pèse que quelques kilo-octets, son chargement est différé et il se déclenche une fois la page interactive ; un endpoint serveur bien conçu répond en quelques millisecondes depuis le point edge le plus proche. Ni l’un ni l’autre ne dégradera vos Core Web Vitals. Le véritable problème, c’est le gestionnaire de balises contenant quatorze scripts tiers que personne n’a audités depuis trois ans. Des parcours de données moins nombreux et mieux contrôlés sont presque toujours plus rapides.
Quand le côté client reste préférable
Le côté client n’est pas un mauvais choix. Pour des analyses à faible enjeu, lorsque vous acceptez déjà la perte de données liée aux bloqueurs (échantillonnage de l’utilisation du produit, événements UX dans l’application, tests rapides et sommaires de pages de destination), le côté client est plus rapide à déployer et moins coûteux à exploiter. Il ne s’agit pas d’affirmer qu’une approche est universellement meilleure ; mais si votre activité dépend de ces données — le pipeline B2B en est un bon exemple —, le côté serveur est plus résilient et plus transparent quant à son fonctionnement.
La bonne question n’est pas « quelle approche est la meilleure ? », mais « quelle décision ces données doivent-elles alimenter, et quel niveau de perte de données cette décision peut-elle tolérer ? ». Pour répondre à la question « quelles entreprises nous ont rendu visite cette semaine ? », idéalement aucune perte. Le choix d’architecture en découle.
Published by
lead.box Team
More articles
Découvrez lead.box sur votre propre trafic
Démarrez gratuitement — sans carte bancaire, sans appel commercial obligatoire. Ou réservez une présentation guidée de 20 minutes.