Êtes-vous prêt à optimiser vos performances de suivi ?
Le server-side, ce n’est pas un outil marketing, c’est un projet d’infrastructure : il faut aligner l’IT, le front et l’analytics. Grâce à la synchronisation entre Didomi et Addingwell, nous avons sécurisé le pilotage de notre marge commerciale et fiabilisé nos données de tracking sur l’ensemble de nos marchés.
Pionnier et leader français de la vente en ligne de pièces détachées automobiles neuves et d'origine, Oscaro couvre la France, l'Espagne, la Belgique et le Portugal avec un catalogue de plus d'un million de références. La France représente 90 % de l'activité commerciale du groupe. La plateforme accueille 5 millions d'utilisateurs et 6 millions de sessions chaque mois sur les quatre marchés.
Maxime Donnet, Analytics & CRO Manager chez Oscaro depuis deux ans, pilote l'ensemble du périmètre web et app de l'entreprise, de la conformité à la conversion. Il a orchestré avec les équipes IT, front et analytics la bascule vers le tracking server-side Addingwell et la CMP Didomi. Un chantier mené comme un projet d'infrastructure à part entière, et dont la mesure fiabilisée a livré davantage que ce qui était attendu.
Défi : une donnée à forte valeur, coincée côté navigateur
L'équipe d'Oscaro pilotait déjà ses tags GA4, Google Ads et Meta en interne. Le sujet n'était donc pas l'absence de tracking, mais ses limites structurelles, à la fois sur la donnée business et sur la fiabilité de la mesure elle-même.
- Un cas d'usage bloqué par le client-side. Le data layer et le code source d'un site restent lisibles par n'importe quel utilisateur averti. Une faille sans conséquence pour des métriques classiques, mais rédhibitoire pour un indicateur aussi sensible que la marge commerciale reversée aux fournisseurs. Exploiter cette donnée supposait de la faire sortir du navigateur pour la traiter dans un environnement qu'Oscaro maîtrise de bout en bout.
- Une bannière maison à bout de souffle. Oscaro avait développé sa propre bannière de cookies en interne. Face aux évolutions réglementaires constantes, cette solution devenait coûteuse à maintenir techniquement et limitait l'autonomie des équipes marketing sur le pilotage de leurs indicateurs.
- Des écarts de mesure qui compliquaient le pilotage. L'écart entre les données Google Analytics 4 et le back-office interne atteignait environ 10 %, rendant difficile toute lecture fiable de la performance commerciale.
- Une audience mal comptée sur Safari et iOS. Plus d'un nouveau visiteur sur quatre n'en était pas un. Il s'agissait d'un visiteur déjà venu, recompté comme nouveau à cause du plafond de sept jours imposé par l'ITP, ce qui faussait la lecture de l'acquisition sur ces navigateurs.
- Un point de blocage resté invisible. Sans reverse proxy, la bannière de consentement elle-même pouvait être bloquée par certains ad-blockers, ce qui empêchait toute mesure en aval sans que personne ne s'en rende compte.
Ce constat a orienté tout le projet. Le server-side n'était pas une option technique parmi d'autres, c'était la condition pour débloquer un cas d'usage jusque-là inaccessible et pour reprendre la main sur une mesure devenue peu fiable.
Solution : un server-side on-premise sur GCP, une CMP synchronisée
Déployer une infrastructure de tagging server-side est à la portée de beaucoup d'équipes techniques. En tirer parti, neutraliser les ad-blockers, corriger l'ITP, poser des cookies first-party, en est une autre. Cela suppose une expertise dédiée à l'exploitation continue de cette infrastructure. Un tag mal configuré, un événement modifié sans le signaler, et c'est tout un flux vers Meta ou un autre partenaire qui s'interrompt silencieusement.
Addingwell : un on-premise qui laisse la main à Oscaro
Oscaro a tranché pour le modèle on-premise plutôt qu'une offre SaaS. Concrètement, le server-side tourne dans l'environnement Google Cloud Platform d'Oscaro, sur son propre compte de facturation. L'IT garde un contrôle total, avec une visibilité en temps réel sur les coûts serveur, un arbitrage du niveau de sécurité et une gouvernance du projet de bout en bout. Addingwell intervient en continu sur la partie qu'Oscaro ne veut pas internaliser, à savoir la maintenance de la stack, le monitoring, l'alerting et le support.
Ce partage des rôles profite aussi aux équipes métier, qui sollicitent directement le support Addingwell pour ajouter un tag ou tester un nouveau cas d'usage, sans passer par la file de tickets internes.
Sur le plan économique, le choix s'est révélé doublement gagnant. L'on-premise revient environ deux fois moins cher qu'une offre SaaS équivalente, et la facture réelle a fini sous les estimations initiales.
Didomi, une CMP pensée pour se synchroniser avec le server-side
La CMP Didomi complète le dispositif côté consentement, avec un objectif similaire d'autonomie. Les équipes marketing éditent leur bannière, ajoutent ou retirent un vendor et suivent leur taux de consentement sans dépendre de l'IT. Le critère qui a fait basculer le choix vers Didomi, c'est sa capacité à synchroniser étroitement ses données de consentement avec la couche server-side d'Addingwell. Un détail qui allait s'avérer déterminant pour la suite.
.webp)
Une mise en production sans filet, mais sans improvisation
Trois équipes ont préparé le lancement en parallèle. La roadmap, pour éviter les périodes commerciales chargées. La technique, pour que tout soit prêt le jour J. L'analytics, pour absorber le changement de référentiel de mesure.
Faute de budget, Oscaro a renoncé à faire tourner l'ancien et le nouveau système en double run. Un choix qui n'est pas sans risque méthodologique, puisque le server-side capte structurellement plus de données que le client-side. Comparer l'avant et l'après sans précaution aurait faussé toute analyse. L'équipe analytics a contourné le problème en calculant une moyenne sur les données post-migration, puis en appliquant un coefficient correcteur aux séries historiques, le temps de reconstituer un référentiel propre.
Résultat, quatre domaines configurés en une journée, GA4 server-side et Google Tag Manager opérationnels en moins d'une semaine.
L'onboarding a été très bon, avec des points réguliers permettant de valider ou débloquer le setup quand c'est nécessaire. Post-onboarding, l'équipe support est réactive quand il y a des questions autour du server-side
Maxime Donnet, Analytics & CRO Manager, Oscaro
Résultats : une mesure plus fiable, une marge sécurisée
Le bénéfice le plus inattendu du projet n'était pas dans le plan de départ. En croisant les données de consentement Didomi avec la couche server-side, les équipes d'Oscaro, Didomi et Addingwell ont repéré des incohérences qui ont mené à l'identification d'un bug de tracking sur le tag de pageview, invisible depuis le navigateur et indétectable sans cette remontée croisée.
Deuxième surprise, découverte en analysant les gains navigateur par navigateur. Sur certains environnements équipés d'ad-blockers, c'est la CMP elle-même qui se retrouvait bloquée. Sans bannière, pas de consentement collecté, donc aucun tag qui se déclenche. Le correctif, faire passer le SDK de la CMP par le reverse proxy Didomi, est en cours de déploiement et devrait encore renforcer la collecte sur Safari.
Fiabilité de la mesure et impact média
En complément, le CDN et le contournement des dispositifs de blocage ont généré environ 8 % de trafic mesuré supplémentaire.
Le cas Safari, une correction, pas une perte
-27 % de nouveaux visiteurs Safari. Un chiffre qui se lit comme une perte mais qui est en réalité une correction. Le plafond ITP de sept jours recomptait comme nouveaux des visiteurs déjà venus, soit plus d'un « nouveau » visiteur Safari sur quatre. Le cookie GA4 posé en first-party via Addingwell rétablit une vision juste de l'audience, un sujet loin d'être marginal puisque le trafic iOS au-delà de huit jours pèse environ 40 % du trafic total d'Oscaro, un volume comparable à celui de Chrome.
Performance technique et marge protégée
Le poids JavaScript des pages a diminué d'environ 10 % avec le retrait du tracking côté navigateur. Le temps de chargement reste stable à ce stade, une analyse plus fine des Core Web Vitals restant à mener.
Et l'objectif initial du projet est tenu. Le pilotage de la marge commerciale s'opère désormais entièrement côté serveur, sans qu'aucune donnée business ne transite par le navigateur.
Conclusion : un projet d'infrastructure, pas un chantier marketing
Ce que ce déploiement démontre, c'est qu'une donnée business aussi sensible que la marge commerciale peut devenir un cas d'usage exploitable, à condition de la traiter là où elle est protégée. Oscaro en tire trois leçons pour toute équipe qui envisagerait un projet comparable.
La première, c'est qu'un tel projet se traite comme une infrastructure et non comme un outil marketing. IT, front et analytics doivent être alignés dès le départ, sous peine de découvrir les frictions une fois le déploiement lancé. La deuxième, c'est l'importance de figer ses métriques de référence avant la bascule, surtout en l'absence d'une période de double run, pour ne pas perdre la capacité de comparer l'avant et l'après. La troisième, c'est de ne pas surpromettre les gains attendus et de laisser la mesure, une fois fiabilisée, parler d'elle-même.
À cela s'ajoute une recommandation plus technique, née d'une leçon apprise sur le terrain.
Aller au bout de la logique first-party. Sous-domaines dédiés, et faire passer aussi le SDK de la CMP par le reverse proxy, sinon la CMP elle-même peut être bloquée par certains bloqueurs, et c'est toute la mesure en aval qui disparaît. Nous l'avons vécu.
Maxime Donnet, Analytics & CRO Manager, Oscaro
Pour Oscaro, ce chantier a transformé une contrainte réglementaire en avantage opérationnel. La marge commerciale est désormais pilotée en toute confidentialité, la mesure sur Safari reflète l'audience réelle, et les équipes marketing ont retrouvé la main sur leur bannière de consentement. Autant de bénéfices qui reposent sur un principe simple. Traiter le consentement et le tracking comme un seul et même sujet de confiance.
