Google Tag Manager pour PrestaShop : configurez votre suivi sans toucher au code

Cet article couvre PrestaShop 1.7, 8 et 9 ; GA4 est désormais la seule version de Google Analytics (Universal Analytics a pris fin en juillet 2023), et le Consent Mode v2 est obligatoire pour les fonctionnalités Google Ads dans l’EEE.

La promesse est dans le titre, mais il y a une condition derrière. Google Tag Manager permet réellement d’ajouter, modifier et supprimer des scripts de suivi depuis une interface web, sans jamais retoucher au code de votre boutique. Une fois qu’il est installé. Mais intégrer GTM dans une boutique PrestaShop, puis lui faire comprendre ce que font réellement les acheteurs, c’est la partie dont personne ne vous parle. PrestaShop ne fournit pas à GTM un flux propre et prêt à l’emploi d’événements e-commerce. Par défaut, un conteneur GTM vide ne fait rien tout seul. Une balise GA4 dans GTM peut suivre les pages vues, mais les rapports e-commerce exigent des événements explicites envoyés au dataLayer ; sinon, vous obtenez des statistiques de trafic, sans le moindre ajout au panier, sans étape du tunnel de commande et sans valeur d’achat. Ce guide sert précisément à combler cet écart sur PrestaShop : comment installer le conteneur correctement, pourquoi le dataLayer est le cœur du sujet, et comment le faire sur 1.7, 8 et 9 sans forker votre thème.

Si vous êtes encore en train de décider quelles balises doivent aller dans votre conteneur au départ, c’est une autre question. Commencez par ce qu’il faut suivre et ce qu’il vaut mieux ignorer, puis revenez ici pour la plomberie.

Ce qu’est vraiment GTM, et ce qu’il n’est volontairement pas

Google Tag Manager est un script conteneur unique que vous installez une seule fois. Ensuite, tous les autres scripts de suivi, GA4, conversions Google Ads, Meta Pixel, balise Pinterest, chargeur de widget de chat, vivent dans GTM et se gèrent depuis tagmanager.google.com, pas depuis votre thème. Le gain est très concret : la prochaine fois que le marketing vous demande « d’ajouter juste le nouveau pixel », vous le faites en deux minutes dans un formulaire web, vous le prévisualisez, puis vous publiez, au lieu d’ouvrir un client FTP, de modifier un .tpl, de vider le cache et d’espérer que la prochaine mise à jour du thème ne l’effacera pas.

Ce que GTM n’est pas : ce n’est pas un outil d’analytics. Il ne collecte rien et ne produit aucun rapport par lui-même. C’est un répartiteur, il écoute des événements et déclenche les bonnes balises avec les bonnes données. Cette distinction compte sur PrestaShop, parce que les événements que GTM déclenche doivent venir de quelque part, et PrestaShop ne les génère pas pour vous. Gardez cette idée en tête ; c’est le point central de tout l’article.

Pourquoi tout faire passer par GTM sur une boutique PrestaShop

Un seul script au lieu de cinq qui cassent à chaque mise à jour du thème

Une boutique PrestaShop typique accumule le suivi de façon désordonnée : GA4 collé dans header.tpl, un Meta Pixel ajouté via un module gratuit, le code de conversion Google Ads modifié à la main dans order-confirmation.tpl, puis un extrait de remarketing ajouté un jour et oublié. Chacun devient un point de défaillance séparé, et chaque mise à jour de thème ou reconstruction de thème enfant peut en faire disparaître un en silence. Avec GTM, la boutique porte un seul conteneur ; tout le reste passe dans le tableau de bord. Et concrètement ? Vous ne découvrez plus trois semaines plus tard que votre suivi des conversions s’est éteint après un changement de template. Il n’y a plus qu’un script à protéger au lieu de cinq.

Historique des versions et retour arrière instantané

GTM versionne chaque publication. Vous poussez un changement, les chiffres deviennent étranges, et vous revenez à la version précédente en un clic. Coller des codes dans les fichiers du thème ne vous offre rien de tout cela, votre seul « retour arrière » consiste à vous souvenir exactement de ce que vous avez supprimé, et où.

Mode aperçu avant toute mise en ligne

Le mode Aperçu de GTM (Tag Assistant) se connecte à votre vraie boutique et vous montre, balise par balise, ce qui s’est déclenché sur chaque page et quelles données ont été transmises, visible uniquement par vous, invisible pour les acheteurs. Sur PrestaShop, c’est là que vous repérez l’échec classique : vous ouvrez une page produit en mode Aperçu et la balise GA4 view_item ne se déclenche tout simplement pas, parce que l’événement dataLayer qu’elle attend n’a jamais été émis. Mieux vaut l’apprendre dans l’Aperçu qu’après un mois de rapports d’entonnoir vides.

Chargement conditionnel et différé

Les balises peuvent être configurées pour ne se déclencher que là où elles sont nécessaires, la balise de conversion Google Ads uniquement sur la page de confirmation de commande, un chargeur de heatmap uniquement sur les pages catégorie et produit, rien de lourd sur la page d’accueil. Vous évitez ainsi d’ajouter du poids marketing sur les pages où ces scripts ne servent à rien. Le chargement se fait de façon asynchrone après votre contenu, ce qui évite à votre score PageSpeed de subir l’impact d’une pile de scripts synchrones dans l’en-tête.

Installer le conteneur GTM sur PrestaShop

Vous avez deux options sérieuses, et la bonne dépend de votre volonté de retoucher un jour aux fichiers du thème.

Option A, la modification du template (la méthode littérale des « deux extraits »)

GTM vous donne deux extraits lorsque vous créez un conteneur Web : l’un pour le <head> et l’autre à placer immédiatement après l’ouverture du <body>. Dans un thème PrestaShop 1.7/8/9 basé sur Classic, l’extrait head va dans themes/your-theme/templates/_partials/head.tpl, et l’extrait body (le fallback iframe <noscript>) se place près du début de layouts/layout-both-columns.tpl ou de votre layout de base. Modifiez un thème enfant, jamais le parent. Une modification du thème parent est exactement le genre de changement qu’une future mise à jour annule en silence. Après modification, videz le cache depuis Paramètres avancés → Performances (ou supprimez var/cache), sinon votre changement ne sera pas rendu.

Un piège propre à PrestaShop : si vous avez un cache agressif ou un CDN devant la boutique, l’extrait du conteneur fait partie du HTML mis en cache ; une ancienne page en cache peut donc continuer à servir un ancien ID de conteneur. Videz les deux couches lorsque vous changez de conteneur.

Option B, la voie du module (sans modification de template)

La raison pour laquelle la plupart des marchands finissent ici n’est pas la paresse. C’est que l’option A ne résout que la moitié du problème. Coller le conteneur charge GTM ; cela ne fait rien pour le dataLayer, qui est la partie difficile sur PrestaShop (section suivante). Un vrai module GTM/dataLayer injecte le conteneur et émet les événements e-commerce sur les bons hooks PrestaShop, le tout configuré depuis le back-office. Et concrètement ? Vous obtenez un tunnel d’achat fonctionnel sans ouvrir le moindre template, et il résiste aux mises à jour parce que c’est un module, pas une modification de thème.

Le dataLayer : la partie qui relève vraiment de PrestaShop

C’est ici que « configurer le suivi sans toucher au code » devient honnête. GTM ne peut déclencher une balise que lorsqu’il reçoit un événement. Pour l’e-commerce, GA4 attend un vocabulaire précis d’événements avec une structure de données précise, view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, chacun envoyé à un objet JavaScript appelé dataLayer, avec les ID produit, prix, quantités et, pour l’achat, l’ID de commande, la valeur, la taxe et les frais de livraison.

PrestaShop n’émet rien de tout cela par défaut. Le thème standard affiche les pages produit et de commande sans jamais pousser d’événement dataLayer au format GA4. Une installation GTM brute vous donne donc des pages vues et rien d’autre, aucune idée des produits consultés, aucun signal d’ajout au panier, aucun chiffre d’affaires. L’entonnoir est vide au milieu. Ce fait explique à lui seul pourquoi le conseil « installez juste GTM » échoue sur PrestaShop et fonctionne correctement sur une boutique Shopify qui fournit ces événements nativement.

Vous avez trois façons d’alimenter le dataLayer :

• Un module qui émet les événements. Un module GTM/dataLayer s’accroche aux points où PrestaShop sait déjà ce qui se passe, displayProductAdditionalInfo / page produit pour view_item, la réponse AJAX add_to_cart du panier, le contrôleur de commande pour les étapes début/livraison/paiement, et le hook de confirmation de commande (displayOrderConfirmation, qui est le hook de rendu front-office capable d’émettre le push JavaScript, et non le hook PHP côté serveur actionValidateOrder, qui se déclenche simplement quand la commande est créée) pour purchase, puis pousse des événements correctement structurés. C’est la voie sans code et celle que la plupart des boutiques devraient choisir.
• Des pushes dataLayer écrits à la main dans votre thème. Vous ajoutez vous-même le JavaScript en lisant les données existantes de PrestaShop JS (prestashop.cart, l’objet produit exposé sur la page, les variables de commande sur la page de confirmation). Contrôle total, mais c’est un vrai travail front-end et cela casse si votre thème change, l’inverse de la promesse du titre.
• Du scraping uniquement dans GTM. Tentant, mais fragile : utiliser des variables GTM pour extraire les prix et les ID depuis le DOM. Cela fonctionne jusqu’au jour où une retouche du thème renomme une classe CSS ; vos données de chiffre d’affaires deviennent alors fausses en silence. À éviter pour tout ce qui alimente les enchères Google Ads.

Quelle que soit l’option choisie, la structure attendue par GTM sur la page de confirmation de commande ressemble à ceci. Notez la clé event: 'purchase'. Cette chaîne est ce qu’un déclencheur GTM Custom Event écoute pour lancer votre balise d’achat GA4, et c’est précisément ce que le scraping DOM ne peut pas reproduire de façon fiable. Les valeurs sont les propres variables de commande de PrestaShop ($order->reference, totaux, ISO de la devise, lignes produit), rendues et échappées dans le template :

<script>
  window.dataLayer = window.dataLayer || [];
  dataLayer.push({ ecommerce: null });  // reset so items can't leak in
  dataLayer.push({
    event: 'purchase',                  // GTM Custom Event trigger listens on this
    ecommerce: {
      transaction_id: '{$order.reference}',
      value: {$order.total_paid|floatval},
      tax: {$order.total_tax|floatval},
      shipping: {$order.total_shipping|floatval},
      currency: '{$currency.iso_code}',
      items: [
        {foreach $products as $p}
        {ldelim}
          item_id: '{$p.reference}',
          item_name: '{$p.name|escape:'javascript'}',
          price: {$p.price_amount|floatval},
          quantity: {$p.quantity|intval}
        {rdelim}{if !$p@last},{/if}
        {/foreach}
      ]
    }
  });
</script>

Dans GTM, vous lisez ensuite chaque champ avec une Data Layer Variable (ecommerce.transaction_id, ecommerce.value, etc.) et vous les mappez dans la balise d’événement d’achat GA4. Protégez le push pour qu’il ne se déclenche qu’une seule fois par référence de commande, sinon un rechargement de la page de confirmation comptera la vente deux fois.

Le résumé honnête : le seul moyen véritablement sans code et sûr lors des mises à jour pour obtenir un dataLayer PrestaShop complet est d’utiliser un module qui s’en charge. Tout le reste implique de toucher au code ou d’accepter une certaine fragilité.

Les balises essentielles. En bref, parce que la difficulté est dans la structure des données

Une fois les événements arrivés dans le dataLayer, les balises elles-mêmes relèvent de GTM standard et ne sont pas propres à PrestaShop ; voici donc la carte courte plutôt qu’un tutoriel générique :

• Configuration GA4 + balises d’événement, votre première balise ; le tag/config Google GA4 plus les balises d’événement GA4 envoient les événements e-commerce recommandés, comme view_item, add_to_cart, begin_checkout et purchase, depuis le dataLayer. Pour savoir quelles métriques GA4 méritent vraiment votre attention plutôt que d’ajouter du bruit, consultez les métriques GA4 qui comptent vraiment, et pour configurer entièrement la propriété et le flux, le guide complet de configuration GA4.
• Conversion Google Ads + remarketing, déclenchez la balise de conversion sur la confirmation de commande, en transmettant la valeur de la commande et l’ID de transaction ; la balise de remarketing construit des audiences à partir des vues produit et des paniers abandonnés.
• Meta / pixels d’autres plateformes, installez-les via GTM plutôt qu’avec des modules séparés, afin de tout gérer (et contrôler par consentement) au même endroit.

Quelle que soit la balise ajoutée, la discipline ci-dessous compte davantage que la liste des tags.

Évitez le double comptage : GTM contre les modules d’analytics PrestaShop

Le problème le plus fréquent que nous voyons sur PrestaShop est le double suivi. Beaucoup de boutiques utilisent un module Google Analytics comme ps_googleanalytics / "PrestaShop Google Analytics", considérez-le comme un module, pas comme des statistiques natives de PrestaShop, et beaucoup l’ont activé en même temps qu’une balise GA4 déclenchée via GTM. Résultat : chaque page vue, chaque achat, chaque euro de chiffre d’affaires est compté deux fois, rapports gonflés, taux de conversion faussés et Google Ads qui optimise sur des ventes fantômes.

Choisissez une seule voie. Si vous misez entièrement sur GTM (le bon choix pour la plupart des boutiques en croissance), désactivez le module GA dans Modules → Gestionnaire de modules et laissez GTM piloter toutes les balises. Si vous avez seulement besoin d’un GA4 basique et de rien d’autre, un module GA seul peut suffire, mais uniquement si sa version actuelle prend en charge GA4 et les événements e-commerce dont vous avez besoin, et vous n’avez alors pas besoin de GTM. Ce qu’il ne faut jamais faire, c’est faire tourner les deux sur la même propriété. Vérifiez-le dans le DebugView de GA4 avec le mode Aperçu activé : chaque action doit apparaître exactement une fois.

Consentement : RGPD/RODO et la réalité de PrestaShop

Dans l’UE, la plupart des balises marketing et analytics nécessitent un consentement avant leur déclenchement, et GTM est le bon endroit pour l’imposer via Google Consent Mode v2. La subtilité propre à PrestaShop : PrestaShop n’a pas de bannière cookies native compatible avec le Consent Mode. Les blocs CCC/textes légaux fournis ne constituent pas une plateforme de gestion du consentement. Il vous faut donc une vraie CMP (un module dédié ou une CMP certifiée par Google) qui définit les signaux Consent Mode, puis vous conditionnez vos balises GTM à ces signaux.

Consent Mode existe en deux variantes, qui se comportent différemment lorsque le consentement est refusé ; choisissez donc celle que votre boutique utilise :

• Mode basique : les balises Google ne se chargent pas du tout tant que le consentement n’est pas accordé. Avant consentement, les balises analytics et publicitaires restent en attente et ne déclenchent rien ; si le consentement est refusé, elles restent bloquées et n’envoient aucun ping.
• Mode avancé : les balises Google se chargent dès le départ, mais avec le stockage défini comme refusé. Quand le consentement est refusé, elles envoient tout de même des pings agrégés sans cookies que Google peut utiliser pour la modélisation ; une fois le consentement accordé, elles passent à la mesure complète.
• Après consentement : dans les deux modes, les balises se déclenchent selon les catégories acceptées par le visiteur.

Les pings de modélisation sans cookies n’existent qu’en mode avancé, le mode basique bloque jusqu’au consentement, donc n’attendez pas de signaux en état refusé avec ce mode. Choisissez un modèle et configurez votre CMP ainsi que vos balises GTM de façon cohérente autour de lui.

Configurez la barrière une seule fois au niveau de GTM plutôt que script par script, cela centralise la conformité et transforme un audit en tâche de cinq minutes au lieu d’une chasse aux templates. Si le consentement et la propriété des données sont des sujets majeurs pour votre boutique, il vaut aussi la peine d’évaluer une stack orientée confidentialité : Matomo vs Google Analytics.

Checklist PrestaShop avant de lancer GTM

• Conteneur présent sur chaque type de page, page d’accueil, catégorie, produit, panier, tunnel de commande et confirmation de commande. Confirmez dans l’Aperçu que la page de confirmation (le seul endroit où purchase peut se déclencher) porte bien le conteneur ; c’est la page la plus facile à oublier si elle utilise un layout différent.
• purchase se déclenche une seule fois, avec la bonne valeur, vérifiez que l’ID de commande, la valeur, la taxe et les frais de livraison correspondent à la commande réelle, et qu’un rafraîchissement de page ne le déclenche pas deux fois.
• Aucun GA en double, module GA PrestaShop désactivé si GTM gère GA4.
• La barrière de consentement fonctionne. Avec le consentement refusé, les balises analytics/publicitaires doivent rester bloquées dans DebugView.
• Cache vidé, après tout changement de conteneur ou de template, videz le cache PrestaShop et votre CDN.

Où GTM est utile, et où il s’arrête

GTM rentabilise son installation dès le premier jour. Pas en argent, puisqu’il est gratuit, mais en sessions FTP que vous n’ouvrez plus et en suivi que vous ne perdez plus silencieusement lors des mises à jour de thème. Sur PrestaShop en particulier, tout le travail se résume à deux choses que la plateforme ne fait pas pour vous : intégrer proprement le conteneur (thème enfant ou module, jamais le thème parent), et l’alimenter avec un dataLayer complet et correctement structuré (un module est la seule façon sans code de le faire de manière fiable). Faites correctement ces deux points et la promesse du titre devient réelle. Chaque future balise devient un formulaire web, pas un déploiement.

Questions fréquentes

Si j’installe GTM, ai-je encore besoin d’un module GA4 sur PrestaShop ?

Il vous faut l’un ou l’autre pour GA4, pas les deux sur la même propriété, exécuter un module GA et une balise GA4 via GTM en même temps double chaque page vue et chaque achat. La vraie question est de savoir qui alimente le dataLayer. GTM déclenche les balises, mais ne génère pas les événements e-commerce de PrestaShop ; quelque chose doit encore pousser view_item, add_to_cart et purchase. Si vous ne voulez pas écrire cela à la main dans votre thème, un module dataLayer le fait depuis les hooks PrestaShop, et vous pointez vos balises GTM vers les événements qu’il émet.

Pourquoi mon GTM affiche-t-il des pages vues, mais aucun ajout au panier ni chiffre d’affaires ?

Parce que le conteneur est présent, mais que le dataLayer est vide. Une installation GTM brute sur PrestaShop suit les pages vues et rien d’autre, le thème par défaut ne pousse jamais d’événements e-commerce au format GA4. L’entonnoir reste vide au milieu jusqu’à ce qu’un module ou du code écrit à la main émette ces événements. C’est la plainte « GTM ne fonctionne pas sur PrestaShop » la plus fréquente, et ce n’est pas un bug de GTM ; c’est le dataLayer manquant.

Dois-je extraire les prix et les ID depuis la page avec des variables GTM ?

Évitez-le pour tout ce qui compte vraiment. Le scraping DOM fonctionne jusqu’à ce qu’une retouche du thème renomme une classe CSS ; vos données de chiffre d’affaires et d’enchères Google Ads deviennent alors fausses en silence, sans erreur visible. Poussez plutôt de vraies valeurs vers le dataLayer depuis les objets commande et produit de PrestaShop, c’est la différence entre des données fiables et des données qui cassent à la prochaine mise à jour du thème.

Où placer le conteneur pour qu’il survive aux mises à jour du thème ?

Jamais dans le thème parent. Une modification du thème parent est exactement ce qu’une future mise à jour écrasera. Modifiez soit un thème enfant (extrait head dans _partials/head.tpl, extrait noscript body près du début de votre layout de base), soit utilisez un module qui injecte le conteneur via un hook, sans aucune chirurgie dans les templates. Dans les deux cas, videz le cache PrestaShop et votre CDN, sinon une ancienne page en cache peut continuer à servir un ancien ID de conteneur.

Consent Mode basique ou avancé, lequel choisir pour ma boutique ?

Avancé si vous voulez des données modélisées lorsque le consentement est refusé : les balises Google se chargent avec le stockage refusé et envoient des pings agrégés sans cookies jusqu’à ce que le visiteur accepte. Le mode basique bloque entièrement les balises jusqu’au consentement et n’envoie aucun ping en état refusé. Les deux sont valides ; choisissez-en un et configurez votre CMP ainsi que vos balises GTM de façon cohérente. Quel que soit votre choix, appliquez la barrière une seule fois au niveau de GTM plutôt que script par script. Si le consentement et la propriété des données sont des sujets prioritaires, il vaut aussi la peine d’évaluer une stack orientée confidentialité, voir Matomo vs Google Analytics.

Une limite honnête : GTM vous dit qu’une étape a eu lieu, il compte les ajouts au panier, les tunnels de commande commencés, les achats. Il ne peut pas vous montrer pourquoi un acheteur a cliqué frénétiquement sur un filtre cassé ou abandonné à l’étape de livraison. Pour le « pourquoi », associez-le à des outils au niveau de la session, voir Microsoft Clarity et les heatmaps et enregistrements de session Hotjar. Et une fois les chiffres propres, la question devient : comment les transformer en décisions rentables ? Notre module de reporting Financial Revolution lit directement les vraies données de commande de votre boutique, pas de dataLayer, pas de balise, pas d’échantillonnage, afin que vos rapports de marge et de chiffre d’affaires reposent sur ce qui a réellement été payé, et non sur ce qu’une balise de navigateur a réussi à capturer. Dernière note pour 2026 : une part croissante du « trafic » n’est pas humaine, et les sessions de bots peuvent polluer discrètement les événements mêmes que GTM transmet à Google, un point à comprendre avant de faire confiance à un entonnoir ; voir Google Storebot dans votre boutique PrestaShop.