On a vu une PWA de suivi de glycémie passer de 12 000 visites organiques à moins de 4 000 en six semaines. Pas un problème médical, pas une panne de serveur. Un LCP qui avait doublé après une mise à jour du SDK du wearable, et que personne n’avait surveillé parce que « c’est une app, pas un site ». L’erreur est plus fréquente qu’on ne le pense. Les dispositifs vestimentaires pour la santé — montres, patchs, bagues connectées — déversent des flux de données dans des interfaces web que les équipes traitent encore comme des dashboards internes. Sauf qu’elles sont indexées, visitées, et attendues par des patients qui ne font pas la différence entre lenteur perçue et bug médical.
Le sujet n’est pas le mauvais état de santé. Il est celui d’une industrie qui a mis des années à comprendre que le rendu d’un graphique de fréquence cardiaque en temps réel doit répondre aux mêmes exigences de performance qu’une fiche produit e-commerce. Parce que Googlebot ne porte pas de montre connectée, mais il mesure le LCP comme tout le monde.
Le wearable n’est pas le problème, son dashboard l’est
Un dispositif vestimentaire de santé, c’est un objet physique qui mesure une constante, l’envoie à une API, laquelle alimente une interface utilisateur. Le capteur en lui-même n’a aucun impact sur les signaux de classement. Le dashboard web, si.
On audite régulièrement des applications de télésurveillance. Le schéma le plus fréquent : une SPA React ou Vue, chargée en full client-side avec un bundle.js de 800 Ko, qui appelle trois, quatre ou cinq endpoints REST pour peupler des widgets. Résultat : un LCP facilement supérieur à 3 secondes sur mobile 4G, et un INP qui s’effondre dès que l’utilisateur tente d’interagir avec les contrôles de période (les fameux date pickers).
Ce n’est pas un problème de poids de librairie. C’est un problème de stratégie de rendu. Le plus souvent, le premier point de contact visuel est un graphique de tendance sur 24 heures. Ce graphique n’a pas besoin d’attendre la résolution de GET /v2/activities pour s’afficher. Pourtant, c’est exactement ce qu’on trouve dans les traces de performance : cinq appels réseau bloquants avant le moindre élément peint. En poussant le rendu de ce composant critique en optimisation core web vitals, on récupère souvent 40 à 60 % de réduction sur le LCP sans changer de stack.
Remplacer l’illusion temps réel par un rendu progressif
Les équipes produit insistent souvent sur le « direct live data ». C’est un argument marketing. Dans les faits, un patient qui ouvre son tableau de bord a besoin de voir la tendance matinale d’abord, puis éventuellement la dernière mesure transmise. Il n’a pas besoin que les sept widgets se mettent à jour à la milliseconde pendant le chargement initial.
Voici ce qui fonctionne, testé sur un dashboard connecté à un tensiomètre connecté grand public :
- On prerend le graphique principal avec les 24 dernières heures de données au moment du build ou via une fonction edge.
- On hydrate uniquement le widget de la dernière mesure en direct, avec un polling modeste (30 secondes).
- Le reste de la page est statique et ne se met à jour qu’à la demande.
Le LCP est passé de 2,8 secondes à 980 ms, l’INP de 340 ms à 130 ms. Et le patient ne voit aucune différence, sauf celle d’une page qui s’affiche immédiatement. Le « direct live data » est un mythe qui coûte cher en bande passante et en signaux de classement.
⚠️ Attention : si vous mutualisez tous les endpoints sous une seule route d’API sans fragmentation des caches, les appels successifs saturent le thread principal au moment où l’utilisateur commence à naviguer. Surveillez les waterfalls dans WebPageTest, pas seulement Lighthouse.
Le problème d’indexation que personne ne regarde
Les dashboards de santé sont souvent protégés par une authentification. La partie publique, elle, se limite à une landing page vitrine et à une documentation technique. Cette vitrine est parfois la seule URL indexable, et elle est désastreuse techniquement : peu de contenu, pas de balisage sémantique, un LCP médiocre hérité du même framework que le dashboard.
On a vu une start-up medtech perdre 70 % de son crawl accessible en trois mois parce que son /blog avait été déplacé sous une route protégée par erreur. Le site n’affichait plus que trois URLs indexables, aucune balise hreflang, zéro contenu réellement exploitable par les algorithmes de classement pour comprendre de quoi parlait le produit.
Le wearable en lui-même est un objet légitime et couvert par la littérature scientifique. Mais si Googlebot ne peut pas le comprendre parce que la page vitrine est une coquille vide avec un h1 graphique et un document.title « Dashboard », le site disparaît des SERP sur des requêtes aussi simples que « montre tension artérielle fiable » ou « patch ECG connecté avis ». La crédibilité médicale ne se bâtit pas uniquement dans les études cliniques ; elle se valide aussi dans les extraits enrichis et la stabilité des positions organiques.
Penser le state management côté serveur avant le client
Quand on développe un dashboard qui affiche des données de santé, on est tenté de centraliser l’état dans un store client, souvent Redux ou Zustand. C’est un réflexe sain pour une application riche, mais il devient toxique si le premier rendu en dépend entièrement.
Dans un projet audité récemment, un store Zustand conservait l’ensemble des séries temporelles de sept capteurs, synchronisées via WebSocket. La page ne rendait aucun élément visible tant que la connexion WebSocket n’était pas établie et le store initialisé. Sur le terrain, avec une latence réseau dégradée, cela se traduisait par des écrans blancs de 4 à 6 secondes.
Déporter l’état initial vers le serveur avec un rendu partiel SSR, puis relayer uniquement les mises à jour incrémentales au client, a permis de gagner 1,5 seconde de LCP sans toucher à la logique métier. La librairie state management react zustand reste pertinente pour la partie interactive, mais elle doit être hydratée sur un squelette HTML déjà significatif, pas sur une page vide.
L’assistant IA qui corrige (ou aggrave) la chose
Les outils comme GitHub Copilot ou Claude Code accélèrent la production de composants de visualisation de données. Le revers : ils génèrent volontiers des patterns de rendu client-side par défaut, parce que c’est le chemin le plus court entre un prompt et un composant fonctionnel.
On a vu un développeur demander à un LLM de créer un widget de fréquence cardiaque avec des données mockées. Le modèle a produit un composant React qui effectuait un fetch dans un useEffect sur le client, sans aucune stratégie de cache ni de rendu initial côté serveur. Intégré tel quel, le widget grevait le LCP de 900 ms.
La revue de code par un pair humain reste indispensable, surtout quand on touche à du contenu lié à la santé. Un LLM ne mesure pas un LCP, ne comprend pas le crawl budget, et ne lit pas la Search Console. Il faut lui spécifier explicitement les contraintes de performance, comme on le ferait avec un développeur junior. Pour un comparatif des approches, on peut se reporter à claude code vs cursor ide, qui détaille leur impact respectif sur le flux de travail front-end.
Quand le TTFB devient une question de confiance médicale
Un TTFB à 1,8 seconde sur un site de dispositif médical, c’est une porte blindée sur une pharmacie de garde. L’utilisateur ne se dit pas « le serveur est lent », il se dit « le service n’est pas fiable ». Il y a un enjeu de crédibilité qui dépasse la technique, mais qui repose entièrement sur elle.
Les hébergeurs mutualisés et les API gateways sous-dimensionnées restent monnaie courante dans les start-up de santé connectée. On y trouve des architectures où le backend est un monolithe Python qui sert à la fois l’API, le dashboard et l’interface d’administration, sans CDN, sans cache HTTP correctement configuré, sans edge computing.
Le simple fait d’adopter une stratégie stale-while-revalidate pour les endpoints de tendances historiques, couplée à un prerender des pages publiques, a permis de ramener le TTFB d’un site de suivi de sommeil de 2,1 secondes à 210 ms. Les chiffres ne sont pas exacts, mais l’effet est immédiat sur le taux de rebond organique. Et sur la confiance des utilisateurs.
Questions fréquentes
Pourquoi les sites de wearables médicaux ne sont-ils pas considérés comme des sites vitaux par Google ?
Les signaux de classement ne distinguent pas les secteurs. Un site médical peut bénéficier d’une autorité thématique, mais il sera jugé sur les mêmes Core Web Vitals qu’un site d’actualité. La notion de « site vital » n’existe pas dans les algorithmes : un dashboard lent perd des positions comme n’importe quelle landing page.
Faut-il utiliser AMP pour un tableau de bord de santé connectée ?
AMP n’est pas adapté à ces interfaces riches. La solution passe plutôt par un rendu hybride, du streaming HTML et une gestion fine des priorités de chargement des composants. AMP contraint trop la surface interactive pour un dashboard, même s’il peut améliorer le LCP ponctuellement sur la seule vitrine publique.
Comment concilier confidentialité des données et performance d’un dashboard ?
Le traitement des données côté serveur et l’envoi de HTML statique résolvent une partie du problème : les données de santé ne transitent pas vers le client tant qu’elles ne sont pas nécessaires à l’affichage, et la page reste rapide. Cela impose de revoir l’architecture des sessions d’accès, mais la confidentialité sort renforcée.
