Le web a besoin d'une norme de point de vue : pourquoi les jeux de données du web public devraient enregistrer l'endroit où les données ont été observées

La provenance des données a traditionnellement répondu à une question fondamentale : d’où viennent ces données ?

Pour un enregistrement de base de données, cela peut désigner le système source. Pour des données de recherche, cela peut désigner l’expérience, l’instrument ou le chercheur qui les a générées. Pour un jeu de données web, cela désigne généralement la page, le domaine, l’API ou l’URL à partir desquels l’information a été collectée.

Mais le web moderne soulève une autre question qui devient tout aussi importante : où les données ont-elles été observées ?

Un résultat de recherche consulté à Londres peut différer de la même requête effectuée à New York. Un détaillant peut afficher un prix, un statut de stock, une devise ou un vendeur différent selon la localisation du visiteur. Une publicité visible via un FAI peut ne jamais apparaître via un autre. Un visiteur mobile peut recevoir une page différente de celle d’un visiteur sur ordinateur.

Pourtant, de nombreux jeux de données web publics enregistrent le résultat sans enregistrer les conditions dans lesquelles il a été observé. Nous pensons que cela doit changer.

Pour les données web géographiquement et contextuellement variables, nous pensons que le point d’observation devrait devenir un élément standard de la provenance des données. Nous utilisons le terme provenance par point d’observation pour désigner ce contexte d’observation.

Points clés à retenir

• La provenance traditionnelle des données enregistre souvent la source des données web sans enregistrer les conditions dans lesquelles elles ont été observées.
• La même URL peut renvoyer des prix, des résultats de recherche, des publicités, des stocks ou un contenu différents selon la géographie, l’identité réseau, l’appareil et l’état de session.
• Une norme utile de point d’observation peut commencer par l’horodatage, le point d’observation demandé, le pays et la ville de sortie validés, l’ASN ou l’opérateur réseau, le contexte client ou appareil, l’état de session, l’URL cible et le statut de validation.
• La configuration d’un proxy résidentiel peut faire partie de l’enregistrement de provenance car elle aide à définir l’environnement dans lequel une observation a été effectuée.
• Un profil de provenance spécifique au web peut s’appuyer sur W3C PROV-O et s’aligner sur l’accent mis par les principes FAIR sur une provenance détaillée, plutôt que de remplacer les cadres existants.

La provenance des données a un angle mort : le contexte d’observation

Le concept de provenance des données est déjà bien établi. Le NIST Research Data Framework définit la provenance comme l’historique documenté d’un actif de données, incluant où, quand, comment et par qui il a été généré, acquis ou traité. Les documents de travail du profil de gouvernance et de gestion des données en cours d’élaboration par le NIST mentionnent également la gestion des métadonnées, la provenance des données et la lignée des données parmi les activités notionnelles de gestion du cycle de vie des données.

C’est un travail important. La provenance permet aux organisations d’établir la confiance, d’enquêter sur les erreurs, de reproduire des processus et de comprendre comment l’information a changé. Mais la collecte sur le web public introduit une distinction inhabituelle.

Il y a l’origine de l’information, et il y a l’observation de l’information. Supposons qu’un jeu de données enregistre https://example.com/product/123 comme la source d’un prix de produit.

Cela nous indique d’où vient l’information. Cela ne nous indique pas si le collecteur a accédé à la page depuis Chicago, Paris ou Singapour. Cela ne nous indique pas si la requête est passée par un FAI résidentiel ou un centre de données cloud. Cela ne nous indique pas si la page a été consultée en tant qu’utilisateur mobile, si une session avait déjà été établie, ou si la réponse était la page attendue plutôt qu’une redirection de localisation ou un défi anti-bot.

Pour les données web modernes, ce contexte peut affecter matériellement l’observation.

La provenance de la source nous indique d’où vient l’information. La provenance par point d’observation ajoute les conditions dans lesquelles elle est devenue observable. Nous avons besoin des deux.

La même URL ne signifie pas toujours le même web

L’hypothèse selon laquelle une URL correspond à une représentation universelle unique de l’information est de plus en plus dépassée. Les sites web modernes adaptent leurs réponses en utilisant un large éventail de signaux.

La géographie peut affecter les prix, la disponibilité, la langue, les résultats de recherche, les vendeurs, la publicité, les avis réglementaires ou les parcours de consentement, ainsi que l’accès au contenu sous licence. L’identité réseau peut influencer les contrôles antifraude et les systèmes anti-bot. Le type d’appareil peut modifier la mise en page et même les informations affichées. Les cookies et l’historique de session peuvent affecter les recommandations, la personnalisation et l’état d’authentification.

Considérons quelques tâches ordinaires de collecte de données :

• Une plateforme d’intelligence tarifaire vérifie un détaillant depuis les États-Unis et l’Allemagne. L’URL est identique, mais le prix du produit, le statut de stock, les options de livraison et le vendeur disponible peuvent différer.
• Une plateforme SEO mesure un résultat Google depuis Miami et Londres. La requête est identique, mais les résultats organiques, les blocs locaux, les publicités et d’autres fonctionnalités des SERP peuvent changer.
• Une plateforme de vérification publicitaire vérifie une campagne depuis plusieurs villes. La page de l’annonceur n’a pas changé, mais la publicité diffusée peut dépendre de la localisation et du réseau du spectateur.

Ce ne sont pas des cas marginaux. Ce sont des propriétés du web tel qu’il existe aujourd’hui. Un jeu de données qui se contente d’enregistrer une URL plus un résultat peut donc préserver le contenu tout en perdant une partie des preuves nécessaires pour l’interpréter.

Ce qu’une norme de provenance par point d’observation devrait enregistrer

La réponse n’a pas besoin d’être un énorme schéma de métadonnées attaché à chaque requête. Une norme utile pourrait commencer par un petit ensemble de champs capturant les conditions les plus susceptibles d’affecter une observation sur le web public.

Champ	Ce qu’il faut enregistrer	Pourquoi c’est important
Horodatage	Le moment où l’observation a eu lieu, de préférence en utilisant un horodatage UTC standardisé.	Le contenu web change constamment. Sans indication temporelle, même un enregistrement de provenance par ailleurs complet est difficile à reproduire.
Point d’observation demandé	La géographie et les sélecteurs réseau demandés à l’infrastructure de collecte, le cas échéant.	Les paramètres demandés décrivent le contexte d’observation prévu et distinguent l’intention de collecte de la sortie réellement utilisée.
Géographie de sortie validée	Le pays et, lorsque disponible, la ville associés à l’IP de sortie réellement observée pour la requête.	La sortie vue par la cible peut différer de la localisation demandée si un comportement de repli est autorisé. Le contexte de sortie validé est ce que l’observation représente réellement.
ASN / opérateur réseau	L’ASN associé à l’IP de sortie et, lorsque disponible, le FAI ou opérateur réseau correspondant.	Le pays seul peut ne pas suffire. Le contexte ASN ou opérateur aide à décrire l’environnement réseau à partir duquel l’observation a été effectuée.
Contexte client / appareil	Les caractéristiques client pertinentes telles que le profil mobile ou bureau, la famille ou le moteur de navigateur, le profil du système d’exploitation, la fenêtre d’affichage, ou le profil de navigateur normalisé utilisé par le système de collecte.	Le contexte client et appareil peut modifier la mise en page et, dans certains cas, les informations affichées.
État de session	Si la requête a utilisé une session nouvelle, persistante ou authentifiée, et si les cookies ou l’état de session ont été conservés. Enregistrer la classification, pas les identifiants ni les valeurs brutes des cookies.	Les conditions de session peuvent modifier fondamentalement la page renvoyée par un site web, tout en évitant le stockage de matériel d’authentification sensible.
URL cible	L’URL exacte demandée, incluant les paramètres pertinents.	La ressource cible fait partie du contexte source nécessaire pour interpréter et reproduire une observation.
Statut de validation	Si la réponse retournée a été validée comme étant le contenu prévu.	Une réponse HTTP réussie peut néanmoins être un CAPTCHA, une redirection, une page de consentement, une page de blocage, une réponse vide ou une localisation inattendue.

Ensemble, ces champs produisent un modèle plus utile :

Observation = Contenu + Source + Temps + Point d’observation + Contexte client/session + Validation.

C’est le niveau auquel nous pensons que la provenance du web public devrait de plus en plus opérer.

Les proxys résidentiels devraient faire partie de l’enregistrement de provenance, pas seulement de la pile de collecte

Les proxys résidentiels sont généralement évoqués en tant qu’infrastructure. Un collecteur a besoin de données depuis l’Allemagne, alors le trafic est routé via une IP allemande. Un flux de travail a besoin d’une identité persistante, alors il utilise une session sticky. Un jeu de données nécessite des résultats au niveau de la ville, alors le système de collecte demande une ville particulière.

Cette description est techniquement correcte, mais incomplète. Si le proxy détermine où et via quel réseau une observation est effectuée, alors sa configuration pertinente fait partie de l’environnement de mesure.

Les chercheurs scientifiques documentent les conditions expérimentales car ces conditions peuvent influencer leurs résultats. La collecte de données sur le web public devrait adopter le même état d’esprit.

Avec notre réseau de proxys résidentiels, les requêtes peuvent être ciblées par pays, région, ville ou ASN, tandis que les systèmes de collecte peuvent choisir entre la rotation par requête et les sessions sticky. Le ciblage géographique de Shifter est configuré par requête, et une correspondance stricte peut être utilisée lorsque la géographie exacte demandée compte. Le comportement de session est également un choix par requête.

Ces contrôles sont normalement considérés comme des paramètres de collecte. Nous pensons qu’ils devraient de plus en plus être considérés aussi comme des paramètres de provenance. Cela ne signifie pas qu’un proxy prouve qu’une observation est correcte. Cela signifie que la configuration aide à expliquer les conditions dans lesquelles l’observation a été obtenue.

Nos benchmarks de proxys montrent pourquoi le point d’observation compte

Nous pouvons observer le même principe dans les tests comparatifs de proxys. Lorsque nous comparons des réseaux résidentiels, nous ne nous appuyons pas uniquement sur les tailles totales de pool annoncées par les fournisseurs. Nos benchmarks mesurent les adresses IP qui sont actives et accessibles au moment du test, et les résultats sont ventilés par marché individuel. La disponibilité des IP résidentielles change continuellement, donc le temps et la géographie font partie de ce que le benchmark représente réellement.

Notre méthodologie contrôle également des conditions de collecte importantes. Le programme de benchmark utilise des volumes de requêtes fixes, une même cible, un paramètre de concurrence fixe, et la même machine ou le même serveur pour des exécutions comparables. Les pages de benchmark par paires recommandent également d’utiliser la même heure lors de la reproduction d’un test.

Nous mesurons également la dispersion réseau, pas simplement le nombre d’adresses. Des fournisseurs disposant d’un nombre similaire d’IP accessibles peuvent néanmoins différer matériellement dans le nombre de systèmes autonomes représentés dans un pays.

Cette méthodologie illustre un principe plus large : une mesure devient plus significative lorsque l’on connaît les conditions dans lesquelles elle a été effectuée. Les jeux de données du web public méritent la même rigueur.

Une meilleure provenance des données signifie des jeux de données web plus reproductibles et auditables

Faire du point d’observation un élément de la provenance des données créerait des avantages pratiques dans tout l’écosystème des données.

• Pour la reproductibilité, une autre équipe pourrait tenter de recréer non seulement l’URL et l’horodatage, mais aussi l’environnement approximatif à partir duquel l’observation a eu lieu.
• Pour l’audit, les analystes enquêtant sur des enregistrements contradictoires pourraient déterminer si deux observations ont été collectées depuis des pays, réseaux, appareils ou sessions différents avant de supposer que l’une d’elles était erronée.
• Pour la qualité des données, les différences régionales pourraient être distinguées des échecs d’extraction.

Les implications deviennent encore plus significatives pour l’IA. Les ensembles d’entraînement, les pipelines de récupération et les jeux de données d’évaluation dépendent de plus en plus d’informations web en direct. Mais la couverture géographique compte. Nos recommandations sur la collecte de données pour l’IA et l’apprentissage automatique reflètent déjà cette réalité : les modèles et les agents peuvent avoir besoin de collecter l’information telle que les utilisateurs de différentes régions la rencontrent réellement, avec une collecte multi-régionale et une évaluation par rapport à une vérité terrain web en direct.

Sans métadonnées de point d’observation, le déséquilibre géographique peut devenir invisible une fois que l’information entre dans un jeu de données. Avec elles, les équipes peuvent poser des questions bien meilleures.

Quel pourcentage de ce jeu de données a été observé depuis les États-Unis ? Quels ASN étaient représentés ? La collecte mobile et bureau a-t-elle produit des résultats différents ? Les incohérences apparentes sont-elles en réalité des variations régionales ? Ce n’est pas seulement de la provenance. C’est une meilleure gouvernance des données.

Une norme de point d’observation peut étendre les cadres existants de provenance des données

Il n’est pas nécessaire de réinventer la provenance à partir de zéro. La norme W3C PROV-O fournit déjà un cadre pour représenter et échanger des informations de provenance entre différents systèmes. Il est important de noter que le W3C a conçu PROV-O de sorte que ses classes et propriétés puissent être spécialisées pour des détails de provenance spécifiques à des applications dans différents domaines.

Les principes de données FAIR vont dans le même sens. Pour que les données soient réutilisables, leurs métadonnées devraient être richement décrites, associées à une provenance détaillée, et alignées sur des normes communautaires pertinentes pour le domaine. L’opportunité n’est donc pas de remplacer les normes de provenance existantes.

Il s’agit de définir un profil de provenance spécifique au web au sein de cet écosystème plus large. Un tel profil pourrait standardiser des champs tels que le point d’observation demandé, la géographie de sortie validée, l’ASN ou l’opérateur réseau, le contexte client, les conditions de session, la ressource cible, l’horodatage et l’état de validation.

Une fois que ces champs deviennent prévisibles, ils deviennent plus faciles à préserver et à échanger pour les plateformes de scraping, les entrepôts de données, les pipelines d’IA et les éditeurs de jeux de données.

Le secteur des données web devrait faire du point d’observation un champ de premier ordre

Les données du web public sont de plus en plus utilisées pour prendre des décisions à conséquences importantes. Elles alimentent l’intelligence tarifaire, l’analyse publicitaire, la protection de marque, la recherche financière, les plateformes SEO, les systèmes d’IA, l’intelligence de marché et les agents autonomes.

Les normes entourant ces données devraient refléter le fonctionnement réel du web. Les API de scraping pourraient exposer les métadonnées d’observation aux côtés du contenu retourné. Les fournisseurs de proxys pourraient faciliter la capture automatique du contexte réseau et géographique pertinent. Les pipelines de données pourraient le préserver à côté de chaque enregistrement plutôt que de le supprimer après la collecte. Les éditeurs de jeux de données pourraient documenter la distribution des points d’observation utilisés pour constituer leurs corpus.

L’essentiel

Rien de tout cela ne nécessite de stocker chaque détail technique de chaque requête HTTP. Cela nécessite de reconnaître un principe important : où quelque chose a été vu peut faire partie de ce qui rend l’observation significative.

Un proxy résidentiel ne devrait donc pas toujours être traité comme un tuyau invisible entre le collecteur et le site web. Lorsque la géographie, l’identité réseau ou le comportement de session peuvent affecter l’information retournée, la configuration pertinente du proxy et le contexte de sortie validé font partie de l’enregistrement de provenance.

Le web est devenu géographiquement, temporellement et contextuellement variable. Nos jeux de données doivent reconnaître cette réalité.

La prochaine génération de données web devrait enregistrer non seulement ce qui a été vu et d’où cela venait, mais aussi où se trouvait l’observateur au moment où il l’a vu.

Sources et références

• NIST, Research Data Framework (RDaF) Version 2.0. Définition de la provenance et cadre du cycle de vie des données de recherche.
• NIST, Data Governance and Management Profile Working Session 2. Activités notionnelles du cycle de vie des données incluant les métadonnées, la provenance des données et la lignée des données.
• W3C, PROV-O: The PROV Ontology. Cadre d’échange de provenance et spécialisation pour des domaines spécifiques aux applications.
• GO FAIR, FAIR Principles Overview. Données réutilisables, métadonnées riches, provenance détaillée et normes communautaires pertinentes pour le domaine.
• Shifter, documentation sur le ciblage géographique des proxys résidentiels. Pays, région, ville, ASN, correspondance stricte et comportement de repli.
• Shifter, documentation sur les sessions des proxys résidentiels. Rotation par requête et comportement de session sticky.
• Shifter, 15 Residential Proxy Providers, Ranked on One Identical Test, 13 août 2026. Méthodologie de benchmark, volumes de requêtes fixes, concurrence, destination et mesure de la dispersion réseau.
• Shifter, Shifter vs Evomi Residential Proxy Benchmark. Méthodologie par paires, mesure des IP en direct et des ASN, et recommandations de reproductibilité.