La veille tarifaire consiste à relever automatiquement, à intervalle régulier, les prix pratiqués par vos concurrents pour piloter les vôtres. La difficulté n’est pas celle qu’on imagine : lire un prix sur une page est trivial, le faire chaque jour à grande échelle sans se faire bloquer ne l’est pas, car les sites e-commerce se défendent activement contre la collecte automatisée. Nous opérons une infrastructure de proxys mobiles utilisée quotidiennement pour ce type de collecte : voici ce qui déclenche les blocages, ce que nous observons selon le type d’IP, et le cadre juridique dans lequel tout cela s’inscrit.

La veille tarifaire : qui en fait, et comment

Concrètement, il s’agit de relever des prix, mais aussi des promotions, des disponibilités et des frais de port, sur les sites concurrents et les marketplaces. Les e-commerçants s’en servent pour alimenter leur repricing, les marques pour vérifier que leurs distributeurs respectent les prix conseillés, les distributeurs pour se positionner rayon par rayon. La veille concurrentielle sur les prix est souvent le premier chantier data d’une PME e-commerce, bien avant la prévision de demande.

Deux approches coexistent. Soit vous passez par un logiciel de veille concurrentielle en SaaS, qui collecte pour vous et intègre le coût du blocage dans son tarif. Soit vous construisez votre propre outil de veille tarifaire, ce qui vous donne la main sur le périmètre et la fraîcheur des données, mais vous rend propriétaire du problème qui suit : les sites cibles ne veulent pas de vous.

Pourquoi les sites e-commerce bloquent la collecte automatisée

Trois raisons se cumulent. La première est comptable : sur les pages catalogue, le trafic automatisé peut peser lourd dans la facture d’infrastructure, pour des visiteurs qui n’achèteront jamais rien. La deuxième est concurrentielle : aucun marchand n’a envie d’alimenter gratuitement le moteur de repricing d’en face. La troisième est patrimoniale : un catalogue structuré, avec ses prix maintenus à jour, est un actif que le droit protège en tant que tel, on y revient plus bas.

Le fichier robots.txt exprime la politique du site vis-à-vis des robots. C’est un protocole standardisé en 2022 par la RFC 9309, mais son respect repose entièrement sur la bonne volonté du client : rien ne force techniquement un collecteur à s’y conformer, et les sites le savent. C’est précisément pour cela qu’ils déploient des défenses actives, souvent via des solutions anti-bot spécialisées, tout en laissant passer les crawlers qui leur apportent quelque chose, à commencer par les moteurs de recherche. Votre collecteur, lui, ne leur apporte rien : il est bloquable sans état d’âme.

Les trois signaux qui déclenchent un blocage

Les systèmes anti-bot ne prennent presque jamais leur décision sur un critère unique. Ils croisent trois familles de signaux.

L’adresse IP. Le type d’adresse se lit dans l’ASN, qui est public : une IP de datacenter s’identifie immédiatement comme telle, et sa réputation est partagée entre tous les sites qui s’abonnent aux mêmes listes. Une adresse qui a déjà servi à collecter ailleurs arrive donc grillée avant votre première requête. La géolocalisation joue aussi : collecter un site français depuis des adresses étrangères fait monter le score de suspicion.

Le rythme. Une requête toutes les x secondes avec la régularité d’un métronome, des centaines de pages produit visitées sans jamais charger une image ni un script, aucun parcours de navigation plausible : tout cela se mesure côté serveur. La réponse polie à un rythme excessif est le code 429 Too Many Requests, défini par la RFC 6585, généralement accompagné d’un en-tête Retry-After. Un collecteur qui ignore ce signal et insiste transforme un simple ralentissement en blocage ferme, et sur notre infrastructure c’est la trajectoire d’échec que nous voyons le plus souvent.

L’empreinte. Le serveur compare ce que votre client annonce et ce qu’il fait réellement : un User-Agent de navigateur récent associé à la poignée de main TLS d’une bibliothèque HTTP, des en-têtes dans un ordre qu’aucun navigateur ne produit, un JavaScript jamais exécuté. Ces incohérences se voient. Nous ne détaillerons pas comment ces empreintes se maquillent : c’est un jeu du chat et de la souris, fragile par nature, et il vous fait glisser d’une collecte assumée vers un contournement difficile à défendre, techniquement comme juridiquement.

Ce que nous observons selon le type d’IP

HexaProxy exploite plusieurs centaines de modems 4G en région toulousaine, sur les réseaux Orange, SFR et Bouygues, avec des ports dédiés. Nous voyons donc passer, jour après jour, les réponses des grands sites e-commerce à des collectes bien réelles, et pas seulement à des tests de laboratoire.

Nous ne publierons pas de pourcentage universel de réussite, parce qu’il n’existe pas : le taux dépend du site cible, de sa solution anti-bot, de votre rythme et de la propreté de votre client. Un fournisseur qui vous annonce un taux de succès global, valable partout, vous vend un chiffre marketing. Ce qui est stable dans nos observations, c’est la hiérarchie : les IP de datacenter sont écartées les premières, les IP résidentielles tiennent mieux, les IP mobiles tiennent le mieux, et l’écart n’est pas marginal.

La raison est structurelle. Sur les réseaux mobiles, l’opérateur partage chaque adresse publique entre de nombreux abonnés simultanés via le CGNAT. Bannir une IP mobile, c’est donc bloquer des clients légitimes en même temps que le robot : les sites le savent et relèvent leurs seuils sur ces plages, préférant des mesures douces au bannissement. Une IP résidentielle, rattachée à un seul foyer, se bloque avec beaucoup moins de dégâts collatéraux. Nous avons détaillé ces différences dans notre comparatif entre proxy résidentiel et proxy 4G mobile.

Soyons clairs sur les limites : une IP mobile ne rend pas fiable une collecte mal conçue. Un port 4G qui martèle une cible finira ralenti comme les autres. La rotation sur demande, telle que nous la proposons sur nos proxys mobiles 4G français, sert à répartir proprement la charge dans le temps, pas à effacer un comportement agressif.

Ce que dit le droit des bases de données

Un prix affiché publiquement n’est pas pour autant librement aspirable en masse. La directive 96/9/CE, transposée aux articles L341-1 et suivants du Code de la propriété intellectuelle, accorde au producteur d’une base de données un droit dit sui generis dès lors qu’il justifie d’un investissement substantiel dans sa constitution ou sa mise à jour, ce qui est plaidable pour la plupart des catalogues e-commerce. Ce droit interdit l’extraction d’une partie substantielle de la base, mais aussi, et c’est le point qui concerne directement la veille tarifaire, l’extraction répétée et systématique de parties même non substantielles quand elle excède l’usage normal du site. Relever quelques prix n’est pas aspirer un catalogue entier chaque nuit.

Deuxième étage : le contrat. La Cour de justice de l’Union européenne a jugé en 2015, dans l’affaire Ryanair contre PR Aviation, que lorsqu’une base n’est protégée ni par le droit d’auteur ni par le droit sui generis, son exploitant reste libre d’en restreindre l’usage par ses conditions générales. Autrement dit, des CGU interdisant la collecte automatisée ne sont pas décoratives.

Troisième étage : les données personnelles. Des prix ne sont pas des données personnelles, mais dès que votre collecte touche une marketplace, les noms de vendeurs et les avis clients en sont. La CNIL a publié une fiche dédiée au moissonnage de données qui conditionne le recours à l’intérêt légitime à des garanties concrètes : minimisation de la collecte, respect des signaux d’opposition, information des personnes. Rien de tout ceci ne remplace l’avis d’un juriste sur votre périmètre précis, mais ces trois étages dessinent la frontière entre une veille défendable et une extraction qui ne l’est pas.

Checklist d’une collecte fiable et conforme

• Réduisez le périmètre au nécessaire. Collectez les références qui influencent réellement vos décisions de prix, à la fréquence que votre repricing exploite vraiment. Un relevé quotidien suffit à la plupart des politiques tarifaires.
• Lisez le robots.txt et les CGU de chaque cible avant de lancer, et documentez votre décision. Si vous implémentez votre propre parseur, la documentation de Google sur son interprétation du robots.txt est une référence utile sur les subtilités de précédence des règles.
• Respectez les signaux du serveur. Un 429 avec Retry-After se respecte à la lettre, avec un backoff qui s’allonge en cas de récidive. Des 403 répétés signifient que le site ne veut pas de vous : insister est le mauvais choix.
• Étalez la charge. Heures creuses, intervalles irréguliers, une file de requêtes par site cible, du cache pour ne jamais redemander une page déjà vue.
• Isolez les réputations. Un port dédié par cible évite qu’un incident sur un site contamine vos autres collectes. C’est l’une des raisons pour lesquelles nous vendons des ports dédiés plutôt que des accès mutualisés.
• Surveillez la qualité avant la disponibilité. Suivez vos taux d’erreur par code HTTP et par cible, mais contrôlez aussi les valeurs : certains sites dégradent les pages servies aux clients suspects avant de les bloquer, et un prix faux est pire qu’un prix manquant. Contrôles de vraisemblance, devise et TVA font partie du pipeline, pas du post-traitement.
• Outillez-vous proprement. Pour l’implémentation, notre guide du web scraping en Python avec un proxy 4G couvre la gestion des sessions, des délais et des erreurs.

Si vous internalisez votre collecte, c’est exactement l’usage pour lequel notre infrastructure est dimensionnée : des IP mobiles françaises réelles, un port dédié facturé à l’abonnement mensuel plutôt qu’au volume, ce qui compte quand on collecte tous les jours, et une rotation déclenchée quand vous en avez besoin. Le plus simple est de tester un proxy mobile 4G sur vos cibles réelles plutôt que de nous croire sur parole.

Google, Ryanair et PR Aviation sont citées à titre d’illustration ou de référence jurisprudentielle ; HexaProxy n’est affilié à aucune de ces marques.