Le WordPress d'aujourd'hui, décodé pour les développeurs

Éditeur de site (FSE)

Umami et un template de landing page événementielle, sans service tiers

Comment envoyer un événement de conversion vers une instance Umami auto-hébergée depuis un template dédié, sans dépendre d'un service d'analytics externe pour une agence événementielle.

Par WordPress Développement • 30 septembre 2026 • 7 min de lecture • Aucun commentaire
Umami et un template de landing page événementielle, sans service tiers

data-umami-event="inscription-salon" : cet unique attribut suffit, une fois le script Umami chargé, à faire remonter un événement de conversion vers une instance auto-hébergée. Pas de compte tiers à créer, pas de contrat de sous-traitance à signer, pas de bannière de consentement supplémentaire à afficher sur le site.

Pour une agence événementielle qui multiplie les landing pages de salons professionnels, ce niveau de simplicité change la donne. Chaque page doit mesurer ses inscriptions sans alourdir le poids de la page ni complexifier la conformité, et un template de landing page dédié dans l’éditeur de site permet justement d’industrialiser ce suivi sans y revenir à chaque nouvel événement.

Le problème : mesurer sans service tiers lourd

Les solutions d’analytics grand public imposent souvent un compte externe, des cookies traceurs et une politique de confidentialité à mettre à jour. Pour une simple landing page de salon, avec une durée de vie de quelques semaines, ce coût administratif est disproportionné par rapport au besoin réel : savoir combien de visiteurs ont cliqué sur le bouton d’inscription.

Umami, auto-hébergé sur un petit serveur dédié, répond à ce besoin précis. Il ne dépose pas de cookie identifiant par défaut, respecte le principe de minimisation des données, et s’intègre dans une page WordPress par un simple script chargé en defer.

Le snippet commenté

Le template landing-salon.html est créé depuis l’éditeur de site, avec un bloc Bouton dédié à l’inscription. L’attribut personnalisé se rajoute via un filtre côté PHP, plutôt qu’en modifiant le bloc à la main à chaque nouvelle page :

L'essentiel à retenir : Auto-héberger sa mesure de conversion ; Un événement, un attribut data ; Pas de cookie, pas de bannière
add_filter( 'render_block_core/button', function ( $contenu, $bloc ) {
	$classes = $bloc['attrs']['className'] ?? '';
	if ( false === strpos( $classes, 'suivi-inscription' ) ) {
		return $contenu;
	}

	$balises = new WP_HTML_Tag_Processor( $contenu );
	if ( $balises->next_tag( 'a' ) ) {
		$balises->set_attribute( 'data-umami-event', 'inscription-salon' );
	}

	return $balises->get_updated_html();
}, 10, 2 );

Le filtre render_block_core/button s’exécute au rendu de chaque bloc Bouton. La première ligne du corps le limite aux boutons portant la classe suivi-inscription, que l’éditeur ajoute depuis le champ « Classes CSS supplémentaires » : les autres boutons du site, par exemple celui du menu ou du pied de page, restent intacts. La classe WP_HTML_Tag_Processor, disponible depuis WordPress 6.2, modifie le balisage sans expression régulière, ce qui évite les cas limites d’un remplacement de texte sur du HTML.

Charger le script, uniquement où il sert

Le script de suivi ne doit apparaître que sur les pages qui l’utilisent. Le modèle de page landing-salon est la condition naturelle. On charge le script Umami depuis l’instance auto-hébergée, avec l’identifiant du site de mesure :

add_action( 'wp_enqueue_scripts', function () {
	if ( ! is_singular( 'page' ) || 'landing-salon' !== get_page_template_slug() ) {
		return;
	}

	wp_enqueue_script(
		'umami',
		'https://stats.exemple.fr/script.js',
		array(),
		null,
		array( 'strategy' => 'defer' )
	);
} );

add_filter( 'script_loader_tag', function ( $balise, $identifiant ) {
	if ( 'umami' !== $identifiant ) {
		return $balise;
	}
	return str_replace(
		' src=',
		' data-website-id="00000000-0000-0000-0000-000000000000" src=',
		$balise
	);
}, 10, 2 );

L’argument strategy de wp_enqueue_script() est pris en charge depuis WordPress 6.3 : il remplace l’ancienne astuce de modification de la balise pour ajouter defer. L’identifiant du site de mesure, ici un exemple factice, est celui que l’interface d’Umami affiche lors de la création du site. Le second filtre injecte cet attribut car wp_enqueue_script() n’offre pas de paramètre pour des attributs personnalisés. Adaptez l’adresse de l’instance : elle doit être servie en HTTPS, sinon les navigateurs bloqueront le chargement sur une page sécurisée.

Ce que l’attribut déclenche réellement

Lorsqu’un visiteur clique sur le bouton, le script lit l’attribut data-umami-event de l’élément cliqué et envoie à l’instance un événement portant ce nom. Aucune ligne de JavaScript à écrire côté site. L’événement apparaît ensuite dans le tableau de bord de l’instance, sous l’onglet des événements, avec son nombre d’occurrences par période. Umami propose également des attributs complémentaires pour associer des propriétés à un événement : consultez la documentation de la version que vous avez installée pour connaître la syntaxe exacte, qui a évolué entre les versions majeures.

Rien n’empêche de nommer les événements par salon, par exemple inscription-salon-lyon. Gardez toutefois une convention stable : un nom par action, suivi d’un suffixe court. Des noms improvisés d’une page à l’autre rendent les comparaisons impossibles quelques mois plus tard.

Un cas concret : cinq landing pages pour une tournée de salons

Une agence organise une tournée de cinq salons professionnels, avec une landing page par ville. Le modèle landing-salon.html contient la structure commune : présentation, programme, formulaire, bouton d’inscription. L’équipe duplique simplement une page, change les textes et la date, et le suivi est déjà en place : le bouton porte la classe de suivi, le script est chargé par le modèle, et les événements remontent sous le même nom. À la fin de la tournée, la comparaison du nombre d’inscriptions par page tient en une seule vue dans le tableau de bord.

Mesurer peu, mais toujours de la même manière, vaut mieux que tout mesurer différemment à chaque projet.

Les limites à connaître

  • L’absence de cookie ne dispense pas de réfléchir à la base légale : vérifiez auprès de votre conseil les conditions d’exemption de consentement applicables à la mesure d’audience, qui dépendent de la configuration et de l’usage des données.
  • Un bloqueur de publicités peut filtrer l’adresse du script, même sur un domaine personnel : les chiffres sont une mesure de tendance, pas un comptage exact.
  • Les événements ne disent rien sur l’origine de la personne qui clique : l’attribution fine des campagnes demande des paramètres d’adresse supplémentaires, à prévoir dans les liens de communication.
  • L’instance auto-hébergée doit être mise à jour et sauvegardée : le gain de confidentialité s’accompagne d’une charge d’exploitation.
  • Le nom de la classe de suivi est un contrat : si un rédacteur la retire, la mesure s’arrête sans message d’erreur.

Tester le suivi avant le lancement

Ouvrez la landing page dans une fenêtre de navigation privée, cliquez sur le bouton, puis vérifiez dans le tableau de bord qu’un événement apparaît. Dans les outils de développement du navigateur, l’onglet Réseau doit montrer une requête vers l’instance au chargement de la page, et une seconde au clic. Si seule la première apparaît, l’attribut n’est pas présent sur le lien : inspectez le HTML produit et vérifiez la classe du bouton.

Quand ne pas utiliser cette approche

Si le projet exige une analyse de parcours détaillée, avec des entonnoirs sur plusieurs pages, des segments ou des exports vers un outil de relation client, un outil d’analyse plus complet sera plus adapté. Et si personne dans l’équipe ne peut assurer l’exploitation d’une instance auto-hébergée, mieux vaut un service géré que des statistiques qui s’interrompent sans que personne ne s’en aperçoive.

Conclusion

Un attribut, un filtre de rendu et un script chargé sur un seul modèle : la mesure de conversion d’une landing page événementielle tient en quelques lignes, sans service tiers. La rigueur se joue ailleurs, dans la convention de nommage des événements, dans l’exploitation de l’instance et dans la vérification avant chaque lancement.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi