Elles le sont quand elles sont assez fiables, fraîches et complètes pour la décision à prendre. Pas parfaites. Utilisables. Je vois trop d’équipes piloter budget, SEO, paid ou UX avec des chiffres propres en apparence mais fragiles dès qu’on creuse.
Pourquoi vos chiffres peuvent tromper ?
Vos chiffres peuvent tromper quand ils donnent une impression de précision alors qu’ils reposent sur un tracking incomplet, des définitions floues ou une collecte modifiée sans être documentée.
Je le vois souvent quand un client me dit : “La conversion baisse, on coupe le budget média ?” Ma première réponse, c’est rarement oui ou non. C’est plutôt : “On est sûrs de ce que cette courbe mesure ?” Parce qu’une courbe dans un dashboard ne vaut rien si on ne sait pas ce qu’elle mesure vraiment.
L’analytics sert à décider. Où corriger. Où investir. Quoi prioriser. Si vos chiffres vous poussent à couper une campagne rentable, à renforcer un canal mal attribué, ou à ignorer un bug de formulaire, le problème n’est pas juste statistique. C’est opérationnel. Vous prenez une mauvaise décision avec une donnée qui avait l’air propre.
Et non, la donnée analytics n’a pas besoin d’être parfaite. Elle doit être adaptée à la décision. Pour un petit test UX sur un bouton, je peux accepter une donnée imparfaite mais cohérente. Pour arbitrer 50 000 € de budget média, je veux un niveau de contrôle beaucoup plus élevé.
Une donnée prête à décider, pour moi, c’est une donnée dont on connaît les limites, les règles de collecte et le niveau de confiance. Pas une donnée magique. Juste une donnée assez fiable pour soutenir une décision sans raconter n’importe quoi.
Les erreurs viennent rarement d’un seul endroit. Elles viennent de toute la chaîne de mesure :
- Le consentement peut bloquer une partie des visiteurs.
- Les tags peuvent se déclencher deux fois, ou pas du tout.
- Les événements peuvent changer de nom sans documentation.
- Les sources de trafic peuvent être mal classées.
- Les modèles d’attribution peuvent donner trop de crédit au dernier clic.
- Les visites internes, les bots ou les tests peuvent polluer les chiffres.
- Les définitions métier peuvent varier entre marketing, sales et direction.
Matomo, GA4, un dashboard BI ou un CRM ne protègent pas automatiquement contre ça. L’outil affiche ce qu’on lui donne. Si la collecte est floue, le dashboard sera flou aussi, même avec de beaux graphiques.
Avant de couper un budget, je préfère toujours vérifier la mesure. Parce qu’une baisse de conversion peut venir du marché, d’une campagne, d’un bug, d’un changement de consentement, ou juste d’un événement mal tracké. Et là, la décision n’a plus du tout la même tête.
Pourquoi on fait confiance trop vite ?
On fait confiance trop vite parce qu’un dashboard bien présenté donne une sensation de vérité, même quand les données ont déjà été contestées après coup.
C’est une contradiction que je vois souvent dans les équipes. Tout le monde dit faire confiance aux données analytics. Puis, quand on gratte un peu, on découvre qu’une décision importante a déjà été prise sur des chiffres jugés ensuite incomplets, ambigus ou franchement discutables. Le rapport Future of Web Analytics de Matomo pointe justement cette tension entre la confiance déclarée dans les données et le doute qui revient au moment d’agir. Et honnêtement, ça colle bien à ce que je vois sur le terrain.
Le piège est assez simple. Les chiffres sont là. Les dashboards tournent. Les réunions avancent. Les courbes montent ou descendent. Donc on suppose que la donnée est valide. Pas forcément parfaite, mais assez fiable pour décider. Sauf que l’analytics, ce n’est pas une photo neutre de la réalité. C’est une construction technique, avec des règles, des tags, des consentements, des événements, des définitions métier.
Un petit changement peut casser une partie de la lecture, sans que ça saute aux yeux tout de suite.
- Une CMP, c’est-à-dire un outil de gestion du consentement, peut modifier le volume de données collectées.
- Une mise à jour de tag peut arrêter de remonter certains événements.
- Une modification de formulaire peut changer ce qu’on appelle une conversion.
- Une refonte de landing page peut déplacer les points de tracking.
- Une évolution du plan de marquage peut rendre deux périodes difficiles à comparer.
J’ai vu des équipes très sérieuses défendre deux conclusions opposées avec le même dashboard. Pas parce qu’elles étaient de mauvaise foi. Juste parce que personne n’avait aligné la définition d’une conversion ou d’une session qualifiée. Et dans ce cas-là, le problème n’est pas le dashboard. Le problème, c’est la confiance qu’on lui donne sans vérifier ce qu’il raconte vraiment.
Le vrai sujet n’est pas de douter de tout. Sinon on ne décide plus rien. Le sujet, c’est de savoir quelles vérifications faire avant d’agir, pour éviter de confondre une donnée disponible avec une donnée prête à décider.
Quand une donnée est-elle prête ?
Une donnée est prête quand elle est suffisamment exacte, récente, complète et comprise pour soutenir une décision précise.
Je dis bien une décision précise, parce que la qualité d’une donnée n’est jamais absolue. Une donnée peut être largement suffisante pour voir qu’un trafic SEO baisse depuis trois semaines. Elle peut être trop fragile pour décider de couper un canal d’acquisition ou de réallouer 30 % d’un budget paid. C’est souvent là que la vraie maturité analytics commence.
L’exactitude, c’est simple à dire, moins simple à garantir. Les événements mesurés doivent correspondre aux actions réelles. Un clic mesuré comme une conversion, un formulaire envoyé deux fois, une page vue déclenchée à chaque refresh automatique… Et vous prenez une décision sur du bruit.
La fraîcheur, c’est le délai entre ce qui se passe et ce que vous regardez. Si votre dashboard a trois jours de retard, il peut rester utile pour analyser une tendance. Mais pour piloter une campagne en cours, vous êtes peut-être déjà en train de corriger un problème qui n’existe plus.
La complétude, c’est vérifier que les segments utiles sont bien couverts. Mobile, desktop, pays, source, nouveaux clients, clients existants. J’ai déjà vu un client conclure qu’une landing page ne convertissait pas, alors que le tracking du formulaire mobile était cassé. Le problème n’était pas la page. C’était la mesure.
La compréhension, c’est le point le plus sous-estimé. Tout le monde doit savoir ce qui est inclus, exclu et calculé. Un “lead” peut vouloir dire formulaire commencé, formulaire envoyé, lead qualifié ou rendez-vous pris. Si chacun met sa définition derrière le même mot, le dashboard devient un générateur de réunions inutiles.
Il faut aussi intégrer la réalité du consentement. Dans un contexte RGPD, avec les recommandations de la CNIL sur les traceurs, tous les visiteurs ne sont pas toujours mesurés. Les refus de cookies, les bloqueurs, les choix de configuration CMP, c’est-à-dire la plateforme qui gère le consentement, peuvent réduire ou modifier la mesure. Il faut donc lire les performances avec ça en tête, pas comme si 100 % des visiteurs étaient visibles.
| Critère | Question à poser | Risque si ignoré |
| Exactitude | Est-ce que l’événement mesuré correspond bien à l’action réelle ? | Décider sur des chiffres faux ou doublonnés. |
| Fraîcheur | Est-ce que la donnée est assez récente pour cette décision ? | Piloter avec une situation déjà dépassée. |
| Complétude | Est-ce que les segments importants sont bien couverts ? | Rater un trou critique dans la collecte. |
| Définitions | Est-ce que tout le monde parle du même indicateur ? | Comparer des chiffres qui ne veulent pas dire la même chose. |
| Consentement | Quelle part de l’audience échappe à la mesure ? | Surestimer ou sous-estimer certaines performances. |
| Périmètre | Qu’est-ce qui est inclus, exclu ou filtré ? | Prendre une décision hors contexte. |
Que vérifier avant d’agir ?
Avant d’agir, je vérifie ce que la donnée couvre, ce qu’elle oublie, comment elle est collectée et si les définitions métier sont partagées.
Je fais ça avant de toucher un budget, une page, une campagne ou un tunnel. Sinon on décide sur une photo floue. Et souvent, le problème n’est pas dans la performance, il est dans la mesure.
Je regarde d’abord le périmètre de mesure. Quelles pages sont incluses ? Quelle app ? Quel pays ? Quelle langue ? Quels domaines ou sous-domaines ? Et surtout, qu’est-ce qui est exclu volontairement ou oublié sans le savoir.
Ensuite je vérifie la collecte. Les tags sont-ils actifs ? Les événements critiques remontent-ils toujours ? Un événement critique, c’est par exemple un achat, un lead, un clic sur “demander une démo”, une création de compte. Je regarde aussi le consentement, parce qu’un changement de bannière cookies peut faire baisser les conversions mesurées sans que les ventes réelles bougent.
Les UTM méritent toujours un contrôle. Les UTM, ce sont les paramètres ajoutés aux liens pour identifier la source, le canal ou la campagne. Avant d’augmenter le budget d’un canal, je vérifie que les UTM n’ont pas changé, que le canal n’absorbe pas du trafic mal classé, que les conversions remontent encore correctement et que la période comparée est comparable. Même saison, mêmes promos, mêmes règles d’attribution.
J’ai déjà vu un client couper une campagne “moins rentable” alors que le problème venait d’un renommage UTM fait par une agence. Le canal avait l’air en chute, mais une partie du trafic était juste partie dans “Direct” ou “Other”. C’est bête, mais ça coûte cher.
Avant d’accuser une page d’avoir fait chuter la conversion, je vérifie le formulaire, le tag, le consentement et le tunnel. Un champ peut bloquer sur mobile. Un navigateur peut refuser un script. Un pays peut ne plus être couvert. Une étape peut avoir changé sans que l’équipe data soit au courant.
Je me méfie aussi des moyennes. Un taux de conversion global peut cacher une rupture mobile, un navigateur mal suivi, une perte liée au consentement ou un formulaire qui bloque seulement certains utilisateurs. La moyenne rassure, les segments racontent la vérité.
- Vérifier le périmètre mesuré, les pages, les apps, les pays et les exclusions connues.
- Comparer les périodes avec les mêmes règles d’attribution, les mêmes campagnes et le même contexte business.
- Documenter les changements récents sur les tags, les UTM, le consentement, le tunnel et les formulaires.
- Isoler les segments sensibles comme mobile, navigateur, pays, source, campagne et nouveaux utilisateurs.
- Valider les définitions des métriques avec les équipes marketing, data et direction.
- Partager les limites connues avant de prendre une décision ou de présenter un résultat.
Comment en faire un vrai réflexe ?
On en fait un réflexe en traitant la qualité analytics comme une capacité business, pas comme une tâche technique qu’on ressort quand un chiffre paraît bizarre.
La qualité analytics ne sert pas juste à avoir des dashboards marketing plus propres. Elle sert à décider où mettre le budget, quels contenus SEO pousser, quelles campagnes paid media couper, quelles pages UX retravailler, quels chiffres remonter au comité de direction, quelles données envoyer dans la BI, le CRM ou les workflows assistés par l’IA.
Et là, le sujet devient plus sérieux. Si la donnée est fragile, l’automatisation ne va pas corriger le problème. Elle va l’amplifier. J’ai déjà vu une équipe relancer automatiquement des segments CRM basés sur des événements mal tagués. Résultat : bons clients exclus, prospects froids sur-sollicités, et tout le monde pensait que “l’IA optimisait”. Non, elle exécutait juste très vite une mauvaise lecture.
Le bon réflexe, c’est une gouvernance légère. Pas une usine à gaz avec quinze comités et personne qui ose toucher au tracking. Juste quelques habitudes simples, visibles, tenues dans le temps.
- Un plan de marquage vivant, c’est-à-dire la liste des événements suivis, avec leur définition et leur usage.
- Un dictionnaire de métriques, pour savoir exactement ce que veut dire “conversion”, “lead qualifié” ou “revenu attribué”.
- Des contrôles réguliers sur les événements clés, surtout ceux qui pilotent le budget ou les alertes.
- Une documentation courte des changements, comme une refonte de page, un nouveau CMP, ou une modification CRM.
- Une revue avant grosse décision, pas pour bloquer, juste pour vérifier qu’on décide sur une base saine.
- Un propriétaire clair pour les métriques sensibles, sinon tout le monde les utilise et personne ne les assume.
Un format simple marche très bien avant chaque décision importante. L’équipe ajoute un petit bloc dans le dashboard ou dans le support de réunion.
| Périmètre | Ce qui est inclus, et ce qui ne l’est pas. |
| Période | Les dates analysées, avec les éventuels biais saisonniers. |
| Limites connues | Les trous de tracking, les écarts CRM, les exclusions. |
| Changements récents | Les updates site, consentement, campagnes, tags ou outils. |
| Niveau de confiance | Fort, moyen ou faible, avec une phrase d’explication. |
Ça évite les débats stériles du type “moi je ne crois pas au chiffre”. Ça rend aussi les décisions plus assumées, parce qu’on sait ce qu’on sait, et on sait ce qu’on ne sait pas.
La maturité analytics ne se mesure pas au volume de données collectées, mais à la capacité de comprendre leurs limites au bon moment.
Et si le vrai sujet était votre niveau de confiance ?
Je retiens une chose simple : une donnée analytics utile n’est pas une donnée parfaite, c’est une donnée assez fiable pour la décision qu’on veut prendre. Avant de couper un canal, d’augmenter un budget ou de conclure qu’une page ne convertit plus, je préfère vérifier le périmètre, le tracking, les définitions, la fraîcheur et les limites connues. C’est moins spectaculaire qu’un nouveau dashboard, mais beaucoup plus rentable. Quand vos équipes savent ce que les données disent vraiment, et ce qu’elles ne disent pas, vous décidez plus vite, avec moins de débats inutiles et moins d’erreurs coûteuses.
FAQ
- Qu’est-ce qu’une donnée analytics prête à décider ?
C’est une donnée assez exacte, récente, complète et comprise pour soutenir une décision précise. Elle n’a pas besoin d’être parfaite. Elle doit surtout être fiable dans son contexte : budget, conversion, canal marketing, SEO, CRM ou dashboard de direction. - Pourquoi des données analytics fiables peuvent quand même être discutées ?
Parce que la fiabilité dépend souvent du périmètre. Un chiffre peut être juste techniquement, mais incomplet si une partie du trafic n’est pas mesurée, si le consentement a changé, si un tag est cassé ou si la définition d’une conversion n’est pas partagée. - Que faut-il vérifier avant de prendre une décision marketing ?
Je vérifie le tracking, les événements clés, les UTM, les changements récents, la période comparée, les exclusions, le trafic interne, le trafic automatisé, les règles d’attribution et les définitions des métriques. C’est souvent là que les mauvaises conclusions naissent. - Le consentement peut-il fausser les données analytics ?
Il peut modifier la mesure, oui. Selon les choix de consentement et la configuration des traceurs, une partie des visites ou conversions peut ne pas être collectée de la même manière. Il faut donc intégrer cette limite avant de comparer des périodes ou des canaux. - Comment améliorer durablement la qualité analytics ?
Le plus efficace, c’est de maintenir un plan de marquage propre, un dictionnaire de métriques, des contrôles réguliers sur les événements critiques et une documentation des changements. La qualité analytics devient alors un réflexe business, pas juste un chantier technique ponctuel.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’ai accompagné des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor sur leurs sujets data, tracking et pilotage marketing. Si vous voulez fiabiliser vos données analytics ou automatiser vos décisions sans partir sur de mauvaises bases, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.