Un matin de janvier, un e‑commerçant nous transfère le mail que personne n’a envie de recevoir : « Produits refusés sur Google Shopping – prix incohérent ». On ouvre la Search Console, on inspecte les fiches produits, et là, rien. Aucune alerte dans le back‑office PrestaShop, les prix s’affichent correctement sur le front. On a mis deux heures à remonter jusqu’au vrai coupable : l’éco‑taxe. Une case cochée par défaut, une valeur d’éco‑participation héritée d’un import CSV mal formaté, et le prix TTC renvoyé dans le flux Merchant Center ne correspondait plus au prix réellement affiché sur la fiche produit. Résultat : 2000 références désactivées sans un bruit, un trou de 35 % dans le trafic shopping en une semaine.
Cet article n’est pas un énième mode d’emploi de l’éco‑taxe dans PrestaShop. Il part d’une conviction : l’éco‑taxe est l’un des rares leviers qui touchent à la fois la performance perçue, la validité des données structurées et l’éligibilité au trafic shopping. Si vous la traitez comme un simple champ administratif, vous passez à côté des trois problèmes qui peuvent vous coûter le plus cher en SEO e‑commerce.
L’éco‑taxe, ce champ que tout le monde coche et que personne ne teste
Dans PrestaShop, l’éco‑taxe se paramètre à deux endroits. D’abord au niveau de la fiche produit, dans l’onglet « Prix », avec un montant unitaire HT. Ensuite dans la configuration générale, où l’on peut activer l’affichage du détail de l’éco‑participation sur le front. Le CMS est bien fait : quand on saisit une valeur, le prix TTC affiché intègre automatiquement cette taxe additionnelle. La mécanique est transparente. Et c’est là que le piège se referme : parce que c’est transparent, personne ne vérifie ce que ça donne ailleurs.
Le premier effet de bord concerne les données structurées. PrestaShop génère par défaut un balisage JSON‑LD avec le prix TTC du produit. Si l’éco‑taxe est incluse dans le calcul du prix mais que vous avez modifié le template du Product schema sans y reporter l’éco‑participation, vous créez une incohérence entre le price affiché dans le DOM et celui envoyé au bot Google. Pour le Merchant Center, c’est un motif de refus immédiat. Les conditions sont documentées par Google : les attributs price et totalPrice doivent inclure toutes les taxes et frais additionnels obligatoires, dont l’éco‑participation. Si votre flux produit omet cette ligne ou si le montant diffère de quelques centimes, Google bloque la diffusion de l’annonce sans vous prévenir autrement que par une baisse du nombre d’impressions.
Le deuxième effet de bord, plus sournois, c’est le comportement des modules tiers. Beaucoup de modules d’affichage dynamique des prix (offres spéciales, compteurs de réduction, upsells en pop‑in) recalculent le prix côté client en JavaScript. Si le développeur du module a oublié de récupérer l’éco‑taxe dans l’objet product, le prix recalculé sera inférieur de quelques centimes ou dizaines de centimes. L’utilisateur final voit un prix X, puis un prix Y après ajout au panier. Cette discontinuité visuelle, en plus d’être illégale dans certaines juridictions, dégrade le Cumulative Layout Shift : le prix change, la zone du bouton « Ajouter au panier » se décale, et l’utilisateur tape à côté.
Le troisième problème est plus rare, mais nous l’avons rencontré sur une boutique en PrestaShop 8 qui utilisait un cache HTTP agressif. La page produit était servie en cache avec un prix TTC incluant l’éco‑taxe, mais lors de la réception d’un bot Googlebot, le serveur reconstruisait une version sans éco‑taxe parce qu’un filtre de personnalisation retirait la ligne « éco‑participation » pour les utilisateurs non identifiés. Le bot voyait un prix, l’acheteur un autre. Inutile de préciser que Google a fini par désindexer ces pages.
Le CLS que vous ne voyez pas
Ouvrez une fiche produit sur mobile avec la console Performance. Repérez le chargement du prix. Si le montant change entre le premier rendu et le rendu final, même de quelques pixels, il y a un problème d’éco‑taxe injectée en différé. On a mesuré un CLS de 0,18 rien qu’à cause d’un module qui remplaçait le prix TTC par un calcul AJAX incluant l’éco‑participation.
Ce type de décalage est directement corrélé à une dégradation du taux de conversion sur mobile. Le seuil Core Web Vitals pour le CLS est à 0,1. Un seul champ mal géré suffit à le franchir.
Données structurées : l’erreur à 0,10 € qui bloque Google Shopping
Un des cas les plus fréquents qu’on voit en audit : le flux produit est généré par un module tiers, souvent un export CSV ou un plugin de synchronisation. Le montant de l’éco‑taxe est omis, ou pire, inclus dans le prix de base au lieu d’être envoyé comme champ dédié. Dans la spécification Google Shopping, il n’y a pas de champ « éco‑taxe » en tant que tel : le prix annoncé doit être le prix TTC total, toutes taxes comprises. Si votre flux envoie un price sans l’éco‑taxe alors que votre front l’affiche, l’écart est flagrant. Le Merchant Center compare le prix du flux avec celui extrait des données structurées de la page produit. Toute divergence au centime près déclenche une erreur price_mismatch.
La correction est simple sur le principe, mais elle demande de la rigueur dans le mapping des champs. Dans PrestaShop, le prix TTC complet est accessible via la méthode Product::getPriceStatic() avec le paramètre $include_ecotax à true. Si vous écrivez votre propre export, vérifiez que la fonction que vous appelez inclut bien ce booléen. Si vous utilisez un module du marketplace, testez deux ou trois fiches avec l’outil Rich Results Test de Google pour vérifier que le price JSON‑LD correspond à celui affiché. Si ce n’est pas le cas, changez de module ou corrigez le template.
L’autre piège, c’est l’arrondi. L’éco‑taxe est souvent un montant avec deux ou trois décimales. PrestaShop arrondit ensuite le prix TTC selon les règles de la devise. Si votre flux arrondit différemment de la méthode interne, l’écart de 0,01 € suffit à faire tomber la fiche. On a vu un site perdre 4000 produits pour un écart de 1 centime sur une éco‑taxe de 0,42 €. Le test est rapide : comparez le totalPrice du JSON‑LD et la valeur de l’attribut price du flux sur trois produits à éco‑taxe. Si les deux ne sont pas strictement identiques, vous avez un bug.
Faites le test en 3 requêtes
Tutoyons‑nous pour ce qui suit, parce qu’on va mettre les mains dans le terminal. Ouvre ta fenêtre de commande et exécute ce curl sur une fiche produit :
curl -s https://tonsite.com/fiche-produit | grep -oP '"price":"?\K[0-9.]+'Tu obtiens le prix extrait du JSON‑LD. Compare‑le avec le prix affiché dans ta page, TTC, éco‑participation incluse. Ensuite, vérifie le flux si tu as un accès direct :
grep 'g:id>SKU123' ton-flux.xml | grep 'g:price'Si les deux valeurs ne sont pas égales en chaîne, ne cherche pas plus loin. La troisième requête, c’est l’outil de test des données structurées de Google : tu copies l’URL de la fiche, et tu regardes si le champ price apparaît en vert dans l’extrait. Si c’est rouge, l’éco‑taxe est probablement dans la nature.
Cette vérification prend moins de trois minutes. Fais‑la sur les dix produits qui font le plus gros volume d’impressions dans ton Merchant Center. C’est un check bien plus rentable que de courir après un hypothétique bug de rendu.
Modules JavaScript : quand l’éco‑taxe devient un cauchemar de rendu
Certaines boutiques PrestaShop ont migré leur front vers des frameworks JavaScript. Dans ce cas, le prix n’est pas assemblé côté serveur, mais côté client, via un appel API qui renvoie un objet product. Si le endpoint omet l’éco‑taxe ou la renvoie dans un champ séparé que le composant d’affichage ne lit pas, le prix affiché est faux. Et comme le rendu est dynamique, le JSON‑LD est souvent généré après l’hydratation, ce qui peut introduire un décalage temporel suffisant pour que le crawl de Googlebot ne voie pas le prix final à temps.
Un lead dev que nous connaissons a résolu ce problème en centralisant le calcul du prix TTC dans un store Zustand, avec un sélecteur unique qui compose le prix de base, la TVA et l’éco‑taxe. Le pattern est intéressant : plutôt que de recalculer le prix dans chaque composant, un seul point de vérité garantit que l’affichage et le balisage schema.org sont cohérents. C’est le genre d’approche qu’un state management bien pensé rend triviale, comme on l’a détaillé dans notre test de Zustand pour un state management efficace sur React.
L’autre risque du rendu côté client, c’est le flash de prix. Pendant la fraction de seconde où le JavaScript n’a pas encore récupéré les données, le prix affiché est celui du squelette HTML, souvent un montant sans éco‑taxe. Ce flash crée un changement de layout qui dégrade le CLS. La parade consiste à pré‑rendre le prix complet côté serveur, y compris l’éco‑taxe, et de l’injecter dans le HTML initial avant l’hydratation. Si vous développez une surcouche PrestaShop en Next.js, cette remarque vaut tous les fetchPriority hints que vous pourriez ajouter.
Pendant un debug de ce type sur un projet, on a utilisé un outil d’analyse de code qui nous a permis de repérer en quelques secondes le composant responsable du double rendu. Sans entrer dans un comparatif exhaustif, un assistant comme Claude Code peut vous faire gagner un temps précieux pour naviguer dans une base legacy PrestaShop où le pricing est dispersé dans trente fichiers. Nous avions documenté cette utilisation dans notre article Claude Code vs Cursor IDE.
Enfin, dernier point : n’oubliez pas que l’éco‑taxe est un attribut produit, pas un panier. Si un module de cart summary recalcule le total sans inclure l’éco‑taxe, vous allez créer un delta entre le prix produit et le panier. L’utilisateur ressentira une friction, et le CLS n’est plus votre seul souci : c’est le taux d’abandon panier qui grimpe.
Questions fréquentes
Faut‑il désactiver l’éco‑taxe si on ne vend pas de produits concernés ? La désactiver globalement est plus sûr que de la laisser active avec des valeurs nulles dans les champs. Si vous ne vendez aucun produit soumis à éco‑participation, mettez le montant à zéro et désactivez l’affichage public. Évitez surtout d’importer un CSV avec la colonne éco‑taxe vide : certaines versions de PrestaShop interprètent le vide comme « ne pas toucher » et conservent une ancienne valeur.
Pourquoi le Merchant Center me renvoie une erreur de prix alors que tout semble correct ? Dans 90 % des cas qu’on diagnostique, c’est une éco‑taxe incluse dans l’affichage mais absente du flux, ou une différence d’arrondi entre le calcul PHP de PrestaShop et la fonction d’arrondi de votre module d’export. Vérifiez d’abord ce point avant d’incriminer les délais de crawl.
Comment gérer l’éco‑taxe avec une boutique multi‑devises ? L’éco‑taxe est définie en euros dans la base de PrestaShop. Si vous activez une seconde devise, assurez‑vous que le taux de conversion ne s’applique pas deux fois. Désactivez le recalcul automatique de l’éco‑taxe par le convertisseur de devises et fixez le montant converti manuellement si la législation l’exige dans le pays cible. Le balisage schema.org doit refléter le prix dans la devise locale.
