Comment mesurer l’audience d’un site quand la page vue par le visiteur n’est jamais générée par WordPress lui-même ? C’est la question posée par une jeune entreprise éditrice d’un logiciel de gestion de plannings pour indépendants, dont le site marketing reposait sur un front Nuxt consommant l’API REST, sans qu’aucune page HTML ne transite jamais par le serveur WordPress vu du visiteur.
Google Analytics a été écarté d’emblée, non pas pour des raisons techniques mais parce que la startup voulait éviter tout dépôt de cookie tiers nécessitant un bandeau de consentement complexe, un choix cohérent avec son positionnement auprès d’une clientèle elle-même soucieuse du RGPD. Deux alternatives ont été retenues pour comparaison : Plausible et Matomo.
Pourquoi la question ne se pose pas comme sur un site classique
Sur un thème WordPress traditionnel, poser un script de mesure d’audience revient à l’insérer dans le <head> via wp_head, une opération triviale documentée depuis des années. En headless, ce hook ne concerne que l’administration : le visiteur du site public ne charge jamais le thème WordPress, donc jamais ce script. La mesure doit être posée directement dans le code du front, ce qui change la nature du travail à effectuer.
La checklist retenue
- Confirmer que le script se charge côté front, pas côté admin. Le script Plausible ou le module de collecte Matomo doit être ajouté dans le gabarit racine du front Nuxt, jamais dans un hook WordPress qui ne s’exécuterait que dans l’administration.
- Vérifier le comportement en application à page unique. Le front étant une application à navigation côté client après le premier chargement, un changement de route ne déclenche pas nativement un nouvel événement de vue de page. Il faut déclencher manuellement l’événement à chaque changement de route via le routeur de l’application.
- Choisir entre auto-hébergement et service géré. Matomo peut être installé sur un serveur propre à l’entreprise, ce qui garantit un contrôle total sur l’hébergement des données mais ajoute une charge de maintenance. Plausible propose un service géré en Europe, plus simple à mettre en place mais avec une dépendance à un prestataire externe.
- Définir les événements personnalisés utiles au produit. Au-delà des vues de page, la startup voulait suivre des actions précises : clic sur le bouton d’essai gratuit, ouverture du calculateur de tarif intégré à la page d’accueil.
- Vérifier l’absence de cookie déposé. Plausible ne dépose aucun cookie par conception. Matomo peut fonctionner sans cookie en activant son mode de mesure sans témoin, une option à activer explicitement plutôt que le réglage par défaut.
- Documenter la configuration retenue. Une fois le choix fait, consigner dans le dépôt du front la liste des événements suivis et leur déclencheur, pour qu’un développeur qui rejoint le projet comprenne le système de mesure sans devoir l’inférer du code.
// front Nuxt, déclenchement d'un événement personnalisé Plausible
export function suivreEvenement(nom, propriete = {}) {
if (typeof window !== 'undefined' && window.plausible) {
window.plausible(nom, { props: propriete });
}
}
// dans le composant du bouton d'essai
suivreEvenement('essai_gratuit_clic', { plan: 'standard' });Le point qui a fait pencher la balance
Les deux outils respectaient la contrainte RGPD initiale, sans réelle différence sur ce plan précis. Le choix final s’est joué sur la question de l’hébergement : la startup préférait ne pas gérer elle-même un serveur Matomo supplémentaire, avec sa maintenance et ses mises à jour de sécurité, et a opté pour le service géré de Plausible, en acceptant la dépendance externe que cela impliquait.
Une checklist de mesure d’audience en headless doit d’abord répondre à une question simple : où s’exécute réellement le code qui affiche la page au visiteur ? Tant que cette question n’a pas de réponse claire, aucun script de suivi ne sera posé au bon endroit.
Ce que cette checklist ne couvre pas
Google Analytics n’a fait l’objet d’aucun test dans ce projet, le choix ayant été tranché en amont pour des raisons de positionnement produit plutôt que par comparaison technique. Une entreprise moins contrainte sur ce point trouverait sans doute des ressources abondantes ailleurs pour adapter Google Analytics à un front headless, un sujet volontairement laissé de côté ici.
En résumé
Mesurer l’audience d’un front headless demande de repenser où et comment le script de suivi s’exécute, bien plus que de choisir entre deux outils aux promesses proches. Une fois cette question de placement réglée, le reste du travail consiste surtout à définir des événements personnalisés qui aient un sens pour le produit, plutôt que de se limiter à un simple comptage de pages vues.
