Remplacer un plugin analytics tout-en-un par GTM proprement

Remplacer un plugin analytics tout-en-un par GTM se fait sans casser vos données si vous gardez la même propriété GA4 et le même identifiant de mesure, et si les deux systèmes tournent en parallèle avant la bascule. Le plugin ne doit être désactivé qu’après une recette comparée, jamais avant. Les deux pièges les plus fréquents sont les événements renommés, qui cassent des conversions sans alerte, et le cache, qui fait survivre l’ancien script après la bascule.

Avant de commencer

⏱ 2 à 3 h de travail, 7 jours de recette Niveau : Intermédiaire

• Accès administrateur au CMS et au plugin analytics
• Accès éditeur au conteneur GTM (ou droit d'en créer un)
• Accès éditeur à la propriété GA4 et à son identifiant de mesure
• Un plan de marquage cible, même court
• Un moyen de purger le cache du site (plugin, CDN)

Les symptômes qui justifient la migration

Un seul de ces symptômes justifie rarement de changer d’outil. Deux ou plus, oui :

• Double tag : le plugin et GTM (ou le thème) envoient chacun un page_view, et les rapports gonflent.
• Événements fantômes : le plugin envoie des événements que personne n’a configurés, et vous ne savez pas les désactiver individuellement.
• Pas de dataLayer : impossible d’ajouter un événement ou un paramètre sans modifier le plugin lui-même.
• Dépendance à un abonnement : une fonctionnalité nécessaire (suivi e-commerce complet, export) est derrière une formule payante, ou le plugin change de modèle économique.

Ce que vous perdez, ce que vous gardez

Vous gardez la propriété GA4 et son historique, son identifiant de mesure (G-XXXXXX), les conversions déjà définies et les audiences. Rien de tout cela ne se réinitialise si vous restez sur le même flux de données.

Ce qui change : les tableaux de bord que le plugin affichait dans WordPress ou dans le back-office PrestaShop disparaissent, et les réglages automatiques (suivi des liens sortants, des téléchargements) doivent être recréés dans GTM.

Avant de remplacer quoi que ce soit, vérifiez que la propriété est saine. Un setup GA4 propre évite de migrer des erreurs existantes vers un nouveau système. Le dataLayer, lui, se conçoit selon le CMS : le guide GTM avec exemples par CMS reprend les cas courants.

Le plan en 7 étapes

1. Inventorier les balises et les événements du plugin

   Listez tout ce que le plugin envoie : pages vues, événements e-commerce, scripts de pixels publicitaires, options cochées dans son interface. Trois outils suffisent : Tag Assistant pour les balises, l’onglet Réseau du navigateur filtré sur collect pour les envois GA4, et le code source (Ctrl+U) pour les scripts injectés.

   Livrable : un tableau avec, pour chaque événement, son nom, son déclencheur et sa destination.

2. Écrire le plan de marquage cible

   Pour chaque événement, notez le nom GA4 (identique à l’existant), les paramètres, le déclencheur GTM et la source dans le dataLayer. Décidez aussi qui envoie quoi : un seul envoi GA4, un seul pixel par plateforme publicitaire. Le détail des événements e-commerce est dans le guide tracking e-commerce GA4.

3. Mettre en place GTM et le dataLayer en parallèle, sans double comptage

   Pendant la recette, deux options. Soit vous envoyez les événements GTM vers une propriété GA4 de test. Soit vous restez sur la propriété de production et vous marquez les hits issus de GTM par un paramètre dédié, à filtrer dans vos rapports. Dans les deux cas, le plugin reste actif, mais ses données ne sont plus lues.

4. Recette comparée sur 7 jours

   Pendant sept jours, comparez sessions, add_to_cart et purchase entre le plugin seul et GTM seul. Les écarts sont normaux s’ils sont expliqués : un bloqueur différent, un bandeau ajouté. Un écart non expliqué ne passe pas à l’étape suivante.

5. Bascule : désactiver le plugin et purger le cachepoint de non-retour

   Désactivez le module lui-même, pas seulement une option de son interface, puis purgez le cache serveur et le CDN. Vérifiez ensuite en navigation privée qu’un seul script de mesure est chargé.

6. Contrôle post-bascule

   Dans les 48 heures, contrôlez dans DebugView et Tag Assistant : un seul page_view par page, un purchase par commande, un seul pixel par plateforme. Vérifiez aussi les conversions Google Ads qui importent des événements GA4.

7. Documentation

   Un document de quelques pages suffit : balises, déclencheurs, variables, événements, date de bascule et version du container. C’est lui qui vous évitera de chercher pendant des mois d’où vient une donnée.

WordPress : GTM4WP, Site Kit ou MonsterInsights

Le plugin à remplacer détermine la marche à suivre. Si vous passez d’un plugin tout-en-un comme MonsterInsights, la bascule consiste souvent à désactiver son envoi GA4, puis à reproduire ses événements WooCommerce dans GTM. GTM4WP expose le dataLayer et convient mieux si vous voulez maîtriser chaque événement. Site Kit reste plus simple, mais offre moins de latitude. Le comparatif GTM4WP, Site Kit et MonsterInsights détaille ces trois options, et la fiche WordPress couvre les points propres au CMS.

Si votre boutique tourne sur WooCommerce, vérifiez les événements e-commerce sur la fiche WooCommerce avant de désactiver quoi que ce soit.

PrestaShop : module officiel ou tiers vers GTM

Sur PrestaShop, le module analytics est souvent un module tiers. Avant la bascule, trois questions. Le module pousse-t-il ses événements dans le dataLayer, ce qui permet de les reprendre dans GTM, ou envoie-t-il directement vers GA4, ce qui oblige à le désactiver précisément ? Ses événements e-commerce suivent-ils la spécification GA4 ? Gère-t-il lui-même le consentement ?

Le comparatif des modules GA4 pour PrestaShop et la fiche PrestaShop couvrent ces cas.

Les pièges à éviter

• Cache : une page en cache sert encore l’ancien script après la bascule. Purgez à chaque changement, y compris le CDN.
• CMP qui bloquait l’ancien plugin : votre bandeau peut être configuré pour bloquer un script précis qui n’existe plus, ou au contraire le plugin était le seul à respecter le refus. Testez le refus après bascule. Le guide Consent Mode v2 détaille les scénarios à tester.
• Conversions Google Ads importées depuis GA4 : si vous renommez un événement, la conversion importée cesse de compter, sans message d’erreur évident. Gardez le nom exact, ou recréez la conversion avant la bascule.
• Double envoi Meta : si le plugin et GTM envoient tous deux des conversions Meta, la commande est comptée deux fois. Un seul chemin par plateforme, et un event_id commun si Meta reçoit aussi des événements serveur.

FAQ

Faut-il désactiver le plugin avant que GTM soit prêt ?

Non. Faites tourner les deux pendant la recette, avec une propriété de test ou un filtre, puis désactivez le plugin à la bascule. Désactiver trop tôt crée une période sans données qui ne se rattrape pas.

Vais-je perdre l’historique GA4 en migrant ?

Non, si vous restez sur la même propriété et le même flux. L’historique reste dans GA4. Ce qui peut casser, ce sont les noms d’événements modifiés et les conversions dont la définition change.

Puis-je migrer sans toucher au thème ou au module ?

Parfois. Les pages vues et quelques événements peuvent être captés par GTM seul. Les événements e-commerce complets (ajout au panier, tunnel de paiement) demandent en général un dataLayer ajouté au thème ou au module.

Sources

• Consent Mode : définir le consentement avant le chargement de la balise Google
• Événements e-commerce GA4 : documentation Google pour développeurs
• Dédupliquer les événements Pixel et Conversions API (Meta)