EN FR

Tag : Gouvernance

Tous les articles du blog avec ce tag.

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

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

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érifiableSimplifier Le rapport mensuel utilise cinq indicateurs stablesRéduire la collecte Chaque champ collecté possède une finalité documentéeGouverner plusieurs sites Les accès et nomenclatures sont cohérentsMaîtriser les coûts Le coût total est connu pour le volume prévuClarifier le consentement La configuration est documentée et testéeAméliorer la qualité Les événements critiques passent un plan de validationSans 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écisionVisite Règle de session actuelle Règle du nouvel outil Comparer par tendanceLead Événement de formulaire Soumission acceptée NormaliserSource Canal calculé Referrer/UTM Documenter l’écartConversion Liste historique Objectifs prioritaires RéduireTrafic interne Filtre IP Filtre ou règle nouvelle RetesterNe 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 StatutVue de page Une occurrence Debug réseau À validerFormulaire réussi Un événement après succès ID de test À validerErreur formulaire Pas de conversion Capture/test À validerUTM Source/campagne lisible URL de test À validerParamètre sensible Valeur absente Requête reçue À validerConsentement refusé Comportement conforme à la configuration Test CMP À validerTrafic interne Exclu ou identifié Session test À validerMulti-domaine Parcours cohérent Session contrôlée À validerMobile CTA et formulaire fonctionnels Appareils tests À validerTestez 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 : les objectifs et critères d’acceptation sont écrits ; l’ancien système a été inventorié ; les définitions sont documentées ; les événements inutiles ont été supprimés ; les URL et paramètres sont filtrés ; le consentement et les contrats ont été revus ; le pilote a été validé ; les tests critiques sont documentés ; la stratégie d’historique est décidée ; la bascule possède un retour arrière ; les rapports ont été reconstruits ; l’ancien outil est réellement décommissionné ; une nouvelle baseline est communiquée.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.CNIL, cookies : solutions pour les outils de mesure d’audience CNIL, durées de conservation des données Google Analytics, configurer l’export BigQuery Google Analytics, structure des comptes et propriétés Plausible, importer des statistiques Google Analytics OWASP, exposition d’informations dans les chaînes de requête

Data collection summary : documenter clairement ce que votre analytics collecte

Data collection summary : documenter clairement ce que votre analytics collecte

Installer un outil analytics prend parfois quelques minutes. Expliquer précisément ce qu’il collecte peut prendre beaucoup plus longtemps. La difficulté ne vient pas seulement du volume de données. Elle vient de la dispersion de l’information. Une partie se trouve dans le plan de marquage, une autre dans la documentation du fournisseur, une autre dans le gestionnaire de consentement, et une dernière dans le code du site. Quand une question arrive, par exemple « transmettons-nous l’URL complète ? », « l’adresse IP est-elle stockée ? » ou « combien de temps gardons-nous les événements ? », personne ne dispose forcément d’une réponse complète. Un data collection summary est un document court qui rassemble ces réponses. Il décrit la collecte telle qu’elle fonctionne réellement, et non telle qu’on l’imagine à partir d’une page marketing. Ce n’est ni un avis juridique, ni un remplacement du registre des traitements, ni une politique de confidentialité. C’est une vue technique et opérationnelle qui relie les trois. À quoi sert un data collection summary ? Le document répond à une question simple :Pour chaque donnée ou signal collecté, savons-nous d’où il vient, pourquoi nous le collectons, où il va, combien de temps nous le gardons et qui peut y accéder ?Cette vue est utile à plusieurs équipes. L’équipe produit peut vérifier qu’un nouvel événement répond à un besoin réel. L’équipe marketing peut comprendre quelles dimensions sont disponibles sans supposer que « l’outil doit sûrement les avoir ». L’équipe technique dispose d’une référence pour les filtres, les transformations et les environnements. Le DPO ou le conseil juridique peut confronter la réalité technique aux documents de conformité. La direction peut enfin savoir quel risque et quelle dette accompagnent la mesure d’audience. Le RGPD impose notamment des principes de finalité, de minimisation, de transparence et de limitation de la conservation. Il prévoit aussi, selon les situations, une information des personnes et la tenue d’un registre des activités de traitement. Le data collection summary ne crée pas ces obligations, mais il facilite la production d’informations exactes et cohérentes. Ce document n’est pas le registre des traitements La distinction est importante. Le registre des activités de traitement est un document de gouvernance prévu par l’article 30 du RGPD dans les cas où il s’applique. Il décrit un traitement à un niveau relativement large : finalités, catégories de personnes, catégories de données, destinataires, transferts, durées et mesures de sécurité. Le data collection summary descend au niveau de l’implémentation. Il peut préciser que :l’URL est enregistrée sans la chaîne de requête ; l’adresse IP est utilisée brièvement pour une opération technique puis non conservée ; le user-agent est réduit à une famille de navigateur ; les paramètres utm_source, utm_medium et utm_campaign sont conservés ; un identifiant de formulaire n’est envoyé qu’après validation ; les données brutes et les rapports agrégés n’ont pas la même durée de conservation.La politique de confidentialité, elle, traduit les éléments pertinents dans un langage destiné aux visiteurs. Elle ne doit pas devenir une copie de la documentation technique, mais elle ne peut être fiable que si cette documentation existe. On peut donc résumer les rôles ainsi :Document Public principal Niveau de détail FonctionRegistre des traitements Interne, conformité Traitement et catégories Démontrer et piloter la conformitéData collection summary Interne, produit et technique Champs, flux et contrôles Décrire la collecte réellement déployéePolitique de confidentialité Visiteurs et utilisateurs Information claire Expliquer les traitements pertinents aux personnesPlan de marquage Produit, marketing, développement Événements et règles Définir ce qui doit être mesuréCes documents se complètent. Ils ne doivent pas se contredire. Les 10 colonnes d’un résumé utile Un tableur suffit. L’important est la qualité des colonnes et la discipline de mise à jour. 1. Donnée ou signal Nommez la donnée sans jargon commercial : chemin de page, domaine référent, type d’appareil, événement de formulaire, identifiant de site, paramètre UTM, pays dérivé, adresse IP temporaire. Évitez les catégories vagues comme « données techniques ». Elles masquent les choix concrets. 2. Exemple de valeur Un exemple réduit les ambiguïtés. Pour un chemin de page : /tarifs/. Pour une source : newsletter. Pour un événement : demo_requested. N’utilisez pas de vraie donnée personnelle dans le document. Un exemple synthétique suffit. 3. Source Précisez où le signal apparaît : navigateur, serveur, formulaire, CMS, CDN, script analytics ou import externe. Cette colonne aide à repérer les données collectées indirectement. Un outil peut, par exemple, recevoir une URL ou un en-tête avant même que votre code de tracking ne les transforme. 4. Finalité opérationnelle Écrivez une phrase qui relie la donnée à une décision : « mesurer les pages d’entrée qui génèrent une demande de démonstration » est plus utile que « analyse marketing ». Une finalité trop large est un signal d’alerte. Si une donnée sert supposément à tout, son besoin n’est probablement pas assez défini. 5. Transformation avant stockage Indiquez ce qui est supprimé, tronqué, agrégé ou dérivé :suppression des paramètres non autorisés ; normalisation du chemin ; réduction du user-agent ; géolocalisation approximative puis suppression de l’adresse IP ; hachage d’un identifiant, avec la précision qu’un hachage n’est pas automatiquement une anonymisation ; agrégation quotidienne ou mensuelle.Cette colonne permet de distinguer ce que le système reçoit de ce qu’il conserve. 6. Destination et sous-traitants Listez les systèmes qui reçoivent la donnée : endpoint de collecte, stockage brut, base agrégée, outil de BI, export, fournisseur cloud ou prestataire analytics. Ajoutez la région d’hébergement et les transferts pertinents lorsqu’ils sont connus et documentés. Ne déduisez pas la localisation juridique d’un simple nom de région cloud. 7. Durée de conservation Séparez les couches lorsque nécessaire :logs techniques ; événements bruts ; données pseudonymisées ; statistiques agrégées ; sauvegardes ; exports manuels.Une seule durée globale est souvent trompeuse. La CNIL rappelle que la durée doit être déterminée selon la finalité et limitée au nécessaire. Pour les traceurs de mesure d’audience susceptibles d’entrer dans le cadre d’une exemption en France, elle recommande notamment une durée de vie de treize mois pour les traceurs et une conservation des informations collectées limitée à vingt-cinq mois. Ces repères ne dispensent pas d’analyser la configuration réelle. 8. Accès Décrivez les rôles, pas seulement les noms : administrateurs, analystes, agence, support, prestataire d’hébergement. Précisez si l’accès porte sur les rapports agrégés, les événements bruts ou les exports. « L’équipe marketing a accès » est insuffisant si un compte générique permet aussi de télécharger toutes les données. 9. Dépendance au consentement ou à la configuration Cette colonne doit rester factuelle. Indiquez par exemple :collecté uniquement après signal de consentement ; désactivé en mode de mesure stricte ; activé uniquement pour certaines campagnes ; soumis à une analyse locale ePrivacy ; utilisé pour une mesure d’audience limitée, sous réserve que toutes les conditions applicables soient remplies.N’écrivez pas simplement « exempté » sans documenter les conditions, le périmètre et la configuration. 10. Suppression et responsable Enfin, indiquez comment la donnée disparaît et qui vérifie le processus : suppression automatique, tâche planifiée, purge fournisseur, procédure manuelle, échéance de contrat, suppression d’un export. Ajoutez un propriétaire interne et une date de dernière revue. Sans responsable, le document vieillit dès la prochaine mise en production. Exemple minimal pour une PME SaaS Voici un extrait volontairement simplifié :Signal Finalité Traitement avant stockage Conservation AccèsChemin de page Mesurer les contenus consultés Query string supprimée, chemin normalisé 25 mois pour les rapports Produit, marketingDomaine référent Comprendre les sources de visite Origine uniquement lorsque transmise 25 mois Marketingutm_source Identifier une campagne déclarée Valeurs normalisées selon une nomenclature 25 mois MarketingÉvénement demo_requested Mesurer une conversion B2B Aucun contenu de formulaire envoyé 25 mois Produit, ventes en agrégéAdresse IP Sécurité et dérivation géographique approximative Utilisée temporairement, non stockée dans l’événement Durée technique documentée Opérations restreintesUser-agent Répartition technique Réduit à une catégorie de navigateur et appareil 25 mois ProduitCe tableau ne prouve rien à lui seul. Il doit correspondre au réseau observé, au code et aux réglages du fournisseur. C’est pourquoi il est utile de commencer par un audit des traceurs effectivement chargés et de comparer le résultat au plan de marquage minimaliste. Méthode de construction en cinq étapes Étape 1 : partir du trafic réseau Ouvrez les outils de développement du navigateur, rechargez les pages représentatives et observez les requêtes. Faites le test avant et après chaque choix de consentement, sur plusieurs parcours et appareils. Relevez les domaines, les payloads, les paramètres d’URL et les événements. Le réseau montre ce qui est transmis depuis le navigateur. Il ne montre pas nécessairement toutes les transformations côté serveur, mais il constitue un point de départ vérifiable. Étape 2 : lire le code et la configuration Inspectez le script de collecte, le gestionnaire de tags, les règles du CMP, les variables d’environnement et les filtres. Une documentation fournisseur générique ne dit pas quelle option votre site a activée. Vérifiez également les fonctionnalités annexes : enregistrement de session, enrichissement publicitaire, export vers une régie, connexion CRM ou identifiants utilisateurs. Étape 3 : interroger le fournisseur avec des questions fermées Demandez des réponses vérifiables :l’URL complète est-elle reçue et stockée ? les paramètres de requête sont-ils filtrables avant stockage ? l’adresse IP est-elle journalisée ailleurs que dans les événements ? quelles sauvegardes contiennent encore les données après suppression ? le fournisseur réutilise-t-il les données pour son propre compte ? quels sous-traitants et transferts sont concernés ? les exports obéissent-ils à la même politique de conservation ?Une réponse « privacy-friendly » ne remplit aucune colonne. Étape 4 : confronter les documents Comparez le résumé technique au registre, au contrat de sous-traitance, à la politique de confidentialité et au bandeau de consentement. Les incohérences sont plus importantes que la qualité littéraire de chaque document pris séparément. Exemple classique : la politique affirme que seules des statistiques agrégées sont collectées, alors que le gestionnaire de tags envoie un identifiant utilisateur à un outil tiers. Étape 5 : instaurer une revue liée aux changements Le document doit être revu lors de toute modification significative :nouvel outil ; nouvel événement ; changement de domaine de collecte ; activation d’un export ; nouvelle durée de conservation ; modification du consentement ; changement de sous-traitant ; ajout d’une propriété ou d’un site.Une revue trimestrielle légère permet aussi de détecter les écarts silencieux. Les erreurs qui rendent le document inutile Copier la documentation commerciale La documentation du fournisseur décrit un produit possible. Votre résumé doit décrire votre instance, vos options et vos flux. Confondre pseudonymisation et anonymisation Un identifiant haché ou rotatif peut rester une donnée personnelle s’il permet encore de distinguer ou relier une personne. Utilisez des termes précis et documentez le risque de réidentification. Oublier les URL Les URL complètes peuvent contenir des emails, identifiants de commande, termes de recherche interne ou jetons. Même un outil conçu pour collecter peu peut recevoir une donnée excessive si le site place cette donnée dans l’adresse. Ne documenter que le tableau de bord Le rapport visible n’est qu’une surface. Les logs, exports, événements bruts, sauvegardes et intégrations comptent aussi. Laisser le document sans propriétaire Une fiche parfaite mais non maintenue devient rapidement plus dangereuse qu’une fiche absente, car elle donne une confiance injustifiée. Checklist de validation Avant d’approuver le résumé, vérifiez que :chaque donnée a une finalité spécifique ; les données reçues et les données stockées sont distinguées ; les paramètres d’URL et champs libres ont été audités ; les durées sont définies par couche ; les destinataires et accès sont nommés ; le consentement et les modes de configuration sont explicités ; la suppression est testable ; le contenu concorde avec les documents publics et contractuels ; un responsable et une date de revue sont indiqués ; toute affirmation d’anonymisation est techniquement justifiée.Conclusion Un data collection summary n’est pas un document de plus à ranger dans un dossier conformité. C’est une interface commune entre produit, marketing, technique et juridique. Sa valeur vient de sa précision. Une équipe qui sait exactement ce qu’elle collecte peut supprimer les données inutiles, expliquer les données utiles, configurer correctement ses outils et répondre plus vite aux questions internes ou externes. Commencez par une seule propriété web et les dix signaux les plus importants. Vérifiez-les dans le réseau et le code, puis élargissez seulement si la collecte réelle le justifie. FAQ Le data collection summary est-il obligatoire au titre du RGPD ? Ce format précis n’est pas imposé par le RGPD. Il peut toutefois aider à produire et maintenir des documents obligatoires ou nécessaires, notamment le registre des traitements et l’information des personnes. Faut-il publier ce document ? Pas nécessairement. Il contient souvent des détails techniques internes. Les informations pertinentes pour les personnes doivent être reprises clairement dans la politique de confidentialité ou d’autres notices appropriées. Une adresse IP non stockée doit-elle apparaître ? Oui si elle est reçue ou utilisée, même brièvement. Le résumé doit distinguer réception, traitement temporaire, transformation et stockage. Peut-on utiliser le même résumé pour plusieurs sites ? Seulement si les flux et configurations sont réellement identiques. Pour un environnement multi-sites, gardez un socle commun et documentez les écarts par propriété. À quelle fréquence faut-il le mettre à jour ? À chaque changement significatif de collecte ou de destination, avec une revue périodique. Une vérification trimestrielle est un rythme pratique pour une petite équipe, sans constituer une règle juridique universelle. SourcesRèglement (UE) 2016/679, notamment articles 5, 13, 25 et 30 CNIL, Le registre des activités de traitement CNIL, Cookies : solutions pour les outils de mesure d’audience CEPD, Lignes directrices 4/2019 sur la protection des données dès la conception et par défaut Chrome for Developers, Network features reference OWASP, Information exposure through query strings in URL

Le plan de marquage minimaliste d’une PME : 12 événements suffisent pour piloter un site

Le plan de marquage minimaliste d’une PME : 12 événements suffisent pour piloter un site

Pendant longtemps, beaucoup d’équipes ont abordé le marquage comme une liste infinie d’options. Il fallait tout suivre, tout nommer, tout enrichir, puis espérer qu’un jour quelqu’un exploite réellement ces données. Dans la pratique, cela produit souvent l’inverse de l’objectif initial. Le plan de marquage devient trop large, les événements se multiplient, les paramètres deviennent illisibles, et le tableau de bord cesse d’aider à décider. L’outil collecte davantage, mais l’équipe comprend moins. Pour une PME, un site vitrine, un site B2B ou un petit site SaaS, la bonne logique est presque toujours plus simple : mesurer moins, mais mesurer ce qui permet d’agir. C’est le rôle d’un plan de marquage minimaliste. Il ne cherche pas à décrire chaque micro-interaction. Il cherche à répondre à quelques questions utiles :d’où vient le trafic ; quelles pages attirent l’attention ; quels contenus déclenchent une intention ; quels signaux montrent qu’un visiteur avance ; quelles actions ressemblent à une conversion réelle.Cet article propose un cadre concret avec 12 événements maximum. Ce n’est pas une vérité universelle. C’est un point de départ robuste pour des équipes qui veulent garder une analytics lisible, gouvernable et utile. Un plan de marquage n’est pas une liste technique, c’est une grille de décision La première erreur consiste à partir de l’outil. On ouvre la documentation, on découvre des dizaines d’événements recommandés, puis on essaie de tout faire rentrer dans le site. C’est la mauvaise direction. Un bon plan de marquage commence par les décisions que l’équipe doit prendre. Par exemple :Quelles pages participent réellement à l’acquisition ? Quels contenus soutiennent la génération de leads ? Quels appels à l’action fonctionnent ? Où les visiteurs abandonnent-ils ? Quels signaux méritent un suivi mensuel en comité, et lesquels relèvent juste de la curiosité ?Tant que ces questions ne sont pas clarifiées, ajouter des événements ne sert pas à grand-chose. Google Analytics 4 distingue d’ailleurs les événements collectés automatiquement, les événements recommandés et les événements personnalisés. Le point important n’est pas qu’il existe beaucoup d’options. Le point important est qu’une équipe n’a pas besoin d’utiliser toutes ces options pour obtenir une lecture utile. De la même manière, Matomo, Plausible et d’autres outils permettent de suivre des événements au-delà des simples pages vues. Cette capacité est utile. Elle devient contre-productive si elle pousse à documenter tout ce qui bouge. Ce que doit couvrir un plan de marquage minimaliste Pour une PME, un plan de marquage sobre doit couvrir cinq zones. 1. La lecture d’audience de base Avant d’ajouter des événements, il faut déjà disposer des fondamentaux :pages vues ; pages d’entrée ; sources ou référents ; campagnes quand elles sont activement utilisées ; conversions principales.Autrement dit, le marquage ne doit pas chercher à compenser l’absence de lecture simple de l’audience. Si votre dashboard n’explique déjà pas clairement quelles pages attirent du trafic qualifié, ajouter vingt événements n’aidera pas. 2. Les signaux d’intention Tous les visiteurs ne convertissent pas immédiatement. Il faut donc repérer quelques signaux intermédiaires : clic sur un bouton stratégique, téléchargement, recherche interne, demande de démo, démarrage d’inscription, etc. Ces signaux servent à lire la progression, pas à fabriquer un tunnel artificiel. 3. Les conversions réelles Le plan minimaliste doit identifier ce qui compte vraiment pour le site :envoi de formulaire ; prise de rendez-vous ; essai démarré ; achat confirmé ; inscription validée.Une conversion qui n’influence aucune décision n’a pas besoin d’être un événement. 4. Les points de friction évidents Le but n’est pas de rejouer toute la session d’un utilisateur. Le but est de comprendre où l’intention se perd. Une recherche interne répétée, un clic vers une page tarification, puis aucune action, ou un démarrage de checkout sans achat peuvent déjà suffire à mettre en évidence un problème. 5. La gouvernance du suivi Un plan de marquage sans gouvernance finit vite par dériver. Il faut savoir :pourquoi l’événement existe ; qui l’a demandé ; à quel endroit il déclenche ; quels paramètres sont réellement utiles ; quand il peut être supprimé.C’est souvent ce point qui différencie un setup propre d’un setup accumulatif. Les 12 événements qui suffisent dans la majorité des cas Voici un modèle simple. Toutes les équipes n’auront pas besoin des 12. Beaucoup peuvent commencer avec 6 à 8 événements. 1. form_submit C’est l’événement le plus universel. Il couvre le formulaire de contact, de demande de devis, de démo ou de lead entrant. Pourquoi le suivre : il matérialise une intention explicite. Paramètres utiles :form_name page_type2. demo_request Si votre site B2B propose une démo, il est utile de distinguer cette action du formulaire générique. Elle correspond souvent à un niveau d’intention plus fort. Pourquoi le suivre : il sépare le simple contact du lead plus qualifié. Paramètre utile :placement3. newsletter_signup Cet événement reste secondaire par rapport à une demande commerciale, mais il peut servir de bon indicateur de contenu utile. Pourquoi le suivre : il mesure une conversion légère, utile pour les équipes contenu. Paramètres utiles :placement content_type4. account_signup Pour un produit SaaS ou un espace utilisateur, le début d’inscription mérite presque toujours un suivi dédié. Pourquoi le suivre : il permet de mesurer le passage entre visite et création de compte. Paramètres utiles :plan_type placement5. trial_start Si un essai existe, il faut le distinguer de l’inscription simple. Le volume peut être plus faible, mais le signal est beaucoup plus proche du revenu. Pourquoi le suivre : il rapproche l’analytics du pipeline réel. Paramètre utile :plan_type6. purchase_complete Pour un site e-commerce ou un SaaS avec souscription directe, c’est l’événement final le plus important. Pourquoi le suivre : il ancre le suivi dans la conversion réelle, pas seulement dans l’intention. Paramètres utiles :plan_type billing_cycle7. phone_click Sur beaucoup de sites locaux, de cabinets, de services B2B ou de structures de conseil, le téléphone reste un canal de conversion. Pourquoi le suivre : une conversion ne passe pas toujours par un formulaire. Paramètre utile :placement8. email_click Même logique pour les liens mailto. Sur certains sites, ce signal vaut plus qu’un clic décoratif vers une page produit. Pourquoi le suivre : il révèle une prise de contact directe. Paramètre utile :placement9. file_download Livres blancs, brochures, fiches produits, documentation PDF : ce type d’action peut signaler une intention sérieuse, à condition de rester sélectif. Pourquoi le suivre : il aide à distinguer les contenus qui génèrent un engagement tangible. Paramètres utiles :file_name content_type10. outbound_click Tout clic externe ne mérite pas un événement. En revanche, certains liens sortants sont stratégiques : prise de rendez-vous Calendly, marketplace, plateforme de paiement, espace partenaire, documentation externe clé. Pourquoi le suivre : il éclaire les sorties utiles du site. Paramètres utiles :destination_type placement11. search_submit Si votre site a une recherche interne, c’est souvent un indicateur précieux. Les visiteurs vous disent eux-mêmes ce qu’ils cherchent. Pourquoi le suivre : il révèle l’écart entre l’architecture du site et l’intention utilisateur. Paramètres utiles :query_group results_stateImportant : évitez de remonter des termes bruts si cela crée une collecte inutilement sensible. Une catégorisation ou une logique d’agrégation est souvent préférable. 12. checkout_start ou pricing_cta_click Le douzième événement dépend du type de site. Pour l’e-commerce : suivez checkout_start. Pour un site B2B sans achat immédiat : suivez plutôt pricing_cta_click ou un clic vers un CTA commercial majeur. Pourquoi le suivre : il capture le passage entre intérêt et démarche active. Paramètres utiles :placement offer_typeLa vraie discipline : limiter les paramètres Un mauvais plan de marquage ne contient pas seulement trop d’événements. Il contient aussi trop de propriétés attachées à chaque événement. La règle simple consiste à ne garder que les paramètres qui changent une lecture utile. Par exemple :placement peut être utile pour comparer un CTA dans le header et le footer ; plan_type peut être utile pour distinguer free, starter, pro ; form_name peut être utile s’il existe plusieurs formulaires.En revanche, beaucoup de paramètres finissent par ne rien apporter :texte exact du bouton ; URL complète quand elle est déjà visible ailleurs ; variantes de casse ou de naming ; détails redondants qui compliquent surtout l’analyse.Plausible, par exemple, permet d’associer des propriétés personnalisées aux événements, mais il ne faut pas confondre possibilité technique et nécessité analytique. Plus vous enrichissez, plus vous devrez ensuite relire et maintenir. Une convention de nommage simple vaut mieux qu’un framework complexe Pour un plan minimaliste, la convention suivante suffit largement :noms d’événements en anglais ; verbes d’action clairs ; pas d’espace ; pas de doublons proches ; une signification stable dans le temps.Exemples corrects :form_submit trial_start file_download phone_clickExemples à éviter :CTA Final Hero Demo contactFormSuccessNew btn_click_v2 conversion_importantLa règle est simple : un nom doit rester compréhensible six mois plus tard, même pour quelqu’un qui n’était pas présent au moment de l’implémentation. Ce qu’il ne faut pas suivre au départ Un plan minimaliste est aussi un plan qui assume des renoncements. Ne suivez pas dès le départ :chaque scroll ; chaque clic de navigation ; chaque ouverture d’accordion ; chaque hover ; chaque variation visuelle de bouton ; chaque lecture vidéo si personne n’utilise cette donnée ; chaque micro-étape d’un formulaire long, sauf problème avéré.Ces données peuvent sembler rassurantes parce qu’elles donnent l’impression de finesse. En réalité, elles créent souvent du bruit. L’ordre recommandé pour implémenter le plan Pour éviter le projet sans fin, déployez en trois vagues. Vague 1 : les conversions principales Commencez par :form_submit demo_request purchase_complete trial_startToutes les équipes n’auront pas les quatre, mais elles doivent commencer par leurs conversions les plus proches de la valeur. Vague 2 : les signaux d’intention Ajoutez ensuite :phone_click email_click file_download checkout_start ou pricing_cta_clickCela suffit souvent à lire les passages intermédiaires utiles. Vague 3 : les signaux d’orientation Enfin seulement, ajoutez si nécessaire :search_submit newsletter_signup account_signup outbound_clickCette logique garde le marquage sous contrôle. On documente d’abord ce qui sert le pilotage, puis ce qui améliore l’interprétation. Un exemple de tableau de marquage minimal Voici un format de documentation suffisant pour la plupart des PME :Event Déclencheur Pourquoi le suivre Paramètresform_submit formulaire envoyé avec succès mesurer les leads entrants form_name, page_typedemo_request clic ou envoi de demande de démo isoler l’intention commerciale forte placementnewsletter_signup inscription confirmée suivre les conversions de contenu placement, content_typeaccount_signup création de compte lancée ou validée lire le passage visite → compte plan_type, placementtrial_start essai activé suivre le signal le plus proche du revenu plan_typepurchase_complete achat ou abonnement confirmé mesurer la conversion finale plan_type, billing_cyclephone_click clic sur lien téléphone capter les conversions hors formulaire placementemail_click clic sur lien mailto suivre le contact direct placementfile_download téléchargement déclenché mesurer l’intérêt pour des assets clés file_name, content_typeoutbound_click clic vers un domaine externe stratégique comprendre les sorties utiles destination_type, placementsearch_submit recherche interne validée lire l’intention utilisateur query_group, results_statecheckout_start ou pricing_cta_click démarrage de checkout ou clic pricing stratégique repérer le passage à l’action placement, offer_typeAttention au cadre privacy et au périmètre de mesure C’est un point important. Un plan de marquage minimaliste n’est pas automatiquement un plan juridiquement simple. La CNIL rappelle que la mesure d’audience peut, dans certaines conditions, relever d’un régime particulier, mais que l’analyse dépend des finalités, de la configuration et de l’usage réel des données. Dès que l’on glisse vers des usages marketing plus larges, l’acquisition ou des réutilisations plus riches, le cadrage change. Concrètement, cela veut dire deux choses :gardez votre plan de marquage proportionné ; distinguez clairement la mesure d’audience utile des besoins marketing plus larges.Autrement dit, un bon plan de marquage n’est pas seulement sobre. Il est aussi explicable. Ce qu’il faut retenir Pour une PME, un bon plan de marquage ne cherche pas à impressionner. Il cherche à rester exploitable. Dans la majorité des cas, 12 événements suffisent largement, et souvent 6 à 8 suffisent pour démarrer correctement. Le plus important n’est pas d’avoir une taxonomie ambitieuse. Le plus important est de pouvoir répondre, chaque mois, à quelques questions simples :qu’est-ce qui attire du trafic qualifié ; qu’est-ce qui déclenche une intention claire ; qu’est-ce qui convertit réellement ; où l’on perd de la progression ; quelles données l’équipe comprend et utilise vraiment.Si votre plan de marquage devient plus complexe que vos décisions, il est probablement déjà trop lourd. FAQ Faut-il suivre les 12 événements dès le premier jour ? Non. La plupart des équipes devraient commencer par les 4 à 8 événements les plus proches de leurs conversions réelles, puis élargir seulement si un besoin clair apparaît. Pourquoi garder les noms d’événements en anglais sur un site francophone ? Parce que cela facilite souvent la maintenance, la cohérence technique et la transcréation éventuelle. L’important n’est pas la langue en elle-même, mais la stabilité du naming. Un clic sur un bouton suffit-il à définir une conversion ? Pas toujours. Un clic peut être un bon signal d’intention, mais il ne remplace pas une conversion réelle comme un formulaire envoyé, un essai activé ou un achat confirmé. Peut-on suivre les campagnes et les UTM dans un plan minimaliste ? Oui, mais il faut distinguer la lecture d’acquisition et le marquage d’événements. Les campagnes peuvent être utiles, mais elles ne justifient pas à elles seules une inflation du plan de marquage. Comment savoir qu’un événement doit être supprimé ? S’il n’est jamais consulté, s’il n’influence aucune décision, s’il duplique une autre donnée ou si personne dans l’équipe ne sait encore à quoi il sert, il mérite probablement d’être retiré. SourcesCNIL, Cookies : solutions pour les outils de mesure d’audience : https://www.cnil.fr/fr/cookies-solutions-pour-les-outils-de-mesure-daudience CNIL, Recommandation relative aux cookies et autres traceurs, édition consolidée 2026 : https://www.cnil.fr/sites/default/files/2026-01/recommandation_cookies_consolidee.pdf Google Analytics, Analytics - Recommended events : https://developers.google.com/analytics/devguides/collection/ga4/reference/events Google Analytics, Set up events : https://developers.google.com/analytics/devguides/collection/ga4/events Google Analytics, Set up event parameters : https://developers.google.com/analytics/devguides/collection/ga4/event-parameters Matomo, JavaScript Tracking Client Guide : https://developer.matomo.org/guides/tracking-javascript-guide Matomo, Event Tracking User Guide : https://matomo.org/guide/reports/event-tracking/ Plausible, Custom event goals : https://plausible.io/docs/custom-event-goals Plausible, Custom properties for events : https://plausible.io/docs/custom-props/for-custom-events Plausible, Goal conversions : https://plausible.io/docs/goal-conversions