Guides

Vous lancez Lighthouse, vous obtenez 100, vous livrez. Un mois plus tard, la Search Console vous annonce que cette même URL échoue à son évaluation Core Web Vitals. Rien n'a cassé entre-temps, et aucun des deux outils ne ment. Ils répondent à des questions différentes.

La documentation de Google trace la ligne sans ambiguïté. Les données labo sont des **« données collectées dans un environnement contrôlé, avec des réglages d'appareil et de réseau prédéfinis »**. Les données terrain sont des **« données collectées auprès des utilisateurs réels qui visitent votre site »**, ce qu'on appelle aussi le Real User Monitoring ; pour les Core Web Vitals, elles proviennent du Chrome User Experience Report.

Les données terrain sont une distribution, pas un nombre

La conséquence la plus importante est structurelle, et c'est celle qu'on manque le plus souvent : les données terrain **ne sont pas un nombre unique**. C'est une distribution. Les outils qui publient un score terrain Core Web Vitals retiennent le **75e centile** des chargements réels sur une fenêtre glissante de **28 jours**. Votre passage en labo, c'est un chargement, sur un appareil, sur une connexion. Votre score terrain, c'est ce que trois quarts de vos visiteurs ont vécu ou mieux, sur un mois.

Cela suffit à expliquer l'essentiel de l'écart. Mais les causes diffèrent selon la métrique, et savoir laquelle vous regardez indique où chercher.

Pourquoi ils divergent, métrique par métrique

Pour le [Largest Contentful Paint](/fr/articles/qu-est-ce-que-le-largest-contentful-paint-lcp), l'élément LCP lui-même peut ne pas être le même. La taille de la fenêtre d'affichage, le contenu personnalisé, les tests A/B, les polices installées et les fragments d'URL peuvent tous changer quel élément compte comme le plus grand. L'état du cache diffère aussi : un test labo démarre à froid, alors qu'un visiteur qui revient peut avoir des ressources en cache. Et la restauration depuis le cache de navigation avant/arrière est quasi instantanée pour un utilisateur réel, ce qu'aucun passage en labo ne reproduit.

• Labo : environnement contrôlé, appareil et réseau prédéfinis, un passage, reproductible
• Terrain : utilisateurs réels, appareils réels, connexions réelles, publié au 75e centile sur 28 jours glissants
• Métriques labo uniquement : Speed Index, Total Blocking Time (des diagnostics, pas des Core Web Vitals)
• État du cache, cache avant/arrière, fenêtre d'affichage et personnalisation diffèrent entre les deux
• Google : quand on dispose des deux, prioriser sur les données terrain

Pour l'[Interaction to Next Paint](/fr/articles/qu-est-ce-que-inp-interaction-to-next-paint), la raison est plus fondamentale : un test en labo **ne peut pas savoir quand un utilisateur choisira d'interagir**, ni avec quoi. C'est pour cela que le [Total Blocking Time](/fr/articles/qu-est-ce-que-le-total-blocking-time) existe comme approximation côté labo, et c'est aussi pourquoi cette approximation est imparfaite. Le TBT ne capture pas le délai de 300 ms au tap qui touche encore les pages sans fenêtre d'affichage optimisée pour mobile.

Pour le [Cumulative Layout Shift](/fr/articles/qu-est-ce-que-le-cls), le labo n'observe généralement que les décalages au-dessus de la ligne de flottaison et pendant le chargement. Les vrais utilisateurs font défiler la page. Les images et les iframes en chargement différé sans dimensions réservées décalent la page bien après que le test labo a cessé de regarder, et les publicités comme les blocs personnalisés se posent différemment pour chacun.

Celle que Google publie réellement

Alors sur laquelle agir ? Google répond clairement : **si vous disposez des deux, ce sont les données terrain qui doivent guider vos priorités.** Ce sont elles que rapporte l'évaluation Core Web Vitals, et les Core Web Vitals font partie du signal d'expérience de page. Un score labo au vert est une hypothèse. Les données terrain sont le verdict.

Le labo n'est pas inutile, il est diagnostique

Cela ne rend pas le labo inutile, et le croire est l'erreur symétrique. Les données terrain vous disent **qu'**un problème existe et pour qui ; elles ne vous diront pas quel script a bloqué le fil principal. Les outils de labo sont reproductibles et attribuables, ce qui est exactement ce qu'il faut une fois que le terrain a désigné une page. Certaines métriques, dont le [Speed Index](/fr/articles/qu-est-ce-que-le-speed-index) et le Total Blocking Time, n'existent qu'en labo et sont des diagnostics par construction.

L'angle mort : quand CrUX n'a rien sur vous

Une limite mérite d'être connue avant de s'appuyer entièrement sur le terrain. CrUX ne collecte que depuis Chrome, et pas depuis Chrome sur iOS ni depuis les WebView Android. Il ne compte que les utilisateurs qui ont activé les rapports de statistiques d'utilisation, synchronisent leur historique de navigation et n'ont pas défini de phrase secrète de synchronisation. La page doit être publiquement découvrable, et elle doit franchir un nombre minimal de visiteurs que Google ne publie délibérément pas. Une page sous ce seuil n'a tout simplement aucune donnée terrain, et un site jeune ou à faible trafic peut n'en avoir nulle part. C'est le manque que comble votre propre Real User Monitoring : vos pages, tous les navigateurs, dès la première visite et non à partir de la millième.

L'ordre qui fonctionne

L'ordre pratique est donc : lire le terrain pour décider **où** travailler, utiliser le labo pour trouver **quoi** changer, puis revenir au terrain vingt-huit jours plus tard pour vérifier que cela a bougé. Tout le reste revient à optimiser un chiffre que personne ne vit. Pour les leviers concrets une fois que vous savez où creuser, commencez par [améliorer vos Core Web Vitals](/fr/articles/ameliorer-les-core-web-vitals).