Vérifiez la donnée avant d'agir dessus

L'audit fait tourner un catalogue fixe de vérifications, groupées par catégorie. La configuration du tag manager couvre les tags dupliqués, les déclencheurs trop larges, le fait que les tags déclarent leurs exigences de consentement, et le fait que le conteneur en ligne corresponde à la dernière version. La sécurité du tag manager couvre le ratio de HTML personnalisé et l'exposition qui va avec. Consentement et privacy est le plus gros groupe avec huit vérifications. Le reste couvre le schema ecommerce, le schema lead et le payload réellement envoyé par vos pages. Chaque vérification nomme sa remédiation et énonce l'impact client, parce qu'un constat sans l'un ni l'autre est une pastille rouge que l'on apprend à ignorer.

Oui, et ce n'est pas vendu séparément. Lumen était le nom des audits et des investigations d'anomalies, et les deux vivent ici dans le Trust Center, sur tous les paliers. Il n'y a pas de ligne de facturation distincte ni d'option par propriété. Si vous avez vu un prix associé à Lumen quelque part, c'est périmé et c'est cette page qui fait foi.

Une alerte se déclenche et produit une investigation. Elle fait tourner un ensemble structuré de vérifications : l'intégrité des données d'abord, parce qu'une panne de tracking rend tout chiffre en aval dénué de sens, puis des sondes parallèles sur la dépense, le trafic, les créas, le tunnel, l'étiquetage des campagnes et la réconciliation entre plateformes, puis le contexte externe. La sortie est un diagnostic avec une catégorie de cause et un niveau de confiance, plus la trace de savoir si un motif connu a été reconnu ou si le run n'a pu que rapporter des faits. Vous enregistrez ensuite un verdict, et sur un verdict faux ou partiel vous nommez la vraie cause, ce dont le référentiel apprend.

Il rejoint la liste d'actions. Les audits et les investigations alimentent le silo instrumentation de Beacon, donc un défaut arrive dans la même liste classée que votre travail paid et SEO, avec ses preuves attachées et son cycle de vie suivi de planifié à fait puis vérifié. C'est la jointure qui vaut le coup : dans la plupart des stacks, l'outil qui détecte le tag cassé n'a aucun moyen de faire concourir la correction face à tout le reste de votre charge.

Parce qu'un agent ne peut pas savoir qu'un chiffre est faux. Il lit les tables qu'on lui donne et répond par une phrase assurée dans les deux cas, ce qui rend un défaut de tracking plus grave et non plus visible : un chiffre faux qui dormait dans un dashboard que personne n'ouvrait est désormais lu à voix haute dans une décision. Les audits, le verdict du contrat et les investigations lisent le même monitor que les tables que le serveur MCP donne à Claude, ChatGPT ou Cursor. Le check qui dit que votre tracking tient et la réponse de votre agent reposent donc sur une seule source, et quand le tracking casse le verdict bouge avec lui.

C'est exactement sa raison d'être. Le plan énonce chaque événement attendu et les tags fournisseurs câblés dessus, le verdict est calculé en direct depuis le moniteur plutôt que stocké, et l'historique des révisions montre ce qui a été convenu et quand cela a changé. Pour une agence, c'est l'artefact qui transforme « le tracking va bien » en quelque chose qu'un client peut vérifier. La vue client en lecture seule est une phase ultérieure ; aujourd'hui le plan, le verdict et l'historique sont tous dans le produit.