520 % de ROAS moyen après une refonte PrestaShop, une correction du tracking et un travail d’automatisation

Meca Express, dirigé par Vincent Junillon, vend des catalyseurs et des pièces automobiles associées en ligne via deux vitrines françaises : e-catalyseur.fr et meca-express.fr. Les deux tournent sous le même nom d’entreprise. Le modèle commercial est celui d’un e-commerce spécialisé classique — profondeur de catalogue, demande sensible au fitment, et un budget paid search assez élevé pour que une mauvaise mesure coûte cher, sans être assez volumineux pour que le bruit disparaisse dans la masse.

Au moment de l’engagement, le stack était PrestaShop sur une version PHP obsolète. Ce n’est pas un détail cosmétique. Un runtime PHP ancien et une version PrestaShop ancienne contraignent la fiabilité du checkout, les performances de page, et ce que l’on peut modifier sans risque dans la couche de mesure. Google Ads tournait déjà sur cette fondation, avec une dépense mensuelle d’environ 5 000 à 7 000 €.

Le brief n’était pas « corrigez une balise purchase cassée et partez ». Il s’agissait de rendre les sites aptes à une mesure e-commerce moderne, puis de piloter Ads sur un signal digne de confiance. Fadhil Mezouar a mené le travail pour Propulse Agency en engagement direct avec le client.

Ce qui ressemblait, depuis l’interface Ads, à un problème de performance était en réalité trois problèmes distincts partageant le même compte de résultat.

Premier point : la plateforme elle-même. Faire tourner PrestaShop sur un PHP obsolète est d’abord un problème d’infrastructure, avant d’être un problème marketing. Des parcours checkout lents ou fragiles font baisser le taux de conversion tout seuls. Les contraintes de thèmes et de modules rendent une instrumentation d’événements propre plus difficile qu’elle ne devrait l’être. On ne peut pas demander honnêtement à Smart Bidding de récupérer ce que la vitrine perd au moment de l’achat.

Deuxième point : le tracking n’était pas correctement configuré. Nous n’allons pas inventer ici une liste colorée de déclencheurs cassés — les faits client ne comportent pas d’inventaire défaut par défaut, et en inventer un serait exactement le type de fiction d’agence que cette page cherche à éviter. Ce que nous pouvons affirmer avec précision, c’est que la couche de mesure n’était pas correctement mise en place pour le reporting e-commerce vers Google Ads. Dans ce cas, le compte est piloté sur une vue partielle de la réalité : une partie des achats sous-attribués, des valeurs peu fiables, des étapes de funnel absentes du tableau. L’enchère optimise alors contre la fraction de vérité que les balises arrivent à capturer.

Troisième point : l’automatisation du site n’était pas optimisée. Là encore, les workflows précis ne sont pas détaillés dans les faits que nous avons le droit de publier, donc nous ne les inventerons pas. Le point opérationnel est plus simple : quand l’automatisation catalogue, commandes ou reporting sous-performe, le paid search hérite des frictions — flux retardés, changements de statut tardifs, rapprochement Ads / carnet de commandes qui traîne.

Pris isolément, chacun de ces trois points peut faire bouger le ROAS. Ensemble, ils font du tableau de bord Ads un mauvais endroit pour diagnostiquer la cause. Une base à 380 % dans ce contexte n’est pas un chiffre propre de « qualité de campagne ». C’est le produit combiné d’une vitrine vieillissante, d’une mesure incomplète et d’une automatisation sous-réglée, avec la dépense média par-dessus.

L’ordre du diagnostic comptait. Nous n’avons pas ouvert Google Ads en premier pour inventer une histoire d’enchères.

Nous avons commencé par la réalité commerciale des deux vitrines : comment les commandes étaient réellement finalisées, ce que les versions PrestaShop/PHP permettaient ou interdisaient, et où le parcours checkout était assez fragile pour supprimer de la conversion indépendamment des médias. Le risque plateforme devait être nommé avant toute recommandation média, parce qu’un brief « tracking seul » aurait laissé intact le plafond de taux de conversion.

Ensuite seulement, nous avons inspecté la couche de mesure — le même type de travail que nous documentons dans notre pratique d’audit GA4 : quels événements atteignaient les plateformes pub, si les valeurs d’achat semblaient réconciliables avec les commandes, et si le funnel était assez visible pour être piloté. Le constat n’était pas « Ads est cassé ». Le constat était « Ads vole partiellement à l’aveugle sur une vitrine qui a aussi besoin d’une montée de version plateforme ».

De là, nous avons cadré l’automatisation du site : ce qui était censé maintenir à jour le catalogue et les processus côté commandes, et où cela sous-performait par rapport à une opération paid search de plusieurs milliers d’euros par mois. Le plan d’engagement qui a suivi a traité plateforme, mesure et automatisation comme une seule fenêtre de refonte — pas trois tickets sans lien.

On commence par le chiffre représentatif, pas par le pic. Après la mise en ligne de la refonte combinée, le ROAS Google Ads est passé d’une base de 380 % à un pic de 580 % dès le premier mois complet, puis s’est stabilisé autour d’une moyenne soutenue de 520 % sur la suite de l’engagement. La dépense mensuelle est restée dans la fourchette d’environ 5 000 à 7 000 €. La fenêtre de mesure est le premier mois complet après la mise en ligne de la montée de version site et du tracking corrigé, par rapport à la période précédente ; l’année de montée de version plateforme est 2022.

Comment lire ce chiffre. Ce résultat reflète trois choses changées ensemble — une plateforme PrestaShop/PHP obsolète mise à niveau, un tracking corrigé, et une automatisation du site optimisée — avec Google Ads géré par-dessus cette fondation plus propre. Ce n’est pas un avant/après tracking seul. Nous le présentons ainsi parce que c’est ainsi que l’engagement s’est réellement déroulé : un site sur ancien PHP, avec un tracking mal configuré et une automatisation sous-optimisée, est un schéma courant, et corriger ces couches ensemble est en pratique ce à quoi ressemble souvent une vraie récupération de ROAS.

Nous n’avons pas de répartition nette entre attribution récupérée et gain de performance réel. La même fenêtre a changé l’environnement de conversion de la vitrine, le signal de conversion qu’Ads pouvait voir, et l’automatisation qui alimentait l’opération. Toute tentative d’attribuer « X points au tracking, Y points à la plateforme » serait une précision inventée. Le chiffre d’affaires derrière le ROAS était réel dans tous les cas ; l’affirmation honnête, c’est que le compte a cessé d’être piloté à l’aveugle sur une fondation cassée.

Nous ne revendiquons pas non plus le tagging server-side, la Meta CAPI ou les Enhanced Conversions comme parties de cet engagement — ces éléments n’ont pas été confirmés dans les faits de cette page. Si vous cadrez une refonte similaire aujourd’hui et avez besoin d’une architecture de collecte first-party, c’est une décision séparée couverte sous le tracking server-side. De même, les exigences Consent Mode ont évolué depuis 2022 ; une refonte en 2026 devrait intégrer le Consent Mode v2 dans la conception de la mesure dès le premier jour.

La plupart des comptes paid search que nous héritons n’échouent pas parce que quelqu’un a oublié un mot-clé négatif. Ils échouent parce que la vitrine, la couche de mesure et l’automatisation opérationnelle sous Ads contribuent chacune une taxe discrète — et l’interface Ads ne peut rapporter que le résidu combiné.

Si vous faites tourner PrestaShop (ou tout stack commerce vieillissant) avec quelques milliers d’euros par mois en Google Ads, la question utile n’est pas « peut-on essayer encore une stratégie d’enchères ? ». C’est de savoir si la plateforme, le dataLayer et l’automatisation survivraient à un audit honnête. C’est le schéma d’engagement que documente cette étude de cas.

Réservez un audit technique gratuit. Nous vous dirons si votre plafond est média, mesure, ou le site lui-même.