De l'exploration à la contribution

Cloudflare tente de reconstruire l'échange

L'article de Cloudflare publié en juillet 2026, Making AI search smarter, décrit un web dans lequel l'ancien échange entre exploration et trafic référent ne fonctionne plus de manière fiable.

La réponse proposée comporte deux volets liés.

Le premier est un programme de recherche destiné à aider les moteurs de réponse à trouver des contenus plus récents et de meilleure qualité, tout en réduisant les explorations inutiles. Cloudflare affirme que plus de la moitié de l'exploration effectuée par les robots légitimes qu'il observe sert à récupérer de nouveau des pages qui n'ont pas changé. De meilleures informations sur les modifications pourraient réduire ce coût pour les robots comme pour les propriétaires de sites.

Le second consiste à passer de la facturation de l'accès à la rémunération des éditeurs lorsque leur contenu est utilisé. Les éditeurs participants devraient également recevoir des rapports sur les requêtes, les pages, les extraits et la visibilité dans les réponses.

Cette orientation est plus pertinente que de considérer chaque requête comme ayant la même valeur. Une page peut être demandée à plusieurs reprises sans jamais contribuer à une réponse. Une autre peut être récupérée une seule fois, conservée dans un index, puis étayer de nombreuses réponses.

Mais plus le paiement se rapproche de la contribution, plus l'attribution devient difficile. Une requête est un événement HTTP distinct. La contribution résulte d'une décision prise au sein d'un système que l'éditeur ne peut généralement pas examiner.

L'échelle des preuves de l'AEO

Un modèle de mesure utile doit montrer à la fois ce que démontre chaque événement et où se situe sa limite probante.

Les événements forment une séquence, mais celle-ci ne constitue pas un tunnel garanti. Une requête peut s'arrêter avant le traitement. Un passage récupéré peut être écarté lors du reclassement. Une réponse peut utiliser plusieurs sources tout en n'en citant que certaines. Une source citée peut ne recevoir aucune visite parce que la réponse se suffisait à elle-même.

C'est pourquoi un score AEO unique risque de masquer plus qu'il n'explique.

La requête d'un robot est une preuve utile, mais pas une preuve d'utilisation

L'observation côté serveur reste essentielle, car elle enregistre une activité que les outils d'analyse conventionnels ne voient pas. Les robots d'entraînement, les robots de recherche et les agents de récupération déclenchés par l'utilisateur peuvent accéder à un site sans exécuter les outils d'analyse du navigateur ni générer de visite humaine.

Les journaux peuvent répondre à des questions concrètes :

• Quels robots vérifiés ont demandé le site ?
• Quelles URL et quels formats ont-ils demandés ?
• Quand les requêtes ont-elles eu lieu et à quelle fréquence se sont-elles répétées ?
• Le serveur a-t-il renvoyé des réponses 200, 304, 403, 404 ou 5xx ?
• Quel volume de contenu a été transféré ?
• Les requêtes ont-elles suivi de véritables modifications du contenu ?
• Les pics d'exploration se concentraient-ils sur certaines sections ou représentations ?

Ces observations sont précieuses. Elles aident à diagnostiquer la politique d'accès, le rendu, l'efficacité de l'exploration, la charge de l'infrastructure et la découverte.

Elles ne permettent toujours pas d'établir une indexation, un entraînement, une récupération, une citation ou un bénéfice commercial.

Je peux démontrer qu'un robot vérifié a demandé un fichier Markdown sur Scrubnet. Je ne peux pas déduire de cette seule requête que le fichier a été placé dans un index, sélectionné pour un prompt ou cité par un produit d'IA. Cette limite n'est pas une faiblesse de l'analyse des journaux. C'est le point à partir duquel les preuves changent de propriétaire.

Le paiement à l'utilisation exige d'abord une définition de l'utilisation

Passer du paiement par exploration au paiement à l'utilisation semble plus juste, car la rémunération se rapproche de l'événement créateur de valeur. Cela engendre aussi un problème comptable bien plus difficile.

Considérons plusieurs façons dont une source pourrait contribuer :

• Un passage est récupéré, mais une autre source l'emporte lors du reclassement.
• Un fait sert à vérifier une affirmation déjà étayée ailleurs.
• Trois sources concordent et la réponse synthétise leur conclusion commune.
• Un chiffre exclusif provenant d'un éditeur modifie sensiblement une recommandation.
• La réponse paraphrase une source sans afficher de citation.
• La source apparaît comme citation alors qu'une autre a fourni la preuve déterminante.
• Un agent utilise les informations de la page pour accomplir une action sans montrer cette page à l'utilisateur.

Lesquels de ces événements doivent être comptabilisés comme une utilisation ? Doivent-ils avoir la même valeur ? Qui vérifie l'événement lorsque les systèmes de récupération et de synthèse sont contrôlés par l'acheteur ?

La granularité pose également problème. L'unité pourrait être un document, un passage, une affirmation factuelle, une image, un jeu de données, une réponse ou une tâche accomplie. Chaque choix crée des incitations différentes.

Un modèle au niveau du document est plus facile à administrer, mais peut récompenser des pages qui ont très peu contribué. Un modèle au niveau de l'affirmation est plus précis, mais introduit des problèmes de provenance et de vérification. Un modèle fondé sur le résultat est commercialement attrayant, même si le contenu source peut être éloigné de plusieurs étapes de l'action finale.

Il ne s'agit pas d'affirmer que le paiement à l'utilisation ne peut pas fonctionner. Mais ses rapports doivent reposer sur une définition transparente des événements, des règles de déduplication, une attribution vérifiable et un moyen pour les éditeurs de contester les écarts. Faute de quoi, l'« utilisation » risque de devenir une nouvelle métrique dont les décisions importantes se prennent dans une boîte noire.

Une architecture pratique de mesure de l'AEO

Au lieu de réunir tous les signaux dans un seul indicateur de visibilité, les éditeurs peuvent organiser la mesure de l'AEO en quatre couches.

1. Accès et diffusion

Il s'agit de la couche de preuves contrôlée par l'éditeur. Utilisez les journaux du CDN, du WAF et du serveur pour enregistrer l'identité vérifiée du robot, l'URL demandée, l'état de la réponse, le résultat du cache, le temps de réponse, la taille de la charge utile et les en-têtes de requête conditionnelle.

L'objectif est de comprendre qui a atteint le contenu et ce que le serveur a diffusé.

2. Découverte et modification

Mesurez si les URL importantes sont exposées par les liens internes, les sitemaps XML, les flux et les protocoles de soumission appropriés. Comparez les véritables événements de publication ou de modification aux requêtes ultérieures.

L'objectif est de comprendre si les systèmes peuvent trouver les bonnes ressources et reconnaître les mises à jour significatives sans gonflement artificiel des horodatages.

3. Visibilité dans les réponses

Suivez les requêtes communiquées, les pages citées, les extraits affichés, l'inclusion dans les réponses et la position sur la plateforme lorsque des rapports fiables sont disponibles. Complétez ces données par un ensemble maîtrisé de prompts fondés sur de véritables recherches et tâches de clients.

L'objectif est d'observer comment le contenu apparaît dans les environnements de réponse, tout en reconnaissant qu'un échantillon de prompts ne représente pas tous les utilisateurs ni toutes les réponses personnalisées.

4. Résultat et valeur

Enregistrez les visites identifiables, les conversions, les parcours assistés, les actions des agents, les revenus de licence et toute rémunération communiquée par une plateforme. Distinguez les résultats directs des contributions modélisées ou autodéclarées.

L'objectif est de relier la visibilité dans les réponses à la valeur commerciale sans prétendre que chaque utilisation précieuse se traduit par un clic.

Ces couches peuvent être analysées ensemble, mais leurs libellés doivent rester distincts. Une hausse des requêtes des robots est un résultat d'accès. Une hausse des citations est un résultat de visibilité. Une demande de renseignements aboutie est un résultat. Traiter les trois comme du « trafic IA » efface la distinction nécessaire à une décision utile.

La fraîcheur révèle l'écart de mesure

L'attention portée par Cloudflare aux réexplorations inutiles est particulièrement pertinente, car la fraîcheur intervient à plusieurs endroits de la chaîne de preuves.

Un éditeur peut exposer des valeurs lastmod exactes, des en-têtes Last-Modified et des validateurs ETag. Un robot peut ensuite décider de planifier une requête, d'envoyer une requête conditionnelle, de réutiliser une représentation en cache ou de télécharger à nouveau l'intégralité du corps.

Il s'agit de décisions distinctes.

Les premiers résultats de l'Observatoire de la fraîcheur de Scrubnet ont montré qu'environ 88 % des requêtes admissibles observées pendant la période analysée visaient du contenu vieux de plus de sept jours. L'âge moyen du contenu demandé était d'environ 120 jours.

Cette observation ne montre pas que les signaux de fraîcheur ont échoué. Le corpus disponible comprenait des ressources plus anciennes et le jeu de données enregistre les requêtes, pas le taux de sélection pour chaque tranche d'âge. Les ressources anciennes peuvent également être contrôlées efficacement grâce à la validation du cache.

C'est précisément la raison pour laquelle le vocabulaire de la mesure compte. « A demandé du contenu ancien », « a téléchargé un corps inchangé » et « a gaspillé une exploration » ne sont pas des affirmations équivalentes.

Une analyse plus solide de l'efficacité combinerait :

• la répartition par âge de toutes les ressources admissibles ;
• les véritables événements de modification du contenu ;
• le moment des requêtes des robots ;
• les en-têtes de requête conditionnelle ;
• les résultats des réponses 200 et 304 ;
• les octets transférés ;
• l'identité et la finalité déclarée du robot ;
• la visibilité ultérieure dans les réponses lorsqu'elle peut être observée.

Ce n'est qu'alors que la discussion pourra dépasser le volume des requêtes pour aborder leur efficacité et leur valeur potentielle.

Ce que les éditeurs peuvent mesurer dès maintenant

La chaîne complète de contribution n'est pas encore observable de manière indépendante, mais les éditeurs n'ont pas besoin d'attendre une attribution parfaite pour améliorer leurs preuves.

1. Distinguer les robots selon leur finalité. Les requêtes d'entraînement, de recherche, déclenchées par l'utilisateur et autonomes correspondent à des politiques et à des résultats potentiels différents.
2. Vérifier les robots connus. Une chaîne de user-agent reconnaissable ne constitue pas une preuve d'identité suffisante.
3. Conserver les champs de chaque requête de manière privée. Gardez les horodatages, les URL, les méthodes, les états, les résultats du cache, les tailles des réponses et les validateurs pour l'analyse, avec des règles adaptées de conservation et de confidentialité.
4. Enregistrer les véritables modifications du contenu. Sans historique exact des changements, l'exploration redondante ne peut pas être mesurée de façon fiable.
5. Maintenir l'intégrité des signaux de découverte. Ne mettez pas à jour les dates de modification simplement parce qu'une page a été reconstruite ou demandée.
6. Suivre séparément la visibilité dans les réponses. Enregistrez la plateforme, la requête ou le prompt, la réponse observée, l'URL citée, la date et tout contexte pertinent relatif au lieu ou au compte.
7. Étiqueter les preuves communiquées et observées. Un événement d'utilisation communiqué par une plateforme ne doit pas être présenté comme vérifié de manière indépendante, sauf s'il peut être rapproché d'une autre source.
8. Éviter les affirmations universelles tirées d'un seul environnement. Les résultats provenant d'un seul domaine, ensemble de prompts ou type de robot doivent être accompagnés de leur périmètre, de leurs dénominateurs et de leurs dates d'observation.

On obtient ainsi un tableau de bord moins spectaculaire, mais plus défendable.

Un rôle pour l'Observatoire Scrubnet

Cloudflare dispose d'une vue sur une part considérable du web. Scrubnet opère à une échelle très différente.

Son rôle utile n'est pas d'imiter des affirmations à l'échelle d'un réseau. Il consiste à maintenir un environnement public et vérifiable dans lequel les représentations lisibles par machine, les signaux de fraîcheur et les requêtes de robots vérifiés peuvent être examinés avec soin.

Cet environnement peut aider à étudier des questions telles que :

• À quelle fréquence les robots vérifiés reviennent-ils sur des ressources dont le corps n'a pas changé ?
• Quels robots envoient des en-têtes If-Modified-Since ou If-None-Match ?
• À quelle fréquence la validation du cache aboutit-elle à une réponse 304 Not Modified ?
• Comment le comportement et le coût de transfert diffèrent-ils entre HTML, TXT, JSON et Markdown ?
• Après une véritable modification, à quelle vitesse les différents robots reviennent-ils sur une ressource ?
• Peut-on un jour comparer de manière responsable la visibilité externe dans les réponses avec l'activité de requêtes qui l'a précédée ?

Les réponses décriront toujours l'accès, et non les traitements invisibles en aval. Cette limite doit rester visible, sans être gommée.

Ce que de bons rapports AEO doivent montrer

Si les plateformes de moteurs de réponse fournissent aux éditeurs des rapports sur les requêtes et les utilisations, des rapports utiles doivent expliquer davantage qu'un simple total.

Ils doivent au minimum identifier :

• l'événement qui constitue une utilisation ;
• la page, le passage ou l'élément associé à cet événement ;
• si la source a été récupérée, incluse, citée ou suivie d'une action ;
• comment les réponses et les utilisateurs répétés sont dédupliqués ;
• le délai de communication et la durée de conservation ;
• si les valeurs sont exhaustives, échantillonnées, estimées ou modélisées ;
• comment les éditeurs peuvent rapprocher ou contester l'enregistrement ;
• quels événements ouvrent droit à une rémunération.

Ces définitions peuvent être commercialement sensibles au départ. Sans elles, toutefois, il sera demandé aux éditeurs d'attribuer un prix à une contribution qu'ils ne voient pas à l'aide d'un système de mesure qu'ils ne peuvent pas auditer.

Sources et lectures complémentaires

• Cloudflare: Making AI search smarter
• Scrubnet : Signaux de fraîcheur et réalité de l'exploration
• Scrubnet : Le guide ultime de l'optimisation technique pour la recherche par l'IA
• Observatoire des robots Scrubnet