Catégorie : Analytics
Tous les articles du blog dans cette catégorie.
- 20 Jul, 2026
Pages d’acquisition : les 7 signaux à suivre sans construire une usine à gaz
Une page d’acquisition n’a pas besoin de cinquante métriques pour être pilotée correctement. Elle doit répondre à une chaîne de questions simple :les bonnes personnes arrivent-elles ? comprennent-elles la proposition ? progressent-elles vers l’action attendue ? terminent-elles cette action ? les contacts ou ventes obtenus sont-ils utiles ? la page fonctionne-t-elle correctement ? la mesure est-elle suffisamment fiable pour décider ?Cette chaîne évite deux erreurs fréquentes. La première consiste à juger une page uniquement sur son volume de trafic. La seconde consiste à empiler des événements comportementaux sans relier les données à une décision. Pour une PME ou un SaaS B2B, sept signaux suffisent généralement à organiser un diagnostic solide. Avant les métriques, définir le rôle de la page Toutes les pages d’acquisition ne poursuivent pas le même objectif. Une page peut chercher à :obtenir une demande de démonstration ; générer un essai ; recevoir une demande de devis ; vendre un produit ; faire télécharger une ressource ; inscrire à un événement ; orienter vers une page tarifaire ; qualifier un besoin avant un échange commercial.Le KPI principal dépend de ce rôle. Une page de contenu destinée à informer ne se juge pas comme une page de démonstration. Une campagne de notoriété ne se lit pas comme une campagne de recherche à forte intention. Documentez quatre éléments avant de construire le rapport :Élément QuestionAudience Pour qui la page est-elle conçue ?Promesse Quel problème précis résout-elle ?Source Par quel canal ou campagne les visiteurs arrivent-ils ?Action Quelle action utile doit suivre la visite ?Cette fiche tient en quelques lignes. Elle sert de référence lorsque les chiffres évoluent. Signal 1 : les entrées qualifiées par source Le premier signal n’est pas le nombre brut de sessions. C’est la répartition des entrées par source, campagne et intention. Deux cents visites issues d’une requête précise peuvent être plus utiles que deux mille visites peu ciblées. À l’inverse, un faible volume ne signifie pas qu’une page fonctionne si aucun visiteur n’appartient au segment attendu. Regardez au minimum :les sessions ou visites qui commencent sur la page ; la source et le medium ; la campagne ; le contenu publicitaire ou le lien identifié ; la requête organique lorsque Search Console la rend disponible ; le pays ou la zone commerciale si c’est réellement pertinent ; la part de trafic direct, avec prudence.Le rapport Landing page de GA4 associe la première page vue d’une session à des métriques comme les sessions et les événements clés. Il permet aussi d’ajouter la dimension secondaire « source / medium de la session ». Search Console complète cette lecture pour Google Search avec les clics, impressions, CTR, position, requêtes et pages. Les deux outils ne mesurent pas la même chose. Search Console décrit la visibilité et les clics dans les résultats Google. L’analytics décrit ce qui se passe après l’arrivée, dans les limites de sa collecte. Ne cherchez pas à faire correspondre leurs totaux au visiteur près. Pour les campagnes, une convention UTM stable est plus importante qu’un dashboard sophistiqué. Notre guide sur les UTM, referrers et trafic direct explique comment éviter les libellés incohérents qui fragmentent les rapports. Question de décision - Signal 1 : entrées qualifiées La page attire-t-elle l’audience pour laquelle son message a été conçu ? Signal 2 : la cohérence entre l’intention et le message Une page peut recevoir un trafic pertinent et échouer parce que sa promesse ne correspond pas à ce qui a déclenché le clic. Comparez :le texte de l’annonce ; le mot-clé ou la requête ; le lien de la newsletter ; le titre visible au-dessus de la ligne de flottaison ; la preuve présentée ; l’action demandée.Un visiteur qui clique sur « comparer des outils analytics pour plusieurs sites » doit retrouver cette question immédiatement. Une page qui ouvre sur un discours générique sur la transformation numérique crée une rupture, même si son design est propre. Ce signal ne se réduit pas à un taux unique. Il s’évalue avec plusieurs indices :conversion par source ou campagne ; clic sur le CTA principal ; passage vers la section attendue ; abandon très rapide, à interpréter prudemment ; retours qualitatifs des ventes ou du support ; tests utilisateurs ciblés.Le temps d’engagement peut aider à repérer une anomalie, mais il n’est pas une preuve d’intérêt. Un temps long peut signaler une lecture attentive ou une page confuse. Un temps court peut signaler un abandon ou une réponse trouvée immédiatement. Question de décision - Signal 2 : cohérence du message Le visiteur retrouve-t-il clairement la promesse qui l’a conduit sur la page ? Signal 3 : l’interaction avec l’appel à l’action Le CTA principal représente le premier engagement observable vers l’objectif. Suivez une action réellement utile, par exemple :clic sur « Demander une démo » ; ouverture du formulaire ; clic vers la tarification ; ajout au panier ; démarrage d’un essai ; téléchargement confirmé ; prise de rendez-vous.Évitez de déclarer chaque clic comme conversion. Un clic sur un onglet, une ouverture d’accordéon ou un scroll peuvent aider au diagnostic, mais ils ne valent pas une intention commerciale. Le bon niveau de mesure comprend généralement :l’affichage ou l’entrée sur la page ; le clic sur le CTA principal ; le début du formulaire ou du parcours ; la réussite finale.Cette séquence permet de distinguer une faiblesse du message d’un problème de formulaire. Si peu de personnes cliquent, le problème se situe probablement avant le CTA. Si beaucoup cliquent mais peu terminent, examinez l’étape suivante. Un plan de marquage minimaliste aide à garder une définition stable de ces événements. Question de décision - Signal 3 : appel à l’action Une part suffisante des visiteurs qualifiés choisit-elle de poursuivre ? Signal 4 : le taux d’achèvement de la conversion La conversion finale est l’action que l’entreprise considère comme utile. Elle doit être définie sans ambiguïté. Exemples :formulaire envoyé et accepté ; rendez-vous confirmé ; compte créé ; paiement validé ; abonnement à l’essai activé ; téléchargement effectivement délivré.Le taux doit préciser son dénominateur. « 8 % de conversion » ne veut rien dire sans savoir s’il s’agit de :8 % des visiteurs ; 8 % des sessions ; 8 % des personnes ayant ouvert le formulaire ; 8 % des clics sur le CTA.Pour diagnostiquer un formulaire, suivez au minimum :ouvertures ; démarrages ; erreurs ; abandons ; réussites.Ne collectez pas la valeur des champs dans l’analytics. Les données saisies peuvent contenir un nom, une adresse email, un téléphone, un message libre ou d’autres informations personnelles. Le système métier doit recevoir le contenu. L’analytics n’a besoin que d’un statut technique ou fonctionnel. Question de décision - Signal 4 : achèvement de la conversion Où le parcours perd-il les visiteurs qui ont exprimé une intention ? Signal 5 : la qualité après conversion Une page peut afficher un bon taux de conversion et produire de mauvais résultats commerciaux. Pour une équipe B2B, le signal décisif se trouve souvent après le formulaire :lead conforme au profil cible ; demande réellement liée au produit ; rendez-vous tenu ; opportunité créée ; cycle commercial poursuivi ; revenu ou valeur créée ; taux de spam ou de demandes hors cible.Reliez l’acquisition au CRM avec une granularité proportionnée. Il n’est pas toujours nécessaire de renvoyer des données personnelles dans l’outil analytics. Une table agrégée par campagne, source ou page d’entrée peut suffire à répondre à la question : quelles entrées produisent des demandes utiles ? Définissez avec les ventes une nomenclature courte :qualifié ; non qualifié ; doublon ; spam ; hors zone ; sans suite ; opportunité.Cette étape empêche l’équipe marketing d’optimiser uniquement le volume de formulaires. Question de décision - Signal 5 : qualité après conversion La page génère-t-elle des résultats utiles, pas seulement des soumissions ? Signal 6 : la performance et les erreurs techniques Une page lente ou instable peut dégrader l’expérience avant même que le message soit évalué. Les Core Web Vitals fournissent trois indicateurs de terrain :LCP pour la vitesse d’affichage du contenu principal ; INP pour la réactivité aux interactions ; CLS pour la stabilité visuelle.Ces mesures doivent être complétées par des vérifications opérationnelles :erreurs JavaScript ; formulaire impossible à envoyer ; ressource bloquée ; CTA masqué sur mobile ; redirection incorrecte ; page 404 après soumission ; tracking absent ou dupliqué ; consentement mal appliqué ; temps de réponse serveur anormal.Ne confondez pas corrélation et causalité. Une amélioration technique peut accompagner une hausse de conversion sans en être l’unique cause. Utilisez les données de performance pour détecter les écarts par appareil, version et période. Question de décision - Signal 6 : performance technique Une contrainte technique empêche-t-elle une partie de l’audience d’avancer ? Signal 7 : la santé de la mesure Le septième signal concerne les données elles-mêmes. Avant de commenter une variation, vérifiez :le volume d’événements par rapport aux visites ; les doublons de tags ; les changements de consentement ; les campagnes sans UTM ou mal nommées ; les redirections qui perdent des paramètres ; les paramètres sensibles présents dans les URL ; les changements de formulaire ; les déploiements intervenus pendant la période ; les différences de fuseau horaire ; les filtres et exclusions internes.Une hausse de 30 % peut provenir d’une campagne réussie, d’un événement envoyé deux fois ou d’une définition modifiée. Le rapport doit indiquer les changements de mesure avant d’attribuer une cause business. Le guide sur le filtrage des paramètres d’URL aide à éviter que des identifiants ou valeurs sensibles contaminent les rapports. Question de décision - Signal 7 : santé de la mesure La variation observée décrit-elle le comportement du marché ou un changement du système de mesure ? Un tableau de bord minimal Un tableau de bord de page d’acquisition peut tenir dans cette structure :Bloc Mesure principale Découpage utileAudience Entrées qualifiées Source, campagne, appareilMessage Clic CTA / entrées Source, varianteParcours Début et réussite Étape, appareilRésultat Conversions utiles Campagne, segmentQualité Leads qualifiés Source, pageTechnique Vitals et erreurs Appareil, versionMesure Anomalies documentées Date, déploiementLimitez les comparaisons aux segments qui conduisent à une action. Un filtre qui n’influence aucune décision ajoute de la complexité sans améliorer le pilotage. La cadence d’analyse Chaque semaine Vérifiez :ruptures de trafic ; erreurs de formulaire ; campagnes mal attribuées ; variations extrêmes ; problèmes mobiles ; incidents de performance.Chaque mois Analysez :qualité des sources ; évolution des conversions ; qualité des leads ; pages et campagnes à améliorer ; hypothèses testées ; décisions prises.Intégrez ensuite la conclusion au reporting web mensuel plutôt que d’envoyer un export séparé de chaque outil. Les métriques à ne pas surinterpréter Le taux de rebond Il dépend de la définition de l’outil et du contexte. Une visite courte sur une page qui répond immédiatement à une question n’est pas nécessairement un échec. Le scroll Il peut indiquer jusqu’où le contenu a été parcouru, mais pas ce qui a été compris. Il est utile pour comparer des variantes, pas pour prouver une intention. Le temps passé Il mélange attention, confusion, onglet laissé ouvert et contraintes de mesure. Les heatmaps Elles peuvent aider à formuler une hypothèse, mais ne remplacent ni la conversion ni la recherche utilisateur. Elles impliquent aussi une collecte plus détaillée qui doit être évaluée séparément. Le volume de clics Il ne vaut que si l’action correspond à un objectif explicite et si l’événement n’est pas déclenché plusieurs fois. Conclusion Une page d’acquisition se pilote comme une chaîne, pas comme un classement de métriques. Les sept signaux utiles sont :les entrées qualifiées ; la cohérence entre intention et message ; l’interaction avec le CTA ; l’achèvement de la conversion ; la qualité après conversion ; la performance technique ; la santé de la mesure.Commencez avec cette structure. Ajoutez une mesure seulement lorsqu’elle répond à une question que l’équipe est prête à traiter. FAQ Quel est le KPI principal d’une landing page ? Le KPI principal est l’action utile définie pour cette page : demande qualifiée, essai, achat, rendez-vous ou autre résultat explicite. Le trafic et l’engagement servent surtout à expliquer ce résultat. Faut-il mesurer le scroll sur une page d’acquisition ? Seulement s’il aide à tester une hypothèse précise, par exemple vérifier si une preuve importante est rarement atteinte. Le scroll ne doit pas être traité comme une conversion. Pourquoi GA4 et Search Console affichent-ils des chiffres différents ? Ils mesurent des étapes et des périmètres différents. Search Console mesure l’apparition et les clics dans Google Search. GA4 mesure les sessions ou événements observés sur le site, selon sa configuration et les choix de consentement. Comment relier une landing page au chiffre d’affaires ? Conservez la source, la campagne et la page d’entrée dans le CRM ou dans une table d’attribution contrôlée, puis analysez les résultats par cohortes agrégées. Évitez de renvoyer inutilement les données personnelles du CRM vers l’analytics. Combien d’événements faut-il suivre ? Pour la plupart des pages B2B, quatre niveaux suffisent : entrée, clic CTA, début du parcours et réussite. Ajoutez des événements de diagnostic uniquement lorsqu’ils répondent à un problème identifié. Sources Sources vérifiées le 21 juin 2026.Google Analytics, rapport Page de destination Google Search Console, rapport sur les performances web.dev, Web Vitals Google Analytics, mesurer les campagnes personnalisées avec les paramètres UTM CNIL, cookies et autres traceurs
- 13 Jul, 2026
Reporting web mensuel : construire un rapport que la direction lit vraiment
Un reporting web peut contenir quarante pages et ne produire aucune décision. La direction ne manque généralement pas de graphiques. Elle manque de réponses claires à cinq questions :qu’est-ce qui a changé ? est-ce important ? pourquoi pensons-nous que cela a changé ? quelle action en découle ? pouvons-nous faire confiance aux données ?Le reporting mensuel doit être conçu comme un support de décision, pas comme une archive de toutes les métriques disponibles. Une bonne version tient sur une page principale, complétée par des annexes accessibles à ceux qui doivent enquêter. Elle privilégie cinq indicateurs cohérents, des variations contextualisées et un plan d’action attribué. Le rôle du reporting mensuel Le dashboard répond à une question à la demande. Le reporting mensuel fixe une lecture commune à une date donnée. Il sert à :suivre les objectifs ; détecter les écarts ; expliquer les changements connus ; décider des actions ; conserver une mémoire des hypothèses ; signaler les limites de mesure ; coordonner marketing, produit, ventes et technique.Il ne doit pas servir à démontrer que l’équipe analytics a travaillé. La quantité de données n’est pas la preuve de la qualité du pilotage. Commencer par le destinataire Un rapport de direction n’est pas un rapport d’analyste. La direction a besoin de :tendance ; écart à l’objectif ; impact business ; risque ; décision ; responsable ; échéance.L’équipe opérationnelle a besoin de :détail par canal ; page ; campagne ; événement ; segment ; anomalie ; méthode.Créez donc deux niveaux :une synthèse décisionnelle ; des annexes de diagnostic.Le premier niveau doit rester compréhensible sans ouvrir le dashboard. Le format en sept blocs 1. Une phrase de synthèse Commencez par le message principal, pas par le trafic total. Exemple :Les demandes de démonstration progressent de 18 % malgré un trafic stable, principalement grâce à l’amélioration de deux pages d’entrée organiques. La qualité des leads reste à confirmer sur le cycle commercial.Cette phrase contient :résultat ; comparaison ; mécanisme probable ; limite.Évitez :Le site a enregistré 42 847 sessions ce mois-ci.Sans objectif ni comparaison, le chiffre n’a pas de sens. 2. Trois à cinq KPIs Le tableau principal peut prendre cette forme :Indicateur Mois Variation Objectif StatutVisites qualifiées 18 240 +4 % 18 000 AtteintDemandes de démo 126 +18 % 120 AtteintTaux visite → démo 0,69 % +0,08 pt 0,65 % AtteintLeads acceptés par les ventes 61 +7 % 70 Sous cibleIncidents de collecte 2 +2 0 À corrigerLe statut doit dépendre d’une règle définie, pas d’une couleur décorative. Choisir les KPIs par chaîne de valeur Pour un SaaS B2B :audience qualifiée ; conversion web ; qualité commerciale ; coût ou efficacité d’acquisition ; santé de mesure.Pour un site de contenu :entrées organiques pertinentes ; engagement utile ; passage vers une offre ; inscription ; couverture technique ou indexation.Pour un portefeuille multi-sites, la vue de gouvernance multi-sites peut fournir un socle commun, avec des indicateurs locaux par propriété. 3. Les changements significatifs Ne commentez pas chaque ligne. Sélectionnez trois à cinq mouvements qui dépassent le bruit habituel. Exemples :hausse de 22 % des conversions depuis la page /comparatif/ ; baisse du paid search après réduction budgétaire ; hausse du direct concentrée sur une campagne email non marquée ; chute des impressions Search Console après un changement de mesure ou de visibilité ; rupture d’événements pendant six heures ; progression mobile après amélioration de la performance.Pour chaque changement, indiquez : Observation Amplitude Périmètre Hypothèse Éléments de preuve Niveau de confianceCette structure évite de transformer une corrélation en certitude. 4. Les explications et leur niveau de confiance Une explication peut être :confirmée : déploiement documenté, budget modifié, panne enregistrée ; probable : plusieurs signaux concordent ; possible : hypothèse à tester ; inconnue : données insuffisantes.Exemple :La hausse des conversions organiques est probablement liée à deux pages dont les clics Search Console et les entrées analytics progressent simultanément. Confiance : moyenne. La qualité commerciale ne sera disponible qu’après qualification des leads.Le langage de confiance est plus honnête qu’une causalité inventée. 5. Les décisions et actions Chaque action contient quatre éléments :Action Responsable Échéance Mesure de succèsReproduire le bloc de preuve sur deux pages produit Content 25 juillet +10 % de conversion sur pages testéesCorriger le marquage de la newsletter Growth 15 juillet Part du direct sur landing page revenue à la normaleAuditer la perte d’événements Engineering 10 juillet Aucun trou de collecte sur 30 joursUne action sans responsable est une intention. Une action sans mesure de succès devient une tâche sans apprentissage. 6. La qualité des données Ajoutez un encadré explicite : Confiance globale : moyenne à élevée Couverture connue : site public, hors espace client Incidents : perte de 6 heures le 12 juin Changements : nouveau CMP le 18 juin Ruptures méthodologiques : définition du lead qualifié modifiée le 1er juin Données manquantes : qualification commerciale des 5 derniers joursLa qualité ne doit pas être cachée dans une note de bas de page. Le reporting gagne en crédibilité lorsqu’il dit ce qu’il ne sait pas. 7. Les annexes Les annexes peuvent contenir :détail des sources ; pages d’entrée ; campagnes ; événements ; Search Console ; performance web ; segmentation ; méthodologie ; historique des définitions ; liens vers dashboards.Elles servent au diagnostic, pas à la lecture principale. Comment choisir cinq indicateurs 1. Relier chaque KPI à une décision Demandez : que ferons-nous différemment si ce chiffre monte ou baisse ? Si aucune action n’est possible, l’indicateur est probablement descriptif. 2. Définir le numérateur et le dénominateur Un taux de conversion peut signifier :conversions / sessions ; conversions / visiteurs ; conversions / pages d’entrée ; comptes créés / formulaires démarrés.Écrivez la formule. Une variation de définition doit être signalée comme une rupture. 3. Séparer volume, efficacité et qualitévolume : demandes de démo ; efficacité : taux de conversion ; qualité : demandes acceptées par les ventes.Une hausse de volume avec une baisse de qualité n’est pas nécessairement une amélioration. 4. Ajouter un KPI de fiabilité Exemples :pourcentage d’événements valides ; temps sans données ; nombre de propriétés en erreur ; couverture du consentement ; part de trafic non attribué ; délai de qualification CRM.La mesure elle-même a une performance. Comparer les bonnes périodes Mois précédent Utile pour l’opérationnel, mais sensible au nombre de jours, aux vacances et aux campagnes. Même mois de l’année précédente Utile pour la saisonnalité, à condition que le produit et la méthode soient comparables. Objectif Indispensable pour savoir si la variation compte. Une hausse de 10 % peut rester sous la cible. Moyenne mobile Utile pour lisser les petits volumes et détecter la tendance. Présentez souvent deux comparaisons, pas quatre. Par exemple : Juin 2026 vs mai 2026 Juin 2026 vs objectif mensuelAjoutez l’année précédente seulement si elle éclaire réellement la saisonnalité. Éviter les faux écarts Normalisez :nombre de jours ; jours ouvrés ; fuseau horaire ; devise ; définition de conversion ; périmètre de site ; consentement ; campagnes ; incidents.Une baisse mensuelle peut simplement venir d’un mois plus court ou d’un week-end supplémentaire. Utiliser Search Console et analytics ensemble Search Console et un outil analytics n’observent pas le même objet. Search Console rapporte notamment les clics et impressions dans les résultats Google, selon ses propres règles. L’analytics observe les visites ou événements collectés sur le site. Les volumes peuvent différer pour des raisons légitimes :clic sans chargement complet ; consentement ou blocage ; fuseau horaire ; regroupement des URL ; filtres ; bots ; définition de session.Le bon usage est la triangulation :Search Console pour visibilité, requêtes et clics ; analytics pour pages d’entrée et actions sur le site ; CRM pour qualité et revenu.Ne forcez pas les chiffres à être identiques. Ajouter la performance web sans noyer le rapport Les Core Web Vitals évaluent actuellement trois dimensions principales de l’expérience :LCP pour le chargement ; INP pour la réactivité ; CLS pour la stabilité visuelle.Un rapport de direction n’a pas besoin de toutes les distributions techniques. Il peut signaler :pourcentage de pages ou d’origines au niveau attendu ; évolution ; pages critiques ; impact d’un déploiement ; action engagée.Utilisez les données de terrain lorsque disponibles, car elles reflètent l’expérience d’utilisateurs réels. Les tests de laboratoire restent utiles au diagnostic. Exemple de rapport mensuel en une page Performance web, juin 2026 Synthèse Les demandes de démonstration progressent de 18 % avec un trafic stable. Deux pages organiques expliquent l’essentiel de la hausse. Les leads acceptés par les ventes restent sous l’objectif, ce qui limite la conclusion sur la qualité. KPIsKPI Résultat vs mai ObjectifVisites qualifiées 18 240 +4 % 18 000Démos 126 +18 % 120Taux de conversion 0,69 % +0,08 pt 0,65 %Leads acceptés 61 +7 % 70Disponibilité collecte 99,2 % -0,8 pt 100 %Trois faits/guide-analytics/ génère 21 démos contre 10 en mai. Le paid search baisse de 14 % après réduction du budget. La part du direct augmente sur une landing page email, probablement à cause de liens sans UTM.DécisionsÉtendre le format de la page guide à deux pages produit. Corriger le générateur de liens newsletter. Revoir la qualification des leads avec les ventes.Qualité des données Un incident de collecte de six heures affecte le 12 juin. Les cinq derniers jours de qualification CRM sont incomplets. Ce format peut être lu en deux minutes. Les annexes répondent aux questions suivantes. Automatiser la préparation, pas le jugement Automatisez :extraction ; calcul des variations ; tableaux ; contrôles de fraîcheur ; alertes ; captures de définitions ; génération du brouillon.Gardez une revue humaine pour :choisir les faits importants ; vérifier les anomalies ; formuler les hypothèses ; attribuer le niveau de confiance ; décider les actions.Une génération automatique ne sait pas qu’une campagne a été arrêtée pour une raison commerciale, qu’un formulaire a changé ou qu’un lead a une valeur différente. Le calendrier mensuel Jour 1 : contrôle des données Vérifiez fraîcheur, incidents, définitions et imports. Jour 2 : analyse Identifiez les mouvements, triangulez et préparez les hypothèses. Jour 3 : revue opérationnelle Marketing, produit et ventes confirment les changements connus. Jour 4 : publication Diffusez la synthèse avec les actions. Milieu de mois : suivi Vérifiez l’avancement des décisions, sans attendre le prochain rapport. Le calendrier peut être plus rapide. La règle essentielle est de séparer contrôle, analyse et validation. Les erreurs qui rendent le reporting inutile Tout afficher Un rapport exhaustif ne hiérarchise rien. Commenter uniquement les hausses Une hausse peut être sous l’objectif ou issue d’un canal peu qualifié. Cacher les incidents Ils seront découverts plus tard et fragiliseront tout le document. Attribuer sans preuve « La campagne a causé la hausse » exige plus qu’une concomitance. Changer les KPIs chaque mois Le reporting perd sa continuité. Modifiez-les lorsque la stratégie change, avec une note de transition. Mesurer les actions de l’équipe plutôt que les résultats « Dix articles publiés » est une activité. « Entrées qualifiées et conversions issues des articles » est un résultat, à interpréter avec prudence. Conclusion Un bon reporting mensuel est un document de décision en sept blocs :synthèse ; KPIs ; changements ; explications et confiance ; actions ; qualité des données ; annexes.Il tient la direction informée sans masquer la complexité. Il rend visibles les incertitudes, relie les chiffres aux objectifs et transforme chaque conclusion en action attribuée. Cinq indicateurs bien définis, lus régulièrement, valent mieux que cinquante graphiques sans propriétaire. FAQ Combien de pages doit faire un reporting mensuel ? La synthèse principale peut tenir sur une page. Les annexes peuvent être plus longues, mais elles doivent rester optionnelles pour la lecture de direction. Faut-il envoyer un PDF ou un lien vers le dashboard ? Le meilleur format est celui qui conserve une synthèse datée et permet d’accéder au détail. Un email ou document court avec lien vers un dashboard fonctionne souvent mieux qu’un export exhaustif. Combien de KPIs faut-il suivre ? Trois à cinq KPIs principaux suffisent généralement. Ajoutez des indicateurs de diagnostic dans les annexes. Comment présenter une donnée incertaine ? Indiquez la limite, la cause possible et un niveau de confiance. Ne remplacez pas une donnée manquante par une certitude narrative. Faut-il comparer avec le mois précédent ou l’année précédente ? Utilisez le mois précédent pour l’opérationnel et l’année précédente pour la saisonnalité lorsque les périmètres sont comparables. L’écart à l’objectif reste souvent la comparaison la plus utile. SourcesGoogle Analytics, Reports overview Google Search Console, Performance report web.dev, Web Vitals Google Analytics, Landing page report Google Analytics, Traffic-source dimensions
Consentement analytics : ce qu’il faut vérifier avant de promettre « sans bannière »
« Analytics sans cookies » devient souvent, en une phrase, une promesse d’absence de consentement, puis de site sans bannière. Ces trois affirmations ne sont pas équivalentes. Un outil peut ne pas déposer de cookie tout en lisant ou écrivant une information sur le terminal par un autre mécanisme. Une solution peut proposer une configuration de mesure d’audience limitée, tandis que d’autres modules du même produit exigent une analyse différente. Et même si l’analytics respecte un cadre strict, un site peut charger des vidéos, formulaires, pixels publicitaires ou outils de support qui rendent une interface de consentement nécessaire. La bonne question n’est donc pas : « l’outil est-il cookieless ? » Elle est :Quels traitements et traceurs sont effectivement déployés sur ce site, dans cette configuration, pour quelles finalités et sous quelles conditions ?Cet article présente une grille de vérification. Il ne constitue pas un avis juridique et doit être adapté aux pays, aux usages et à la configuration du site. Trois couches à ne pas confondre 1. La technologie de stockage ou d’accès Le mot « cookie » décrit une technique parmi d’autres. Le cadre ePrivacy vise plus largement le stockage d’informations dans le terminal d’un utilisateur ou l’accès à des informations déjà stockées, selon les règles transposées dans chaque État. Des identifiants en local storage, certains pixels, SDK, mécanismes de fingerprinting ou autres accès au terminal peuvent donc poser la même question de consentement, même sans cookie HTTP traditionnel. Cookieless décrit une caractéristique technique. Ce n’est pas une qualification juridique complète. 2. Le régime ePrivacy des traceurs En France, l’article 82 de la loi Informatique et Libertés transpose le cadre relatif aux traceurs. Le principe est l’information et le consentement préalable pour les opérations concernées, avec des exceptions notamment lorsque le traceur est strictement nécessaire à la fourniture d’un service expressément demandé. La CNIL décrit aussi des conditions sous lesquelles certains traceurs de mesure d’audience peuvent entrer dans un périmètre d’exemption. Il s’agit d’un cadre étroit, pas d’une exemption générale pour toute analytics. 3. Le traitement de données personnelles au titre du RGPD Même lorsqu’une opération sur le terminal ne requiert pas de consentement ePrivacy dans une configuration donnée, le traitement peut rester soumis au RGPD s’il porte sur des données personnelles. Il faut alors documenter notamment les finalités, la base légale pertinente, l’information, la minimisation, la durée, les destinataires, les transferts, la sécurité et les droits. L’absence de bannière ne signifie donc ni absence de traitement, ni absence d’information. Les conditions françaises d’une mesure d’audience limitée La CNIL indique que, pour être limités à ce qui est strictement nécessaire à la fourniture du service et pouvoir être exemptés de consentement dans le cadre décrit, les traceurs doivent notamment :avoir une finalité strictement limitée à la mesure de l’audience du site ou de l’application ; être utilisés pour le compte exclusif de l’éditeur ; produire uniquement des données statistiques anonymes ; ne pas conduire à un recoupement avec d’autres traitements ; ne pas transmettre de données non anonymes à des tiers ; ne pas permettre un suivi global entre plusieurs sites ou applications.La CNIL recommande également l’information des utilisateurs, une durée de vie des traceurs limitée, par exemple treize mois sans prorogation automatique, une conservation des informations collectées limitée à vingt-cinq mois et un réexamen périodique de ces durées. Chaque terme compte. « Finalité strictement limitée » Mesurer les performances techniques, les contenus consultés ou les problèmes de navigation peut entrer dans la logique décrite. Constituer des audiences publicitaires, enrichir un profil CRM, personnaliser des annonces ou suivre une personne entre services relève d’autres finalités. Une même interface produit peut proposer les deux. C’est la fonctionnalité activée qui doit être auditée. « Pour le compte exclusif de l’éditeur » Le fournisseur ne doit pas transformer la collecte en ressource pour son propre ciblage, son profilage ou une mesure transversale non compatible avec le cadre considéré. Lisez le contrat, la documentation du produit et la liste des sous-traitants. Une affirmation commerciale ne suffit pas. « Statistiques anonymes » Le mot anonyme est exigeant. Supprimer un nom, tronquer une IP ou hacher un identifiant ne garantit pas automatiquement l’anonymat. Si un signal permet encore de distinguer ou relier une personne, l’analyse doit rester prudente. Demandez au fournisseur de décrire les transformations et les risques de réidentification. « Pas de suivi global entre sites » Un identifiant commun utilisé pour dédupliquer une personne entre plusieurs propriétés change le périmètre. Cette règle est particulièrement importante pour les groupes et agences qui souhaitent consolider leur audience. Le tableau de bord multi-sites peut agréger des indicateurs sans imposer un identifiant transversal. La checklist avant toute promesse « sans bannière » 1. Inventorier tous les composants du site Ne commencez pas par l’outil analytics. Commencez par le site complet :analytics ; gestionnaire de tags ; vidéos intégrées ; cartes ; chat et support ; formulaires ; anti-fraude ; A/B testing ; session replay ; publicité ; réseaux sociaux ; CDN et sécurité ; scripts des partenaires ; SDK mobiles éventuels.Réalisez un audit des traceurs avant et après chaque choix de consentement. Testez plusieurs pages et parcours. Une analytics stricte ne neutralise pas un pixel publicitaire chargé ailleurs. 2. Décrire les finalités réelles Pour chaque composant, écrivez ce qu’il permet réellement :statistiques agrégées de fréquentation ; analyse de campagne ; personnalisation ; publicité ; sécurité ; enregistrement d’interactions ; assistance ; expérimentation produit.Évitez la catégorie unique « amélioration du service ». Elle est trop large pour gouverner la configuration. 3. Vérifier les opérations sur le terminal Documentez :cookies déposés ou lus ; local storage ; session storage ; identifiants de cache ; SDK ; pixels ; accès à des caractéristiques du terminal ; mécanismes de consentement et de retrait.Le fait qu’aucun cookie n’apparaisse dans un outil de scan ne clôt pas l’analyse. 4. Vérifier les données collectées et les transformations Le data collection summary doit répondre à des questions concrètes :l’adresse IP est-elle reçue, utilisée et stockée ? l’URL complète est-elle transmise ? le user-agent est-il conservé brut ou réduit ? un identifiant visiteur est-il créé ? peut-il être stable entre des jours ou des sites ? les paramètres UTM sont-ils conservés ? des événements libres peuvent-ils contenir du texte ? quelles données sont agrégées ? à quel moment une donnée devient-elle non individualisable ?Un mode « anonyme » dont personne ne peut expliquer le fonctionnement n’est pas une preuve. 5. Vérifier l’usage par le fournisseur Demandez :le fournisseur agit-il uniquement comme sous-traitant pour cette collecte ? réutilise-t-il certaines données pour ses propres finalités ? combine-t-il les données entre clients ? fournit-il un benchmark à partir de données individualisées ? entraîne-t-il un modèle ou enrichit-il un autre produit ? quels sous-traitants reçoivent les données ? quels transferts internationaux s’appliquent ?Une fonctionnalité de benchmark peut parfois être conçue sur des données agrégées et séparées. Elle doit néanmoins être comprise, pas supposée. 6. Vérifier la configuration exacte La documentation peut indiquer « configurable pour respecter les critères ». Cela ne signifie pas que la configuration par défaut de votre compte les respecte. Conservez une preuve des réglages :capture ou export de configuration ; version du script ; paramètres de collecte ; modules désactivés ; domaines autorisés ; rétention ; options de partage ; date de vérification ; responsable.La CNIL invite les éditeurs à demander aux fournisseurs les documents permettant de justifier le cadre et ses modalités opérationnelles. 7. Examiner la rétention Distinguez :durée de vie d’un traceur ou identifiant ; rétention des événements bruts ; rétention des statistiques ; logs techniques ; sauvegardes ; exports.La suppression automatique doit être vérifiée. Une durée affichée dans le tableau de bord ne couvre pas nécessairement les exports créés par l’équipe. 8. Vérifier l’information des visiteurs Même lorsqu’un consentement n’est pas requis pour une mesure strictement encadrée, la CNIL recommande d’informer les utilisateurs de sa mise en œuvre, par exemple dans la politique de confidentialité. L’information doit expliquer, selon le contexte :la finalité ; les données ou catégories pertinentes ; le fonctionnement général ; la durée ; le fournisseur ; les destinataires ; les droits et moyens de contact ; les transferts pertinents.« Nous utilisons une analytics respectueuse de la vie privée » est trop vague. 9. Tester le refus et le retrait Lorsqu’une partie de la stack repose sur le consentement :aucun traceur concerné ne doit partir avant le choix ; le refus doit être aussi simple que l’acceptation selon les règles applicables ; le retrait doit produire un effet ; le signal doit atteindre tous les tags concernés ; les nouvelles pages et composants doivent respecter le choix.Testez le comportement, pas seulement l’apparence de la CMP. 10. Faire valider le périmètre La décision finale appartient au responsable de traitement, accompagné si nécessaire par son DPO ou son conseil. Conservez l’analyse :pays concernés ; finalités ; inventaire ; critères examinés ; documentation fournisseur ; configuration ; tests ; risques résiduels ; date et responsables ; déclencheurs de révision.Une conclusion peut être différente entre un site corporate français, une application authentifiée et un ensemble de propriétés internationales. Cookieless, Consent Mode et mesure sans bannière Cookieless Le terme peut signifier :aucun cookie persistant ; aucun cookie dans un mode précis ; stockage alternatif ; événement sans identifiant ; identifiant dérivé côté serveur ; simple absence de cookies publicitaires.Demandez une définition technique. Le mot seul ne suffit pas. Consent Mode Un mode de consentement transmet l’état du choix aux tags et peut modifier leur comportement. Selon le produit et la configuration, des signaux peuvent encore être envoyés sans cookie publicitaire. Ce mécanisme aide à appliquer une décision. Il ne décide pas à la place de l’éditeur si la collecte sans consentement est permise. Il ne transforme pas non plus une finalité publicitaire en mesure strictement nécessaire. « Pas de bannière » Cette phrase ne peut être évaluée qu’au niveau du site complet. Elle peut être raisonnable lorsqu’aucun composant non nécessaire n’est déployé avant consentement et que la mesure d’audience utilisée respecte effectivement le cadre applicable. Elle devient trompeuse si elle repose seulement sur l’absence de cookie analytics. Les formulations à utiliser ou éviter À éviterpromesse de conformité RGPD totale ; exemption valable dans tous les cas ; équivalence automatique entre absence de cookies et absence de bannière ; certification officielle par la CNIL ; validation officielle par l’autorité ; « aucune donnée personnelle » « aucune analyse juridique nécessaire »La CNIL précise qu’une solution ne peut pas se présenter comme certifiée ou validée par elle sur la seule base de l’auto-évaluation relative à la mesure d’audience. Formulations plus précises« cookieless par défaut » « conçu pour une collecte minimale » « peut être configuré pour une mesure d’audience limitée » « l’applicabilité d’une exemption dépend des finalités, de la configuration et du contexte » « les utilisateurs restent informés de la mesure mise en œuvre » « la stack complète du site doit être auditée »La précision protège la crédibilité autant que la conformité. Quand conserver une bannière Une bannière ou autre mécanisme de consentement reste généralement nécessaire lorsque le site active, selon le cadre applicable :publicité personnalisée ; retargeting ; partage avec des régies ; suivi inter-sites ; enrichissement de profils ; certains outils de session replay ; personnalisation non nécessaire ; intégrations tierces déposant des traceurs non essentiels ; analytics dépassant le périmètre d’une mesure limitée.L’article sur le session replay et la consultation CNIL montre pourquoi une fonctionnalité détaillée d’observation ne doit pas être assimilée à une statistique d’audience agrégée. Un processus de décision simple Cas A : mesure strictement limitée L’équipe utilise une collecte minimale, sans suivi transversal, sans réutilisation fournisseur, avec statistiques anonymes, rétention cadrée, information et documentation. Action : analyser et documenter l’applicabilité du cadre local, puis vérifier le reste du site. Cas B : analytics enrichie après consentement L’équipe veut des événements détaillés, de l’attribution avancée ou des identifiants plus persistants. Action : bloquer les fonctionnalités concernées avant consentement, transmettre le choix correctement et documenter le traitement. Cas C : stack mixte Une mesure minimale fonctionne par défaut, puis des modules étendus sont activés après consentement. Action : séparer techniquement les modes, éviter qu’un changement de rapport active silencieusement une collecte, et tester chaque transition. Cette séparation stricte est plus crédible qu’un réglage unique supposé convenir à tous les usages. Conclusion Une promesse « sans bannière » ne se déduit pas du mot cookieless. Elle résulte d’une analyse du site complet, de ses finalités, de ses opérations techniques et de sa configuration. Avant de communiquer, vérifiez :tous les composants ; les finalités ; les accès au terminal ; les données et identifiants ; les usages du fournisseur ; la configuration ; la rétention ; l’information ; le fonctionnement du consentement lorsqu’il s’applique ; la documentation de la décision.Le résultat peut être une stack sans bannière pour un périmètre strict, une stack avec consentement pour des usages étendus, ou une combinaison clairement séparée. La qualité vient de cette distinction, pas d’un slogan. FAQ Une analytics sans cookies est-elle automatiquement exemptée de consentement ? Non. Il faut examiner les autres opérations sur le terminal, les finalités, les données, les identifiants et le droit national applicable. Cookieless est une caractéristique technique, pas une conclusion juridique. La CNIL certifie-t-elle les outils analytics exemptés ? Non. La CNIL fournit un cadre et un outil d’auto-évaluation, mais précise qu’une solution ne peut pas se présenter comme « certifiée » ou « validée par la CNIL » sur cette base. Peut-on informer les visiteurs sans afficher une bannière ? Oui, lorsque le consentement n’est pas requis pour la collecte considérée, une information peut être fournie dans la politique de confidentialité ou un espace approprié. Son contenu doit rester clair et exact. Les UTM empêchent-ils une exemption ? Pas automatiquement, mais leur usage et leur combinaison doivent rester compatibles avec la finalité limitée, la minimisation et l’absence de suivi transversal. Ils ne doivent jamais contenir de donnée personnelle. Qui décide si le site peut fonctionner sans bannière ? Le responsable de traitement prend la décision et doit pouvoir la documenter, avec l’appui de son DPO ou conseil lorsque nécessaire. Le fournisseur seul ne peut pas garantir la conclusion pour tous les sites. SourcesCNIL, Cookies : solutions pour les outils de mesure d’audience CNIL, Cookies et traceurs : que dit la loi ? CNIL, Cadre de mesure d’audience à comprendre avant de choisir un outil Directive 2002/58/CE relative à la vie privée et aux communications électroniques CEPD, Lignes directrices 05/2020 sur le consentement CEPD, Lignes directrices 2/2023 sur le champ technique de l’article 5(3) ePrivacy
- 08 Jun, 2026
Tableau de bord multi-sites : suivre 5, 10 ou 30 sites sans perdre la lisibilité
Suivre un site est un problème de mesure. En suivre dix devient un problème de gouvernance. Au départ, chaque équipe crée sa propriété analytics, nomme ses événements et construit son tableau de bord. Quelques mois plus tard, le groupe dispose de dix définitions de « conversion », trois fuseaux horaires, des sources UTM incompatibles et plusieurs comptes dont personne ne connaît le propriétaire. Le problème n’est pas qu’il manque des graphiques. Il manque une structure commune. Un tableau de bord multi-sites utile doit permettre deux mouvements :comparer les propriétés à partir d’un socle homogène ; descendre dans chaque site sans effacer son contexte métier.Chercher à tout fusionner produit une moyenne abstraite. Tout séparer empêche de voir le portefeuille. La bonne architecture garde les deux niveaux. Commencer par une carte des propriétés Avant de choisir les indicateurs, listez les sites et leur rôle.Propriété Rôle Public principal Conversion utile ResponsableSite corporate Réassurance Prospects, partenaires Contact qualifié CommunicationSite produit A Acquisition PME Demande de démo Growth ASite produit B Acquisition ETI Rendez-vous Growth BCentre d’aide Support Clients Résolution autonome SupportBlog Découverte Audience B2B Inscription ou passage produit ContentDeux sites avec des objectifs différents ne doivent pas être classés uniquement par volume de visites. Le centre d’aide peut être très performant quand il réduit les demandes de support, même si son taux de démonstration est nul. La carte doit également contenir :domaine et sous-domaines ; environnement de production ; outil et identifiant de propriété ; fuseau horaire ; devise éventuelle ; date de création ; propriétaire métier ; propriétaire technique ; personnes ayant accès ; mode de collecte ; durée de conservation ; statut actif, en migration ou archivé.Cette fiche devient l’inventaire de référence. Définir un contrat de mesure commun Le socle multi-sites n’est pas un tableau de bord. C’est un petit contrat de mesure appliqué à chaque propriété. Dimensions communes Choisissez une définition commune pour :page ou chemin ; domaine référent ; source, medium et campagne ; pays ou zone géographique ; type d’appareil ; date et fuseau horaire ; événements principaux ; statut de conversion.Les paramètres d’URL doivent suivre une politique de filtrage commune. Les campagnes doivent utiliser la même nomenclature UTM. Événements communs Une petite bibliothèque suffit : form_submitted demo_requested signup_completed download_completed outbound_clicked search_usedChaque événement doit avoir :une définition ; une condition de déclenchement ; des propriétés autorisées ; un propriétaire ; un test ; une version.Un même nom ne doit pas représenter deux actions différentes. À l’inverse, trois noms différents pour la même demande de contact empêchent toute comparaison. Règles de qualité communes Documentez :filtrage des environnements de test ; exclusion ou traitement des bots ; gestion des domaines internes ; consentement et modes de collecte ; normalisation des chemins ; fuseau horaire ; calendrier de déploiement ; seuils d’alerte.Le résumé de collecte peut contenir le socle global et les exceptions de chaque propriété. Séparer trois niveaux de lecture Un bon système multi-sites ne met pas tous les graphiques sur une seule page. Il crée trois vues. Niveau 1 : la vue portefeuille Cette vue répond aux questions de direction :quels sites gagnent ou perdent du trafic utile ? où les conversions progressent-elles ? quelle propriété présente une anomalie ? quelles équipes ont besoin d’un diagnostic ? quel site ne remonte plus de données ?Elle doit rester courte. Un tableau avec une ligne par propriété est souvent plus utile qu’une mosaïque de vingt courbes. Colonnes possibles :Site Visites Évolution Conversions utiles Taux Canal principal Statut donnéesCorporate 24 500 +6 % 132 0,54 % Organique OKProduit A 18 100 -4 % 284 1,57 % Paid search À examinerProduit B 9 600 +12 % 96 1,00 % Partenaires OKAide 41 000 +2 % n/a n/a Direct OKLes chiffres sont illustratifs. Le statut données est essentiel : un volume en baisse n’a pas le même sens si le script a cessé de fonctionner. Niveau 2 : la vue propriété Chaque site dispose de son tableau de bord métier :acquisition ; pages d’entrée ; contenus ; conversions ; événements ; tendances ; qualité des données.Cette vue conserve les dimensions propres au site. Un SaaS peut suivre l’essai démarré, tandis qu’un centre d’aide suit la recherche sans résultat ou le passage vers le support. Niveau 3 : le diagnostic Le diagnostic sert aux analystes et développeurs :événements par version ; erreurs de collecte ; paramètres inconnus ; écarts entre client et serveur ; ruptures temporelles ; domaines inattendus ; volumes de tests ; délai d’ingestion.Il ne doit pas encombrer le reporting de direction. Mais son absence transforme chaque anomalie en enquête manuelle. Les KPIs que l’on peut comparer Tous les indicateurs ne sont pas additionnables. Volume de visites ou pages vues Ils donnent un ordre de grandeur, mais favorisent naturellement les sites à forte audience. Utilisez-les avec une tendance et un contexte. Conversions définies sur un socle commun Une « conversion utile » peut regrouper plusieurs actions si la règle est explicite, par exemple :demande de démo ; formulaire de contact qualifié ; inscription validée ; achat confirmé.Pour comparer, conservez aussi le détail par type. Une somme seule peut cacher un déplacement vers des actions de moindre valeur. Taux de conversion Le taux permet de comparer des propriétés de tailles différentes, à condition d’utiliser le même dénominateur. Documentez s’il s’agit de visites, visiteurs, sessions ou pages d’entrée. Part des canaux La répartition organique, payante, email, partenaire, referral et direct aide à comprendre la dépendance de chaque site. Elle suppose une taxonomie de campagnes commune. Santé de collecte Ajoutez des KPIs techniques :dernière donnée reçue ; variation du volume d’événements ; part d’événements rejetés ; nombre de paramètres inconnus ; pages sans titre ou chemin ; évolution brutale du direct.La fiabilité de la donnée est un KPI de gouvernance. Ce qu’il ne faut pas additionner naïvement Les visiteurs uniques Une même personne peut visiter plusieurs domaines. Additionner les visiteurs uniques de chaque propriété la compte plusieurs fois. Créer un identifiant global pour dédupliquer les personnes change fortement le profil de collecte. En France, la CNIL précise notamment que l’usage d’un même identifiant à travers plusieurs sites pour un suivi global exclut la mesure du cadre d’exemption décrit pour certains traceurs d’audience. Une équipe ne doit donc pas introduire un suivi transversal uniquement pour obtenir un total plus propre. Pour un reporting frugal, acceptez :une somme de visites par propriété ; une portée non dédupliquée clairement nommée ; ou une analyse agrégée sans identifiant individuel, lorsque la méthode est adaptée.Les conversions hétérogènes Un téléchargement de brochure ne vaut pas automatiquement une vente. Présentez un socle de conversions, puis la composition. Les moyennes simples La moyenne des taux de conversion de dix sites donne le même poids à un site de 100 visites et à un site de 100 000 visites. Utilisez un taux global pondéré ou affichez la distribution. Les périodes non alignées Des fuseaux horaires ou calendriers de campagne différents peuvent déplacer les événements d’un jour ou d’une semaine. Normalisez le temps avant de comparer. Comparer sans punir les petits sites Une vue multi-sites devient vite un classement. C’est rarement une bonne idée. Utilisez plutôt quatre axes :niveau actuel : volume ou taux ; évolution : comparaison à la période précédente ; objectif local : progression vers une cible propre au site ; qualité de mesure : confiance dans la donnée.Un site de niche peut avoir peu de trafic mais une progression saine et des conversions de grande valeur. Une propriété très visitée peut cacher une dépendance excessive au paid ou un tracking cassé. Les sparklines et intervalles de comparaison sont plus utiles qu’un podium. Structurer les accès Le multi-sites augmente le risque d’accès excessifs. Définissez des rôles :propriétaire portefeuille : voit toutes les propriétés et gère les standards ; propriétaire de site : administre sa propriété ; analyste : consulte et exporte selon le besoin ; contributeur : voit les rapports sans modifier la collecte ; agence ou partenaire : accès limité aux propriétés du contrat ; support technique : accès temporaire et journalisé lorsque nécessaire.Évitez les comptes partagés. Revue trimestrielle des accès, retrait automatique au départ d’un prestataire et principe du moindre privilège. Une agence qui gère dix clients ne devrait pas utiliser un seul compte administrateur permanent sur tous les environnements. Organiser le cycle de gouvernance Chaque semaine : surveiller la santé Automatisez des alertes simples :aucune donnée reçue depuis un délai défini ; chute ou hausse anormale ; apparition d’un domaine inconnu ; augmentation des événements rejetés ; changement de part du direct.Chaque mois : lire les décisions Réunissez les propriétaires de sites autour de trois questions :qu’est-ce qui a changé ? quelle action en découle ? quelle hypothèse sera testée ensuite ?Le reporting ne doit pas devenir une tournée de chiffres. Chaque trimestre : revoir le contrat Vérifiez :événements communs ; nomenclature UTM ; propriétés inactives ; accès ; rétention ; nouveaux fournisseurs ; écarts de configuration ; objectifs métier.À chaque lancement : utiliser une checklist Avant d’ajouter un site :attribuer les propriétaires ; choisir le fuseau horaire ; appliquer le socle de collecte ; configurer les filtres ; tester les événements ; vérifier le consentement ; ajouter la propriété au portefeuille ; documenter les exceptions ; définir les alertes ; programmer la première revue.Choisir l’architecture d’outil Plusieurs modèles existent. Une propriété par site C’est la structure la plus lisible pour les accès, la rétention et les configurations. Elle exige une couche portefeuille pour comparer. Une propriété commune avec dimension de site Elle simplifie certains rapports mais mélange les droits, les configurations et les risques de collecte. Une erreur sur une propriété affecte l’ensemble. Une propriété par site plus une vue consolidée C’est souvent le meilleur compromis : séparation opérationnelle et agrégation pour le pilotage. Certains outils proposent des fonctions de roll-up ou de vue consolidée. Vérifiez toujours le plan nécessaire, la méthode de déduplication, les droits et les données réellement regroupées. Le choix dépend moins du nombre de sites que de leur indépendance : équipes, marques, finalités, régions, droits d’accès et configurations privacy. Un modèle de dashboard en une page Bandeau supérieurvisites du portefeuille ; conversions utiles ; taux global pondéré ; nombre de propriétés saines ; nombre d’anomalies ouvertes.Tableau central Une ligne par propriété avec tendance, conversion, canal et statut. Bloc acquisition Répartition des canaux par site, idéalement sous forme de parts comparables. Bloc contenu Top pages d’entrée et pages qui progressent, avec filtre par propriété. Bloc qualité Données manquantes, événements rejetés, accès à revoir et déploiements récents. Chaque bloc doit conduire à une page de détail. La vue portefeuille signale, elle n’explique pas tout. Conclusion Le suivi multi-sites fonctionne quand la gouvernance précède la visualisation. Il faut :une carte claire des propriétés ; un contrat de mesure commun ; des exceptions documentées ; trois niveaux de lecture ; des indicateurs comparables ; des accès limités ; un cycle de revue ; une consolidation qui n’impose pas un suivi individuel transversal.Le bon tableau de bord ne cherche pas à rendre tous les sites identiques. Il leur donne un langage commun sans perdre leur rôle. FAQ Faut-il une propriété analytics par site ? C’est souvent le choix le plus clair pour séparer les accès et configurations. Une vue consolidée peut ensuite comparer les propriétés. Une propriété commune reste possible, mais elle doit être justifiée par des besoins et droits réellement communs. Peut-on additionner les visiteurs uniques de plusieurs sites ? Pas comme une audience dédupliquée. Une personne peut être comptée sur plusieurs propriétés. Indiquez qu’il s’agit d’une somme non dédupliquée ou utilisez une méthode agrégée adaptée, sans introduire par défaut un identifiant global. Combien de KPIs dans la vue portefeuille ? Cinq à huit colonnes bien définies suffisent généralement : volume, tendance, conversion, taux, canal principal et santé de collecte. Le détail appartient aux vues par propriété. Comment gérer des objectifs différents selon les sites ? Gardez un petit socle commun, puis ajoutez des indicateurs locaux. Comparez aussi chaque site à son propre objectif et à sa tendance, pas uniquement aux autres. À quelle fréquence revoir les accès ? Une revue trimestrielle est une pratique raisonnable, complétée par un retrait immédiat lors des départs ou fins de contrat. SourcesCNIL, Cookies : solutions pour les outils de mesure d’audience Google Analytics, Analytics account structure Google Analytics, Roll-up properties Matomo, Roll-Up Reporting Plausible, Consolidated view Règlement (UE) 2016/679, principes de minimisation et de limitation des finalités
- 01 Jun, 2026
Quels paramètres d’URL filtrer dans une analytics privacy-first ?
Une URL peut sembler anodine tout en transportant beaucoup plus d’information que le chemin de la page. https://example.com/confirmation? email=alice@example.com& order_id=84721& utm_source=newsletter& session_token=abc123Si un outil analytics collecte l’URL complète, ces valeurs peuvent se retrouver dans les événements, les logs, les exports, les captures d’écran et les rapports partagés. Le problème ne vient pas seulement de l’outil. Il commence souvent dans l’application, qui place une information excessive dans l’adresse. Une approche privacy-first traite le sujet à deux niveaux :ne pas mettre de donnée sensible ou personnelle dans l’URL ; ne transmettre à l’analytics que les paramètres explicitement utiles.Le filtre n’est donc pas une rustine unique. C’est un contrôle de défense en profondeur. Pourquoi les query parameters demandent un traitement spécifique La partie située après ? s’appelle la chaîne de requête. Elle contient des paires clé-valeur séparées par &. Ces paramètres peuvent servir à :attribuer une campagne ; paginer ou trier une liste ; sélectionner une langue ; préremplir un formulaire ; identifier une ressource ; transporter un jeton ; suivre une expérience ; mémoriser un filtre de recherche.Le navigateur, le serveur, le CDN, les outils de supervision et les scripts tiers peuvent tous observer une partie de l’URL. OWASP rappelle que des informations sensibles placées dans la query string peuvent apparaître dans l’historique, les journaux, les systèmes intermédiaires et parfois les en-têtes de provenance, même lorsque la connexion utilise HTTPS. HTTPS protège le transport entre deux points. Il ne rend pas le contenu de l’URL invisible aux systèmes autorisés qui la traitent. La règle principale : autoriser, plutôt que tenter de tout bloquer Une blocklist énumère les paramètres interdits : email phone token user_idElle échoue dès qu’un développeur introduit customer_email, invitee, auth ou une clé inconnue. Une allowlist énumère les paramètres dont l’usage analytics a été justifié : utm_source utm_medium utm_campaign utm_contentTout le reste est supprimé avant transmission ou stockage. L’allowlist est généralement plus robuste pour une collecte minimale. Elle réduit aussi la fragmentation des rapports : /produits/?sort=price, /produits/?sort=name et /produits/?session=xyz peuvent être regroupés sous un chemin stable lorsque ces variantes ne répondent à aucune question de pilotage. Il existe toutefois des applications où certains paramètres fonctionnels doivent rester visibles. La bonne méthode n’est pas « supprimer tout ce qui suit ? », mais classer chaque famille. Une grille de décision en six catégories 1. Paramètres de campagne autorisés Exemples : utm_source utm_medium utm_campaign utm_contentIls peuvent être utiles pour lire l’acquisition, à condition d’appliquer une nomenclature contrôlée et de ne jamais y placer d’identifiant personnel. Le guide sur les UTM, referrers et trafic direct détaille ces règles. Décision possible :collecter une liste courte ; normaliser la casse et les valeurs ; séparer les dimensions de campagne du chemin de page ; supprimer les paramètres de l’URL affichée après capture si cela ne casse pas le parcours.2. Paramètres fonctionnels sans intérêt analytique Exemples : sort view page theme currencyIls peuvent être nécessaires à l’interface sans mériter une dimension analytics. Les garder dans le rapport « pages » crée souvent des centaines de lignes. Décision possible :ne pas les envoyer dans l’URL de page ; mesurer un événement dédié si une décision produit dépend réellement du tri ou de la vue ; conserver seulement une catégorie réduite, par exemple filter_applied, sans recopier la valeur libre.3. Paramètres de contenu potentiellement utiles Exemples : lang category plan variantLeur utilité dépend du modèle de données. Avant de les autoriser, posez trois questions :cette valeur change-t-elle la décision ? existe-t-il une liste fermée de valeurs ? peut-elle contenir du texte saisi ou un identifiant ?Si les réponses sont favorables, transformez le paramètre en dimension contrôlée. Sinon, retirez-le. 4. Identifiants métier Exemples : order_id invoice customer ticket workspaceIls permettent souvent de relier une visite à un dossier, une commande ou un compte. Même lorsqu’ils ne contiennent pas un nom, ils peuvent devenir des données personnelles par recoupement. Décision recommandée :ne pas les transmettre à l’analytics généraliste ; mesurer une catégorie ou un statut agrégé ; traiter les besoins de diagnostic dans un système opérationnel séparé, avec des accès et une rétention adaptés.5. Données personnelles ou texte libre Exemples : email name phone address search messageLe texte libre est particulièrement risqué. Un champ de recherche interne peut contenir un nom, un problème médical, une adresse ou une phrase confidentielle. Décision recommandée :empêcher la donnée d’entrer dans l’URL ; la supprimer du payload analytics ; vérifier aussi les logs et outils tiers ; ne mesurer, si nécessaire, qu’une catégorie ou la présence d’une recherche.6. Secrets et jetons Exemples : token code jwt signature password_reset inviteCes valeurs ne doivent pas être capturées. Elles peuvent donner accès à une action ou à une ressource. Décision recommandée :revoir le design du parcours ; utiliser des jetons à durée courte et usage limité quand l’URL est techniquement nécessaire ; éviter leur journalisation ; supprimer le paramètre de l’adresse dès que possible ; exclure entièrement les pages concernées de l’analytics si le contrôle n’est pas fiable.Filtrer au bon endroit Niveau 1 : dans l’application La meilleure protection consiste à ne pas construire d’URL excessive. Ne préremplissez pas un formulaire avec une adresse email en clair dans la query string. Ne mettez pas un identifiant client dans un lien marketing. Ne copiez pas une recherche libre dans le titre de page. Ce niveau réduit l’exposition dans tous les systèmes, pas seulement l’analytics. Niveau 2 : avant l’envoi analytics Construisez une représentation nettoyée de la page : const current = new URL(window.location.href); const allowed = new Set([ "utm_source", "utm_medium", "utm_campaign", "utm_content", ]);const clean = new URL(current.origin + current.pathname);for (const [key, value] of current.searchParams) { if (allowed.has(key)) { clean.searchParams.set(key, value.toLowerCase().slice(0, 100)); } }const analyticsPage = clean.pathname; const campaign = Object.fromEntries(clean.searchParams);Cet exemple illustre le principe, pas une implémentation universelle. Il faut aussi :gérer les paramètres répétés ; valider les valeurs ; définir une longueur maximale ; refuser le texte libre ; tester les caractères encodés ; tenir compte du routeur de l’application ; vérifier que les erreurs ne font pas revenir à l’URL brute.Le plus sûr est souvent d’envoyer le chemin et les dimensions de campagne dans des champs séparés. Niveau 3 : dans le collecteur ou le proxy Un filtre côté serveur protège contre une erreur du navigateur ou un ancien script. Il peut rejeter les champs non autorisés, tronquer les valeurs et journaliser uniquement un code d’erreur sans recopier la donnée rejetée. Cette couche est essentielle si plusieurs sites ou équipes utilisent le même endpoint. Niveau 4 : dans l’outil analytics Certains outils fournissent des contrôles de redaction ou d’exclusion. GA4 propose notamment une fonction de redaction des emails et de paramètres de requête définis par l’administrateur. Matomo permet d’exclure des paramètres d’URL des rapports de pages. Ces réglages sont utiles, mais ils ne remplacent pas les contrôles précédents. Une donnée peut avoir traversé un tag manager, un log ou un proxy avant d’être masquée dans le rapport. Niveau 5 : dans les exports Un export historique peut conserver des valeurs qui ont ensuite été filtrées dans l’outil. La procédure doit inclure les entrepôts, sauvegardes, fichiers CSV et connecteurs de BI. Votre data collection summary doit distinguer ce qui est reçu, transformé, stocké et exposé. Normaliser les pages sans perdre l’information utile Un rapport de contenu doit généralement regrouper les variantes qui représentent la même ressource. Exemple : /products?sort=price&page=1 /products?sort=name&page=1 /products?utm_source=newsletter /products?session=abcLa dimension principale peut rester : /productsLes éléments utiles sont envoyés séparément : campaign_source=newsletter sort_used=trueCette structure produit des rapports plus lisibles et évite que des dimensions à forte cardinalité consomment inutilement les capacités de l’outil. Attention aux routes où le paramètre définit réellement le contenu Sur certaines architectures, ?article=42 ou ?category=security identifie la ressource. Supprimer le paramètre sans remplacement fusionnerait des pages différentes. Deux solutions :migrer vers des chemins stables, par exemple /articles/42; dériver un identifiant de contenu non personnel et contrôlé dans une dimension dédiée.Ne conservez pas automatiquement l’identifiant brut. Demandez d’abord s’il peut être relié à une personne ou à un dossier. SEO et analytics : deux nettoyages différents Le filtrage analytics et la gestion SEO des paramètres se recoupent, mais ne sont pas identiques. Pour le SEO, une équipe peut utiliser des URL canoniques, des redirections, des règles d’indexation et une structure de liens cohérente. Pour l’analytics, elle choisit la représentation utilisée dans les rapports. Une balise canonique n’empêche pas un script de collecter l’URL complète. Inversement, supprimer un paramètre du rapport analytics ne change pas la manière dont un moteur explore le site. Documentez les deux décisions séparément. Le protocole de test Test 1 : corpus de paramètres Créez une liste d’URL de test couvrant :UTM autorisés ; paramètre inconnu ; email encodé ; identifiant numérique ; valeur très longue ; paramètre répété ; caractères spéciaux ; token factice ; texte de recherche.Test 2 : observation réseau Dans les outils développeur, vérifiez le payload exact envoyé par le navigateur. Recherchez la valeur sensible factice dans toutes les requêtes, pas seulement celle de l’analytics principal. Test 3 : logs et stockage Vérifiez le collecteur, le CDN, les erreurs applicatives et les données brutes. Le fait qu’une valeur n’apparaisse pas dans le tableau de bord ne prouve pas qu’elle n’a jamais été stockée. Test 4 : rapports et exports Contrôlez les rapports pages, les dimensions personnalisées, l’API et un export représentatif. Test 5 : comportement en erreur Désactivez une règle, envoyez une clé inconnue et simulez un payload invalide. Le système doit échouer en mode sûr, sans enregistrer l’URL complète dans un message d’erreur. Gouverner l’allowlist dans le temps Conservez un petit registre avec :Paramètre Statut Finalité Valeurs autorisées Propriétaire Date de revueutm_source Autorisé Acquisition Taxonomie marketing Growth Trimestrielleutm_medium Autorisé Canal Liste fermée Growth Trimestriellelang Dérivé Contenu fr, en Produit Semestrielleemail Interdit Aucune Aucune Engineering Permanentetoken Interdit Sécurité Aucune Security PermanenteToute nouvelle clé doit passer par la même question : quelle décision justifie sa collecte ? Pour un environnement multi-sites, appliquez une allowlist commune par défaut et n’autorisez une exception que si elle est documentée pour la propriété concernée. Conclusion Le bon filtre n’est pas une longue liste de mots interdits. C’est une politique simple :aucune donnée personnelle ou secret dans l’URL ; une allowlist courte pour les signaux de campagne réellement utiles ; des dimensions contrôlées pour les besoins produit ; un nettoyage avant envoi et une validation côté serveur ; des tests sur le réseau, les logs, le stockage et les exports.Cette approche améliore simultanément la privacy, la sécurité et la lisibilité des rapports. Mesurer moins de variantes produit souvent une meilleure compréhension des pages qui comptent. FAQ Faut-il supprimer toute la query string des rapports analytics ? C’est une bonne valeur par défaut pour la dimension page, mais certaines applications utilisent des paramètres pour définir le contenu. Dans ce cas, dérivez une dimension contrôlée plutôt que de conserver l’URL brute. Les paramètres UTM peuvent-ils contenir une adresse email ? Non. Une adresse email dans une URL peut circuler dans de nombreux systèmes. Utilisez des catégories de campagne, jamais des identifiants de personnes. La redaction de GA4 suffit-elle ? Elle réduit certains risques dans GA4, mais ne couvre pas nécessairement les logs, autres tags, proxies ou exports. Filtrez le plus tôt possible et vérifiez toutes les couches. Un identifiant haché peut-il rester dans l’URL ? Le hachage ne rend pas automatiquement une valeur anonyme. Si l’identifiant permet de distinguer, relier ou retrouver une personne, il peut rester une donnée personnelle et ne devrait pas être transmis sans justification. Comment traiter les termes de recherche interne ? Évitez d’envoyer le texte libre. Mesurez plutôt l’usage de la recherche, une catégorie contrôlée ou des statistiques agrégées, après analyse du besoin. SourcesOWASP, Information exposure through query strings in URL MDN, URLSearchParams Google Analytics, Data redaction Matomo, Exclude URL query parameters from tracked URLs Règlement (UE) 2016/679, article 25 et principes de l’article 5 CEPD, Lignes directrices sur la protection des données dès la conception et par défaut
- 25 May, 2026
UTM, referrers et trafic direct : lire correctement vos sources d’acquisition
Une hausse du trafic direct ne signifie pas forcément que davantage de personnes tapent spontanément votre adresse dans leur navigateur. Une campagne marquée avec des UTM ne dit pas toujours qui a réellement influencé la conversion. Et un domaine référent absent ne prouve pas que la visite n’avait aucune source. Ces trois notions sont souvent regroupées dans le même rapport d’acquisition, alors qu’elles décrivent des signaux différents :les paramètres UTM sont des étiquettes ajoutées volontairement à une URL ; le referrer est une information transmise par le navigateur dans certaines conditions ; le trafic direct est une catégorie utilisée lorsque l’outil ne dispose pas d’une source exploitable selon ses règles.Une lecture fiable commence par cette distinction. Elle se poursuit avec une nomenclature stable et une dose de prudence : l’attribution web est une reconstruction à partir de signaux incomplets, pas un relevé exhaustif du parcours d’une personne. Les UTM : une déclaration ajoutée au lien Un lien de campagne peut ressembler à ceci : https://www.example.com/guide/?utm_source=newsletter&utm_medium=email&utm_campaign=launch_juneLes paramètres les plus courants sont :utm_source : l’origine déclarée, par exemple linkedin, newsletter ou partner_name ; utm_medium : le type de canal, par exemple paid_social, email ou referral; utm_campaign : le nom de l’initiative ; utm_content : une variante de création, de placement ou de bouton ; utm_term : historiquement associé aux mots-clés, mais utilisable avec prudence selon le besoin.Google Analytics documente aussi d’autres paramètres manuels, mais une PME gagne rarement à multiplier les dimensions. Trois champs obligatoires et un champ de variante suffisent souvent. L’UTM n’est pas détecté automatiquement par le navigateur. Il est écrit par la personne ou le système qui produit le lien. Il faut donc le lire comme une déclaration de campagne, avec les forces et les faiblesses de toute donnée déclarative. Ce que les UTM font bien Ils sont utiles lorsque le referrer est absent, trop générique ou insuffisant :une newsletter ; un QR code ; un document PDF ; une signature d’email ; une publication sociale organique ou payante ; une campagne partenaire ; un lien dans une application.Ils permettent aussi de distinguer deux liens qui pointent vers la même page, par exemple le bouton principal et le lien de pied de newsletter. Ce qu’ils ne prouvent pas Un UTM ne prouve pas que la campagne a créé toute la demande. Il indique que la visite observée est arrivée avec cette étiquette. Le lien peut avoir été copié dans un canal privé, partagé par un collègue, ouvert plusieurs jours après sa réception ou modifié par un intermédiaire. Un utilisateur peut également avoir découvert la marque ailleurs avant de cliquer. C’est pourquoi le reporting doit parler de visites et conversions attribuées selon la règle de mesure, pas d’une causalité certaine. Le referrer : un signal transmis sous conditions Lorsqu’un navigateur suit un lien, il peut envoyer un en-tête HTTP Referer au site de destination. Malgré la faute historique dans le nom de l’en-tête, il s’agit du mécanisme qui permet souvent d’identifier le site précédent. La quantité d’information transmise dépend de la politique de referrer, du protocole, du navigateur, du contexte d’ouverture et des choix du site source. La politique par défaut moderne strict-origin-when-cross-origin transmet généralement :l’URL complète pour une navigation vers la même origine ; uniquement l’origine pour une navigation HTTPS entre origines ; aucune information lors d’une navigation d’un contexte HTTPS vers HTTP.Un site peut appliquer une politique plus stricte, une application peut ouvrir le lien dans une webview, et certaines redirections ou protections peuvent supprimer le signal. Le referrer est donc utile, mais jamais garanti. Referrer et UTM peuvent coexister Une visite peut fournir les deux :referrer : linkedin.com; utm_source : linkedin; utm_medium : paid_social; utm_campaign : webinar_june.L’outil analytics applique alors ses propres règles de priorité. Dans GA4, les paramètres manuels alimentent des dimensions spécifiques de source, support et campagne, tandis que les regroupements de canaux reposent sur des règles documentées et susceptibles d’évoluer. Le point opérationnel est simple : ne comparez pas deux rapports sans vérifier leur périmètre et leur scope. « Première source utilisateur », « source de session » et « source d’un événement clé » ne répondent pas à la même question. Le trafic direct est un manque de signal exploitable Dans le langage courant, « direct » évoque une personne qui saisit l’adresse ou utilise un favori. Ces comportements existent. Mais la catégorie peut aussi recevoir des visites dont la source a été perdue. Exemples fréquents :lien non marqué dans une application mobile ou une messagerie ; document local, PDF ou présentation ; redirection qui ne conserve pas les paramètres ; politique de referrer restrictive ; passage d’un environnement sécurisé vers un environnement moins sécurisé ; campagne email sans UTM ; lien copié puis partagé dans un canal privé ; erreur de déploiement ou de configuration analytics ; URL nettoyée avant que le script ne lise les paramètres.Il est donc plus juste d’interpréter « direct » comme :L’outil n’a pas attribué cette visite à une source plus précise avec les données disponibles.Une forte part de direct n’est pas automatiquement un problème. Elle devient un signal d’audit lorsqu’elle change brutalement, se concentre sur une page de campagne ou diffère fortement entre des outils censés observer le même périmètre. La méthode pour construire une nomenclature UTM stable Le principal risque n’est pas l’absence d’UTM. C’est une nomenclature incohérente qui fragmente les rapports. 1. Définir un vocabulaire fermé pour utm_medium Le support doit représenter une famille de canal. Limitez-le à une liste contrôlée, par exemple : email paid_search paid_social organic_social partner affiliate display offlineNe mélangez pas paid-social, paidsocial, cpc_social et social_paid. Les outils peuvent traiter les majuscules et variantes de manière différente, et vos tableaux les afficheront souvent comme des valeurs distinctes. 2. Nommer la source comme une plateforme ou un partenaire Exemples : linkedin google customer_newsletter partner_acme event_parisÉvitez de placer le nom de la campagne dans la source. Sinon, vous perdez la capacité à comparer un même canal dans le temps. 3. Donner à la campagne une structure lisible Une convention simple : objectif_offre_periodePar exemple : lead_demo_2026q2 launch_product_2026june retention_webinar_2026q3Choisissez une langue, une casse et un séparateur. Pour réduire les erreurs, les minuscules et les underscores sont faciles à contrôler. 4. Réserver utm_content aux variantes utiles Ce champ peut identifier :hero_button; footer_link; video_a; creative_02; partner_banner.Ne l’utilisez pas pour injecter des phrases ou des informations sur le destinataire. 5. Centraliser la génération Un tableur avec validation de données, un petit générateur interne ou un formulaire contrôlé évite la majorité des variantes. Chaque ligne doit contenir :URL de destination ; source ; medium ; campagne ; contenu éventuel ; propriétaire ; date de création ; statut actif ou archivé.Ne mettez jamais de donnée personnelle dans un UTM Les paramètres de requête circulent largement. Ils peuvent apparaître dans :l’historique du navigateur ; les logs du serveur et du CDN ; les outils analytics ; les outils de support ; les captures d’écran ; les liens copiés ; certains referrers ; les exports et rapports.N’utilisez donc pas d’adresse email, de nom, de numéro client, de téléphone, de jeton ou d’identifiant permettant de retrouver une personne. Cette règle vaut aussi pour des champs internes apparemment pratiques : utm_content=client_12345 utm_campaign=renewal_alice@example.comCes valeurs transforment un outil de campagne en vecteur de diffusion de données personnelles. Le bon niveau est une catégorie ou une variante de création, pas un individu. Votre data collection summary doit préciser quels paramètres sont autorisés, stockés ou supprimés. Cinq erreurs qui faussent les rapports Utiliser des UTM sur les liens internes Ajouter des UTM entre deux pages de son propre site peut créer une nouvelle attribution ou écraser le contexte précédent selon l’outil. Utilisez plutôt un événement ou une dimension interne lorsque vous devez comparer des emplacements de navigation. Marquer tous les liens externes sans hiérarchie Un UTM n’est pas nécessaire quand le referrer fournit déjà un signal suffisant et que vous n’avez aucune variante à distinguer. Le marquage doit servir une question, pas produire des colonnes supplémentaires. Changer de convention en cours de campagne linkedin, LinkedIn et linkedin.com deviennent facilement trois lignes. Corrigez la nomenclature à la source et conservez un journal des changements. Nettoyer l’URL trop tôt Il est légitime de retirer les paramètres visibles après leur lecture afin d’obtenir une URL propre. Mais si le code les supprime avant que le système de mesure ne les capture, la campagne tombe dans une autre catégorie. Testez l’ordre d’exécution. Comparer des outils sans aligner les règles Deux plateformes peuvent avoir des définitions de session, fenêtres d’attribution, listes de sources et règles de priorité différentes. Un écart ne signifie pas automatiquement qu’une des deux est défaillante. Diagnostiquer une hausse du trafic direct Procédez dans cet ordre. 1. Localiser la hausse Regardez les pages d’entrée, appareils, pays, heures et domaines concernés. Une hausse sur la page d’accueil n’a pas la même signification qu’une hausse sur une landing page accessible uniquement depuis une campagne. 2. Vérifier les déploiements Cherchez un changement de redirection, de routeur, de CMP, de tag manager, de script analytics ou de nettoyage d’URL. 3. Auditer les campagnes actives Ouvrez les liens réels des emails, publicités, profils sociaux, QR codes et documents. Ne vous contentez pas du tableur de préparation. 4. Tester le parcours complet Suivez le lien dans le contexte réel : application mobile, messagerie, navigateur intégré, PDF ou QR code. Observez la requête de collecte et le rapport final. 5. Accepter une part d’incertitude Le dark social et les contextes sans referrer ne peuvent pas être reconstruits avec certitude sans ajouter des mécanismes de suivi plus intrusifs. Une analytics responsable accepte parfois une catégorie résiduelle plutôt que de fabriquer une précision artificielle. Le tableau de bord minimal d’acquisition Pour une PME B2B, quatre vues suffisent souvent :sessions ou visites par source et medium ; pages d’entrée par source ; conversions utiles par source ; évolution du direct et de l’unassigned.Ajoutez le coût et le revenu seulement si leur définition est fiable et leur rapprochement documenté. Un ROAS précis en apparence mais construit sur des identifiants incomplets peut être moins utile qu’un coût par demande qualifiée bien défini. Analysez les tendances sur plusieurs semaines. Les volumes faibles rendent les variations journalières trompeuses. Conclusion Les UTM, le referrer et le trafic direct ne sont pas trois versions d’une même donnée. Ce sont trois mécanismes qui se complètent et se contredisent parfois. Une bonne pratique d’acquisition repose sur :une nomenclature UTM courte et contrôlée ; aucun identifiant personnel dans les URL ; une compréhension des limites du referrer ; une définition prudente du direct ; des règles d’attribution documentées ; des contrôles réguliers sur les liens réellement diffusés.L’objectif n’est pas de faire disparaître tout trafic direct. Il est de rendre les campagnes importantes lisibles sans prétendre reconstituer chaque parcours. FAQ Quelle différence entre utm_source et le referrer ? utm_source est une valeur ajoutée volontairement au lien. Le referrer est un signal que le navigateur peut transmettre à partir de la page précédente. Ils peuvent être présents ensemble ou séparément. Le trafic direct correspond-il aux personnes qui connaissent déjà la marque ? Parfois, mais pas uniquement. Il inclut aussi des visites pour lesquelles aucune source exploitable n’a été attribuée, par exemple depuis certaines applications, documents ou campagnes non marquées. Quels UTM sont vraiment nécessaires ? Pour la plupart des équipes, utm_source, utm_medium et utm_campaign forment le socle. utm_content est utile pour distinguer des variantes. Ajoutez d’autres paramètres seulement s’ils répondent à une question précise. Faut-il mettre des UTM sur les liens internes ? En général, non. Ils peuvent perturber l’attribution. Utilisez des événements ou dimensions dédiées pour mesurer la navigation interne. Peut-on supprimer les UTM de l’URL après l’arrivée ? Oui, après les avoir capturés correctement. Testez l’ordre d’exécution et conservez les informations uniquement selon votre politique de collecte et de conservation. SourcesGoogle Analytics, Traffic-source dimensions, manual tagging and auto-tagging Google Analytics, Default channel group definitions MDN, Referer header MDN, Referrer-Policy header OWASP, Information exposure through query strings in URL CNIL, Les six grands principes du RGPD
- 18 May, 2026
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
- 02 Feb, 2026
Trafic IA : comment mesurer les visites que ChatGPT, Perplexity et Claude envoient sur votre site
Quelque chose a changé dans la manière dont les internautes découvrent votre site. Et il y a de fortes chances que vous ne le voyiez pas. Depuis fin 2024, les plateformes d'intelligence artificielle conversationnelle ne se contentent plus de répondre aux questions de leurs utilisateurs. Elles citent des sources, insèrent des liens, et envoient des visiteurs réels vers des sites web. ChatGPT, Perplexity, Claude, Gemini, Copilot : ces outils sont en train de devenir un canal de découverte à part entière, comparable aux moteurs de recherche classiques par la qualité du trafic qu'ils génèrent. Le problème ? La plupart des outils analytics ne distinguent pas ce trafic. Il se noie dans la catégorie "referral", se mélange au "direct", ou disparaît purement et simplement des rapports. Résultat : vous avez peut-être déjà des visiteurs qui arrivent via une recommandation de ChatGPT, et vous ne le savez pas. Cet article vous donne la méthode complète pour identifier ce trafic, comprendre sa valeur, et adapter votre stratégie de contenu. Un nouveau canal de découverte en pleine explosion Les chiffres sont encore modestes en volume absolu, mais la dynamique est spectaculaire. Selon une étude de SE Ranking portant sur près de 64 000 sites dans 250 pays (janvier-avril 2025), ChatGPT concentre à lui seul 78 % du trafic IA référent mondial. Perplexity représente environ 15 %, Gemini 6,4 %. Claude et DeepSeek se partagent le reste, avec des parts inférieures à 1 % mais des dynamiques de croissance très intéressantes. (Source : SE Ranking, "AI Traffic in 2025") Une analyse complémentaire de Conductor, relayée par Search Engine Land, confirme cette hiérarchie sur un échantillon de 13 770 domaines et 3,3 milliards de sessions : le trafic IA représente en moyenne 1 % du trafic total d'un site, et ChatGPT en génère 87 % à lui seul. (Source : Search Engine Land, nov. 2025) Un pour cent, c'est peu en apparence. Mais deux éléments changent la perspective. La croissance est forte, mais encore inégale. Entre janvier et avril 2025, la part de ChatGPT dans le trafic internet global a doublé dans l'étude SE Ranking, passant de 0,08 % à 0,16 %. Certaines analyses sectorielles observent aussi une forte progression annuelle du trafic IA référent. Ces chiffres restent à relire par secteur : ils ne transforment pas automatiquement l'IA en premier canal d'acquisition. La qualité du trafic peut être intéressante. Les visiteurs provenant des plateformes IA passent en moyenne 9 à 10 minutes par session sur les sites visités dans l'étude SE Ranking, contre 3 à 4 minutes pour le trafic organique classique. Les sessions référées par Claude y atteignent même une durée moyenne très élevée dans l'UE. Ce sont des signaux à examiner, pas une garantie de conversion : chaque équipe doit vérifier les pages d'entrée, les événements utiles et les conversions sur ses propres données. L'explication est logique : un utilisateur qui clique sur un lien dans une réponse IA a déjà formulé une question précise, reçu un contexte, et choisi de visiter votre site parmi les sources citées. Son intention est pré-qualifiée. C'est un visiteur qui sait pourquoi il vient. Pourquoi vos analytics ne voient pas ce trafic Si le trafic IA est si intéressant, pourquoi n'apparaît-il pas clairement dans vos rapports ? Trois raisons techniques expliquent cet angle mort. Le problème du referrer manquant Lorsqu'un utilisateur clique un lien dans Perplexity depuis un navigateur web, le header HTTP Referer transmet généralement perplexity.ai comme source. L'outil analytics peut alors classer cette visite en "referral" depuis Perplexity. Mais ce mécanisme ne fonctionne pas toujours. Selon le contexte, une partie des sessions provenant d'outils IA peut ne pas transmettre de referrer exploitable. Les raisons sont multiples : les applications mobiles (ChatGPT sur iOS, Copilot dans Windows) peuvent ouvrir les liens dans des webviews internes, certains agents IA préchargent ou prévisualisent des pages sans déclencher le script analytics, et les navigateurs IA comme Perplexity Comet ou ChatGPT Atlas ne transmettent pas tous les signaux de la même manière. (Source : MarTech, nov. 2025) Résultat : une part importante du trafic IA tombe dans la catégorie "direct" ou "unassigned" de vos analytics, invisible et non attribué. La classification par défaut de GA4 Google Analytics 4 peut classer les visites issues des assistants IA comme du trafic "referral", au même titre qu'un lien depuis Facebook, un forum ou un annuaire. Dans les configurations observées lors de la rédaction initiale, les équipes devaient encore créer leur propre regroupement pour isoler ce trafic. Vérifiez toujours l'état courant de votre interface GA4 avant de documenter la procédure. Concrètement, si vous ouvrez votre rapport d'acquisition dans GA4 sans configuration spécifique, le trafic de ChatGPT est noyé parmi des dizaines d'autres sources de referral. Pour un site qui reçoit des centaines de referrers différents, repérer chatgpt.com ou perplexity.ai demande de savoir ce qu'on cherche. La confusion bots vs humains Les plateformes IA ont deux manières d'interagir avec votre site. La première est le trafic référent : un humain clique sur un lien dans une réponse IA et arrive sur votre page. C'est du vrai trafic, avec un vrai visiteur. La seconde est le crawl : les robots des plateformes IA (GPTBot pour OpenAI, PerplexityBot, ClaudeBot, etc.) visitent votre site pour indexer son contenu et nourrir leurs modèles. Ce crawl n'est pas du trafic utile, c'est de l'aspiration de données. GA4 filtre automatiquement les bots connus, mais la liste n'est pas exhaustive. Certains bots IA récents passent entre les mailles du filet, ou au contraire, certains visiteurs humains légitimes provenant d'outils IA sont filtrés par erreur. Selon Cloudflare, le ratio de crawl par rapport aux clics référents peut atteindre 700:1 pour Perplexity, ce qui donne une idée de l'ampleur du phénomène d'aspiration. (Source : Digiday, déc. 2025) Méthode : identifier le trafic IA dans vos outils Deux approches sont possibles selon l'outil que vous utilisez. Dans GA4 : créer un canal "Trafic IA" dédié La méthode recommandée consiste à créer un channel group personnalisé qui regroupe toutes les sources IA connues. Voici la procédure :Dans GA4, allez dans Admin > Paramètres des données > Groupes de canaux. Cliquez sur le groupe de canaux par défaut, puis "Copier" pour en créer un nouveau. Ajoutez un canal nommé "Trafic IA" (ou "AI Traffic"). Définissez la règle : Type de correspondance = "correspond à l'expression régulière", puis collez cette regex :(chatgpt\.com|chat\.openai\.com|perplexity\.ai|claude\.ai|gemini\.google\.com|copilot\.microsoft\.com|deepseek\.com|meta\.ai)Placez ce canal au-dessus du canal "Referral" par défaut dans l'ordre de priorité. C'est crucial : GA4 évalue les règles de haut en bas, et si "Trafic IA" est en dessous de "Referral", les visites seront classées en referral avant d'atteindre votre règle.Cette configuration ne s'applique qu'aux nouvelles données (pas de rétroactivité). Comptez quelques jours avant de voir les premiers résultats. Pour une analyse ponctuelle sur des données existantes, vous pouvez créer un rapport Exploration avec un filtre sur la dimension "Source de la session" utilisant la même regex. (Source : MarTech, nov. 2025) Dans un analytics frugal (Plausible, Fathom, etc.) C'est ici que la simplicité d'un outil bien conçu peut faire la différence. Dans Plausible, par exemple, le rapport "Sources" affiche directement chaque referrer identifié. Si chatgpt.com ou perplexity.ai apparaît comme source, vous le voyez dans la liste des sources sans créer un canal personnalisé. Il suffit ensuite de filtrer le dashboard par cette provenance et d'analyser les pages d'entrée, le temps passé et les événements déclenchés. Plausible a d'ailleurs documenté sa propre expérience : en 2024, le blog de Plausible a constaté une hausse de 2 200 % de son trafic IA référent en quelques mois, identifiable directement depuis leur dashboard standard. (Source : Plausible, déc. 2024) C'est un cas d'école où la philosophie de l'analytics frugale aide : quand l'outil est conçu pour montrer les données essentielles sans couches de configuration, les signaux émergents sont plus faciles à inspecter. Un outil comme GA4 reste puissant, mais il demande souvent une configuration dédiée pour isoler une nouvelle famille de sources. Pour une vue d'ensemble des familles d'outils analytics, consultez notre comparatif Google Analytics, Matomo et analytics frugales. Trafic IA vs crawl IA : deux phénomènes distincts Une confusion fréquente consiste à mélanger le trafic référent (des humains qui cliquent) et le crawl (des robots qui aspirent). Il est important de les distinguer, car ils posent des questions différentes. Le trafic référent IA est une opportunité. C'est un visiteur qualifié, pré-informé, qui arrive avec une intention. Le mesurer permet d'optimiser les pages d'entrée, d'adapter le contenu, et de comprendre comment les IA perçoivent votre site. Le crawl IA est une question de gouvernance. Les robots comme GPTBot, PerplexityBot ou ClaudeBot visitent votre site pour entraîner leurs modèles ou répondre en temps réel aux requêtes de leurs utilisateurs. Certains le font de manière intensive : Cloudflare a observé que le volume de crawl de GoogleBot (qui alimente aussi Gemini) dépasse de loin celui de tous les autres bots IA combinés. Vous pouvez contrôler le crawl via votre fichier robots.txt : User-agent: GPTBot Disallow: /User-agent: PerplexityBot Disallow: /User-agent: ClaudeBot Disallow: /Mais attention au paradoxe : bloquer le crawl peut réduire votre trafic référent. Si une IA ne peut pas indexer votre contenu, elle ne pourra pas le recommander à ses utilisateurs. C'est un arbitrage à faire en connaissance de cause. Une approche émergente consiste à utiliser un fichier llms.txt (au format Markdown, placé à la racine du site) pour guider les IA vers le contenu que vous souhaitez rendre accessible, sans bloquer l'ensemble du crawl. Anthropic (le créateur de Claude) utilise d'ailleurs ce mécanisme sur son propre site. Comment être cité par les IA Comprendre le trafic IA, c'est aussi comprendre ce qui le déclenche. Les plateformes d'IA ne citent pas les sites au hasard. Plusieurs facteurs favorisent les citations. La structure du contenu compte. Les analyses citées par Superprompt suggèrent que les pages organisées avec une hiérarchie claire (H2, H3, listes) et qui répondent directement à des questions précises sont plus facilement reprises. Les FAQ structurées sont particulièrement utiles : elles correspondent au format question-réponse des interactions IA. La fraîcheur peut aider. Les contenus récemment mis à jour sont souvent plus faciles à exploiter dans des réponses qui recherchent une information actuelle. L'effet dépend toutefois du sujet, de l'autorité du domaine et du mode de collecte de la plateforme IA. Les données originales attirent les citations. Les tableaux, statistiques propres et benchmarks exclusifs peuvent être plus faciles à citer qu'un contenu généraliste. C'est un argument supplémentaire pour l'approche data-driven et les KPIs précis plutôt que les métriques de vanité. Le SEO classique reste la fondation. Plusieurs études de marché rapprochent visibilité IA et référencement traditionnel : structure, autorité, fraîcheur et clarté éditoriale restent centrales. Le SEO ne dépend pas de Google Analytics, mais il reste le socle sur lequel se construit une partie de la visibilité IA. Ce que ça change pour le choix de votre outil analytics Le trafic IA met en lumière une limite opérationnelle des outils analytics complexes : les signaux émergents demandent souvent une configuration préalable pour être lisibles. Avec GA4, il faut créer un channel group, écrire une regex, la mettre à jour régulièrement (de nouveaux outils IA apparaissent chaque mois), et accepter que les données ne seront pas rétroactives. C'est faisable, mais ça demande une compétence technique que la plupart des dirigeants de PME ou des freelances n'ont pas. Avec un analytics frugal bien conçu, les referrers IA peuvent apparaître directement dans le rapport des sources, au même titre que Google, LinkedIn ou Twitter, dès lors que le referrer est transmis. Cela ne supprime pas les limites liées aux webviews, au direct ou au prefetch, mais rend les signaux visibles plus faciles à lire. C'est le principe même de la sobriété analytique : collecter moins de données, mais rendre chaque donnée immédiatement lisible. Le trafic IA n'est pas un phénomène à ignorer. C'est l'un des signaux d'un changement dans la manière dont certains internautes découvrent du contenu. Les sites qui le mesurent aujourd'hui auront surtout une meilleure lecture de leurs sources émergentes, sans surestimer un volume qui reste souvent minoritaire. La question n'est plus de savoir si les IA envoient du trafic vers votre site. C'est de savoir si votre outil de mesure vous le montre.Questions fréquentes Quelle part de mon trafic provient des IA ? Les études publiées fin 2025 situent encore le trafic IA identifiable à une part faible du trafic total, avec de fortes variations par secteur. Ces chiffres ne reflètent que le trafic identifiable : lorsqu'une session IA n'a pas de referrer exploitable, elle peut tomber dans "direct" et rester difficile à attribuer. Comment voir le trafic ChatGPT dans Google Analytics 4 ? Si votre interface GA4 ne propose pas encore de canal IA adapté à votre besoin, créez un channel group personnalisé : dans Admin > Paramètres des données > Groupes de canaux, ajoutez un canal "Trafic IA" avec une règle regex couvrant les domaines IA (chatgpt.com, perplexity.ai, claude.ai, gemini.google.com, copilot.microsoft.com). Placez-le au-dessus du canal "Referral" dans la hiérarchie. Les données ne seront collectées qu'à partir de la date de création du canal. Faut-il bloquer les bots IA avec robots.txt ? C'est un arbitrage. Bloquer les bots IA (GPTBot, PerplexityBot, ClaudeBot) via robots.txt empêche l'indexation de votre contenu par ces plateformes, ce qui peut réduire les citations et donc le trafic référent. À l'inverse, ne pas bloquer signifie que votre contenu alimente l'entraînement de modèles IA, ce qui soulève des questions de propriété intellectuelle et de consentement. Une approche intermédiaire consiste à utiliser un fichier llms.txt pour guider les IA vers le contenu que vous souhaitez rendre accessible. Les analytics sans cookies détectent-elles le trafic IA ? Oui, lorsqu'un referrer exploitable est transmis. Les outils cookieless comme Plausible, Fathom ou Simple Analytics peuvent afficher ces referrers directement dans leur rapport de sources, sans channel group dédié. C'est souvent plus simple à inspecter, mais cela ne résout pas les limites de referrer, de direct ou de prefetch. Comment optimiser son contenu pour être cité par ChatGPT ou Perplexity ? Cinq leviers sont utiles à tester : structurer le contenu avec des titres clairs (H2/H3) et des FAQ ; maintenir le contenu à jour quand le sujet l'exige ; produire des données originales (tableaux, statistiques, benchmarks) ; soigner le SEO classique ; et envisager un fichier llms.txt pour faciliter l'accès des IA à votre contenu structuré. Les effets varient selon les plateformes et les sujets : documentez vos hypothèses avant d'en faire une règle éditoriale.Sources et chiffres vérifiés pour la publication initiale de février 2026. Les parts de trafic IA et les classifications GA4 évoluent rapidement : vérifiez l'interface et la documentation courantes avant d'en faire une règle interne. Sources Sources vérifiées le 10 mai 2026.SE Ranking, "AI Traffic in 2025: Comparing ChatGPT, Perplexity & Other Top Platforms" Search Engine Land, "AI sends 1% of website traffic — and most of it is from ChatGPT" MarTech, "How GA4 records traffic from Perplexity Comet and ChatGPT Atlas" Plausible Analytics, "Breaking down our 2.2K% surge in AI traffic"