Un script d’analyse peut figurer dans le code source alors que les achats sont envoyés au mauvais compte. À l’inverse, une intégration serveur fonctionnelle peut rester invisible dans le HTML public. Un audit d’intégrations commence donc par un inventaire, pas par un jugement définitif sur la qualité.
Posez une question vérifiable : une inscription terminée envoie-t-elle exactement un événement à la propriété prévue ? Le rapport fournit des preuves publiques et identifie les points inconnus. Vérifiez ensuite la transmission dans les systèmes auxquels vous avez légitimement accès.
Périmètre de cet audit
Ce qui peut être mesuré
- HTML statique public et en-têtes HTTP de la page demandée ; éventuellement une seconde page liée de même origine.
- Signatures de certains outils d’analyse, de publicité, d’étude du comportement, de consentement et de gestion de tags.
- Indices publics de vérification dans le HTML, les en-têtes et certains enregistrements DNS, ainsi que certains motifs de suivi et de formulaire.
Ce qu’il ne prouve pas
- Pas d’exécution JavaScript ni de preuve de livraison des événements ou d’attribution des conversions.
- Pas d’accès aux comptes fournisseurs, aux droits ou aux configurations privées.
- Pas de validation exhaustive du consentement ni de verdict juridique général.
Le module d’intégrations est disponible avec Starter, Professional et Enterprise, mais pas Free. Les vérifications chez un fournisseur nécessitent séparément les droits d’accès adaptés.
Définir l’inventaire attendu
Notez d’abord les outils dont le site a réellement besoin : analyse, publicité, gestion du consentement, assistance et éventuel traitement serveur. Identifiez le rôle et le responsable de chacun. Un site informatif sans pixel publicitaire n’est pas automatiquement défectueux. Un petit ensemble bien compris est souvent préférable à une accumulation de tags abandonnés.
Choisissez ensuite une page publique et un événement commercial pertinent. Une page vue, un formulaire envoyé et un achat confirmé sont trois faits différents. Documentez la propriété et l’événement attendus sans copier d’identifiants privés ni de données clients dans des rapports partagés. Cet état attendu évite de traiter l’absence de chaque logo de fournisseur comme une anomalie.
Comprendre le périmètre de l’observation publique
Le moteur actuel lit le HTML statique et les en-têtes ; il n’exécute pas JavaScript. Il examine la page demandée et peut ajouter une seconde page liée de même origine. Référez-vous aux pages réellement indiquées dans le rapport, sans étendre les conclusions à tous les modèles, sous-pages ou parcours de paiement externes.
Les signatures peuvent indiquer des outils d’analyse, des pixels publicitaires, de mesure comportementale, de consentement ou de gestion de tags. Les jetons publics trouvés dans le HTML, les en-têtes ou le DNS apportent une autre information : un jeton ne révèle pas qui peut accéder à Search Console. Son absence n’exclut pas les autres méthodes de vérification. La documentation Google sur la vérification des propriétés décrit les possibilités.
Suivre les preuves au-delà du statut
« Détecté » signifie qu’un motif pris en charge était visible. Cela ne démontre ni l’exécution, ni le consentement, ni la transmission réseau, ni l’acceptation par le fournisseur. « Non détecté » peut correspondre à une intégration exécutée plus tard, côté serveur ou sur une autre page. Confrontez ces deux états à l’implémentation réelle.
Une page inaccessible ou remplacée par un écran de vérification prive l’analyse de sa base. Elle ne prouve pas que toutes les intégrations sont absentes. Distinguez aussi un délai DNS dépassé d’une requête réussie sans enregistrement correspondant. Face à une URL de suivi non sécurisée, vérifiez d’abord si elle est utilisée ou simplement présente dans du code inactif, puis examinez les requêtes du navigateur.
| Observation | Priorité selon le contexte | Preuve à confirmer | Action suivante |
|---|---|---|---|
| Un événement arrive à la mauvaise propriété | Élevée pour un événement métier confirmé | Requête du navigateur et réception autorisée chez le fournisseur | Corriger la destination et tester l’action puis ses répétitions |
| Un tag n’est pas détecté | Non confirmé ; pas automatiquement un défaut | Vérifier l’architecture attendue et la livraison réelle | Examiner l’exécution dynamique, côté serveur ou sur une autre page |
| Une signature de plateforme de consentement est présente | Vérification du comportement nécessaire | Observer avant choix, après refus et après acceptation | Vérifier que la transmission suit le choix prévu |
Suivre un événement jusqu’à sa destination
- Ouvrez une session de navigateur propre. Tenez compte du choix de consentement et des extensions susceptibles de perturber le test.
- Effectuez l’action une fois, avec des données de test. Examinez le réseau et la vue de diagnostic du fournisseur à laquelle vous êtes autorisé à accéder.
- Comparez le nom de l’événement, sa destination et ses valeurs nécessaires. Cliquer sur « Acheter » n’équivaut pas à une transaction confirmée.
- Testez rechargements, redirections et nouvelles tentatives. Si navigateur et serveur émettent ensemble, vérifiez la déduplication prévue.
Avec une couche de données Google, le moment et le contenu des événements sont essentiels. La présence de dataLayer ne confirme pas la justesse des valeurs. Corrigez le déclenchement ou l’intégration responsable au lieu d’ajouter un tag supplémentaire sans diagnostic.
Interpréter consentement et signaux de données avec prudence
Détecter une plateforme de consentement ne prouve pas qu’elle respecte le choix effectué. Testez une nouvelle session avant tout choix, puis le refus, l’acceptation et une modification ultérieure. Comparez le comportement observé au fonctionnement prévu. Google décrit la gestion du consentement comme le fait de recueillir, transmettre et respecter le choix ; son guide d’implémentation explique l’importance de l’ordre des opérations.
Des motifs évoquant des données personnelles ou certains cookies constituent des pistes d’enquête, pas des verdicts juridiques automatiques. Vérifiez destination et règles du produit avant modification ; le hachage n’autorise pas universellement une transmission. Un signal concernant le texte de confidentialité ou une case obligatoire d’un formulaire exige aussi une revue manuelle. Le HTML statique ne suffit pas à déterminer définitivement les obligations applicables.
Retester et conclure sur la bonne affirmation
Relancez l’observation publique sur les mêmes pages et documentez les signatures modifiées. Ajoutez le contrôle au navigateur et la preuve de réception autorisée chez le fournisseur. Une fiche courte indiquant action, consentement, événement attendu, événement observé et recherche de doublons est souvent suffisante. Masquez données personnelles, jetons et informations de paiement dans les preuves partagées.
Concluez uniquement sur ce que vous avez vérifié. Si un script indésirable a été supprimé, assurez-vous que les événements importants arrivent encore. Une meilleure note ne prouve ni attribution correcte, ni livraison, ni conformité juridique. Reprenez les tests pertinents après une modification du consentement, des tags de campagne ou du parcours de commande.
Questions fréquentes
Un tag d’analyse détecté prouve-t-il que l’analyse fonctionne ?
Non. Il confirme un motif public visible. L’exécution, la bonne destination, les valeurs et l’acceptation par le fournisseur doivent être vérifiées séparément.
Un jeton de vérification indique-t-il qui accède à Search Console ?
Non. Les indices publics ne permettent pas d’évaluer les permissions des comptes. Il faut un accès autorisé au service concerné pour les consulter.
Une plateforme de consentement non détectée constitue-t-elle automatiquement une infraction ?
Non. La détection est limitée et les obligations dépendent du traitement réel et du contexte. Examinez l’implémentation et son comportement plutôt que de conclure à partir d’un motif absent.
Sources et lectures
- Google : la couche de donnéesdevelopers.google.com
- Google : mode Consentement et gestion du consentementdevelopers.google.com
- Google : configurer le mode Consentementdevelopers.google.com
- Google : valider la propriété d’un sitesupport.google.com
Rédigé par l’équipe Sitelemetry et vérifié par rapport au périmètre du produit et aux sources primaires citées. Les exemples sont illustratifs, sauf mention explicite d’un cas observé.
