Les Core Web Vitals sont les trois métriques par lesquelles Google résume l'expérience d'une page : le LCP pour la vitesse d'affichage du contenu principal, l'INP pour la réactivité aux clics, le CLS pour la stabilité visuelle. Tout le monde les connaît, beaucoup d'équipes les optimisent, et la documentation de Google est explicite sur leur statut : elles comptent pour le classement.
La question que ce chantier ne pose jamais est de savoir ce qu'il en reste quand le visiteur n'est pas un humain.
Le 14 septembre 2026, j'ai passé neuf pages à Lighthouse 13.4.0 et j'ai trouvé une réponse que je n'attendais pas dans l'outil lui-même. Lighthouse a discrètement ajouté une cinquième catégorie, à côté de Performance, Accessibilité, Bonnes pratiques et SEO : Agentic Browsing, la navigation par des agents. J'ai lu sa documentation et compté ses critères. Sur les trois Core Web Vitals, un seul y figure, et il y figure pour une raison qui n'a rien à voir avec celle qui l'a fait naître.
Ce que la SERP « core web vitals » raconte
Relevé du 14 septembre 2026 sur Google France, requête « core web vitals », 1 000 recherches par mois, concurrence faible, indice 33, CPC 12,78 EUR. C'est un volume confortable pour un sujet technique. Autour, le champ est maigre : « lcp seo » 30 recherches mensuelles, « temps de chargement site » 20. Le gros volume voisin, « pagespeed insights » à 12 100, est navigationnel : les gens y cherchent l'outil, pas une explication.
Huit résultats organiques, surmontés d'un Aperçu IA, suivis de questions associées, d'un bloc d'images et de recherches connexes.
Le podium est entièrement tenu par Google : la documentation Search Central, l'article vitals de web.dev, la page d'aide Search Console. Puis Cloudflare, l'agence Eficiens, Akamai, Fasterize, et une seconde page de web.dev. Le compte exact est donc de quatre pages de documentation Google, trois fournisseurs de CDN ou d'accélération web, et une seule agence.
Aucune des huit ne traite du versant génératif. Elles expliquent les seuils, les outils de mesure, les causes classiques d'un mauvais score. C'est un corpus purement définitionnel, et il est cohérent : la question qu'il traite est la seule qui existait avant que des robots se mettent à lire les pages pour en tirer des réponses.
Un détail mérite d'être relevé, parce qu'il fixe l'enjeu. L'Aperçu IA qui surmonte cette SERP affirme, dans sa section « Pourquoi c'est important ? », que « Google utilise ces scores dans son algorithme de classement des résultats de recherche ». C'est exact. Mais l'Aperçu IA est lui-même produit par un système qui ne classe pas des pages : il en extrait des passages. Le moteur qui répond en haut de l'écran explique un mécanisme dont il est, lui, le contre-exemple.
Ce que les Core Web Vitals mesurent exactement
La définition de Google est d'une précision qu'on néglige. Sa page de documentation ouvre ainsi : « Core Web Vitals is a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page ».
L'expérience utilisateur réelle. Pas une simulation, pas un score de laboratoire : ce que des gens ont vécu sur votre page. La page d'aide Search Console le répète en français, « en fonction de données d'utilisation réelles (parfois appelées données de champ) ».
Ces données de champ ont une source unique et documentée, le CrUX, le Chrome User Experience Report. Sa méthodologie publie les conditions qu'une visite doit remplir pour y entrer. Pour l'utilisateur, il y en a quatre, et la page les énumère sans ambiguïté :
Conditions d'admission d'un utilisateur au CrUX
-----------------------------------------------------------
1. Enable usage statistic reporting
(avoir activé l'envoi des statistiques d'usage)
2. Sync their browser history
(synchroniser son historique de navigation)
3. Not have a Sync passphrase set
(ne pas avoir défini de phrase secrète de synchro)
4. Use a supported platform
(Chrome bureau Windows, macOS, ChromeOS, Linux,
ou Chrome Android, Custom Tabs et WebAPK compris)
La page ajoute une exception explicite : Chrome sur iOS ne fournit aucune donnée au CrUX.
Regardez cette liste avec GPTBot en tête. Un robot d'exploration n'active pas l'envoi de statistiques d'usage, ne synchronise pas d'historique, n'a pas de compte, et n'utilise pas Chrome. Il remplit zéro des quatre conditions. Aucune de ses visites n'entre dans le CrUX, et le raisonnement vaut pour ClaudeBot, PerplexityBot et OAI-SearchBot.
Ce n'est pas une subtilité de collecte. C'est la conséquence de ce que les trois métriques mesurent. Le LCP est l'instant où le plus gros élément visible finit de s'afficher : un robot qui télécharge du HTML n'affiche rien. L'INP est le délai entre un clic et le repeint qui suit : un robot ne clique pas. Le CLS compte les déplacements d'éléments pendant le chargement : un robot n'a pas de fenêtre où quelque chose pourrait bouger.
Un moteur génératif ne dégrade donc pas vos Core Web Vitals, et ne les améliore pas non plus. Il est, littéralement, hors de leur champ de mesure.
Ce que les éditeurs de moteurs en disent
J'ai compté les termes de performance dans les quatre documentations qui régissent l'accès des robots, corps de page seulement, menus et pieds de page exclus. Aux trois métriques j'ai ajouté le TTFB, le temps jusqu'au premier octet, qui est la seule mesure de vitesse qu'un robot puisse réellement éprouver. Chaque zéro est accompagné d'un témoin non nul, qui prouve que le bon document a bien été récupéré.
document CWV LCP INP CLS TTFB témoin
-------------------------- --- --- --- --- ---- -------
Google, AI features 0 0 0 0 0 crawl 17
OpenAI, bots 0 0 0 0 0 crawl 11
Perplexity, crawlers 0 0 0 0 0 crawl 4
Anthropic, crawler 0 0 0 0 0 crawl 20
La page « AI features » de Google mérite une précision de méthode. Le moteur de recherche y trouve bien une occurrence de « Core Web Vitals », mais elle est dans la barre latérale de navigation, qui reproduit le sommaire entier de Search Central. Dans le corps du texte, la page ne contient ni « Core Web Vitals », ni « speed », ni aucune des trois métriques. Même remarque chez OpenAI, dont les uniques « speed » et « latency » sont deux entrées de menu qui renvoient à Codex et à l'optimisation de l'API, sans rapport avec l'exploration.
Quatre documentations, cinq termes, vingt cases, vingt zéros. Les éditeurs qui décrivent par ailleurs très précisément quels robots ils envoient, ce qu'ils lisent et comment les bloquer n'ont rien écrit sur la vitesse des pages qu'ils explorent.
La catégorie que Lighthouse a ajoutée
C'est en lisant les résultats bruts que la vraie nouvelle est apparue. Lighthouse 13.4.0 ne retourne plus quatre catégories mais cinq. La cinquième s'intitule Agentic Browsing et se décrit ainsi : « These checks ensure high-quality, browsable websites for AI agents and validate the correctness of WebMCP integrations. This category is still under development and subject to change ».
Sa documentation, sur Chrome for Developers, est encore plus nette : « The Agentic Browsing category evaluates how well your site is constructed for machine interaction ». L'interaction machine, par opposition à l'expérience humaine que mesure Performance. Les deux catégories cohabitent dans le même rapport et ne regardent pas la même chose.
Google y assume le caractère provisoire : la catégorie est expérimentale, elle exige Chrome 150 ou plus, ses contrôles WebMCP passent par un essai d'origine. Et elle refuse de produire une note unique : « Unlike other Lighthouse categories, the Agentic Browsing category does not have a weighted average score from 0 to 100. Because the standards for the agentic web are still emerging, the current focus is to gather data and provide actionable signals rather than a definitive ranking ». Ce que le rapport affiche est une fraction de contrôles réussis.
Trois familles de critères la composent. L'intégration WebMCP, qui expose les fonctions d'un site à un agent. L'accessibilité vue par la machine, avec une phrase qui résume tout le sujet : « Agents rely on the accessibility tree as their primary data model », l'arbre d'accessibilité est le modèle de données principal d'un agent, ce que la page appelle plus loin la « machine-eye view ». Et la stabilité, où l'on retrouve deux choses : le CLS, et la présence d'un llms.txt, décrit comme « a machine-readable summary at the domain root ».
J'ai compté les termes dans le corps de cette page :
terme occurrences
------------------------------- -----------
accessibility tree 3
WebMCP 9
Cumulative Layout Shift / CLS 2
llms.txt 1
Largest Contentful Paint / LCP 0
Interaction to Next Paint / INP 0
« Core Web Vitals » 0
« performance » 0
--- témoins --------------------------------
agentic 11
agent 16
audit 9
Voilà le résultat central de cet article. Dans la catégorie que Google consacre aux agents, le LCP et l'INP n'apparaissent pas une seule fois. L'expression « Core Web Vitals » non plus. Le mot « performance » non plus. Une seule des trois métriques passe la frontière, le CLS, et la raison qu'en donne la page n'est pas le confort visuel : « Layout shifts caused by ads, images without dimensions, or injected content can move elements between the time an agent identifies them and the time it attempts an interaction ». Le CLS survit parce qu'un élément qui bouge fait rater sa cible à un agent, pas parce qu'il gêne un lecteur.
La même métrique, conservée pour un motif entièrement différent. C'est la meilleure illustration que j'aie trouvée de ce que devient le SEO technique quand le destinataire change.
Ce que donnent neuf pages passées aux deux catégories
J'ai fait tourner Lighthouse 13.4.0, configuration bureau, sur les huit résultats organiques de la SERP. L'Aperçu IA cite par ailleurs deux sources absentes de ce top 8 : une page de skymooninfotech.com, que j'ai mesurée, et une vidéo YouTube, que j'ai écartée parce qu'une note de performance sur une page de lecture vidéo ne se compare à rien ici. Le corpus est donc de neuf pages. Colonnes : la note Performance, la fraction Agentic Browsing, et le CLS mesuré.
page (rang organique) perf. agents CLS
-------------------------------------- ----- ------ -----
1 developers.google.com (doc CWV) 0,71 0,03 0,789
2 web.dev/articles/vitals 0,91 0,49 0,056
3 support.google.com (Search Console) 0,95 0,33 0,004
4 cloudflare.com 1,00 1,00 .
5 eficiens.com 1,00 1,00 0,009
6 akamai.com 0,85 1,00 0,000
7 fasterize.com 0,94 0,50 0,000
8 web.dev/explore 0,91 0,93 0,118
. skymooninfotech.com (hors top 8) 0,87 0,85 0,222
Le point qui saute aux yeux est en haut du tableau. La page de documentation de Google qui explique les Core Web Vitals affiche 0,03 sur la catégorie agents et un CLS de 0,789, près de huit fois le seuil de 0,1 qu'elle recommande elle-même deux paragraphes plus bas.
Ce chiffre étant spectaculaire, je l'ai rejoué. Second passage, sur l'URL sans paramètre de langue : Performance 0,77, Agentic 0,11, CLS 0,44. Les valeurs bougent, et la documentation de Google prévient d'ailleurs que cette catégorie fluctue. Ce qui ne bouge pas, c'est le verdict : sur deux mesures indépendantes, la note agents reste sous 0,12, et le CLS reste entre quatre et huit fois au-dessus du seuil recommandé. Sur les huit pages où le CLS a pu être mesuré, trois dépassent 0,1.
Deuxième constat, sur l'ensemble du corpus : la corrélation entre la note Performance et la fraction Agentic Browsing vaut r = 0,561. Les deux vont vaguement dans le même sens, sans se confondre. Sur neuf pages, ce coefficient est indicatif et rien de plus, mais les cas extrêmes suffisent à faire le point : une page à 0,71 de performance tombe à 0,03 pour les agents, une autre à 0,85 de performance monte à 1,00. Optimiser l'une ne vous donne pas l'autre.
Le résultat que j'attendais le moins
L'Aperçu IA de cette SERP cite sept sources. Cinq sont des résultats organiques, aux rangs 1 à 5. Les rangs 6, 7 et 8 ne sont pas cités. J'ai donc deux groupes comparables, mesurés le même jour, sur la même question : six pages citées, les cinq premiers rangs plus skymooninfotech.com, contre trois pages classées mais ignorées.
Une observation en passant, qui prolonge mon relevé de la veille sur les URL canoniques : pour Cloudflare, l'Aperçu IA ne cite pas l'adresse qui se classe. Le résultat organique est la version française, en /fr-fr/, et la référence affichée pointe vers la version anglaise. Le moteur qui classe et le moteur qui cite ne servent pas la même adresse, sur la même SERP, au même instant.
groupe n perf. moyenne agents moyen
------------------------ --- ------------- ------------
cité par l'Aperçu IA 6 0,907 0,617
non cité 3 0,900 0,810
Les pages citées ne sont pas plus rapides que les pages ignorées. L'écart est de 0,7 point sur 100. Autant dire rien, et le résultat va dans le sens de l'hypothèse simple : l'Aperçu IA a cité le haut de la SERP, du rang 1 au rang 5, et la performance ne départage personne.
Le second chiffre est plus inconfortable, et c'est pour cela qu'il faut le publier. Sur la catégorie agents, les pages citées sont moins bonnes que les pages ignorées, 0,617 contre 0,810. Si j'avais espéré que la nouvelle catégorie de Lighthouse prédise la citation, la mesure me détrompe. Elle ne la prédit pas, et elle n'a jamais prétendu le faire : elle évalue un site pour un agent qui agit dessus, qui remplit un formulaire ou déclenche une fonction, pas pour un moteur qui vient y prélever un passage. Ce sont deux métiers différents, et le rappeler évite le contresens que cet article aurait pu fabriquer.
Ce que le robot vit vraiment de votre page
Reste la question pratique. Si les trois métriques sont hors sujet, qu'est-ce qu'un robot génératif éprouve en arrivant chez vous ? Deux choses seulement : un code de réponse, et un délai avant le premier octet.
J'ai mesuré les neuf pages avec l'agent de PerplexityBot, médiane de trois passages.
page code TTFB médian
------------------------------ ---- -----------
fasterize.com 200 50 ms
eficiens.com 200 56 ms
skymooninfotech.com 200 60 ms
support.google.com 200 229 ms
developers.google.com 200 311 ms
web.dev/explore 200 420 ms
web.dev/articles/vitals 200 900 ms
cloudflare.com 403 .
akamai.com 403 .
Un facteur dix-huit sépare la page la plus prompte de la plus lente, et toutes restent en dessous de la seconde. Sur ce corpus, le délai n'est pas le sujet.
Le code de réponse, lui, l'est. Deux des huit pages qui se classent pour « core web vitals » ne servent rien du tout à un robot venu de mon adresse. Une page à 403 a un LCP parfait et une valeur d'usage nulle : il n'y a pas de passage à en extraire.
Il faut dire honnêtement ce que ce 403 signifie, parce que la tentation serait d'y lire un blocage des IA. Sur cloudflare.com, j'ai obtenu 403 avec les six agents testés, y compris un Chrome parfaitement ordinaire : c'est un filtrage au niveau du réseau, lié à mon adresse, et non une décision visant les robots génératifs. Lighthouse, lancé depuis une autre infrastructure, a d'ailleurs noté la page 1,00 en performance.
Le cas d'Akamai est plus curieux et parfaitement stable, quatre passages dans chaque sens : 403 pour PerplexityBot, GPTBot, OAI-SearchBot et Googlebot, 403 pour un Chrome récent, et 200 pour ClaudeBot. Le robot déclaré entre, le navigateur reste dehors. Je ne sais pas expliquer la sélection, et je me garde d'en tirer une règle. Elle rappelle simplement que l'accès se décide agent par agent, sur des critères que personne ne publie, et qu'aucun score de performance ne vous préviendra du jour où votre hébergeur changera d'avis. C'est le sujet de mon article sur les logs serveur, qui restent la trace de première main la plus directe dont vous disposiez sur ces visites.
Auto-audit
La règle de la maison veut que je passe le site par le même instrument. Sur agencegeoparis.com, article du 13 septembre : Performance 0,97, Agentic Browsing 0,99, CLS 0,07, SEO 1,00, Bonnes pratiques 1,00.
La bonne note pour les agents ne récompense aucune audace : elle vient de HTML pré-rendu, d'un balisage sémantique sans acrobatie, d'images dimensionnées, et de la présence d'un llms.txt à la racine. Ce fichier vaut d'ailleurs une mise à jour de ce que j'écrivais en juillet dans llms.txt : faut-il vraiment en créer un. L'argument tenait, et il tient toujours : la documentation de Google Search dit ne pas s'en servir pour le classement. Mais Lighthouse en contrôle désormais la présence dans sa catégorie agents. Ce sont deux équipes et deux périmètres, ce n'est pas une contradiction, et cela ne transforme pas un fichier facultatif en levier de citation. Cela range simplement le llms.txt du côté des choses qu'un outil Google regarde, ce qui n'était pas vrai il y a deux mois.
Ce qu'il faut faire, dans l'ordre
Continuez à soigner vos Core Web Vitals. Rien ici ne dit le contraire. Google écrit noir sur blanc que « Core Web Vitals are used by our ranking systems », et le classement continue d'alimenter les moteurs génératifs en candidats. Un bon LCP reste un bon investissement, pour vos visiteurs d'abord.
Cessez d'en attendre un effet sur vos citations. Aucune documentation d'éditeur n'évoque la vitesse d'une page, et sur ce relevé les pages citées ne sont pas plus rapides que les autres. Si votre plan de visibilité générative repose sur un score PageSpeed, il repose sur une métrique qui ne vous voit pas.
Vérifiez ce que votre serveur répond aux robots, agent par agent. C'est la seule variable de cette famille qui décide vraiment. Un curl avec l'agent de GPTBot, de ClaudeBot et de PerplexityBot prend trois minutes et vous dira ce qu'aucun audit de performance ne vous dira.
Traitez l'arbre d'accessibilité comme un livrable technique. Du HTML sémantique, des libellés programmatiques sur les éléments interactifs, des rôles valides : c'est le « modèle de données principal » d'un agent selon Google, et c'est la partie de la nouvelle catégorie qui ne dépend d'aucune norme expérimentale.
Dimensionnez vos images et vos encarts. Le CLS est la seule des trois métriques à franchir la frontière, avec un bénéfice double : le confort de vos lecteurs d'un côté, la fiabilité du repérage d'un agent de l'autre.
Ce que cet article n'établit pas
Trois réserves, et la première est la plus importante.
Je n'ai pas mesuré de Core Web Vitals de champ. Les notes de ce relevé viennent de Lighthouse, donc du laboratoire, sur une configuration bureau unique et un seul passage par page hors le cas rejoué. Les données de champ exigent le CrUX, dont l'accès m'était fermé ce jour-là, quota d'API épuisé. Ce choix ne fragilise pas la thèse, qui porte sur la nature des métriques et sur le contenu d'une documentation, mais il interdit de lire mes colonnes comme un verdict CrUX sur ces sites.
La catégorie Agentic Browsing est expérimentale et Google le dit deux fois, dans l'outil et dans la documentation. Ses contrôles WebMCP dépendent d'un essai d'origine, ses résultats fluctuent, et mes deux passages sur la même page de Google l'ont montré, 0,03 puis 0,11. Rien ne garantit que cette catégorie existera sous cette forme dans six mois, ni qu'elle soit liée d'une quelconque façon au classement ou à la citation. Je la traite comme un indice de la direction que prend l'outillage de Google, pas comme un critère à optimiser.
Enfin, neuf pages sur une seule requête ne sont pas un échantillon. La comparaison cité contre non cité repose sur six pages d'un côté et trois de l'autre ; l'écart de 0,7 point qu'elle donne est un résultat nul, et un résultat nul sur neuf pages reste fragile. Il vaut par sa cohérence avec le reste : vingt zéros dans les documentations, aucune trace du LCP ni de l'INP dans la catégorie agents, et aucun mécanisme connu par lequel un robot pourrait éprouver ces métriques. Si la vitesse comptait pour la citation, il faudrait expliquer par quel canal.
Ce qu'il faut retenir
Les Core Web Vitals mesurent l'expérience réelle d'un humain, et leur définition le dit en toutes lettres. Leur source de données, le CrUX, impose quatre conditions qu'aucun robot ne remplit. Les trois métriques décrivent un affichage, un clic et un déplacement à l'écran, trois choses qui n'ont pas lieu quand un moteur génératif vous lit.
Ce constat aurait pu rester une déduction. Lighthouse en a fait une ligne de son rapport : à côté de Performance, une catégorie séparée pour les agents, où le LCP et l'INP sont absents, où le CLS subsiste pour une raison mécanique, et où apparaissent trois objets dont le SEO classique ne parlait pas, l'arbre d'accessibilité, le llms.txt et WebMCP.
Sur le terrain, la seule variable de cette famille qui change quelque chose est plus banale que toutes les autres : est-ce que votre serveur répond, et à qui. Deux des huit pages qui se classent pour « core web vitals » ne répondaient pas à un robot venu de chez moi. Leur note de performance ne l'avait signalé nulle part.
Chez Orbite, nous mesurons ce que les moteurs génératifs obtiennent réellement de vos pages, code de réponse et agent par agent compris. Si vous voulez savoir ce que les vôtres servent à GPTBot aujourd'hui : parlons de votre visibilité générative. Les termes employés ici sont définis dans le glossaire GEO.