{"id":31594,"date":"2025-12-05T10:50:50","date_gmt":"2025-12-05T10:50:50","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/monitoring-client-side-routing-frameworks-spa-csr-ssr-hybrid\/"},"modified":"2026-05-21T23:17:30","modified_gmt":"2026-05-21T23:17:30","slug":"monitoring-client-side-routing-frameworks-spa-csr-ssr-hybrid","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/monitoring-client-side-routing-frameworks-spa-csr-ssr-hybrid\/","title":{"rendered":"Surveillance du routage c\u00f4t\u00e9 client : SPA, CSR & hybride"},"content":{"rendered":"

\"SurveillanceLes applications web modernes ont d\u00e9plac\u00e9 leur centre de gravit\u00e9. La page n’est plus le syst\u00e8me \u2014 c’est le runtime. Des frameworks comme React, Angular, Vue, Next.js, SvelteKit, Remix et Nuxt traitent le HTML comme un chargeur de d\u00e9marrage, et la v\u00e9ritable application n’\u00e9merge qu’apr\u00e8s l’hydratation, le routage, la r\u00e9cup\u00e9ration des donn\u00e9es et les rerenderings continus. Ce que les utilisateurs voient d\u00e9pend enti\u00e8rement de l’ex\u00e9cution JavaScript, et non du balisage statique.<\/p>\n

Les \u00e9quipes d\u00e9couvrent g\u00e9n\u00e9ralement ce changement lorsque l’interface semble se charger mais que rien ne fonctionne. Les boutons ne r\u00e9pondent pas, les panneaux restent vides et les flux se cassent sans erreur serveur \u00e9vidente. Le routeur \u2014 pas la page \u2014 d\u00e9termine si l’application est r\u00e9ellement utilisable, pourtant la plupart des outils de surveillance ne l’observent jamais.<\/p>\n

Si vous vous fiez \u00e0 une surveillance centr\u00e9e sur la page pour des architectures SPA, CSR, SSR ou hybrides, vous regardez la coquille au lieu de l’application. Cet article explique comment surveiller correctement les syst\u00e8mes dirig\u00e9s par le routage, et pourquoi les flux synth\u00e9tiques et le RUM doivent suivre le runtime plut\u00f4t que le HTML initial.<\/p>\n

Surveiller apr\u00e8s le chargement de la page<\/h2>\n

Dans une application multi-page, le cycle de vie de la page \u00e9tait le cycle de vie de l’application. Vous mesuriez le temps de chargement, la disponibilit\u00e9 du DOM, les erreurs et les r\u00e9ponses serveur. Les d\u00e9pendances \u00e9taient stables et visibles.<\/p>\n

Le routage c\u00f4t\u00e9 client casse cette hypoth\u00e8se. Le premier chargement n’est qu’un parmi d’autres. Les vraies erreurs se produisent d\u00e9sormais dans des \u00e9tats que les navigateurs ne r\u00e9initialisent pas : arbres de composants dynamiques, donn\u00e9es accumul\u00e9es dans le store, caches de fetch, guards de route, feature flags et transitions entre une \u00ab page \u00bb logique et une autre sans rechargement d’URL. Si votre surveillance s’arr\u00eate \u00e0 DOMContentLoaded, vous manquez 90 % du runtime.<\/p>\n

La question op\u00e9rationnelle devient : comment mesurer une application qui ne \u00ab recommence \u00bb plus quand l’utilisateur change d’\u00e9cran ?<\/p>\n

La r\u00e9ponse est : vous suivez le routeur.<\/p>\n

Pourquoi le routage c\u00f4t\u00e9 client casse les mod\u00e8les traditionnels de surveillance<\/h2>\n

Les frameworks de routage interceptent les \u00e9v\u00e9nements de navigation, rendent de nouvelles vues en place et effectuent des appels asynchrones vers des services distants. L’URL peut changer, ou pas. Le DOM peut se mettre \u00e0 jour partiellement, ou se rerender compl\u00e8tement. Il n’y a pas de concept de \u00ab page compl\u00e8te \u00bb. Il y a seulement \u00ab vue mont\u00e9e \u00bb, \u00ab donn\u00e9es r\u00e9solues \u00bb et \u00ab store mis \u00e0 jour \u00bb.<\/p>\n

Les contr\u00f4les traditionnels de disponibilit\u00e9 supposent :<\/p>\n