Migration vers Google Analytics 4 : le plan d'action complet pour une PME en 2026

Universal Analytics a cessé de collecter la moindre donnée depuis juillet 2023, et l'accès aux historiques a disparu un an plus tard. Pourtant, la majorité des setups GA4 que nous auditons en 2026 ne sont pas le fruit d'une vraie migration : ce sont des propriétés générées automatiquement par Google, jamais relues, jamais nettoyées. Le résultat est presque toujours le même — des chiffres qui s'affichent, une direction qui les regarde, et personne pour garantir qu'ils veulent dire quelque chose. Voici la méthode que nous utilisons chez Data Detective pour transformer une migration subie en système de mesure réellement fiable.

Le piège des propriétés GA4 créées automatiquement

Pour éviter que les entreprises ne se retrouvent sans aucune mesure du jour au lendemain, Google a automatiquement créé des propriétés GA4 à partir des réglages des anciennes propriétés Universal Analytics. L'intention était bonne ; le résultat est trompeur. Comme Google le reconnaît lui-même, « toutes les configurations Universal Analytics n'ont pas d'équivalent évident dans Google Analytics 4, et le processus automatisé peut ne pas faire les mêmes choix que vous ».

Concrètement, cette propriété auto-créée a recopié vos objectifs, vos audiences et vos liens Google Ads du mieux qu'elle a pu — mais sans comprendre votre logique métier. Les conversions importées dans Google Ads ont été basculées vers leur équivalent GA4 « quand c'était possible », et Google prévient que cette bascule provoque des écarts de mesure et des fluctuations de performance le temps que les modèles d'enchères se recalibrent. Beaucoup de directions marketing ont vu leurs conversions bouger sans jamais relier ce mouvement à une migration qu'elles n'avaient même pas pilotée.

La première règle est donc simple : une propriété GA4 auto-créée n'est pas une migration, c'est un point de départ minimal à reprendre entièrement. Google recommande explicitement de migrer manuellement plutôt que de s'en remettre à l'automatisation.

Votre migration GA4 a-t-elle été faite à la va-vite ?

30 minutes suffisent pour repérer les trous dans votre collecte et vos conversions.

Réserver un audit flash

Pourquoi GA4 n'est pas « la même chose en mieux »

L'erreur de cadrage la plus coûteuse, c'est de traiter GA4 comme une simple nouvelle version de l'ancien outil. Le modèle de données est fondamentalement différent. Universal Analytics raisonnait en sessions et en hits ; GA4 raisonne en événements. Tout ce que vous mesuriez — un clic, un scroll, une lecture vidéo, un envoi de formulaire — devient un événement à part entière, avec ses propres paramètres.

Trois changements de vocabulaire résument ce basculement, et il faut que votre CMO les ait en tête :

Les hits deviennent des événements. Il n'y a plus de types de hits figés ; tout est un événement que vous structurez vous-même.
Les objectifs deviennent des conversions (puis des « key events »). La logique d'objectif de destination par URL existe toujours, mais elle se reconstruit autrement.
Les vues disparaissent. Plus de vues filtrées comme dans l'ancien outil : on travaille avec des explorations, des rapports et des filtres au niveau de la propriété.

Autre rupture structurelle : web et application ne sont plus des propriétés séparées. GA4 réunit tous vos points de contact dans une seule propriété alimentée par plusieurs flux de données. Pour une PME qui pilote un site et une app, c'est une simplification réelle — à condition de l'avoir pensée en amont plutôt que de la subir.

Conséquence directe que nous martelons en audit : vos historiques Universal Analytics ne sont pas récupérables dans GA4. Les deux modèles sont trop différents pour qu'un import soit possible. Si personne n'a archivé ces données avant leur disparition, elles sont perdues — d'où l'importance d'exporter ce qui peut encore l'être et de bâtir au plus vite un historique GA4 propre.

Les 8 étapes d'une migration GA4 maîtrisée

La méthode tient en huit phases. Elle vaut autant pour repartir d'une propriété auto-créée que pour reconstruire un setup bricolé dans l'urgence.

Étape 1 — Cartographier ce que vous mesuriez vraiment

Avant de toucher à quoi que ce soit, on liste tous les indicateurs réellement utiles à la décision. Pas tout ce que l'ancien outil suivait par défaut : ce qui sert effectivement à arbitrer un budget ou à juger une campagne. Un tableur suffit. C'est l'étape qui sépare une migration « lift and shift » (on recopie tout à l'identique) d'une vraie remise à plat — l'occasion de nettoyer dix ans d'événements parasites accumulés.

Étape 2 — Créer la propriété et les flux de données

On crée la propriété GA4 cible et on déclare un flux de données par source (site web, application). Déclarer un flux dit à GA4 d'attendre des données ; encore faut-il que le code de suivi les envoie réellement. Trois options existent : le tag Google global (gtag.js), Google Tag Manager, ou Firebase pour les apps. Pour un site web, nous recommandons systématiquement Google Tag Manager : il permet de gérer les événements personnalisés sans coder ligne par ligne, et d'orchestrer aussi les tags non-Google au même endroit.

Étape 3 — Reconstruire le tracking des métriques clés

Comme le modèle de données a changé, chaque indicateur retenu à l'étape 1 doit être réimplémenté un par un. Il n'y a pas de bouton magique. C'est laborieux, mais c'est précisément là que se joue la fiabilité de tout le reste : un événement mal nommé ou mal paramétré, et c'est un KPI faussé pour des mois. Quand vous suivez des indicateurs business comme le coût d'acquisition client (CAC) ou le ROAS, la définition de l'événement de conversion sous-jacent doit être verrouillée et documentée.

Étape 4 — Relier GA4 à vos autres outils

GA4 prend toute sa valeur connecté au reste de votre stack. On lie la propriété à Google Ads pour faire remonter les résultats de campagne et nourrir le retargeting, et — point décisif pour une PME ambitieuse — à BigQuery, l'entrepôt de données cloud de Google. La connexion GA4 → BigQuery permet d'exporter la donnée brute et de l'interroger en SQL, sans les limites de l'interface. C'est l'option qui, à terme, vous rend indépendant des rapports standards et ouvre la porte à un vrai data warehouse.

Étape 5 — Gérer les accès

On reporte les droits utilisateurs vers la nouvelle propriété. Les rôles connus existent toujours, mais comme les vues ont disparu, toute permission qui s'appuyait dessus doit être repensée. Passer par des groupes plutôt que par des accès individuels fait gagner un temps considérable dès que l'équipe dépasse quelques personnes.

Étape 6 — Valider en parallèle et fixer une bascule

L'idéal reste de faire tourner la mesure en double le temps de vérifier que les chiffres se tiennent, puis de décider d'une date à partir de laquelle GA4 devient la source de vérité unique. En 2026, l'ancien outil n'existe plus, donc cette validation se fait désormais entre votre propriété auto-créée et votre propriété reconstruite — on compare, on corrige les écarts, on tranche.

Étape 7 — Former les équipes

Une migration technique réussie qui s'arrête au moment du « go » est une migration ratée. Tant que les utilisateurs ne savent pas lire une exploration ni où retrouver leurs conversions, ils ne feront pas confiance à l'outil et reviendront à leurs vieux tableurs. La maîtrise ne vient qu'avec la pratique : démos, sessions courtes, accompagnement sur les rapports réellement consultés.

Étape 8 — Archiver et sécuriser l'historique

Tout ce qui pouvait être exporté de l'ancien outil aurait dû l'être avant sa fermeture. Pour l'avenir, l'export GA4 → BigQuery devient votre filet de sécurité : il met vos données brutes à l'abri des limites de rétention de l'interface et vous garantit de garder la main sur votre propre historique.

Besoin de reconstruire une mesure fiable ?

On audite, on répare et on documente votre stack analytics en 4 à 6 semaines.

Voir la méthode Data Detective

La vraie question n'est pas technique, elle est business

Au-delà des étapes, ce qui détermine la réussite d'une migration, c'est le cadrage de départ. Les bonnes équipes se posent trois questions avant d'ouvrir le moindre compte :

Quel objectif ? Un simple « ne pas se retrouver sans mesure », ou une refonte complète de la collecte ? Les deux n'engagent ni le même effort ni le même budget.
Quelles ressources ? Quel niveau de support technique côté développeurs ? Une migration sans appui dev ne se pilote pas comme une migration adossée à une refonte de la couche de données.
Quel niveau d'ambition ? « Lift and shift » à l'identique, quelques améliorations, ou réarchitecture complète ? Cette décision conditionne tout le reste.

Côté délai, un ordre de grandeur réaliste pour une PME se situe entre deux et trois mois, très variable selon la complexité de l'implémentation existante et l'approche retenue. Ce qui ressemble parfois à un simple paramétrage devient vite un projet à part entière dès qu'on veut une mesure réellement propre.

Comment savoir si votre migration est à reprendre

Quelques signaux suffisent à trancher. Si votre propriété GA4 a un identifiant composé uniquement de chiffres (contre UA-XXXXXXXXX pour l'ancien outil) mais que personne dans l'équipe ne sait dire qui a configuré les événements, vous êtes probablement sur une propriété auto-créée jamais reprise. Si vos conversions Google Ads ont bougé sans explication entre 2023 et 2024, c'est la signature de la bascule automatique. Et si vos rapports affichent des incohérences que personne n'arrive à expliquer simplement, le problème n'est pas dans la lecture : il est dans la collecte.

Dans ce cas, la bonne nouvelle, c'est qu'une reprise propre se mène vite — quelques semaines — et qu'elle se rentabilise dès que la direction recommence à prendre ses décisions sur des chiffres en lesquels elle peut avoir confiance. Le coût réel n'est jamais celui de la migration : c'est celui de tous les arbitrages faits, mois après mois, sur une mesure faussée.

Sources et ressources complémentaires