Migration analytics : la checklist pour changer d’outil sans recréer de dette de tracking

27 Jul, 2026
- Migration ,
- Analytics

Changer d’outil analytics paraît simple : remplacer un script, attendre quelques jours et comparer les courbes.

C’est rarement suffisant.

Une migration modifie plusieurs couches à la fois :

les données collectées ;
la définition des métriques ;
le fonctionnement du consentement ;
les événements et conversions ;
la structure des sites et espaces ;
les accès ;
la rétention ;
les rapports ;
les habitudes de décision.

Le principal risque n’est pas de perdre un graphique. C’est de transporter une dette de tracking ancienne dans un nouvel outil, puis d’interpréter comme un changement business ce qui n’est qu’un changement de méthode.

Cette checklist propose une migration en dix étapes, adaptée aux PME, SaaS B2B et équipes multi-sites.

1. Définir pourquoi vous migrez

Commencez par écrire la raison du changement.

Exemples :

réduire la complexité de la collecte ;
mieux documenter les données ;
améliorer la lisibilité pour plusieurs équipes ;
diminuer le coût ;
reprendre le contrôle de l’hébergement ou de la rétention ;
simplifier le consentement ;
suivre plusieurs sites dans une gouvernance commune ;
remplacer un outil arrêté ou devenu inadapté.

Transformez cette raison en critères d’acceptation.

Objectif	Critère vérifiable
Simplifier	Le rapport mensuel utilise cinq indicateurs stables
Réduire la collecte	Chaque champ collecté possède une finalité documentée
Gouverner plusieurs sites	Les accès et nomenclatures sont cohérents
Maîtriser les coûts	Le coût total est connu pour le volume prévu
Clarifier le consentement	La configuration est documentée et testée
Améliorer la qualité	Les événements critiques passent un plan de validation

Sans critères, la migration se termine lorsque le script fonctionne. Avec des critères, elle se termine lorsque l’équipe peut à nouveau décider avec confiance.

La grille de gouvernance pour choisir un outil analytics aide à formaliser cette étape.

2. Inventorier l’existant avant de supprimer quoi que ce soit

Créez un inventaire technique et éditorial.

Scripts et points de collecte

Relevez :

scripts chargés dans le site ;
tags gérés par un gestionnaire de balises ;
pixels publicitaires ;
collecte côté serveur ;
plugins CMS ;
SDK mobiles ;
événements envoyés par le backend ;
intégrations CRM, support, paiement ou emailing ;
paramètres de consentement ;
proxys et domaines de collecte.

Données et rapports

Listez :

pages vues ;
événements ;
conversions ;
dimensions personnalisées ;
audiences ;
segments ;
funnels ;
rapports récurrents ;
exports ;
alertes ;
tableaux de bord ;
API utilisées ;
destinataires.

Responsabilités

Pour chaque composant, notez :

propriétaire ;
finalité ;
outil destinataire ;
base ou condition de collecte à examiner ;
durée de conservation ;
personnes ayant accès ;
dépendances ;
décision : conserver, transformer ou supprimer.

Cet inventaire devient le point de départ du résumé de collecte analytics. Il révèle souvent des tags que personne n’utilise plus.

3. Geler les définitions avant de reconstruire

Deux outils peuvent utiliser les mêmes mots pour des métriques différentes.

« Visiteur », « utilisateur », « session », « engagement », « rebond », « conversion » ou « source » dépendent :

de la fenêtre temporelle ;
de la méthode d’identification ;
des règles de session ;
des filtres ;
du consentement ;
du traitement des bots ;
du fuseau horaire ;
de l’attribution ;
des événements reçus.

Créez un dictionnaire de migration :

Concept métier	Ancienne définition	Nouvelle définition	Décision
Visite	Règle de session actuelle	Règle du nouvel outil	Comparer par tendance
Lead	Événement de formulaire	Soumission acceptée	Normaliser
Source	Canal calculé	Referrer/UTM	Documenter l’écart
Conversion	Liste historique	Objectifs prioritaires	Réduire
Trafic interne	Filtre IP	Filtre ou règle nouvelle	Retester

Ne forcez pas une fausse équivalence. Il vaut mieux documenter une rupture de série que produire des nombres artificiellement alignés.

4. Réduire le plan de marquage

Une migration est une occasion de supprimer, pas seulement de recopier.

Classez les événements existants en quatre groupes :

décisionnels : nécessaires à un KPI ou une action ;
diagnostiques : utiles pour expliquer un problème ;
opérationnels : nécessaires à une intégration ;
orphelins : collectés sans usage identifiable.

Supprimez les événements orphelins. Réduisez les variantes qui décrivent la même action. Choisissez des noms stables et une propriété claire pour chaque événement.

Un événement critique doit préciser :

nom ;
déclencheur ;
page ou contexte ;
paramètres autorisés ;
exemple ;
propriétaire ;
KPI associé ;
test de réussite.

Le plan de marquage minimaliste fournit une base pour limiter le volume.

5. Vérifier la collecte et les URL

Avant d’installer le nouvel outil, examinez ce qu’il recevra réellement.

Les URL peuvent contenir :

paramètres UTM ;
identifiants de campagne ;
termes de recherche internes ;
adresses email ;
tokens ;
références de commande ;
identifiants client ;
valeurs de formulaire ;
fragments techniques.

Définissez une allowlist ou une stratégie de suppression. Conservez les paramètres utiles à l’acquisition lorsqu’ils sont nécessaires, mais retirez les valeurs sensibles ou purement techniques avant stockage.

Le guide sur le filtrage des paramètres d’URL détaille cette étape.

Testez aussi :

le referrer ;
l’adresse IP et son traitement ;
les headers ;
le user-agent ;
les propriétés d’événements ;
les données envoyées côté serveur ;
les logs d’infrastructure ;
les exports.

« Cookieless » ne décrit qu’une partie de la collecte. La migration doit documenter l’ensemble des signaux.

6. Revoir consentement, contrats et gouvernance

Un changement d’outil ne rend pas automatiquement une configuration exemptée de consentement.

Vérifiez :

finalités ;
traceurs ou accès au terminal ;
données collectées ;
enrichissements ;
transmission à des tiers ;
réutilisation par le fournisseur ;
transfert hors Espace économique européen ;
sous-traitants ;
rétention ;
mécanisme d’opposition lorsqu’il est pertinent ;
documentation et information des personnes ;
paramétrage du gestionnaire de consentement.

La CNIL encadre strictement les solutions de mesure d’audience qui peuvent, sous conditions, entrer dans un régime limité. Elle rappelle aussi qu’une solution ne doit pas être présentée comme « certifiée » ou « approuvée » par la CNIL.

Mettez à jour :

registre de traitement ;
politique de confidentialité ;
inventaire des traceurs ;
contrat de sous-traitance ;
procédure d’accès et de suppression ;
documentation interne.

L’analyse dépend de la configuration réelle, pas du seul nom du fournisseur.

7. Construire un environnement pilote

Évitez un remplacement immédiat sur tous les sites.

Choisissez :

un site représentatif ;
une page d’acquisition ;
un formulaire ;
quelques événements critiques ;
un trafic suffisant pour observer le fonctionnement ;
une période qui ne coïncide pas avec une refonte majeure.

Installez le nouvel outil dans un mode pilote. Selon le contexte, une période de mesure parallèle peut être utile, mais elle doit rester courte et contrôlée. Deux systèmes actifs signifient potentiellement deux collectes, deux scripts et deux configurations de consentement.

Le but n’est pas d’obtenir des totaux identiques. Il est de vérifier :

que les pages attendues remontent ;
que les événements se déclenchent une seule fois ;
que les sources sont lisibles ;
que les filtres fonctionnent ;
que les conversions correspondent à des réussites réelles ;
que les fuseaux horaires et domaines sont corrects ;
que les accès sont maîtrisés ;
que les données sensibles ne sont pas collectées.

8. Valider avec un plan de recette

Utilisez une matrice simple.

Test	Résultat attendu	Preuve	Statut
Vue de page	Une occurrence	Debug réseau	À valider
Formulaire réussi	Un événement après succès	ID de test	À valider
Erreur formulaire	Pas de conversion	Capture/test	À valider
UTM	Source/campagne lisible	URL de test	À valider
Paramètre sensible	Valeur absente	Requête reçue	À valider
Consentement refusé	Comportement conforme à la configuration	Test CMP	À valider
Trafic interne	Exclu ou identifié	Session test	À valider
Multi-domaine	Parcours cohérent	Session contrôlée	À valider
Mobile	CTA et formulaire fonctionnels	Appareils tests	À valider

Testez en conditions réelles :

navigateur normal et privé ;
mobile et ordinateur ;
consentement accepté et refusé ;
adblocker si une part importante de l’audience en utilise ;
redirections ;
sous-domaines ;
langues ;
formulaires avec succès et erreur ;
campagnes de test.

Conservez les preuves de recette avec la date, la version et le responsable.

9. Décider du sort de l’historique

L’historique n’a pas toujours besoin d’être importé dans le nouvel outil.

Trois options existent.

Conserver l’ancien outil en lecture seule

C’est souvent la solution la plus simple lorsque le contrat, la sécurité et le coût le permettent. Limitez les accès et fixez une date de suppression.

Exporter un historique agrégé

Conservez les indicateurs nécessaires :

trafic mensuel ;
principales pages ;
sources ;
conversions ;
objectifs ;
notes de campagne ;
incidents de mesure.

Un fichier documenté ou un entrepôt contrôlé peut suffire.

Importer dans le nouvel outil

Certains outils proposent un import. Plausible documente par exemple un import depuis Google Analytics. GA4 peut aussi exporter des événements vers BigQuery lorsqu’une liaison a été configurée.

Un import ne garantit pas une série parfaitement comparable. Vérifiez :

périmètre importé ;
dimensions absentes ;
granularité ;
définitions ;
période ;
doublons ;
fuseaux horaires ;
restrictions liées au consentement ;
coût de stockage ;
politique de suppression.

Ne conservez pas toutes les données simplement parce qu’elles existent. Appliquez la politique de rétention des données analytics à l’historique migré.

10. Préparer la bascule et le retour arrière

La bascule doit être réversible.

Écrivez un runbook avec :

date et heure ;
sites concernés ;
responsable technique ;
responsable métier ;
scripts à activer ;
scripts à désactiver ;
configuration CMP ;
tests immédiats ;
seuils d’alerte ;
procédure de retour arrière ;
canal de communication ;
validation finale.

Évitez de basculer :

avant un lancement important ;
le vendredi soir ;
pendant une campagne majeure ;
sans accès aux personnes capables de corriger ;
en même temps qu’une refonte et un changement de CRM.

Après la bascule, surveillez chaque jour les événements critiques pendant la première semaine.

11. Reconstruire les rapports autour des décisions

Ne reproduisez pas automatiquement tous les dashboards.

Commencez par :

objectifs ;
cinq KPIs ;
pages prioritaires ;
sources ;
conversions ;
qualité des leads ;
incidents ;
actions.

Pour plusieurs sites, appliquez une nomenclature commune et distinguez les rapports locaux du pilotage consolidé. Le guide du tableau de bord multi-sites propose une structure.

Mettez ensuite à jour le reporting web mensuel avec une note de rupture :

date de migration ;
ancien et nouvel outil ;
définitions modifiées ;
métriques non comparables ;
période de stabilisation ;
anomalies connues.

Cette note protège les analyses futures.

12. Décommissionner proprement l’ancien outil

Une migration n’est pas terminée tant que l’ancien système reste actif sans raison.

Vérifiez :

scripts retirés du code ;
tags supprimés du gestionnaire ;
collecte serveur arrêtée ;
clés API révoquées ;
comptes et accès supprimés ;
webhooks désactivés ;
exports planifiés arrêtés ;
domaines de collecte supprimés ;
contrats ajustés ;
données supprimées ou archivées selon la politique ;
registre et politique de confidentialité mis à jour ;
facturation arrêtée ;
documentation clôturée.

Contrôlez le réseau du site après suppression. Un ancien tag peut rester dans un template, un plugin, un conteneur non publié ou un sous-domaine oublié.

Les écarts de chiffres à accepter

Pendant la migration, des différences sont normales.

Elles peuvent venir :

des règles de session ;
du consentement ;
des bloqueurs ;
du filtrage des bots ;
des fuseaux horaires ;
des délais de traitement ;
des événements dupliqués dans l’ancien système ;
de la définition des utilisateurs ;
de l’attribution ;
des pages exclues ;
de la collecte côté serveur.

Évaluez les écarts par scénario, pas par obsession du total.

Pour une page ou une conversion critique, vérifiez que le sens de la tendance et le fonctionnement opérationnel sont cohérents. Documentez les différences structurelles et fixez une nouvelle baseline après stabilisation.

Checklist finale

Avant de clôturer la migration, confirmez que :

Conclusion

Une bonne migration analytics ne cherche pas à recopier chaque écran. Elle conserve les décisions utiles, clarifie les définitions et réduit ce qui n’a plus de finalité.

La séquence la plus sûre est :

inventorier ;
définir ;
réduire ;
documenter ;
piloter ;
tester ;
basculer ;
décommissionner.

Le résultat attendu n’est pas seulement un nouveau dashboard. C’est un système de mesure plus compréhensible et plus gouvernable.

FAQ

Combien de temps faut-il faire tourner deux outils en parallèle ?

Seulement le temps nécessaire pour valider les scénarios critiques et observer un fonctionnement normal. La durée dépend du trafic et du cycle de conversion. Une longue période augmente la complexité, le coût et la collecte.

Les chiffres du nouvel outil doivent-ils être identiques ?

Non. Les définitions, filtres, consentements et règles de session peuvent différer. Comparez les scénarios, les tendances et les conversions réelles plutôt que d’exiger une égalité artificielle.

Faut-il importer tout l’historique ?

Pas nécessairement. Conservez uniquement ce qui sert aux obligations, comparaisons ou décisions futures. Un historique agrégé et documenté est souvent plus utile qu’un import complet difficile à comparer.

Comment éviter de perdre les UTM pendant la migration ?

Testez les redirections, formulaires et changements de domaine avec des URL de campagne contrôlées. Vérifiez que les paramètres utiles sont lus avant leur suppression ou normalisation.

Quand supprimer l’ancien outil ?

Après validation du nouvel outil, sécurisation de l’historique nécessaire, mise à jour des rapports et confirmation qu’aucune intégration ne dépend encore de l’ancien système.

Sources

Sources vérifiées le 21 juin 2026.