Le script de suivi est un petit script asynchrone — quelques kilooctets servis depuis un chemin propriétaire mis en cache en périphérie — qui identifie l’organisation à l’origine de chaque session. Correctement installé, il doit passer totalement inaperçu. Mal installé, il peut vous faire perdre une semaine à chercher pourquoi certaines entreprises identifiées manquent, avant de découvrir que le chargeur se trouvait dans un fragment chargé à la demande. Ce guide vous évitera cette semaine de débogage.
Trois principes avant de coller quoi que ce soit
- Le chargeur doit être placé dans le head HTML global du site. Pas dans le pied de page, ni dans un modèle de page particulier, ni dans un composant affiché uniquement sur les pages marketing. Dans le head, sur chaque page.
- Le chargeur est asynchrone par défaut. N’ajoutez pas de paramètre defer/async qui modifierait le moment de son exécution : les attributs fournis sont ceux que nous avons testés.
- Installez-le une seule fois, très exactement. Deux exemplaires du chargeur sur une même page ne doublent pas vos données : ils doublent les requêtes et compliquent le débogage.
WordPress
Sur WordPress, l’installation la plus propre évite de modifier le thème. Utilisez une extension d’insertion de scripts dans l’en-tête — n’importe laquelle parmi les plus connues fera l’affaire —, collez le chargeur dans le champ « scripts dans le head », enregistrez, puis videz tout cache de pages. Si vous ne souhaitez pas utiliser d’extension, ajoutez un petit fichier mu-plugin qui se raccorde à wp_head avec une priorité de 5, afin que le chargeur soit inséré avant les balises d’analytics. Ne le collez pas dans le corps d’une page ou d’un article : WordPress supprimera la balise script lors du nettoyage du contenu.
Une vérification propre à WordPress : si vous utilisez un cache de pages complètes (LiteSpeed, WP Rocket, W3 Total Cache), purgez-le après l’installation. Le HTML mis en cache avant l’installation ne contiendra pas le chargeur.
Shopify
Shopify place le HTML du thème dans theme.liquid. Dans votre interface d’administration Shopify, ouvrez Boutique en ligne → Thèmes → Actions → Modifier le code → theme.liquid, puis collez le chargeur juste avant la balise de fermeture </head>. Enregistrez. C’est tout : aucune application ni aucun script de paiement n’est nécessaire — le paiement n’entre de toute façon pas dans le périmètre de l’identification au niveau de l’entreprise.
Commencez par dupliquer le thème
Avant de modifier theme.liquid, utilisez Actions → Dupliquer. Si quelque chose se passe mal, vous pourrez revenir en arrière en un clic. Cette habitude de cinq secondes a sauvé toutes les équipes Shopify auxquelles elle a été conseillée.
Webflow
Webflow → Paramètres du site → Code personnalisé → Code du head. Collez le chargeur. Enregistrez. Publiez le site. Le code du head s’applique globalement à toutes les pages, ce qui est exactement l’objectif recherché. Ne collez pas le chargeur dans un élément d’intégration au niveau d’une page : seule cette page sera suivie.
Google Tag Manager
GTM fonctionne, avec deux réserves. Premièrement, utilisez une balise HTML personnalisée avec le déclencheur « Toutes les pages », afin que le chargeur s’exécute à chaque page vue. Deuxièmement, attribuez-lui une priorité suffisamment élevée pour qu’elle se déclenche avant les autres balises d’analytics susceptibles de ralentir la charge utile initiale. Les utilisateurs de GTM superposent souvent quatre ou cinq balises dans le head. Le chargeur est léger, mais l’ordre de déclenchement des balises compte si vous voulez identifier l’entreprise dès la première requête.
Réserve concernant le mode Consentement : si GTM se trouve derrière une bannière de consentement qui ne déclenche les balises d’analytics qu’après acceptation, ne soumettez pas l’identification au niveau de l’entreprise à la même condition. Elle n’utilise pas de cookies et ne stocke aucune donnée sur l’appareil utilisé pour la visite ; elle ne requiert donc pas le même dispositif de consentement. Configurez la balise pour qu’elle se déclenche immédiatement, en même temps que vos balises strictement nécessaires.
HTML simple et stacks sur mesure
Pour un site développé sur mesure ou un framework que nous n’avons pas cité, collez le chargeur dans l’élément <head> de votre modèle de base, c’est-à-dire le fichier rendu sur chaque page. Relancez la compilation et le déploiement. Avec les générateurs de sites statiques, le chargeur doit se trouver dans le fichier de mise en page global du site (dans Next.js, il s’agit d’un <Script> dans la mise en page au niveau de l’application avec strategy="afterInteractive" ; dans Astro, du composant <BaseHead> ; dans 11ty, du fragment de modèle de base). Si vous l’avez ajouté comme script au niveau d’un composant, seules les pages qui incluent ce composant transmettront des données.
Applications monopages : le seul piège
Dans une SPA, la première page vue est capturée par le chargeur lors du chargement initial. Du point de vue du navigateur, les navigations ultérieures côté client ne constituent pas automatiquement de nouvelles pages vues. Par défaut, notre chargeur écoute l’API History : les retours en arrière, les avancées et les navigations fondées sur pushState sont donc enregistrés comme de nouvelles pages vues sans intervention de votre part. Si votre SPA utilise un routeur non standard qui contourne l’API History — c’est rare, mais cela arrive —, appelez la petite fonction de page vue documentée à chaque changement de route : trois lignes de code, indiquées dans la documentation.
Vérifiez l’installation en deux minutes
La vérification n’est pas facultative. Effectuez-la avant de fermer l’onglet depuis lequel vous avez installé le chargeur : repérer une installation défaillante cinq minutes après l’avoir collé est simple ; s’en apercevoir cinq jours plus tard ne l’est pas.
- Ouvrez votre site dans une fenêtre privée ou de navigation privée, afin que des ressources en cache ne faussent pas la vérification.
- Ouvrez les outils de développement → onglet Réseau, puis filtrez avec « l5e » ou le chemin du chargeur.
- Rechargez la page. Vous devriez voir une requête vers le chargeur, puis une petite balise d’identification. Toutes deux doivent renvoyer le statut 200. Les en-têtes de réponse du chargeur doivent inclure une directive cache-control avec s-maxage et stale-while-revalidate.
- Accédez à une deuxième page. Vous devriez voir une nouvelle balise d’identification se déclencher, sans nouveau téléchargement du chargeur — il renverra 304.
- Revenez au tableau de bord lead.box, ouvrez le flux des visites en direct et vérifiez que votre visite de test apparaît. Si c’est le cas, l’installation est terminée.
Erreurs courantes : le tableau à vérifier en premier
| Symptôme | Cause probable | Correction |
|---|---|---|
| Aucune visite en direct | Chargeur absent du head ou placé dans le mauvais modèle | Déplacer le chargeur dans le modèle de head global du site |
| Visites en direct provenant d’une seule section | Chargeur placé dans une intégration au niveau d’une page, et non globalement | Le déplacer dans le head global ou l’en-tête du thème |
| Le chargeur se lance, mais aucune balise d’identification | Bannière de consentement bloquant trop strictement les scripts tiers | Configurer la bannière pour autoriser les scripts strictement nécessaires ; le chargeur ne nécessite pas de consentement |
| Deux balises par page vue | Chargeur installé deux fois (thème + extension/balise) | En supprimer une |
| Premier affichage lent après l’installation | Chargeur placé avant le CSS critique | Vérifier que l’attribut async est présent ; le placer après le préchargement du CSS critique |
| La SPA ne transmet que la première page | Routeur personnalisé contournant l’API History | Appeler la fonction pageview() documentée à chaque changement de route |
| HTML obsolète servi sans le chargeur | Cache de pages complètes non purgé après l’installation | Purger le cache ; vérifier en navigation privée |
Remarque sur les performances : chargeur mis en cache en périphérie
Le chargeur est servi depuis un chemin propriétaire, transmis par proxy à notre cache en périphérie avec s-maxage=300 et stale-while-revalidate. En pratique, cela signifie qu’il est récupéré une fois toutes les cinq minutes par point de présence périphérique, puis servi depuis le cache pour chaque visite suivante. Son poids en octets et son impact bloquant sont suffisamment faibles pour que nous déconseillions de lui superposer une logique de chargement supplémentaire.
Quand demander de l’aide
Si vous avez suivi les étapes de vérification et que quelque chose ne fonctionne toujours pas correctement, nous préférons que vous nous contactiez au bout de dix minutes plutôt qu’au bout de dix jours. Préparez trois éléments : l’URL du site, une capture d’écran de l’onglet Réseau des outils de développement filtré selon le chemin du chargeur et le nom de la plateforme sur laquelle vous l’avez installé. Cela suffit pour diagnostiquer presque tous les problèmes d’installation dès notre première réponse.
Published by
lead.box Team
More articles
Découvrez lead.box sur votre propre trafic
Démarrez gratuitement — sans carte bancaire, sans appel commercial obligatoire. Ou réservez une présentation guidée de 20 minutes.