Politique d’intégration de Partytown et Google Analytics (GA4)

Décision

Adopter Google Analytics 4 (GA4) pour l’analyse d’audience, avec l’identifiant de mesure G-WZ3RT34EZZ.
Introduire @astrojs/partytown et déporter l’exécution des scripts GA côté Web Worker via type="text/partytown".
Centraliser la sortie des balises analytics dans une couche commune (composant dédié sous Layout), au lieu d’une implémentation page par page.
Activer la mesure uniquement sur les URL de production, et la désactiver en local et en environnement de preview.
Limiter le périmètre initial à la mesure des pages vues ; la taxonomie des événements personnalisés sera définie dans un ADR séparé.
Lors de la première mise en place, ne pas surcharger de paramètres privacy supplémentaires dans gtag('config', ...) et démarrer en production avec les réglages par défaut de GA4.

Conventions d’implémentation

Élément	Règle
Exécution des scripts	Charger `gtag.js` avec `type="text/partytown"`.
Gestion de l’identifiant	Ne pas coder l’ID en dur dans les pages ; l’injecter via `PUBLIC_GA_MEASUREMENT_ID` (valeur initiale `G-WZ3RT34EZZ`).
Condition de sortie	Émettre les balises uniquement si `PROD` est vrai et qu’un ID de mesure est présent.
Emplacement	Centralisé dans le `Layout` partagé, pas au niveau de chaque page.
Périmètre des événements	Initialement `page_view` uniquement ; pas d’événements personnalisés arbitraires à ce stade.

Contexte

L’analyse d’audience n’est pas encore en place ; il est donc impossible d’observer les tendances d’acquisition, de consultation et de portée des contenus. En parallèle, l’exécution de scripts tiers sur le thread principal peut dégrader TTI/FID/INP.

Le projet centralise déjà les responsabilités du head dans le Layout Astro partagé ; l’analytics doit suivre le même modèle. Vu l’architecture multilingue, une implémentation par page augmenterait les risques d’incohérence.

Options

Option A : Charger gtag.js standard directement sur le thread principal
Option B : Exécuter gtag.js via @astrojs/partytown dans un Worker (retenue)
Option C : Ne pas adopter GA4 et passer à un autre outil analytics plus léger

Justification

Performance : Partytown déporte l’exécution tierce hors du thread principal.
Sécurité opérationnelle : La sortie centralisée évite les oublis de balises lors de l’ajout de pages.
Déploiement progressif : Démarrage avec les pages vues, puis extension des événements via un ADR dédié.
Auditabilité : Le gating production et l’hypothèse « démarrer avec les réglages GA par défaut » sont explicites.

Conséquences

Ajouter la dépendance @astrojs/partytown et configurer l’intégration dans astro.config.mjs.
Ajouter un composant analytics partagé (ou une responsabilité équivalente) référencé depuis Layout.
Définir et maintenir les règles d’exploitation de PUBLIC_GA_MEASUREMENT_ID.
Mettre à jour la politique de confidentialité pour documenter l’usage de GA4 et l’objectif de mesure.
Critères d’acceptation :
- Les balises GA ne sont émises qu’en production
- Les pages vues sont mesurables sur toutes les pages publiques
- La régression de performance du thread principal reste acceptable dans Lighthouse (ou équivalent)