J'ai audité mon propre tracking. Voici les 5 problèmes que j'ai trouvés.
Je gagne ma vie en réparant le tracking des autres. Cette semaine, j'ai audité mon propre site. J'ai trouvé 5 problèmes, dont 3 qui duraient depuis des mois — et une leçon : un tracking peut avoir l'air de fonctionner pendant que ses signaux les plus précieux se perdent en silence.
Je gagne ma vie en réparant le tracking des autres. Server-side, consentement Loi 25, enhanced conversions : c'est littéralement écrit sur ma page d'accueil.
Cette semaine, j'ai audité mon propre site.
J'ai trouvé 5 problèmes. Dont 3 qui duraient depuis des mois.
Je pourrais ne jamais t'en parler. Personne ne l'aurait su. Mais ces 5 problèmes, je les retrouve presque chaque fois que j'audite le compte d'un client, et il y a une leçon là-dedans qui vaut plus cher que mon orgueil : un tracking peut avoir l'air de fonctionner pendant que ses signaux les plus précieux se perdent en silence.
Voici ce que j'ai trouvé, dans l'ordre du plus sournois au plus gênant.
Problème 1 : mon pixel ChatGPT Ads envoyait zéro conversion (et tout semblait normal)
Je teste les publicités dans ChatGPT depuis leur lancement, avec le pixel de conversion d'OpenAI installé sur mon site. Le script se chargeait parfaitement. Aucune erreur visible. Dans l'interface, le pixel apparaissait comme « installé ».
Sauf que la politique de sécurité de mon site (la CSP, ce fichier qui dit au navigateur quels domaines ont le droit de communiquer avec ta page) autorisait le domaine qui charge le script, mais pas celui qui reçoit les conversions.
Résultat : le pixel se réveillait, mesurait chaque lead... et chaque envoi vers OpenAI était bloqué par le navigateur. Silencieusement. Zéro conversion transmise, zéro alerte — et une campagne ChatGPT Ads qui optimisait à l'aveugle.
Pourquoi c'est sournois : tous les outils de vérification standard disaient que le pixel était bien installé. Il l'était. Il ne pouvait juste rien dire à personne.
Vérifie chez toi : ouvre ta console de navigateur (F12) sur ton site, onglet Console, et cherche les mentions « Content Security Policy » ou « blocked ». Si tu en vois qui pointent vers des domaines publicitaires, une partie de ton tracking crie dans le vide.
Problème 2 : un script de mesure mort depuis sa création
Mon site mesure les Web Vitals : la vitesse de chargement réelle vécue par chaque visiteur, envoyée dans Google Analytics pour pouvoir corréler vitesse et conversion.
Enfin. C'est ce qu'il était censé faire.
Le script contenait une erreur de configuration qui faisait qu'il était livré au navigateur dans un format que celui-ci ne peut pas exécuter. Il mourait à la première ligne. Depuis le jour de sa mise en ligne.
Combien de données de vitesse collectées en plusieurs mois? Zéro. Pas « peu ». Zéro.
Pourquoi c'est sournois : quand une donnée n'arrive pas, GA4 ne te le dit pas. Il n'y a pas de case vide avec une alerte rouge. Le rapport n'existe juste pas, et comme tu ne l'as jamais vu exister, il ne te manque pas.
Vérifie chez toi : fais la liste de tout ce que ton plan de mesure est censé collecter, puis va vérifier que chaque événement existe réellement dans GA4 (Admin → DebugView, ou Rapports → Engagement → Événements). Ce qui n'apparaît pas n'a jamais été collecté.
Problème 3 : mes preuves de consentement partaient dans le vide
Celle-là, c'est la plus gênante pour un gars qui vend de la conformité Loi 25.
Ma bannière de consentement fonctionnait. Les visiteurs voyaient le choix, cliquaient, et leurs préférences étaient respectées : pas de tag publicitaire sans consentement. De l'extérieur, conformité parfaite.
Mais la preuve de chaque consentement (l'enregistrement horodaté qui te permet de démontrer, en cas de plainte ou de vérification, que ce visiteur a bel et bien consenti) était envoyée vers un endpoint mal configuré qui répondait une erreur 400. Chaque preuve, perdue. Depuis le début.
La nuance est importante : j'étais conforme dans les faits (les tags respectaient le choix des visiteurs), mais incapable de le prouver. Et en conformité, ce que tu ne peux pas prouver n'existe pas.
Vérifie chez toi : dans la console, onglet Réseau (Network), accepte ta propre bannière de consentement et regarde si la requête d'enregistrement part avec un code 200. Si tu vois du rouge, tes preuves n'existent pas.
Problème 4 : des paramètres de trop dans mes événements de formulaire
Pour les enhanced conversions de Google Ads, on transmet certaines données comme le courriel, mais hashées (illisibles) et par le canal prévu pour. Cette partie-là de mon installation était correcte.
Mais en inspectant mes événements de formulaire, j'ai trouvé des paramètres redondants qui transportaient plus d'information que nécessaire vers Google Analytics. Rien que les enhanced conversions n'utilisaient, donc aucun bénéfice — juste de la surface d'exposition inutile. Retirés la journée même.
Pourquoi je t'en parle quand même : c'est la version bénigne d'un problème que je retrouve sous sa forme grave sur une majorité des sites que j'audite. Le courriel du prospect en clair dans les événements GA4, dans l'URL de la page de remerciement, ou dans les paramètres de formulaire. Ça, c'est interdit par les politiques de Google — pas « déconseillé » : interdit, avec la suspension de la propriété Analytics comme sanction possible. Et c'est exactement le genre de fuite de renseignements personnels que la Loi 25 te demande d'éviter.
La règle est simple : tout ce qui part vers un outil d'analytique doit être soit anonyme, soit hashé. S'il y a un canal officiel pour les données personnelles (comme les enhanced conversions), c'est le seul à utiliser.
Vérifie chez toi : soumets ton propre formulaire avec la console ouverte (onglet Réseau, filtre « collect ») et inspecte ce qui part vers Google. Si tu peux lire un courriel ou un nom en clair dans l'URL ou le payload, règle ça cette semaine.
Problème 5 : des données d'attribution faussées par des raccourcis
Deux trouvailles plus petites, mais qui faussaient mes rapports :
- Toutes mes inscriptions à l'infolettre étaient attribuées au footer. Le formulaire du footer, celui de la page d'inscription, celui des articles : tous envoyaient « footer » comme provenance, parce que la valeur était écrite en dur dans le code du composant. Impossible de savoir quel emplacement convertissait le mieux.
- Mon calculateur poussait un événement « lead_magnet_download » à chaque calcul. Aucun lead, aucun téléchargement : juste un clic sur « Calculer ». Cet événement entrait en collision avec le vrai événement de capture de ma checklist, et gonflait artificiellement mes rapports de lead magnets.
Pourquoi ça compte : ces données-là sont celles sur lesquelles tu prends tes décisions d'optimisation. Des données faussées ne sont pas neutres, elles sont pires que pas de données : elles te donnent confiance dans la mauvaise direction.
La leçon : « installé » et « fonctionnel » sont deux choses différentes
Mon site avait l'air parfaitement tracké. GA4 recevait des pages vues. Les tags se déclenchaient dans Tag Manager. La bannière de consentement s'affichait. Tous les voyants étaient verts.
Et pendant ce temps : zéro conversion transmise à ChatGPT Ads, zéro donnée de vitesse, zéro preuve de consentement, des paramètres de trop dans mes événements, et une attribution faussée.
Aucun de ces problèmes n'était visible dans un rapport. Ils ne se voyaient qu'en allant regarder ce qui se passe réellement dans le navigateur, requête par requête. C'est exactement pour ça que les audits de surface (« le pixel est-il installé? ») ne valent rien : la vraie question est toujours « est-ce que la donnée se rend, complète et propre, jusqu'à sa destination? »
Si moi, avec le tracking comme métier, j'ai laissé traîner ça des mois sur mon propre site, je te garantis qu'il y a l'équivalent sur le tien.
Par où commencer
Trois vérifications de 5 minutes, sans outil spécialisé :
- Console ouverte, navigue sur ton site. Toute erreur rouge qui mentionne un domaine de tracking ou « Content Security Policy » mérite une enquête.
- Compare ton plan de mesure à GA4. Chaque événement censé exister doit apparaître dans DebugView. Les absents sont morts.
- Soumets ton propre formulaire et regarde ce qui part. Onglet Réseau, filtre « collect » : la donnée part-elle? Vers le bon endroit? Sans renseignement personnel en clair?
Sur le choix de l’outil lui-même, et pourquoi un analytics « gratuit » comme GA4 peut te coûter cher en signal perdu, j’ai détaillé ma grille de décision dans pourquoi Google Analytics te coûte de l’argent.
Et si tu veux que quelqu'un fasse le tour complet (CSP, consentement, server-side, enhanced conversions, attribution), c'est exactement ce que je fais dans mes audits de tracking. Je viens de me le faire à moi-même, alors je peux te confirmer que personne n'y échappe.