Comment Tracker une Iframe avec Google Tag Manager

Tracker ce qui se passe à l'intérieur d'une iframe (formulaire embarqué, prise de rendez-vous, simulateur tiers) est un cas classique mal documenté, parce que la vraie contrainte n'est pas dans GTM, elle est dans le navigateur lui-même.

La vraie limite : la same-origin policy

Confirmé par la documentation MDN : l'accès aux propriétés d'une fenêtre chargée depuis une autre origine est bloqué par le navigateur, y compris pour un script à l'intérieur d'une iframe qui voudrait accéder à sa page parente. Via contentWindow ou contentDocument, la page parente peut accéder au DOM de l'iframe seulement si elles partagent la même origine (même protocole, domaine et port). En cross-origin, cet accès est très restreint. Ce n'est pas une limitation de GTM, c'est une protection de sécurité du navigateur, aucun tag ni aucune configuration GTM ne la contourne.

postMessage, la méthode standard

Le seul canal de communication documenté entre deux origines différentes est Window.postMessage(). Le principe : l'iframe émet un message, la page parente l'écoute et relaie l'information dans le dataLayer.

Côté iframe (si vous contrôlez son code) :

window.parent.postMessage({
  event: "form_submitted",
  data: { formName: "contact" }
}, "https://votre-domaine-parent.com");

Côté page parente, dans une balise HTML personnalisée GTM :

window.addEventListener("message", function(e) {
  if (e.origin !== "https://domaine-iframe.com") return;
  if (e.data && e.data.event === "form_submitted") {
    window.dataLayer.push({
      event: "form_submitted",
      formData: e.data.data
    });
  }
});

Deux points de sécurité documentés à respecter systématiquement : ne jamais émettre avec postMessage(payload, '*'), qui envoie le message à n'importe quel parent sur n'importe quel domaine, et toujours vérifier e.origin côté réception avant de traiter le message, sous peine d'accepter des données injectées par une page tierce malveillante.

Quand vous ne contrôlez pas le code de l'iframe

Pour une iframe tierce (widget de prise de rendez-vous, formulaire externe), tout dépend de si le fournisseur envoie déjà des postMessage documentés.

Calendly : confirmé par sa documentation développeur officielle. L'embed standard Calendly envoie des événements avec le préfixe calendly., dont calendly.profile_page_viewed, calendly.event_type_viewed, calendly.date_and_time_selected et calendly.event_scheduled :

function isCalendlyEvent(e) {
  return e.origin === "https://calendly.com" && e.data.event && e.data.event.indexOf("calendly.") === 0;
}
window.addEventListener("message", function(e) {
  if (isCalendlyEvent(e)) {
    window.dataLayer.push({ event: e.data.event, calendlyPayload: e.data.payload });
  }
});

Point à vérifier avant de copier ce code tel quel : ça ne fonctionne que via l'embed JS standard de Calendly, pas via une iframe brute sans son script d'intégration.

Typeform : la documentation officielle met surtout en avant un système de callbacks (onSubmit) via son SDK d'embed, plus que du postMessage brut à écouter soi-même. Un événement form-submit observable en écoute passive existe et est utilisé par des implémentations tierces, mais il est moins formellement documenté par Typeform elle-même que ne l'est le système Calendly, à traiter avec cette réserve avant de bâtir un tracking dessus.

Un conteneur GTM dans l'iframe, ou un seul sur la page parente ?

Aucune position officielle Google ne tranche ce choix, mais la pratique convergente des consultants tracking donne une règle simple : quand vous contrôlez le code de l'iframe, un seul conteneur sur la page parente avec la méthode postMessage ci-dessus reste préférable, ça garde un Client ID et un Session ID unifiés côté domaine parent et évite la duplication de mesure. Un second conteneur GTM installé directement dans l'iframe se justifie quand l'iframe vit sur un domaine distinct avec son propre besoin de mesure autonome, ou quand vous n'avez aucune main sur le code de la page parente. Le risque documenté dans ce second cas : les déclencheurs standards ("Toutes les pages", clics) du conteneur de l'iframe se déclenchent aussi dans son propre contexte et peuvent générer des données dupliquées ou incorrectes si les tags ne sont pas contraints par des exceptions vérifiant le nom d'hôte.

Christophe Dubois

Consultant tracking & data, freelance senior depuis 2012. Architecture de mesure, server-side, attribution.