27 000 pages passées au crible. Les moteurs derrière les réponses, les deux cents caractères qui vous représentent, et les caches qui les figent.
Quand ChatGPT répond en s'appuyant sur le web, il ne va pas lire votre page. Il interroge un ou plusieurs moteurs, en retire un titre, une adresse et environ deux cents caractères, et travaille avec ça. La page elle-même n'est ouverte qu'à peine plus d'une fois sur 80, et uniquement en mode thinking. Le reste du temps, ce qui vous représente auprès du modèle tient dans trois lignes de texte fabriquées ailleurs, à un autre moment, et parfois servies à quelqu'un d'autre avant vous.
Cette étude démonte cette chaîne étage par étage, sur plus de mille deux cents réponses réelles capturées en juillet 2026. Qui ramène les résultats, ce que le modèle en voit exactement, combien de temps cette copie reste valable, et ce qui franchit la dernière marche pour devenir un lien visible dans la réponse.
Regards croisés avec Jérôme Salomon (Oncrawl)
Dans le code, chaque résultat embarquait jusqu'ici quel moteur l'avait ramené, grâce au champ result_source. Ce champ a disparu du flux. Nous travaillons sur une fenêtre qui vient de se fermer.
deprecated.Le champ result_source était porté par chaque objet résultat du flux serveur, avec quatre valeurs possibles : labrador, bright, oxylabs, serp. Sur les 1 249 réponses du corpus, 760 le portent et 489 ne le portent pas. Dernier flux étiqueté le 21 juillet, premier jour entièrement nu le 22 juillet.
Deux des quatre moteurs, bright et oxylabs, servent du Google scrapé. Nous l'avons établi en rejouant les mêmes requêtes sur les deux moteurs, puis en cherchant les URLs utilisées par ChatGPT dans leurs résultats. Une URL sur trois se retrouve dans le haut de page de Google. Une sur vingt seulement chez Bing. Et quand elle est dans Google, neuf titres sur dix sont identiques au caractère près, points de suspension compris, au même endroit.
Ce qui rend l'écart concluant, c'est que Google et Bing ne se recouvrent presque pas entre eux sur ces requêtes. Être présent dans l'un et pas dans l'autre devient donc un signal fort, et non une coïncidence de classement. Quant à labrador, il n'appartient ni à l'un ni à l'autre : c'est un index maison, pas un scrape.
Le même mouvement se lit côté shopping. Les tokens Google ont quitté les carrousels produits, mais l'identifiant Google du produit survit en clair dans la requête envoyée quand un utilisateur clique sur une fiche, accompagné cette fois d'un bloc chiffré.
Et la dépendance n'est pas résiduelle, elle est fonctionnelle. Les offres affichées dans les carrousels viennent bien du catalogue interne d'OpenAI, alimenté par les flux marchands. Mais ce catalogue ne sait pas tout faire : c'est Google qui reste l'oracle sur le meilleur prix, sur une partie des métadonnées produit et sur les avis. Autrement dit, OpenAI a rendu sa dépendance illisible dans le flux visible, tout en la gardant opérationnelle dans la couche qui ne se déclenche qu'au clic.
Le retrait tombe à deux jours du rejet de la plainte de Google contre SerpApi. Nous le signalons comme une concordance de calendrier, pas comme un mécanisme de cause à effet. Rien dans nos mesures ne permet de relier les deux, mais avouez que c'est troublant ;)
Le compte gratuit ne raisonne pas. Sur nos 493 réponses gratuites, pas une seule n'est passée en mode thinking. Or instant se contente d'une seule fan-out dans plus de huit cas sur dix, et n'ouvre jamais une page pour la lire.
Valeurs médianes par réponse. Le mode thinking va chercher neuf fois plus large, et parfois jusqu'à plusieurs centaines de pages sur une seule question.
En mode instant, sur un compte gratuit, quatre familles de questions et deux comportements seulement.
| Ce que vous demandez | labrador | Sans snippet | |
|---|---|---|---|
| Une information stable | 100 % | 0 % | 1 % |
| Un commerce, un lieu | 100 % | 0 % | 25 % |
| Un produit à acheter | 100 % | 0 % | 1 % |
| Informations live | 50 % | 50 % | 8 % |
La dernière ligne, ce sont les questions dont la réponse change dans la journée : qui a gagné le match hier, le classement du Masters en direct, la décision de la Fed aujourd'hui. Elles seules ouvrent la porte au Google scrapé. Tout le reste, et c'est la plus grande part de ce qu'on demande à ChatGPT, ne sort jamais de l'index maison.
Autrement dit, comprendre labrador n'est pas un sujet de spécialiste : c'est le fournisseur de presque tous les résultats, pour la population qui utilise réellement ChatGPT.
Résultats de recherche uniquement, snippets vides écartés du calcul de la part, sur 5 245 snippets et 424 réponses gratuites en mode instant. Information stable : 99,9 % labrador sur 2 136 snippets. Commerce et lieu : 100 % sur 310. Produit : 97,6 % sur 1 392. Informations live : 52,6 % labrador et 46,1 % Google sur 1 407. Le partage se lit sur la longueur du snippet servi, qui sépare les deux moteurs sans ambiguïté : au-delà de cent quatre-vingt-quinze caractères, la source est labrador dans 99,9 % des cas mesurés sur la période où le flux nommait encore son fournisseur.
La colonne des snippets manquants mérite d'être lue avec la première : sur les commerces et les lieux, un quart des résultats arrivent sans aucun snippet, avec seulement un titre et une adresse. La classe la mieux servie du tableau est aussi celle où le modèle reçoit le moins de matière.
Le tableau de gauche vaut pour le mode instant. Reposez les mêmes questions en thinking et le rapport se retourne, sur les quatre familles à la fois.
| La même question, en thinking | labrador | |
|---|---|---|
| Une information stable | 1 % | 99 % |
| Un commerce, un lieu | 3 % | 95 % |
| Un produit à acheter | 1 % | 99 % |
| Informations live | 0 % | 96 % |
En instant, la famille de la question décide de tout. En thinking, elle n'a plus aucun effet : les quatre valeurs se resserrent là où l'instant les étale de 50 à 100 %. Le commerce et le lieu changent même d'architecture entre les deux régimes. En instant, la réponse est portée par une carte, et la liste de résultats n'est qu'un rappel de liens dont un quart n'a aucun snippet. En thinking, la carte disparaît complètement, la liste redevient un vrai support de grounding, et la part de résultats sans snippet tombe de 25 % à 4 %.
Deux lectures circulent sur labrador, et nos mesures les écartent toutes les deux. La première en fait du Bing servi sous un autre nom, au motif du partenariat entre OpenAI et Microsoft. Une seule mesure suffit à la renverser : Bing coupe les titres qu'il affiche à soixante-quinze caractères, jamais un de plus, et un quart des titres labrador dépassent ce plafond. Le plus long que nous ayons vu en fait neuf cent soixante-dix-sept.
La longueur maximale des balises title affichées dans les pages de résultats de Bing est de soixante-quinze caractères, jamais un de plus. C'est ce plafond qui a permis d'écarter l'hypothèse selon laquelle labrador serait du Bing rebadgé : un quart des titres labrador le franchissent, ce qui est physiquement impossible pour un scrape de Bing.
Un cinquième pipeline, nommé bing, a été rapporté par d'autres chercheurs. Nous ne l'avons jamais observé, sur aucun compte, dans aucun régime, à aucune date. Notre hypothèse est qu'il ne serait exposé qu'aux comptes OpenAI Teams, du fait de la relation avec Microsoft.
Jérôme Salomon nous a transmis des captures de juin où ce pipeline apparaît massivement sur un compte Team, quand son propre compte gratuit n'en voit aucun le même jour (section collaboration).
Deux autres mesures vont dans le même sens. Les longueurs de snippet sont incompatibles : Bing coupe large et irrégulier, labrador s'arrête net à deux cent deux caractères, sur la totalité de ses résultats. Et le snippet labrador n'est le snippet d'aucun moteur : sur les URLs labrador qui ressortent aussi chez Google et chez Bing, la reprise de texte est nulle des deux côtés. La même mesure appliquée à bright retrouve le texte de Google quatre fois sur dix.
La seconde lecture fait de labrador le domaine réservé des éditeurs sous accord avec OpenAI. Nos mesures ne la soutiennent pas davantage. À moteur égal, la présence ou l'absence d'un accord de licence ne change rien au traitement : des centaines de médias hors accord reçoivent exactement le même format, la même longueur, la même fraîcheur que les partenaires.
Labrador se décrit mieux comme un repository d'accès immédiats.
Ce qui le définit n'est pas le contrat, c'est le fait qu'OpenAI l'interroge sans payer un tiers et sans attendre un scrape.
Toutes les parts de moteur de cette section sont calculées sur les seuls résultats de type search, sur les 373 réponses antérieures à la césure, et à partir du champ result_source lu tel quel, sans classifieur.
Ce filtre est indispensable. Compté tous types confondus, oxylabs semble représenter 12,7 % du mode instant. Sur les résultats de recherche seuls, il tombe à zéro : oxylabs est un pipeline d'actualités et rien d'autre, ses résultats sont tous de type news. Symétriquement, les résultats scientifiques et les forums sont servis à 100 % par labrador, si bien que les inclure gonfle mécaniquement sa part.
Valeurs exactes, résultats de recherche uniquement. Gratuit et instant : labrador 63,6 %, bright 34,7 %, serp 1,6 %, sur 1 793 résultats et 158 réponses. Payant et thinking : bright 74,6 %, labrador 23,6 %, serp 1,9 %, sur 16 407 résultats et 176 réponses.
Ces deux moyennes tiennent, mais elles dépendent entièrement de ce qu'on demande. Le batch qui les produit était composé pour moitié de questions d'actualité, la seule famille qui parte sur du Google. Sur un batch de questions stables, la part de labrador au gratuit monte à 100 %. Une moyenne de moteurs n'a donc de sens qu'accompagnée du mélange de questions qui l'a produite : c'est le tableau par famille, plus haut, qui décrit le comportement du système.
En mode instant, tout tient dans un titre et deux cents caractères. Et ces deux cents caractères ne sont pas ceux que vous croyez.
Une fois ses fan-outs lancés, ChatGPT reçoit une liste de résultats exactement comme celle que vous obtenez en tapant une requête dans un moteur : pour chaque page, un titre, un snippet et une URL. Rien de plus. C'est sur ce grounding, et sur lui seul, que le modèle s'appuie pour rédiger sa réponse et décider qui il va citer.
Autrement dit, ces trois champs sont votre unique représentation auprès du modèle dans l'immense majorité des cas. D'où l'importance de savoir précisément comment ils sont fabriqués.
Selon le moteur qui la ramène, une même page arrive avec son titre complet ou avec un titre déjà tronqué par une page de résultats. Via labrador, la balise title passe entière : un quart des titres dépasse soixante-quinze caractères et pratiquement aucun ne se termine par des points de suspension. Via Google scrapé, le titre est coupé à la longueur d'affichage d'un moteur, et près d'un sur quatre porte la marque de la coupe.
Voici les trois formats réellement transmis au modèle, du plus court au plus long. Même structure à chaque fois, une URL, un titre et un snippet, mais des budgets qui varient du simple au septuple.
Le snippet stocké par l'index maison de labrador est coupé net un peu au-delà de deux cents caractères, et il est pris au début du corps rendu de la page, pas dans vos métadonnées. Votre meta description est ignorée. Elle reste utile pour les résultats bright, le scrap de Google, qui la reprend une fois sur trois.
La coupure ne tombe presque jamais au milieu du H1 : sur près de quatre cents snippets qui le contiennent, quatre seulement le tronquent. Votre budget de grounding est donc parfaitement calculable. Il se compose de trois blocs qui se suivent toujours dans le même ordre : ce qui traîne avant le H1, le H1 lui-même, et ce qui reste ensuite pour votre contenu réel.
Ce qui mange le début du snippet n'est pas ce qu'on croit. Le fil d'Ariane et la signature d'auteur sont marginaux. Les deux vrais postes de perte sont le surtitre de rubrique et le texte alternatif de la première image, celle qui suit immédiatement le titre, qui peut à elle seule consommer cinquante caractères.
| Ce qui s'intercale avant le H1 | Fréquence | Caractères perdus |
|---|---|---|
| Surtitre, rubrique, catégorie | 29 % | 18 |
| Date de publication ou de mise à jour | 11 % | 25 |
| Texte alternatif de la première image, juste sous le titre | 9 % | 50 |
| Nom du site ou de la marque | 7 % | 44 |
| Fil d'Ariane | 7 % | 23 |
| Signature d'auteur | 3 % | 45 |
Le premier levier n'est pourtant pas là. Sur les pages que nous avons examinées, une sur sept n'a tout simplement aucun H1 balisé. Dans ce cas l'ancrage devient imprévisible : le snippet démarre sur un intertitre choisi au hasard du gabarit, et vous ne contrôlez plus rien.
Méthode : 534 pages effectivement citées par ChatGPT ont été récupérées puis comparées au snippet que l'index en avait stocké. Sur les 463 qui possèdent un H1, 387 snippets le contiennent, soit 83,6 %. Sur ces 387, le H1 est le tout premier caractère dans 297 cas, soit 77 %. Le préfixe, quand il existe, mesure 20 caractères en médiane.
Le snippet n'est pas choisi en fonction de la question posée : sept variantes régionales d'un même communiqué de presse, interrogées avec la même requête, donnent sept ancrages différents. Et il n'est pas fabriqué au moment de la recherche : la grande majorité des pages revues sous plusieurs requêtes différentes rendent un snippet strictement identique. Il est figé au moment du crawl, et il vieillit.
Ce qu'il faut en faire. Votre budget de grounding en mode instant, c'est votre titre entier plus environ cent cinquante caractères utiles à partir de votre H1. Balisez un H1, dégagez la piste entre lui et le premier paragraphe, et surveillez le texte alternatif de la première image, celle qui suit immédiatement le titre.
OpenAI garde vos pages dans deux stocks distincts, écrits par deux robots différents. La copie que vous y avez a un âge. Vous ne le choisissez pas, et vous ne le voyez pas dans vos logs.
Tout le reste de cette section se lit à travers cette distinction. L'index sert à vous trouver, le cache de lecture sert à vous lire. Ce ne sont ni les mêmes contenus, ni les mêmes robots, ni les mêmes délais.
| L'index | Le cache de lecture | |
|---|---|---|
| Ce qu'il contient | un snippet court, figé au moment du crawl | la page entière, déjà convertie en Markdown |
| On y accède par | une requête, des mots-clés | une adresse, l'URL exacte |
| À quoi il sert | trouver votre page | la lire |
| Qui l'écrit | OAI-SearchBot | ChatGPT-User, et OAI-SearchBot aussi |
| Ce qui le met à jour | le passage de SearchBot, et lui seul | une demande d'utilisateur, passé trente minutes |
| Durée de vie | aucune expiration observée ; 13 % des snippets ont plus d'un mois de retard sur le crawl | aucune expiration observée ; plusieurs semaines, voire mois |
| Comment le mesurer | le champ Crawled de l'API, qui ne laisse aucune trace dans vos logs | le passage de ChatGPT-User dans vos logs serveur |
Les deux ne contiennent pas les mêmes pages. Jérôme a constaté que toutes les URLs de l'index ne se retrouvaient pas dans le cache de lecture. Être trouvable et être lisible ne sont pas la même chose.
En deçà de cette fenêtre, la page n'est pas rouverte du tout. Un utilisateur demande votre page à 14 h, un autre la demande à 14 h 29 : c'est la copie de 14 h qui est servie au second, et ChatGPT ne prend même pas la peine de retourner voir si la page a changé.
Sans nouvelle demande, la copie ne s'efface pas. Nous n'avons observé aucune expiration.
Le mécanisme est celui d'un cache qui sert d'abord et vérifie ensuite. Quand la copie a dépassé la demi-heure, ChatGPT vous montre quand même l'ancienne version, puis part rafraîchir en arrière-plan. La version fraîche ne sera servie qu'à la demande suivante. Autrement dit, quand vous voyez passer ChatGPT-User dans vos logs, ce n'est pas une lecture pour l'utilisateur en cours : c'est un rafraîchissement du cache d'OpenAI, dont le prochain visiteur bénéficiera.
Sur notre site de test, une empreinte aléatoire est écrite au même instant dans la page servie et dans nos logs serveur. Quand le modèle la recrache, on sait exactement quelle visite a fabriqué la copie qu'il vient de lire.
Voici la séquence qui a établi que le cache est mutualisé entre utilisateurs. Une page neuve, jamais lue par personne, et deux comptes payants sans aucun lien entre eux.
La copie vient d'être fabriquée.
Il restitue mot pour mot l'empreinte du compte A.
Le compte B n'a jamais touché notre serveur. Il a lu la copie du compte A.
Double preuve : l'empreinte est identique, et le compteur de visites reste à zéro. L'une sans l'autre ne prouverait rien.
La copie créée par un compte est resservie à un autre compte, dans un autre pays, sur un autre abonnement, sans qu'aucune visite n'atteigne le serveur d'origine. La clé du cache est l'adresse de la page, pas l'utilisateur.
Autre point à connaître : nos pages de test envoyaient un header Cache-Control: no-store, qui interdit explicitement toute mise en cache. Elles sont mises en cache quand même.
ChatGPT-User fabrique le cache de lecture, celui de la page entière : c'est lui qui se déclenche quand le modèle ou l'utilisateur demande explicitement une page. OAI-SearchBot, le robot de recherche, fabrique l'index, celui du snippet, et il alimente aussi le cache de lecture, mais pas systématiquement. Des pages qu'il a visitées seul, sans qu'aucune lecture à la demande soit jamais passée, y sont bien présentes.
L'inverse n'est pas vrai, et c'est le point contre-intuitif. ChatGPT-User ne touche jamais à l'index. Sur les pages datées à la fois par l'index d'OpenAI et par des logs serveur, le snippet servi suit le passage de SearchBot à quelques jours près ; ChatGPT-User est pourtant le plus récent des deux robots dans la plupart des cas. Il revient donc lire vos pages, il rafraîchit sa copie entière, et cela ne change rien au snippet que la recherche affiche.
La quasi-totalité des entrées d'index sont plus récentes que la dernière visite de GPTBot, donc rafraîchies après son passage et pas par lui, et nous avions vérifié la même chose sur le cache de lecture. La conséquence pratique mérite d'être posée : être crawlé et être disponible sont deux choses différentes. Le détail de la mesure est dans la section collaboration.
Au-delà des deux stocks principaux, ChatGPT conserve aussi des objets qu'il a lui-même fabriqués. Ils ne se lisent pas comme des pages, mais ils vieillissent de la même manière.
| Ce qui est mis en cache | Durée observée | Conséquence |
|---|---|---|
| Le résumé d'un article de presse | stable entre captures | Généré une fois, resservi ensuite |
| La fiche produit ou la fiche entité (sidebar ChatGPT) | plusieurs semaines voire mois | Identique d'un compte à l'autre, y compris entre pays |
Sur la fiche produit, la démonstration est spectaculaire : le même produit cliqué depuis un compte payant français et depuis un compte gratuit américain renvoie exactement le même texte, généré une seule fois.
Nous avons borné la fenêtre de fraîcheur par dichotomie sur deux pages différentes et deux jours différents, en lisant l'empreinte servie et en vérifiant en parallèle la présence ou l'absence d'une visite serveur. Pas de rafraîchissement à 3, 16 et 25 minutes. Rafraîchissement à 31 et 33 minutes, puis à 1 heure, 9 heures et 10 jours. Le seuil se situe donc entre 25 et 31 minutes, et 30 est une valeur ronde plausible plutôt qu'une valeur lue quelque part.
La rétention est une borne inférieure : une copie du 11 juillet était encore servie le 23. Nous n'avons jamais observé d'expiration, ce qui ne prouve pas qu'il n'y en a pas. Sur le terrain de Jérôme Salomon, des pages étaient encore servies depuis ce cache plus de quatre-vingt-dix jours après leur récupération, log serveur à l'appui.
Deux enquêtes menées en parallèle sur les mêmes objets, l'une chez Oncrawl, l'autre chez nous. Voici ce que leur croisement a établi.
Pendant toute la durée de ces investigations, nous avons travaillé en dialogue avec Jérôme Salomon, expert SEO technique chez Oncrawl. Chacun menait ses mesures de son côté, avec ses propres outils et ses propres terrains ; à chaque échange, les découvertes de l'un corrigeaient ou prolongeaient celles de l'autre. Voici ce que cette collaboration a établi, entre confirmations croisées et trouvailles complémentaires.
La section précédente doit à peu près tout à cette partie du dialogue. Deux protocoles indépendants s'y répondent : les logs serveur et l'API d'un côté, les pages tatouées et le parc de comptes de l'autre. Cinq faits, établis par Jérôme.
external_web_access: false, on demande au modèle de répondre sans sortir sur le web. Ce qu'il restitue alors vient forcément de ce qu'il a en stock. C'est une preuve concrète que l'index de découverte et le cache de lecture existent, et le point de départ de toute la section précédente. meta robots: noindex et visitées par les robots d'OpenAI se retrouvent tout de même dans le cache. Interdire l'indexation n'empêche donc pas d'être mis en cache. L'intuition de Jérôme était la bonne : l'API expose la même machinerie que l'application, jusqu'à ses marqueurs internes. Le pipeline de retrieval, lui, ne se choisit pas depuis l'API, mais la piste désignait le bon endroit : en la creusant, on a trouvé le champ que personne ne regarde.
Le levier tient en une ligne. Sur POST /v1/responses, avec l'outil web_search, on demande include: ["web_search_call.results"]. Chaque résultat arrive alors précédé de métadonnées internes que le flux de l'application n'expose jamais.
Trois informations, sur les 7 782 résultats que nous avons analysés via l'API. Crawled donne l'âge de la copie servie, URL par URL, sans aucun accès aux logs du site : c'est un oracle d'audit qui n'existe nulle part ailleurs. wordlim donne le budget en mots alloué au domaine. Et le marqueur de citation nomme le canal d'origine : recherche, actualités, science, forum, page ouverte. Rien de tout cela n'est documenté, et rien n'empêche OpenAI de le retirer demain, comme le champ qui nommait les pipelines a été retiré le 21 juillet.
| Budget par source | Qui est concerné | Lecture |
|---|---|---|
| 25 mots | Guardian, ESPN, Washington Post, Bloomberg, Corriere, Spiegel… | Cause indéterminée |
| 100 mots | 11 domaines identifiés, tous licenciés connus : Le Monde, WSJ, Politico, Bild, Condé Nast, Hearst… | Ressemble à une clause de contrat |
| 200 mots | Le défaut, tout le reste du web | Le régime normal |
La valeur est une constante par couple nom de domaine et canal, sans aucune variance résiduelle une fois la bonne clé trouvée, et les PDF d'un domaine héritent du budget du domaine. La classe à 100 se lit sans effort. La classe à 25 reste une énigme : elle mélange des éditeurs sous accord et des éditeurs sans accord, et l'explication par le fichier robots.txt est réfutée par des contre-exemples dans les deux sens.
Ce plafond en mots n'est pas une invention de l'API. Il figurait dans le system prompt de ChatGPT que nous avions publié en mars : la consigne [wordlim N], avec deux cents mots par source par défaut, est présente dans la version GPT-5.3. L'API la confirme aujourd'hui côté serveur, source par source. La boucle est bouclée entre ce que le prompt ordonnait hier et ce que le flux mesure aujourd'hui.
Extrait du system prompt de ChatGPT, publié dans notre étude de mars.
L'oracle d'âge, lui, réserve deux surprises grand public. Sur le web vivant il date bien une lecture réelle, découplée de la date de publication. Mais sur les corpus ingérés en masse, il date le contenu de la copie, et cette copie n'a jamais été rafraîchie.
Une page Wikipedia que nous avons analysée, éditée plusieurs fois par jour, est servie avec la mention « Crawled: 2 months ago ». Sur 308 résultats Wikipédia, 209 sont datés de huit à quatre-vingt-dix jours : l'encyclopédie la plus citée des modèles est servie depuis un instantané périodique, pas depuis le site. Ces âges cadrent avec le rythme de l'encyclopédie elle-même, dont les exports complets sont produits une fois par mois : la copie suit la cadence des dumps, pas celle des éditions.
Sur Reddit, la date de collecte est celle de la création du fil de discussion, à zéro jour d'écart en médiane, et elle remonte jusqu'à sept ans. Un fil ouvert en 2019 est servi tel qu'il était à sa création, ou quelques semaines après : les réponses ajoutées ensuite ne figurent pas dans la copie.
C'est le terrain où nos deux positions d'observation diffèrent le plus, et où elles se recoupent le mieux. Trois points.
site:reuters.com, toutes à vide. Il existe donc un canal d'ingestion directe des contenus de presse, qui ne dépend pas du crawl. Jérôme en donne le mécanisme : les partenaires disposent d'une API pour pousser leurs articles chez OpenAI, et ces articles sont disponibles sans avoir eu besoin d'être crawlés une première fois. Ils le sont quand même ensuite, par ChatGPT-User et par SearchBot, mais moins que les articles qui ne passent pas par ce canal. Conséquence concrète pour les éditeurs : les mieux intégrés sont aussi les moins crawlés, et l'absence de ChatGPT dans vos logs ne signifie pas l'absence de ChatGPT dans les réponses. news ; récupéré par le crawl, il arrive avec le flag search. Une capture du 30 juillet montre les deux côtés dans la même réponse, chez le même éditeur : Le Monde y apparaît sept fois en news avec un résumé de 180 mots, et une fois en search avec un snippet de 32 mots. Le flag ne décrit pas le sujet, il décrit la porte d'entrée. bing massivement, sur 93,7 % des sources ramenées. Le même mois, sur nos comptes, zéro. Nous avons écarté deux explications : ce n'est ni la région de serveur qui traite la réponse, ni le gratuit contre le payant. Reste le plan Team : l'hypothèse la plus probable. Nous soupçonnons un accord entre OpenAI et Microsoft ouvrant un accès Bing aux utilisateurs de ChatGPT Team, sans être en mesure de le vérifier. Tout ce que ChatGPT récupère finit listé quelque part. Mais entre être listé et être cité, il y a trois marches, et presque personne ne les franchit.
Rien dans les données ne marque un résultat comme retenu. La notion de citation n'existe qu'au moment de l'affichage, ce qui explique que les chiffres publiés sur le sujet divergent autant d'une étude à l'autre : chacun compte à un étage différent sans le dire. Nous avons reconstruit les étages depuis le flux brut, puis vérifié leur correspondance avec l'interface sur deux sessions réelles où le client nomme lui-même chaque zone d'affichage.
Il est tentant d'écrire que la plupart des pages récupérées ne sont jamais vues. C'est faux, et nous l'avons cru un moment. Toutes les pages ramenées par le retrieval sont bien listées dans le panneau qui s'ouvre en cliquant sur « Sources », sous la réponse. Sur plus de soixante mille couples réponse et page, aucune n'est absente de toutes les surfaces d'affichage.
Ce qui est vrai est plus subtil : neuf sur dix restent au fond de ce panneau, dans la section « Plus », derrière un clic, sans jamais être promues en tête ni reprises dans le texte. Techniquement visibles, pratiquement invisibles.
Un appel de citation dans le texte peut porter plusieurs sources. La pastille affiche le nom de la première et signale les autres par un « +1 », consultables en ouvrant l'infobulle. Toutes sont rattachées à la citation, mais une seule donne son nom.
C'est tout l'écart entre les deux étages ci-dessous : environ 1/3 des URLs sont rattachées à une citation sans en être la source principale. Elles existent, elles sont cliquables, mais ce n'est pas elles que le lecteur voit en premier.
La première colonne suit le panneau Sources, étage par étage. La deuxième colonne dit ce que le modèle a réellement fait des pages. Les filtres croisent le mode, la nature du résultat et le moteur ; les combinaisons trop peu peuplées sont signalées.
Une réponse médiane liste une vingtaine de pages au fond du panneau latéral des sources, en promeut cinq en tête, en cite trois dans son texte et n'en ouvre aucune. La médiane des pages ouvertes est zéro : neuf réponses sur dix n'ouvrent jamais rien.
Neuf pages sur dix ne quittent jamais le fond du panneau. Elles ont été sélectionnées, transmises au modèle, elles ont potentiellement contribué à la réponse, mais très peu mises en valeur par ChatGPT.
ChatGPT encode ses citations sous la forme turn0search11 : tour zéro, famille recherche, onzième résultat. Gemini encode les siennes en PerQueryResult(index='6.2'), soit sixième requête lancée, deuxième résultat de cette requête, comme l'a montré Dan Petrovic.
Deux entreprises rivales, deux architectures, la même décision d'ingénierie : une citation n'est pas une adresse, c'est une coordonnée dans un cache ordonné. Ce qui a été mis en réserve au moment de la recherche détermine ce qui pourra être cité au moment de la rédaction. Le reste, la qualité de votre page, sa fraîcheur, n'entre dans l'équation que s'il a survécu à l'étape d'avant.
C'est rare, mais ça change tout. Quand ChatGPT ouvre vraiment une page, il la cite trois fois sur quatre.
Mais c'est rare. Sur quatre-vingts pages récupérées, une seule est ouverte. Et cette ouverture est réservée au mode thinking sur compte payant : sur les 759 ouvertures de notre corpus, 757 s'y concentrent, et deux conversations gratuites seulement en ouvrent une.
Ce que ChatGPT ouvre pour accéder à la page complète est très typé : du réglementaire, de l'officiel, de la source primaire. Des pages profondes dans l'arborescence, presque jamais des pages d'accueil.
Les domaines les plus ouverts de notre corpus francophone : service-public.fr, economie.gouv.fr, diplomatie.gouv.fr, la CNIL, Légifrance, ameli.fr, france-renov.gouv.fr, la Commission des sondages.
Sept cent cinquante-neuf pages ouvertes ont été recensées sur les 1 249 réponses, soit 1,2 % des URLs du panneau latéral. Elles se concentrent sur 176 réponses, dont 174 en mode thinking sur compte payant, soit 31 % des conversations de ce régime.
Les deux taux de citation ci-dessus ne sont pas calculés sur ces 759 pages, mais sur les 440 qui sont exposées comme objets de résultat : 326 citées sur 440 ouvertes, contre 4 303 sur 57 853 simplement récupérées. Les autres ouvertures ne se retrouvent que par les références portées par les citations, donc elles sont citées par construction et gonfleraient le premier taux sans rien mesurer.
Note pour qui voudrait reproduire : depuis la disparition du champ result_source, les pages ouvertes ne sont plus exposées comme des objets de résultat. On peut encore les retrouver par les références portées par les citations, ce qui reste fiable pour dire si le modèle a ouvert des pages et lesquelles, mais sous-estime le total. Une page ouverte puis écartée ne laisse aucune trace.
En mode instant, 85 % des citations pointent vers une URL qui n'apparaît nulle part dans le grounding reçu, contre 31 % en thinking. Une part vient des widgets, carte, fiche produit, fiche entité, qui portent leurs propres liens hors du canal de recherche. Le reste ressemble à des pages d'accueil de marque écrites depuis la mémoire du modèle. Nous ne savons pas encore faire le partage entre les deux.
arXiv est remonté plus de deux mille six cents fois dans notre corpus. Il est cité dix fois. Il n'est jamais ouvert. On pourrait croire que c'est parce qu'il arrive sans snippet, et il l'est presque toujours, mais la contre-épreuve est sans appel : sur les cent dix-sept occasions où arXiv est arrivé avec un snippet, il n'a été cité aucune fois. Il n'est pas ignoré parce qu'il est nu, il est ignoré tout court.
Le même schéma vaut pour Reddit, massivement récupéré et très peu affiché. ChatGPT lit des preprints et des fils de discussion Reddit pour se faire une idée, et n'expose au lecteur que des pages web ordinaires.
Quand une étude présente arXiv ou Reddit parmi les sites les plus visibles dans ChatGPT, cela signifie que l'outil derrière ne fait pas la différence entre une page récupérée et une page citée. Ces domaines sont massivement récupérés et pratiquement jamais montrés à l'utilisateur. C'est exactement la distinction que mesure la pyramide de la section précédente, et c'est ce qui sépare une mesure de visibilité d'une mesure de trafic potentiel.
Ce qui vaut pour la recherche web ne vaut pour aucune des autres surfaces. Chacune a son propre approvisionnement, et quatre sur cinq n'ont aucun lien avec les moteurs.
Le socle, traité dans les sections précédentes de notre étude. Index maison en mode gratuit, Google scrapé en mode thinking. C'est la seule surface où votre travail sur la page compte directement.
Deux régimes sous une même étiquette. Via l'index maison, ChatGPT reçoit un résumé d'environ mille cent caractères, soit six à huit fois plus long que les snippets scrapés servis par l'autre voie. Ce résumé est plafonné à deux cents mots, avec un palier à cent chez quelques hôtes : le même plafond que celui mesuré côté API pour les éditeurs sous licence.
Ce résumé long n'est pas une contrepartie de licence : des centaines de médias sans accord reçoivent le même traitement. Et il est bien réécrit, pas extrait : aucun ne commence par le titre de l'article, aucun n'est retrouvable mot pour mot.
Ici la copie ne vient pas de votre site du tout, mais de flux : Yelp, TripAdvisor, Google Maps. On reconnaît chaque fournisseur à la forme de son identifiant.
Le fait le plus parlant : près d'une fiche estampillée Yelp sur cinq porte un lien copié depuis la fiche Google Business du commerce, alors que Yelp affiche l'adresse nue. C'est OpenAI qui recoud. L'étiquette d'un fournisseur ne dit pas d'où vient chaque champ.
Le carrousel produits ne partage pas une seule adresse avec les moteurs. Être bien placé dans les liens de ChatGPT n'aide en rien à apparaître dans les cartes produit : ce sont deux métiers différents.
Amazon est totalement absent des offres, y compris sur les questions qui le nomment. Et la fiche produit est un objet mis en cache pendant des semaines, identique pour tout le monde : être dans le premier relevé d'un produit vaut plus que d'être bien classé ensuite.
Vos images sont re-hébergées chez OpenAI. Elles s'affichent dans les réponses sans qu'une seule requête n'atteigne votre infrastructure, donc sans aucune trace dans vos logs.
Détail contre-intuitif : en mode thinking, les vignettes transitent par le réseau de diffusion d'images de Bing. C'est la seule empreinte Microsoft de tout notre corpus.
Un seul de ces cinq systèmes est relié au search classique. Les quatre autres sont alimentés par des flux, des catalogues et des index dédiés, sur lesquels ce sont les techniques SEO propres à chaque verticale qui s'appliquent : SEO image, SEO local et fiche Google Business, flux shopping. Une stratégie de visibilité dans ChatGPT qui ne traite que la recherche web laisse quatre portes fermées.
Sur les actualités, OpenAI fabrique un résumé de votre article, le conserve, le sert à ses utilisateurs pendant des jours, et l'article lui-même n'est cité qu'environ une fois sur huit. La valeur est captée à l'ingestion. Elle n'est pas restituée à l'affichage. Nous posons les faits, chacun en tirera ses conclusions.
Trois questions ouvertes, avec pour chacune un protocole en cours ou prêt à lancer.
Voici la question que nous n'arrivons pas à résoudre, et sur laquelle nous aimerions des mesures indépendantes.
Une partie des résultats de recherche arrive avec un titre, une URL, et rien d'autre. Pas même un snippet tronqué : un snippet vide. On écarte d'emblée YouTube, Reddit et arXiv, qui n'en portent quasiment jamais. Restent des pages ordinaires, sur des domaines ordinaires : la NBA, Costco, CBS News, des annuaires de commerces.
On s'attendrait à ce que le modèle les ignore, faute de matière pour juger. C'est l'inverse. En mode instant, un résultat sans snippet est cité dans 14,9 % des cas, contre 8,2 % pour un résultat qui en porte un : il est cité près de deux fois plus souvent alors que le modèle en sait deux fois moins.
Nos pistes ne suffisent pas. Sur les questions locales, l'absence de snippet est totale par conversation et coïncide avec l'affichage d'une carte, comme si la liste de liens n'était plus qu'un décor et que la carte portait la réponse : cela expliquerait la citation, pas l'absence de snippet. Sur les questions d'actualité, le mécanisme est différent, l'absence est attachée à l'URL et suit la même page d'une conversation à l'autre.
Si vous savez reproduire le phénomène, ou si vous avez une explication, écrivez-nous. Le protocole tient en peu de choses : capturer le flux serveur en mode instant, isoler les résultats de type search, écarter YouTube, Reddit et arXiv, puis comparer le taux de citation avec et sans snippet. Le mode thinking ne se compare pas de la même façon, il ramène tant d'URLs que le taux de citation y perd son sens.
Des observations qui ne méritaient pas leur chapitre, mais qui méritaient d'être écrites.
result_source, dont l'une des quatre valeurs est justement bright, la lecture la plus simple est que ce moteur est Bright Data.utm_source=chatgpt.com à 95 % des liens qu'il affiche, et en mode instant à la totalité d'entre eux. Une famille y échappe pourtant systématiquement : les pages que le modèle a ouvertes et lues lui-même ne portent jamais ce paramètre. Autrement dit, les citations qui valent le plus, celles qui viennent d'une page réellement lue, sont précisément celles que votre outil de mesure d'audience ne saura pas rattacher à ChatGPT.Nous avons mesuré ce que ChatGPT a fait de nos pages.
Mille deux cent quarante-neuf réponses ChatGPT capturées en conditions réelles. Six cent quatre-vingt-deux en mode instant et cinq cent soixante-sept en mode thinking. Un peu moins de cinq cents sur des comptes gratuits, un peu plus de sept cent cinquante sur des comptes payants.
L'unité de compte de toute l'étude est le couple réponse et page. Une même page vue dans deux réponses compte deux fois, une même page vue deux fois dans la même réponse compte une fois. Les adresses sont normalisées avant comptage, paramètres de tracking retirés.
Ce ne sont ni des appels d'API, ni du monitoring d'interface. Ce sont de vraies conversations sur de vrais comptes : gratuits, payants, plusieurs comptes payants distincts, dans plusieurs pays, et même en non logué.
La plupart des outils du marché surveillent l'interface en non logué. Ils observent donc un seul régime, et c'est un des moins représentatifs. C'est précisément l'écart entre nos comptes qui a permis d'isoler le rôle de chaque moteur : sans comparaison gratuit contre payant à prompt identique, il est impossible de voir que le routage dépend du couple modèle et effort, et non de l'abonnement.
Les quatre premiers sont les nôtres. Les deux derniers viennent de Jérôme Salomon (Oncrawl), et regardent la même machine par l'autre bout : le serveur qui reçoit les robots, et l'API qui répond au même moteur que l'application.
Un labo de pages piégées sur un de nos sites. Chaque page servie porte une empreinte aléatoire, écrite au même instant dans la page et dans notre log. On sait donc quelle visite précise a produit la copie que le modèle recrache, et quand.
Une extension Chrome de capture, que nous développons et distribuons librement. Elle enregistre le flux serveur brut de chaque réponse, avant tout rendu à l'écran.
Un parc de comptes ChatGPT : gratuits, payants, plusieurs comptes payants distincts, plus le mode non logué. Le tout derrière un VPN, pour changer d'adresse et de pays à volonté.
Un tracker de feature flags, qui archive chaque jour la configuration embarquée dans le HTML public de chatgpt.com. Il date les bascules serveur au jour près.
L'analyse des logs serveur, sur trois mois et 325 000 URLs. Chaque passage de GPTBot, d'OAI-SearchBot et de ChatGPT-User y est daté, à l'échelle d'un site entier. C'est ce qui permet de dire quel robot est passé quand, de mesurer les rythmes de chacun, et de dater une rétention de cache sur une ligne de log plutôt que sur une déduction.
L'API de recherche instrumentée. Sur POST /v1/responses avec l'outil web_search, le paramètre include: ["web_search_call.results"] fait apparaître les métadonnées internes que l'application n'affiche jamais : Crawled, l'âge de la copie servie URL par URL, et wordlim, le budget en mots accordé au domaine. Et external_web_access: false interroge les stocks sans sortir sur le web. 7 782 résultats analysés.
Les conversations ne sont pas prises au hasard. Les mêmes prompts, mot pour mot, ont été rejoués sur chaque type de compte. C'est la seule façon de séparer ce qui vient de l'abonnement de ce qui vient du mode de réponse. Et les jeux de prompts sont découpés par thématique, pour couvrir toutes les surfaces plutôt qu'une seule : recherche généraliste, actualités, achat, local et cartes, images, sport, culture, administratif et santé.
Ensuite seulement, pour savoir quel moteur se cache derrière chaque pipeline, nous avons rejoué les requêtes que ChatGPT s'écrit à lui-même, les fameuses fan-outs, sur Google et sur Bing, puis cherché les URLs qu'il avait servies dans les résultats des deux moteurs.
Notre étude de mars décrivait l'outil et ses commandes. Celle-ci décrit ce qui circule dedans. think.resoneo.com/chatgpt/5.3-5.4
Ce travail est une suite. Il ne serait pas possible sans plusieurs personnes qui ont publié avant nous, et qui ont publié leur méthode en même temps que leurs résultats.
| Suganthan Mohanadasan |
A mis le champ qui nomme les moteurs sur la place publique, en lisant le trafic réseau plutôt que les réponses, et en établissant ses quatre valeurs. C'est le point de départ de ce travail, y compris du seul endroit où nous le contredisons : nos mesures ne soutiennent pas la lecture de labrador comme un catalogue de contenus sous licence. |
| Mark Williams-Cook Metehan Yeşilyurt |
Nous ont mis sur cette piste. Le premier a documenté que ChatGPT lance en sous-main de vraies recherches Google et a rendu ces requêtes lisibles, ce que notre validation croisée confirme par un autre chemin. Le second poursuit un travail de fond sur le classement interne de ChatGPT. |
| Chris Green | A fourni le seul jeu de données public à grande échelle sur la répartition des moteurs, près de dix mille exécutions de recherche. Nos propres distributions se lisent contre les siennes. |
| David Konitzny | A le premier documenté l'infrastructure locale de ChatGPT et repéré les identifiants de fournisseurs anonymisés. Nous partons de son constat pour montrer que ces identifiants partagent le schéma des flux nommés, qu'un de ceux qu'il liste ne s'est jamais matérialisé dans nos captures, et qu'un quatrième fournisseur, ouvertement Google, comble les catégories que Yelp couvre mal. |
| Jérôme Salomon | Nous a guidés sur toute la partie cache, et a mis au jour le paramètre permettant d'interroger le cache d'OpenAI sans accès web, preuve concrète que l'index de découverte et le cache de lecture existent. On lui doit aussi trois mesures que nous n'avions pas : OAI-SearchBot alimente les deux stocks et c'est lui qui date l'index, la directive noindex y est ignorée, et être lu ne garantit pas d'y être admis. Plus la rétention de plus de quatre-vingt-dix jours, datée sur log serveur. C'est enfin son intuition d'aller instrumenter l'API web_search qui a ouvert tout le chantier des métadonnées internes. Le détail est dans la section collaboration. |
| Dan Petrovic | A exposé le format d'ancrage interne de Gemini et son décodage requête par résultat. Le parallèle avec les ancres de ChatGPT structure la section 5. |
L'extension qui a produit ce corpus vient d'être mise à jour. Elle ne se contente plus d'enregistrer le flux brut : elle reconstitue, réponse par réponse, le parcours d'une URL depuis le fond du panneau latéral jusqu'à la pastille de citation. Les chiffres de cette étude peuvent donc être recalculés sur vos propres conversations.
ref_type brut : recherche web, actualités, scientifique, forum, vidéo, local, produit, image, météo, page ouverte, et sans ref_type.Total lines: et sur les références de lecture, dédoublonnée par URL normalisée, la signature de récupération étant conservée.result_source du flux serveur, entre le 20 et le 22 juillet, les résultats de l'index maison d'OpenAI sont déduits de signatures de format : snippet d'au moins cent quatre-vingt-six caractères, en-tête de snippet en capitales. Les signaux retenus sont affichés dans l'infobulle, pour que la déduction reste vérifiable.