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

Ce guide explique Comment vérifier que votre outil danalyse Web de manière pratique, avec un accent sur les décisions d'analytics respectueuses de la vie privée.

Les échecs d’analyse sont souvent silencieux. Un script peut être absent d'un modèle, bloqué par la politique de sécurité du contenu, dupliqué par un gestionnaire de balises, interrompu par les paramètres de consentement ou envoyé des événements avec le mauvais domaine. Le tableau de bord affiche toujours des chiffres, donc personne ne le remarque jusqu'à ce que les décisions soient basées sur de mauvaises données.

Utilisez cette liste de contrôle après l'installation d'un outil d'analyse et après des modifications majeures du site.

1. Confirmez le chargement du script

Ouvrez les outils de développement du navigateur et vérifiez l'onglet Réseau. Filtrez le domaine d'analyse ou le nom du fichier de script. Confirmer:

• Le script renvoie 200.
• Il n'est pas bloqué par CSP.
• Il n'est pas bloqué par un bloqueur de publicités lors de votre test de base.
• Il ne se charge qu'une seule fois.
• Il est présent sur tous les modèles requis.

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

2. Testez les pages vues en temps réel

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

Pour les applications à page unique, vérifiez que les modifications d'itinéraire déclenchent des pages vues. De nombreux bogues de suivi proviennent de la navigation client-side qui modifie le URL sans réexécuter la logique de visualisation de page.

3. Valider le comportement de consentement

Si l'analyse nécessite le consentement, testez tous les états :

• Avant de choisir.
• Accepter.
• Rejeter.
• Retirer le consentement.
• Visite de retour.
• Région différente si les règles géographiques s'appliquent.

Les requêtes réseau doivent correspondre au choix de l'utilisateur. Une bannière qui apparaît après le déclenchement de la demande de suivi ne fait pas son travail.

4. Vérifiez le suivi des doublons

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

• Script codé en dur et script de gestionnaire de balises.
• Mise en page et modèle de page injectant tous deux des analyses.
• Ancienne propriété GA plus nouvelle propriété GA4.
• Le gestionnaire de consentement déclenche deux fois la même balise.

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

5. Testez les événements et les objectifs

Déclenchez chaque conversion manuellement :

• CTA clic.
• Soumettre le formulaire.
• Inscription terminée.
• Paiement terminé.
• Abonnement à la newsletter.
• Télécharger.

Vérifiez les noms, les propriétés et les horodatages des événements. Les événements doivent se déclencher après le succès, et pas simplement après un clic sur un bouton, lorsque l'action commerciale dépend de la validation ou de la confirmation du serveur.

6. Inspecter les charges utiles pour les données personnelles

Examinez les charges utiles des requêtes. Confirmez que vous n'envoyez pas d'e-mails, de noms, de numéros de téléphone, de compte IDs, de jetons, de paiement complet URLs ou de saisies de texte libre. Ceci est particulièrement important pour les soins de santé, la finance, l’éducation et le commerce électronique.

7. Valider l'attribution

Créez le test URLs avec UTMs :

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

Visitez le lien et confirmez que la campagne s'affiche correctement. Testez également un référencement d'un autre domaine. Si l'attribution est manquante, vérifiez les redirections, les domaines canoniques, le délai de consentement et la suppression des paramètres.

8. Comparez avec les journaux du serveur

Les analyses ne correspondent pas exactement aux journaux du serveur, mais des écarts importants sont des signaux utiles. Comparez le nombre total de demandes, les pages vues et les premières pages sur une courte période. Les différences peuvent provenir de robots, de bloqueurs, de pages mises en cache ou d'erreurs de script.

9. Surveiller après le lancement

Définir un contrôle récurrent :

• Contrôle hebdomadaire de l'intégrité du trafic.
• Alerte sur les événements zéro soudains.
• L'alerte sur la conversion dépasse la variance normale.
• Revue après déploiements.
• Re-tester après les modifications du gestionnaire de consentement ou de CSP.

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

Garde-corps de déploiement

Ajoutez des contrôles analytiques pour publier QA. Par exemple, après une refactorisation d'itinéraire, vérifiez que la présentation globale inclut toujours le script, que la navigation client-side émet toujours des pages vues et que CSP autorise toujours le point de terminaison d'analyse. Si votre plateforme le prend en charge, créez un moniteur synthétique qui visite une page de test et confirme l'arrivée d'un événement.

Confidentialité QA

Le QA technique doit inclure le QA de confidentialité. Inspectez les charges utiles après des flux réalistes, y compris les formulaires ayant échoué et les pages d'erreur. Ce sont des endroits où des données sensibles fuient car les développeurs envoient un contexte d'erreur complet. Les analyses qui fonctionnent correctement mais collectent les mauvaises données sont toujours interrompues.

Utiliser les preuves du navigateur et du serveur

Ne vous fiez pas uniquement au tableau de bord analytique. Utilisez l'onglet Réseau du navigateur, les journaux d'accès au serveur et les analyses UI ensemble. L'onglet Réseau prouve qu'une demande a été envoyée. Le journal du serveur prouve qu'il a atteint votre point de terminaison. Le tableau de bord prouve qu'il a été accepté, traité et attribué correctement. Un bug peut survenir à n’importe quelle couche.

Le guide de 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 d'état, la synchronisation et les ressources transférées (MDN Network Monitor). Utilisez ces preuves pendant 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'analyse axé sur la confidentialité, vérifiez ces points supplémentaires :

• Les chaînes de requête sont supprimées ou inscrites sur la liste autorisée en toute sécurité.
• La gestion de IP correspond à votre avis de confidentialité.
• Le filtrage des robots ne supprime pas le trafic réel QA de manière inattendue.
• Les événements envoyés avec navigator.sendBeacon arrivent lors du déchargement des pages.
• Les onglets de navigateur en double ne gonflent pas les événements de conversion.
• Les bloqueurs de publicités n'interrompent pas les fonctionnalités essentielles du site.

Créez une petite matrice de test avant les versions importantes :

Scénario	Résultat attendu
Première visite avec UTMs	Une page vue avec les libellés de campagne
Rejeter le consentement	Seules les requêtes autorisées sont déclenchées
SPA changement d'itinéraire	Nouvelle page vue enregistrée
Inscription réussie	Une conversion après le succès du serveur
Formulaire échoué	Aucune conversion et aucune charge utile sensible

Conservez cette matrice avec la version QA. La qualité des analyses se dégrade lorsque personne n’en est propriétaire; des tests légers et reproductibles le maintiennent digne de confiance.

## Vérification prête à être publiée

Traitez la vérification analytique comme la production QA. Pour chaque version importante, conservez les preuves de la demande de script, de la demande de page vue, de la demande de conversion et de la ligne finale du tableau de bord. Incluez au moins un test de consentement accepté, un test de consentement rejeté le cas échéant, un test mobile et un test de conversion rapproché avec le backend.

Ne marquez pas les analyses comme fonctionnant 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 charges utiles, préserve les UTMs via les redirections et enregistre les conversions uniquement après que l'événement commercial réel se soit produit.