Un guide pratique de Comment vérifier que votre outil danalyse Web

Les outils d'analytics tombent rarement en panne de façon visible. Pour vérifier que votre outil fonctionne correctement, il faut traquer les défaillances silencieuses : un script absent d'un template, un blocage par la Content Security Policy, un gestionnaire de balises qui déclenche deux fois le même événement.

Les défaillances d'analytics sont souvent silencieuses. Un script peut manquer sur un template, être bloqué par la Content Security Policy, dupliqué par un gestionnaire de balises, cassé par les paramètres de consentement, ou envoyer des événements avec le mauvais domaine. Le tableau de bord continue d'afficher des chiffres, donc personne ne s'en aperçoit jusqu'à ce que des décisions soient prises sur de mauvaises données.

Utilisez cette checklist après l'installation de tout outil d'analytics et après toute modification majeure du site.

1. Vérifiez que le script se charge

Ouvrez les outils de développement du navigateur et consultez l'onglet Réseau. Filtrez sur le domaine ou le nom du fichier du script d'analytics. Vérifiez que :

• Le script renvoie un code 200.
• Il n'est pas bloqué par la CSP.
• Il n'est pas bloqué par un bloqueur de publicités pendant votre test de référence.
• Il ne se charge qu'une seule fois.
• Il est présent sur tous les templates requis.

Si vous utilisez un gestionnaire de balises, vérifiez à la fois le code source de la page et le mode aperçu du gestionnaire de balises.

2. Testez les pages vues en temps réel

Ouvrez une fenêtre de navigation privée, visitez le site et observez les rapports en temps réel. Testez la page d'accueil, un article de blog, la page tarifs, la page de paiement ou d'inscription, et une page 404 si elle est suivie.

Pour les applications monopages, vérifiez que les changements de route déclenchent bien des pages vues. De nombreux bugs de suivi viennent d'une navigation côté client qui change l'URL sans relancer la logique de page vue.

3. Validez le comportement du consentement

Si l'analytics nécessite un consentement, testez tous les états :

• Avant tout choix.
• Acceptation.
• Refus.
• Retrait du consentement.
• Visite de retour.
• Région différente si des règles géographiques s'appliquent.

Les requêtes réseau doivent correspondre au choix de l'utilisateur. Une bannière qui s'affiche après que la requête de suivi a déjà été envoyée ne remplit pas son rôle.

4. Vérifiez le suivi en double

Des scripts en double comptent deux fois les pages vues et les conversions. Les causes courantes sont :

• Un script codé en dur en plus du script du gestionnaire de balises.
• Le layout et le template de page qui injectent tous deux l'analytics.
• L'ancienne propriété GA en plus de la nouvelle propriété GA4.
• Le gestionnaire de consentement qui déclenche deux fois la même balise.

Utilisez le nombre de requêtes réseau et les pics dans le tableau de bord pour détecter les doublons.

5. Testez les événements et les objectifs

Déclenchez chaque conversion manuellement :

• Clic sur un CTA.
• Envoi d'un formulaire.
• Inscription terminée.
• Paiement terminé.
• Abonnement à la newsletter.
• Téléchargement.

Vérifiez les noms d'événements, les propriétés et les horodatages. Les événements doivent se déclencher après le succès, pas seulement au clic sur le bouton, lorsque l'action métier dépend d'une validation ou d'une confirmation serveur.

6. Inspectez les charges utiles à la recherche de données personnelles

Examinez les charges utiles des requêtes. Vérifiez que vous n'envoyez pas d'e-mails, de noms, de numéros de téléphone, d'identifiants de compte, de tokens, d'URL complètes de paiement, ou de champs de texte libre. C'est particulièrement important pour la santé, la finance, l'éducation et l'e-commerce.

7. Validez l'attribution

Créez des URL de test avec des UTM :

?utm_source=test&utm_medium=email&utm_campaign=qa

Visitez le lien et vérifiez que la campagne apparaît correctement. Testez également un renvoi depuis un autre domaine. Si l'attribution est manquante, vérifiez les redirections, les domaines canoniques, le moment du consentement et la suppression des paramètres.

8. Comparez avec les journaux du serveur

L'analytics ne correspondra jamais exactement aux journaux du serveur, mais les écarts importants sont des signaux utiles. Comparez le nombre total de requêtes, les pages vues et les pages les plus consultées sur une courte période. Les différences peuvent venir des bots, des bloqueurs, des pages en cache ou d'erreurs de script.

9. Surveillez après le lancement

Mettez en place un contrôle récurrent :

• Vérification hebdomadaire de cohérence du trafic.
• Alerte en cas de chute soudaine à zéro événement.
• Alerte en cas de baisse des conversions au-delà de la variance normale.
• Vérification après chaque déploiement.
• Nouveau test après toute modification du gestionnaire de consentement ou de la CSP.

La vérification n'est pas une tâche d'installation ponctuelle. Traitez l'analytics comme une instrumentation en production : testée, surveillée et révisée à chaque changement de l'application.

Garde-fous de déploiement

Ajoutez des vérifications d'analytics à la QA de release. Par exemple, après une refonte des routes, vérifiez que le layout global inclut toujours le script, que la navigation côté client émet toujours des pages vues, et que la CSP autorise toujours le endpoint d'analytics. Si votre plateforme le permet, créez un moniteur synthétique qui visite une page de test et confirme la réception d'un événement.

QA de confidentialité

Le QA technique doit inclure un QA de confidentialité. Inspectez les payloads après des parcours réalistes, y compris les formulaires en échec et les pages d'erreur. Ce sont des endroits où des données sensibles fuient parce que les développeurs envoient le contexte d'erreur complet. Un système d'analytics qui fonctionne correctement mais qui collecte les mauvaises données reste défectueux.

Utiliser les preuves du navigateur et du serveur

Ne vous fiez pas uniquement au tableau de bord analytics. Utilisez ensemble l'onglet Réseau du navigateur, les journaux d'accès serveur et l'interface analytics. L'onglet Réseau prouve qu'une requête a été envoyée. Le journal serveur prouve qu'elle a atteint votre endpoint. Le tableau de bord prouve qu'elle a été acceptée, traitée et attribuée correctement. Un bug peut survenir à n'importe quel niveau.

Le guide MDN sur la liste des requêtes réseau explique comment les outils de développement exposent les méthodes de requête, les codes de statut, les délais et les ressources transférées (MDN Network Monitor). Utilisez ces preuves pendant le QA : enregistrez des captures d'écran ou des fichiers HAR pour l'installation, les états de consentement et les tests de conversion.

Pour un outil d'analytics axé sur la confidentialité, vérifiez ces points supplémentaires :

• Les chaînes de requête sont supprimées ou correctement mises sur liste blanche.
• Le traitement des IP correspond à votre politique de confidentialité.
• Le filtrage des bots ne supprime pas de trafic QA légitime par erreur.
• Les événements envoyés avec navigator.sendBeacon arrivent bien lors de la fermeture des pages.
• Les onglets de navigateur dupliqués ne gonflent pas les événements de conversion.
• Les bloqueurs de publicité ne cassent pas les fonctionnalités essentielles du site.

Créez une petite matrice de tests avant les mises en production importantes :

Conservez cette matrice avec le QA de mise en production. La qualité des analytics se dégrade quand personne n'en est responsable ; des tests légers et reproductibles la maintiennent fiable.

Vérification prête pour la mise en production

Traitez la vérification des analytics comme un QA de production. Pour chaque mise en production importante, conservez des preuves pour la requête du script, la requête de pageview, la requête de conversion et la ligne finale du tableau de bord. Incluez au moins un test avec consentement accepté, un test avec consentement refusé le cas échéant, un test mobile et un test de conversion réconcilié avec le backend.

Ne considérez pas les analytics comme fonctionnels simplement parce que le tableau de bord a bougé. Une configuration correcte se charge une seule fois, respecte le consentement, exclut le trafic de test évident, n'envoie aucune donnée personnelle dans les payloads, préserve les UTM à travers les redirections et n'enregistre les conversions qu'après la survenue réelle de l'événement métier.

Foire aux questions

Comment savoir si mon script d'analyse se charge réellement ?

Ouvrez les outils de développement, allez dans l'onglet Réseau et filtrez sur le domaine ou le nom de fichier du script d'analyse. Vérifiez qu'il renvoie un statut 200, qu'il n'est bloqué ni par la CSP ni par un bloqueur de publicités pendant votre test de référence, qu'il ne se charge qu'une seule fois et qu'il apparaît sur chaque modèle requis. Si vous utilisez un gestionnaire de balises, vérifiez à la fois le code source de la page et le mode aperçu du gestionnaire de balises.

Pourquoi mon tableau de bord affiche-t-il des chiffres alors que le suivi est toujours défaillant ?

Les défaillances d'analyse sont souvent silencieuses. Un script peut être absent d'un modèle, bloqué par la CSP, dupliqué par un gestionnaire de balises, cassé par les paramètres de consentement, ou envoyer des événements avec le mauvais domaine, et le tableau de bord continue d'afficher des chiffres malgré tout. C'est pourquoi des décisions peuvent reposer sur de mauvaises données jusqu'à ce que quelqu'un applique la liste de vérification.

Comment tester l'analyse sur une application monopage ?

Vérifiez que les changements de route déclenchent des pages vues, car de nombreux bugs de suivi viennent d'une navigation côté client qui change l'URL sans relancer la logique de page vue. Surveillez les rapports en temps réel en naviguant entre les pages dans une fenêtre privée pour confirmer que chaque changement de route est enregistré.

Qu'est-ce qui cause le suivi analytique en double ?

Les causes courantes sont un script codé en dur en parallèle d'un script de gestionnaire de balises, la mise en page et le modèle de page qui injectent tous deux l'analyse, une ancienne propriété GA toujours active à côté d'une nouvelle propriété GA4, ou un gestionnaire de consentement qui déclenche la même balise deux fois. Utilisez le nombre de requêtes réseau et les pics du tableau de bord pour repérer la duplication.

Quand un événement de conversion doit-il se déclencher ?

Après la réussite réelle de l'action commerciale, pas simplement au clic sur un bouton, lorsque cette action dépend d'une validation ou d'une confirmation serveur. Déclenchez manuellement les clics sur les CTA, les envois de formulaires, les inscriptions, les paiements, les abonnements à la newsletter et les téléchargements, puis vérifiez les noms d'événements, les propriétés et les horodatages.

Quelles données personnelles ne doivent jamais apparaître dans les payloads d'analyse ?

Les e-mails, noms, numéros de téléphone, identifiants de compte, jetons, URL de paiement complètes et saisies de texte libre ne doivent jamais figurer dans le payload d'une requête. Cela compte particulièrement pour les sites de santé, de finance, d'éducation et de commerce électronique, et cela s'applique aussi aux formulaires en échec et aux pages d'erreur, car les développeurs y consignent souvent le contexte complet de l'erreur.

Comment tester l'attribution UTM ?

Construisez une URL de test comme ?utm_source=test&utm_medium=email&utm_campaign=qa, visitez-la et vérifiez que la campagne apparaît correctement dans les rapports. Testez aussi une recommandation depuis un autre domaine, et si l'attribution est absente, vérifiez les redirections, les domaines canoniques, le moment du consentement et la suppression des paramètres.

Pourquoi mes données d'analyse ne correspondent-elles pas aux journaux de mon serveur ?

L'analyse ne correspondra jamais exactement aux journaux du serveur, mais les grands écarts restent un signal utile. Comparez le nombre total de requêtes, les pages vues et les pages principales sur une courte période, car les différences peuvent venir des robots, des bloqueurs, des pages en cache ou d'erreurs de script.

Que dois-je surveiller après le lancement ?

Mettez en place une vérification récurrente couvrant un contrôle hebdomadaire de cohérence du trafic et des alertes en cas de chute soudaine à zéro événement et de baisse des conversions au-delà de la variation normale. Ajoutez une revue après chaque déploiement et un nouveau test après toute modification du gestionnaire de consentement ou de la CSP. La vérification n'est pas une tâche d'installation ponctuelle.

Comment vérifier l'analyse sans se fier uniquement au tableau de bord ?

Utilisez ensemble l'onglet Réseau du navigateur, les journaux d'accès du serveur et l'interface d'analyse. L'onglet Réseau prouve qu'une requête a été envoyée, le journal serveur prouve qu'elle a atteint votre point de terminaison, et le tableau de bord prouve qu'elle a été acceptée, traitée et attribuée correctement, car un bug peut survenir à n'importe quel niveau.