Migrer de Google Analytics 4 vers quelque chose de plus simple : le guide pratique

Un playbook étape par étape pour quitter GA4 sans perdre l'historique ni casser votre reporting. Les quatre phases, les pièges, et comment choisir le bon remplaçant — sans le contenu cargo-cult de migration dont internet est rempli.

Quand migrer hors de GA4 a vraiment du sens

GA4 est gratuit, omniprésent, et intégré à tous les produits Google. Ce sont de vrais avantages. Les laisser de côté n'a de sens que pour des raisons spécifiques — si votre raison n'en fait pas partie, la migration ne vaut probablement pas la friction :

• Vous êtes fatigué du bandeau cookies et de la chute de consentement qu'il génère. GA4 stocke des identifiants ; sous RGPD/PECR cela nécessite un consentement ; des taux d'acceptation de 50-70 % signifient que vous perdez déjà un tiers de vos données.
• Votre audience utilise massivement des bloqueurs de publicités. Les audiences techniques, dev, conscientes de la vie privée ou proches du crypto bloquent GA4 à des taux de 30-50 %. Votre tableau de bord ne montre pas ce que vous pensez qu'il montre.
• Vous passez plus de temps à configurer GA4 qu'à l'analyser. Dimensions personnalisées, mappage d'événements, modélisation de conversions, export BigQuery, seuils de sampling. Si un quart de votre semaine part dans la plomberie GA4, vous payez "gratuit" avec votre temps.
• Vous voulez posséder les données, pas louer une vue dessus. GA4 possède le dataset ; vous interrogez des slices via leur UI. Avec un outil plus petit, vous possédez généralement les lignes brutes et pouvez exporter, archiver ou les mettre dans un entrepôt à vous.

Si votre raison est juste "Google est trop gros" — c'est un sentiment, pas un brief de migration. Vous y passerez une semaine et finirez avec un outil moins puissant. Ne migrez pas sur des feelings.

Phase 1 : installation parallèle (semaine 1)

N'éteignez pas GA4. Installez votre nouvel outil d'analyse à côté de GA4 pendant au moins 14 jours. Ce n'est pas négociable et la plupart des migrations ratées sautent cette étape.

Deux raisons :

1. Calibration. Vous êtes sur le point de regarder des chiffres très différents. Si votre nouvel outil affiche 40 % de sessions de plus que GA4, est-ce réel (ad blockers, pas de bandeau cookies) ou un bug de tracking de votre côté ? Vous ne pouvez le savoir qu'en faisant tourner les deux en même temps sur le même trafic et en comparant jour par jour.
2. Confiance. Deux semaines de données parallèles vous permettent de dire des choses comme "nous capturons 1,4× les visiteurs que GA4 rapporte, nos trois principaux référents correspondent, la distribution par pays est la même, les utilisateurs avec bloqueur sont l'écart". Ça, c'est une migration défendable. "On a juste changé et les chiffres ont l'air différents" ne l'est pas.

Pendant cette phase, gardez votre reporting et la prise de décision sur GA4. Le nouvel outil est à l'essai.

Phase 2 : valider la parité sur les dimensions qui comptent (semaine 2-3)

La plupart des outils d'analyse mesurent les pages vues, les sessions et les pages principales à peu près de la même façon. Les endroits où ils divergent — et où vous devez valider avant de basculer — sont :

Sessions vs visiteurs

GA4 met par défaut l'accent sur les métriques par utilisateur ; les outils plus petits privilégient souvent les métriques par session. Si GA4 dit "12 000 utilisateurs le mois dernier" et le nouvel outil dit "16 000 sessions" — vous ne comparez pas la même chose. Tirez la métrique comparable des deux outils avant de déclarer une divergence.

Définition du bounce rate

GA4 a inversé le bounce rate en "engagement rate" avec un minimum de 10 secondes. La plupart des autres outils utilisent encore la définition classique de "visite à une seule page". Un site avec 60 % de bounce dans GA4 peut afficher 35 % ailleurs — les deux corrects, définitions différentes.

Temps sur la page

GA4 utilise un engagement time basé sur des heuristiques. Les traceurs qui utilisent la Page Visibility API mesurent le temps visible réel. Le nouveau chiffre sera plus bas de 30 à 60 %. Ce n'est pas une régression — voir comment mesurer le vrai temps passé sur la page pour le détail.

Attribution de la source de trafic

Le modèle "Source / Medium" de GA4 est inhabituellement agressif — il sépare des choses que d'autres regrouperaient. Les principaux référents devraient correspondre dans l'esprit ; les pourcentages exacts non.

Phase 3 : exportez votre historique GA4 (semaine 3)

C'est l'étape que la plupart des équipes sautent et regrettent six mois plus tard. GA4 conserve les données pendant 14 mois par défaut (extensible à 50 avec un plan payant, dans certaines régions). Une fois que vous arrêtez d'envoyer des événements, vos rapports historiques restent accessibles jusqu'à la fermeture de la fenêtre de rétention — et ensuite ils disparaissent.

Trois choses à exporter avant que cette fenêtre se ferme :

• Rapports mensuels agrégés des deux dernières années : pages vues mensuelles, sessions, top 50 pages, top 20 référents, top 20 pays. Exportez en CSV depuis les Explorations de GA4. Rangez dans un dossier Google Drive étiqueté avec la date d'export.
• Totaux de conversions pour chaque goal/événement suivi dans GA4 : conversions totales par mois, taux de conversion par source. Même approche CSV.
• Si vous avez l'export BigQuery activé : téléchargez les tables d'événements brutes vers votre propre entrepôt ou cold storage. C'est la seule voie pour les données historiques au niveau ligne.

Vous ne consulterez probablement pas cet archive souvent. Mais le jour où quelqu'un demande "quel était notre trafic organique au Q3 2024 ?" vous aurez un CSV ou un regret.

Phase 4 : la bascule (semaine 4)

Une fois que vous avez 14 jours de données parallèles, un export de l'historique GA4, et que vous avez réconcilié par écrit les différences de métriques pour votre équipe :

1. Basculez votre reporting (tableaux de bord, revues hebdo, posts internes) vers le nouvel outil.
2. Retirez le tag GA4 du site, ou mettez-le en mode "diagnostic uniquement" où vous le gardez pour cross-check mais ne le traitez plus comme source de vérité.
3. Mettez à jour le bandeau cookies — si votre seul traceur tiers était GA4, vous n'avez peut-être plus besoin du bandeau. Vérifiez avec le juridique si votre juridiction est stricte.
4. Documentez la migration dans un mémo d'une page : pourquoi, ce qui a changé dans les chiffres et pourquoi, ce que vous mesurez maintenant à la place. Votre futur vous et votre future équipe en ont besoin.

Comment choisir le bon remplaçant

Il y a trois catégories crédibles de remplaçants, chacune avec des compromis différents :

SaaS privacy-first (Plausible, Fathom, Logly, Pirsch)

Sans cookies, RGPD by design, pas de bandeau. Scripts légers qui passent les bloqueurs. Tableaux de bord qui privilégient la clarté à la densité de fonctionnalités. Gratuits ou peu chers jusqu'à ~10k pages vues ; prix à l'usage au-delà. Le mieux quand votre priorité est l'honnêteté de la mesure et zéro friction de conformité.

Open-source auto-hébergé (Umami, Plausible CE, GoatCounter, Matomo)

Vous gérez la base de données. Propriété totale des données ; zéro coût mensuel au-delà de l'hébergement. Charge opérationnelle plus élevée — vous maintenez Postgres ou SQLite, gérez les sauvegardes, appliquez les mises à jour. Matomo spécifiquement peut répliquer la majeure partie de la surface fonctionnelle de GA4 mais c'est lourd. Le mieux quand la souveraineté des données compte plus que la commodité.

GA4 server-side ou GA4 proxied

Vous gardez GA4 mais routez les événements via votre propre serveur. Résout le problème des bloqueurs. Ne résout pas le problème du consentement (vous collectez toujours des données personnelles, juste via un autre transport — le bandeau reste). Le mieux quand vous avez vraiment besoin de la profondeur de reporting de GA4 et voulez juste corriger le problème du blocage.

Pièges courants

Les migrations échouent de manière prévisible. Ceux qu'on voit le plus :

• Sauter la phase parallèle. "On l'a juste installé et retiré GA4." Puis le jour 1 les chiffres ne correspondent pas et il n'y a pas de baseline de calibration. La confiance s'effondre.
• Migrer sans exporter l'historique GA4. Trois mois plus tard, quelqu'un a besoin du trafic du Q4 de l'an dernier pour un board deck. Les données sont techniquement encore dans GA4 mais vous avez oublié comment naviguer dans Explorations.
• Choisir le mauvais remplaçant pour l'audience. Un site de marque grand public passant à GoatCounter et découvrant que c'est trop minimal. Un SaaS de privacy passant à Matomo Cloud et réalisant que le bandeau cookies est de retour.
• Ne pas mettre à jour les tableaux de bord internes. Pages Notion, dashboards Looker, modèles de revue hebdo continuent à référencer les chiffres GA4. La migration est techniquement terminée mais le reporting n'a pas suivi.
• Comparer des métriques incompatibles. Voir la Phase 2 ci-dessus. Le nombre d'équipes qui concluent "notre nouvel outil est cassé" parce qu'elles ont comparé les "utilisateurs" de GA4 avec les "sessions" d'un outil basé sur les sessions est trop élevé pour être compté.