Voir combien de personnes naviguent sur votre site en ce moment même ressemble à une fonctionnalité de tableau de bord premium, mais on peut la mettre en place avec des éléments que vous possédez déjà. La partie intéressante n’est pas le compteur : c’est d’interpréter le signal sans se tromper. Passons au montage réel.
Étape 1 : choisissez la source de données avant de toucher à quoi que ce soit
Il existe trois voies et elles ne sont pas interchangeables :
- Balise du fournisseur d’analytique (GA4, Matomo, Plausible). Zéro développement, mais la latence d’agrégation fait que le « temps réel » de GA4 n’est pas instantané : selon la documentation officielle de Google, les rapports en temps réel reflètent l’activité des 30 dernières minutes et les données peuvent mettre du temps à se consolider.
- Logs du serveur. C’est la donnée la plus fidèle, elle inclut les bots et les téléchargements que le JavaScript ne voit jamais. Nécessite un accès au log et un parseur.
- Streaming depuis le site lui-même (WebSocket ou Server-Sent Events). Contrôle total, mais c’est vous qui assumez le coût d’infrastructure.
Pour une PME avec WordPress, la voie 1 suffit. Pour auditer le crawl des bots ou les pics de trafic anormaux, la 2 est obligatoire.
Étape 2 : activez la vue en direct dans GA4 et vérifiez-la
- Allez dans Administrer → Flux de données et confirmez que la balise se déclenche (extension de navigateur ou rapport DebugView).
- Ouvrez Rapports → Temps réel et naviguez vous-même sur une URL avec le paramètre ?utm_source=test.
- Vérifiez que vous apparaissez avec cette source. Si vous n’apparaissez pas, le problème se situe presque toujours dans une condition de consentement qui bloque la balise, pas dans la balise.
L’erreur que presque tout le monde commet la première fois
Un cas typique : vous installez le snippet dans l’en-tête, le compteur d’utilisateurs actifs affiche 0 et vous paniquez. En réalité, le blocage des cookies a rejeté le script ou un plugin de cache sert du HTML avec la balise dupliquée et désactivée. Avant de réinstaller quoi que ce soit, ouvrez la console du navigateur et cherchez la requête vers collect ou vers l’endpoint de votre outil. Si elle n’apparaît pas, le problème vient du chargement ; si elle apparaît avec un 204, la mesure fonctionne et la défaillance se trouve dans le filtrage interne.
Étape 3 : montez votre propre tableau de bord avec les logs (facultatif mais révélateur)
Si vous voulez voir les requêtes par seconde sans dépendre de tiers, une commande de terminal suffit pour commencer :
tail -f /var/log/nginx/access.log | awk ‘{print $1}’ | sort | uniq -c | sort -rn | head
Cela vous donne les IP avec le plus de requêtes dans la fenêtre que vous laissez ouverte. Cela sert à détecter un scraper agressif en quelques secondes, mais ne distingue pas les utilisateurs des bots ni les sessions : pour cela, il vous faut une agrégation par fenêtres de temps et un tableau de bord type Grafana lisant le log.
Ce que le temps réel ne vous dira pas
Ici, il convient d’être honnête : le trafic en direct ne sert pas à mesurer les conversions ni l’attribution. Un utilisateur qui achète peut être arrivé il y a trois jours par un autre canal. Il ne distingue pas non plus correctement une visite humaine d’un bot avec un user-agent falsifié. Et si votre site a beaucoup de trafic, rafraîchir chaque seconde consomme des ressources et vous montre du bruit, pas une tendance.
Selon des études du secteur de l’analytique web, une part significative du trafic classé comme « direct » dans les tableaux de bord en direct correspond à du trafic interne, à des outils de monitoring et à des liens mal étiquetés. Filtrez votre propre IP et celle de votre équipe avant de tirer des conclusions.
Checklist de configuration minimale
- Balise chargée sur tous les templates, y compris celui de remerciement.
- Filtre d’IP interne actif.
- Événement personnalisé pour les clics sur les CTA, visible aussi dans le rapport en direct.
- Alerte (email ou Slack) lorsque le flux de données s’arrête plus de 30 minutes : la chute de balise est plus fréquente que la chute du serveur.
- Revue hebdomadaire du log pour comparer avec l’outil : si les écarts sont importants, il y a des bots ou un blocage de scripts.
Avec cela, vous disposez d’un monitoring en direct fonctionnel et, surtout, vous savez quand vous méfier de ce que vous voyez.