Une refonte est mise en ligne et le LCP gagne 300 millisecondes. Pourtant, l’ancien site avait été mesuré pendant une campagne mobile, tandis que le nouveau bénéficie d’un trafic plus calme et d’une nouvelle CMP. Les chiffres sont exacts dans chaque fenêtre, mais leur comparaison raconte une histoire que les données ne permettent pas de défendre.
Le problème vient d’une baseline réduite à une capture du mois précédent. En pratique, elle fonctionne comme un contrat qui fixe populations, gabarits, métriques, versions, couverture et événements capables de rompre la série. Sans ce contrat, la refonte paraît meilleure ou pire selon la période choisie après coup.
La référence doit être signée avant la migration et accompagnée d’un plan d’analyse. Contre-intuitivement, davantage de semaines n’améliorent pas toujours la preuve : mélanger régimes de collecte incompatibles ou saisons différentes dilue la cohorte réellement comparable.
Vous apprendrez à construire cette référence et à la relier au SEO technique. Tous les nombres d’exemple sont fictifs et ne décrivent aucun projet client.
Définir ce que la refonte doit rendre comparable
Comparer des expériences, pas deux mois choisis après coup
La référence nomme les familles de pages, parcours, métriques et populations qui survivront à la migration. Elle documente les correspondances lorsque les URL, gabarits ou transitions changent. Une ancienne fiche et une nouvelle fiche peuvent être comparables malgré des routes différentes ; une URL identique peut cesser de l’être si son rôle ou son rendu est transformé.
Le diagnostic commence par les ruptures attendues : bibliothèque RUM, CMP, sampling, navigation SPA, cache, CDN, service worker et instrumentation de release. Chaque rupture crée soit une période de chevauchement, soit une nouvelle série. Recalculer silencieusement l’ancien historique est interdit.
Protéger les parcours plutôt qu’une moyenne de site
Une refonte peut améliorer le catalogue et dégrader la recherche, puis afficher une moyenne favorable grâce au poids du trafic. La baseline publie donc LCP, INP, CLS, erreurs, contenu principal et conversion par famille. Le verdict peut avancer une surface, contenir une autre et replier la troisième.
Le coût d’une référence faible apparaît le jour du go : équipes techniques et produit reconstruisent les cohortes pendant l’incident, tandis que le trafic reste exposé. Une table de correspondance testée en préproduction raccourcit ce délai et protège aussi crawl, indexation, canonicals et redirections.
Assembler RUM, releases, gabarits et couverture
Le collecteur RUM fournit distributions et attribution terrain ; le journal de release identifie l’expérience réellement servie ; le catalogue de gabarits donne la surface fonctionnelle ; la CMP et le sampling expliquent la couverture. CrUX situe une tendance publique, mais ne remplace ni la version de build ni la navigation logique interne.
Chaque observation porte route normalisée, gabarit, release, type de navigation, appareil et stratégie de rendu. Les URL complètes et contenus utilisateur sont exclus. Le retard d’ingestion, les doublons et les versions inconnues sont suivis, car une baisse de couverture peut fabriquer une amélioration au moment exact de la migration.
Construire les cohortes avant de voir le résultat
La cohorte principale est figée par gabarit, appareil, pays, type de navigation et exposition à la release. Les campagnes, promotions et incidents sont annotés selon une règle préalable. Une nouvelle segmentation après lecture reste exploratoire et ne remplace pas la décision signée.
Un double run contemporain réduit saisonnalité et changement de mix. Lorsque ce dispositif est impossible, une surface non migrée ou des périodes homologues fournissent un témoin imparfait dont la limite est écrite. Davantage de semaines ne compensent pas une définition incompatible.
Signer percentiles, volumes et gardes
Chaque percentile est accompagné du nombre d’observations, de la couverture, de la période et de la distribution par appareil. Les gardes couvrent erreurs, disponibilité, contenu, indexabilité, conversion et métriques non ciblées. Une page plus rapide mais vide ou non crawlable échoue.
La baseline distingue respect d’une frontière et amélioration relative. Une surface peut progresser tout en restant hors du niveau « bon », ou respecter le seuil sans battre l’ancienne. Les deux constats conduisent à des dettes et décisions différentes.
Traiter saison, consentement et changement de mix
Jour de semaine, campagne, canal, pays, appareil, stock et CMP peuvent déplacer la distribution indépendamment de la refonte. Le rapport publie le brut puis, si nécessaire, une repondération transparente. Une correction de la CMP ou du sampling ouvre une série distincte si aucun chevauchement ne permet de mesurer son effet.
Les signaux faibles sont une hausse des versions inconnues, une amélioration parallèle à une chute de couverture et la disparition d’un ancien gabarit lent dans « non classé ». Ils suspendent le verdict avant toute conclusion sur la migration.
Test contradictoire. Une famille non migrée est observée sur la même période. Si elle progresse autant, campagne ou mix d’audience deviennent des explications plausibles. Si seule la famille exposée réagit et que la décomposition montre le mécanisme attendu, l’attribution technique gagne en force.
Versionner l’instrumentation et le mapping
Les entrées du contrat sont version de document, bundle, gabarit, navigation et expérience ; ses sorties alimentent journalisation, cohorte et tableau de couverture. La CI vérifie le mapping sur des routes témoins. La QA compare HTML, canonical, liens, données structurées et DOM hydraté avant chaque canari.
Data possède intégrité et couverture, frontend l’instrumentation, SEO les gabarits et signaux d’indexation, produit les gardes métier, release management le monitoring et le rollback. Une dépendance non versionnée ou un repli non exercé bloque l’élargissement.
Décider par gabarit avec couverture visible
Le tableau commence par couverture, versions inconnues et volumes, puis montre les distributions. Le go est fractionné : élargir les surfaces saines, maintenir en canari celles qui manquent de données et replier celles qui régressent. Une moyenne globale n’efface jamais une interaction critique.
Le monitoring rapproche logs, TTFB, cache, rendu SSR ou SSG, hydratation et erreurs de navigation. Le verdict conserve l’intervalle observé, les exclusions et la prochaine fenêtre. Cette traçabilité évite de réinterpréter une même release à chaque réunion.
Pour qui et dans quels cas figer une baseline RUM
La démarche devient indispensable avant refonte, migration headless, changement de CMP, remplacement du collecteur ou modification profonde des gabarits. Elle convient aux équipes capables d’identifier la version réellement servie et de maintenir un mapping. Pour une correction locale sans rupture de mesure, une annotation de release et une cohorte ciblée peuvent suffire.
Éviter les baselines qui embellissent la migration
Choisir le mois précédent, supprimer les jours lents après lecture, comparer des moyennes sans gabarit, ignorer les pages non classées et cacher la couverture produisent une référence avantageuse mais inutilisable. La prévention consiste à signer règles d’exclusion, table de correspondance, volumes, gardes et décision par surface avant le résultat.
Plan d’action : signer la référence avant le premier canari
D’abord, geler le contrat et tester sa reprise
La première semaine inventorie collecteur, CMP, sampling, gabarits, navigations, métriques, couverture et incidents. Elle signe les périodes, exclusions et seuils, puis teste la requête de segmentation sur l’historique.
La deuxième semaine construit la table ancien-nouveau et l’exécute en préproduction. Les entrées inconnues sont corrigées ; HTML, canonicals, liens, routes et contenu essentiel sont vérifiés pour chaque famille.
La troisième semaine lance un double run ou un témoin contemporain, avec instrumentation, journalisation, monitoring, responsabilités et rollback. Le canari reste limité tant que couverture et versions ne sont pas stables.
La quatrième semaine produit le premier verdict par gabarit : élargir, maintenir, corriger ou replier. Le dossier conserve brut, distributions, mécanisme, métriques de garde et limites ; tout changement de contrat ouvre une nouvelle version.
Arbitrer chaque surface selon quatre branches explicites
Si la couverture et les versions sont stables, que la métrique ciblée progresse et que les gardes tiennent, alors le gabarit passe au palier suivant. Si la métrique progresse mais reste hors de la frontière attendue, le canari avance seulement avec une dette datée. Dans ce cas, le progrès n’est pas présenté comme conformité.
Si une interaction critique régresse, le gabarit est replié même lorsque la moyenne du site s’améliore. Si couverture, mapping ou instrumentation dérivent, le verdict devient « inconnu » : l’équipe corrige d’abord la mesure et conserve le palier. Cette branche évite qu’une absence de données soit interprétée comme absence de défaut.
La revue finale rassemble les responsables data, frontend, SEO, produit et exploitation. Chacun signe ses sorties : intégrité de la cohorte, mécanisme, HTML et indexabilité, garde métier, monitoring et rollback. Le journal de décision garde seuils, dépendances, exclusions et date de réexamen afin que la release suivante parte du même contrat.
- D’abord, signer versions, cohortes, périodes, mapping, couverture et gardes.
- Ensuite, tester la correspondance ancien-nouveau sur chaque parcours critique.
- Puis, exécuter un double run avec canari, monitoring et repli autonomes.
- Enfin, décider par gabarit et ouvrir une nouvelle série à toute rupture de mesure.
Signer le contrat de mesure avant le premier lot
Versionner tout ce qui change le dénominateur
Le contrat nomme bibliothèque RUM, version, options, événements, sampling, CMP, définition des gabarits et exclusions. Il conserve nombre d’observations, couverture et retard d’ingestion. Modifier une dimension crée une nouvelle version ; l’historique précédent reste visible au lieu d’être recalculé silencieusement.
Chaque mesure transporte une version de document, de bundle et de gabarit lorsque l’architecture le nécessite. Pendant un déploiement progressif, la date de release ne suffit pas : ancien et nouveau coexistent derrière un CDN, un feature flag ou un service worker. L’exposition réellement reçue devient la clé.
Le propriétaire de la baseline est nommé. Data contrôle intégrité et couverture, front vérifie l’instrumentation, SEO protège gabarits et routes, produit valide les critères business. Une référence sans responsable devient rapidement un fichier que chacun interprète différemment.
Le premier signal faible est une hausse des observations « version inconnue ». Le deuxième est une amélioration parallèle à une chute de couverture. Le troisième est un changement de distribution sans aucun mouvement des métriques techniques. Ces alertes suspendent le verdict avant d’évaluer la refonte.
Construire la table de correspondance entre ancien et nouveau
Une refonte renomme souvent les templates, regroupe des pages ou transforme une pagination en navigation dynamique. La table relie ancienne famille, nouvelle famille, intention, poids de trafic et règle d’exclusion. Les pages sans équivalent restent analysées séparément ; on ne les force pas dans une moyenne.
Comparer l’expérience, pas seulement l’URL
Deux routes différentes peuvent remplir la même fonction, tandis qu’une URL conservée peut changer profondément. La cohorte porte donc le rôle fonctionnel et le gabarit rendu. Pour une SPA, les transitions logiques sont documentées séparément des navigations complètes, car les API et CrUX ne les attribuent pas toujours comme l’utilisateur les perçoit.
Une amélioration globale accompagnée de la disparition d’un ancien gabarit lent constitue un avertissement, pas un succès. Une nouvelle famille trop large peut aussi mélanger pages simples et riches. Enfin, un volume « non classé » qui augmente après migration fait perdre la couverture au moment critique.
Le coût caché apparaît lors du go/no-go. Sans correspondance, les équipes débattent de moyennes plutôt que des parcours à restaurer. Une table testée en préproduction réduit ce délai et protège également analyses SEO, logs et redirections.
Choisir une période représentative sans absorber les incidents
La baseline couvre plusieurs cycles de trafic comparables, mais exclut uniquement les incidents documentés selon une règle écrite avant le résultat. Effacer les mauvais jours embellit l’ancien site ; conserver une panne exceptionnelle comme niveau normal fausse aussi le verdict.
Jour de semaine, campagne, promotion, saison, pays et appareil sont consignés. La comparaison principale peut utiliser des périodes homologues ou repondérer quelques dimensions. Le brut reste visible afin qu’un ajustement ne devienne jamais un chiffre opaque.
Une période de gel de définition précède le lancement. Si une correction critique du collecteur intervient, on organise un chevauchement pour mesurer l’écart entre versions. À défaut, le rapport ouvre une nouvelle série et interdit le calcul direct d’un gain.
Les frontières officielles restent des repères : LCP au plus à 2,5 secondes, INP au plus à 200 millisecondes et CLS au plus à 0,1 au p75, séparé entre mobile et ordinateur. La baseline ajoute une règle de non-régression propre à chaque famille, souvent plus stricte lorsque l’ancien site dispose d’une marge.
Organiser un double run plutôt qu’un avant-après fragile
Lorsque l’architecture le permet, un canari sert ancien et nouveau simultanément à des populations comparables. Cette contemporanéité réduit l’effet saison et campagne. La répartition reste stable, enregistrée et indépendante de l’appareil ou du canal, sauf si le pilote vise explicitement un segment.
Garder des métriques de protection
Le test surveille CWV, erreur, disponibilité, contenu principal, indexabilité, conversion et couverture RUM. Améliorer le LCP en retirant une information essentielle ou en servant un HTML incomplet ne constitue pas un succès. Le canari possède un rollback exercé et une progression 5 %, 20 %, 50 %, 100 % conditionnée à plusieurs fenêtres.
Si le double run est impossible, une cohorte contrôle non migrée ou une introduction par groupe peut aider. On documente les différences initiales et les événements concurrents. Une comparaison historique reste exploitable, mais son niveau de preuve est inférieur et son vocabulaire doit le refléter.
La décision sépare conformité et amélioration. La refonte peut respecter les seuils sans battre l’ancien site, ou améliorer nettement une métrique tout en restant hors frontière « bonne ». Dans le second cas, on reconnaît le progrès sans clôturer la dette.
Relier le canari à l’exploitation
Le contrat d’instrumentation reçoit en entrée version, route et gabarit ; sa sortie alimente une journalisation contrôlée par seuil de couverture. La CI et la QA valident JavaScript, HTML, canonicals, cache et invalidation avant chaque progression du canari.
Le monitoring rapproche logs, TTFB, rendu SSR ou SSG, hydratation et rollback dans le runbook. Crawl, indexation et comportement de Googlebot restent visibles afin qu’une amélioration RUM ne masque pas une régression SEO technique.
Rejouer un scénario entièrement simulé
Exemple concret entièrement simulé : un service fictif mesure 180 000 navigations mobiles sur quatre semaines avant refonte. Le LCP p75 produit vaut 2,62 secondes avec 54 % de couverture. Le canari reçoit fictivement 42 000 navigations et le contrôle contemporain 43 500 ; leurs couvertures sont 53 % et 55 %. Ces données pédagogiques ne représentent aucun client.
Le canari atteint 2,29 secondes contre 2,60 pour le contrôle. L’écart existe dans les mêmes familles d’appareils et réseaux. La décomposition montre un délai de découverte réduit parce que l’image héro se trouve dans le HTML initial. Le CLS reste stable, les erreurs n’augmentent pas et le contenu essentiel est identique.
Sur une autre famille, la nouvelle recherche affiche un INP fictif de 245 millisecondes contre 185. La moyenne de site reste meilleure grâce au catalogue, mais le go global est refusé. Le catalogue progresse à 50 %, tandis que la recherche retourne à la version précédente pour corriger une tâche JavaScript longue.
Cette simulation illustre la valeur de la baseline : autoriser une décision par surface plutôt qu’un verdict marketing unique. Elle ne transforme pas les écarts en gain de chiffre d’affaires et conserve volumes, distributions et mécanismes.
Guides complémentaires et sources primaires
La documentation Web Vitals de Google définit métriques, seuils et rôles du terrain et du laboratoire. Le dépôt web-vitals officiel décrit collecte, delta et attribution. La méthodologie CrUX précise éligibilité, page, origine et limites des SPA.
Pour préparer le suivi, consultez la méthode d’annotation des déploiements. Pour présenter les résultats sans extrapolation, utilisez l’analyse qui relie performance et conversion sans fausse causalité.
- Tester la table de correspondance avant la bascule.
- Contrôler couverture et version sur le double run.
- Conserver un rollback indépendant pour chaque gabarit.
Conclusion : décider depuis la requête de segmentation, pas depuis un score isolé
Une baseline RUM crédible fixe son contrat avant la refonte. Elle versionne la collecte, cartographie les familles et conserve couverture, volumes et distributions à côté des percentiles.
Le double run réduit les effets de saison et de campagne, mais ne remplace pas les métriques de garde. Une amélioration agrégée ne doit jamais racheter une régression sur un parcours critique.
Le verdict mature peut être partiel : avancer sur les gabarits sains, replier une surface et maintenir une dette explicite. Cette granularité protège mieux les utilisateurs qu’un go/no-go fondé sur une moyenne.
Pour signer vos cohortes, exercer le canari et construire un dossier avant-après opposable, notre accompagnement en SEO technique relie instrumentation, migration, critères de reprise et décisions par gabarit.
