Scripts tiers
Les scripts d'analytics et de tags sont du code applicatif, pas du contenu. Où les monter, quelle stratégie de chargement choisir, et pourquoi la CSP de l'éditeur compte.
Analytics, gestionnaires de tags, widgets de chat, bannières de consentement : tout cela appartient à votre application, pas au CMS.
La raison tient à la propriété. Une balise script est du code exécutable sur chaque page ; elle est relue, versionnée et déployée comme le reste. La mettre dans un champ éditable fait de « changer un titre » et « exécuter du JavaScript arbitraire en production » la même permission.
Analytics : utilisez les composants officiels
Pour Google Analytics et Tag Manager, n'écrivez pas la balise script à la main. @next/third-parties fournit des composants qui chargent le script et l'extrait d'initialisation, avec la bonne stratégie :
// app/[[...path]]/layout.tsx
import { GoogleAnalytics, GoogleTagManager } from "@next/third-parties/google";
const gaId = process.env.NEXT_PUBLIC_GA_ID?.trim();
const gtmId = process.env.NEXT_PUBLIC_GTM_ID?.trim();
// ...à l'intérieur de <body>
{gtmId ? <GoogleTagManager gtmId={gtmId} /> : null}
{gaId ? <GoogleAnalytics gaId={gaId} /> : null}Un simple <Script src="...gtag/js?id=..."> charge la bibliothèque mais ne la configure jamais : il manque l'appel inline gtag('config', id). C'est exactement le genre d'installation à moitié fonctionnelle que ces composants évitent.
Conditionner sur la variable d'environnement n'est pas une politesse : cela garde l'analytics hors des déploiements de prévisualisation et du développement local, pour que vos chiffres ne soient pas vos propres clics.
Tout le reste : next/script
Widgets de chat, bulles de support, intégrations sociales et balises ponctuelles n'ont pas de composant officiel. Ceux-là passent par next/script :
import Script from "next/script";
<Script src="https://widget.example.com/embed.js" strategy="lazyOnload" />Choisir une stratégie
La valeur par défaut est rarement la bonne :
afterInteractive- le défaut, correct pour l'analytics et les gestionnaires de tags. Charge une fois la page interactive.lazyOnload- pour tout ce dont le premier écran n'a pas besoin : chats, bulles de support, intégrations sociales.beforeInteractive- réservé aux scripts devant s'exécuter avant l'hydratation, comme une barrière de consentement qui décide si les autres scripts peuvent charger. Elle bloque : dernier recours.
Un widget de chat en afterInteractive concurrence votre propre hydratation sur le thread principal. C'est la façon la plus courante dont un site cmssy rapide devient lent : les pages sont statiques, la charge tierce ne l'est pas.
La CSP va les bloquer
C'est le point qui piège le plus.
createCmssyProxy applique une Content Security Policy pour que l'admin cmssy puisse encadrer votre site dans l'éditeur. Cette politique régit chaque script chargé par la page : un script tiers fraîchement ajouté peut donc être bloqué par un en-tête que vous n'avez pas écrit et dont vous ignorez peut-être l'existence.
Le symptôme est précis : le script ne s'exécute jamais, rien n'apparaît en erreur dans l'onglet réseau, et la console affiche une violation CSP nommant l'origine bloquée. Si un tag « ne se déclenche pas » en production mais marche en local, regardez la console avant le gestionnaire de tags.
Quand vous ajoutez un script d'une nouvelle origine, étendez la politique pour l'autoriser.
Consentement
Si vous conditionnez des scripts au consentement, la barrière est aussi du code applicatif et doit s'exécuter en premier. Placez la logique de consentement en beforeInteractive et chargez ensuite les scripts conditionnés.
Ne conditionnez pas en rendant la bannière comme un bloc CMS. Un éditeur dépubliant ce bloc retirerait silencieusement le mécanisme, pas le traçage - et le site continuerait de collecter des données sans rien à l'écran pour demander l'autorisation.
Ce qui relève du CMS à la place
Pas le script - la configuration. Un identifiant de mesure, un drapeau de campagne, un interrupteur de fonctionnalité sont des valeurs, et les valeurs sont sûres à éditer. Lisez-les depuis la configuration du site ou les champs personnalisés d'une page, et passez-les à un script que votre application possède.
La surface éditable reste ainsi « quel identifiant » plutôt que « quel code ».
Étapes suivantes
- Routes et pages - le middleware qui pose la CSP.
- SEO - les métadonnées, qui sont du contenu et non du code.
- Branding - les valeurs au niveau du site qu'il vaut la peine d'éditer.