Un scraping prix concurrents fiable ne collecte pas un nombre : il restitue l’offre qu’un acheteur verrait dans un contexte défini. Le choix entre HTTP, données structurées et navigateur vient ensuite. La priorité reste de détecter les relevés plausibles mais faux, bien plus dangereux qu’une extraction qui échoue ouvertement.
Choisir l’architecture du scraping prix concurrents#
La meilleure architecture est la moins complexe capable de restituer l’offre réelle. Si une requête HTTP fournit le produit, son prix et sa disponibilité, lancer un navigateur ajoute du temps d’exécution et des pannes possibles sans enrichir la donnée.
Inspectez d’abord le HTML, les blocs JSON-LD et les réponses JSON chargées par la page. Google documente notamment les propriétés price, priceCurrency et availability du balisage Product et Offer1. Ces éléments offrent souvent un contrat plus stable que la structure visuelle du DOM.
Ils ne constituent pourtant pas une vérité de référence. Un balisage peut rester en cache, ignorer une promotion ou décrire la variante par défaut tandis que la page en affiche une autre. Validez chaque nouvelle source contre le texte rendu sur un échantillon représentatif.
| Mode d’accès | Cas pertinent | Risque dominant |
|---|---|---|
| API ou flux autorisé | L’éditeur fournit des données assez fraîches et complètes | Couverture, quotas ou dépendance contractuelle |
| Requête HTTP | L’offre figure dans le HTML ou une réponse publique stable | Dérive du schéma ou du parseur |
| Navigateur automatisé | Le rendu, la localisation ou une interaction modifient le prix | Temps d’exécution et états d’interface |
| Agent dans le navigateur | Le parcours exige des décisions ou tolère plusieurs chemins | Reproductibilité et validation du résultat |
Une API documentée ou un flux partenaire reste préférable. Une réponse JSON utilisée par le front peut également simplifier la collecte, si ses conditions d’accès le permettent. Un jeton de session ou une route protégée ne devient pas une API publique parce qu’un navigateur sait l’appeler.
Le navigateur se justifie lorsque le prix dépend d’un magasin, d’une adresse, d’une variante ou d’un configurateur. L’agent prend le relais quand le parcours varie sans pouvoir être réduit à une séquence fixe. Dans les deux cas, la sortie doit respecter le même schéma qu’un parseur déterministe, preuves et motifs d’échec compris.
Extraire l’offre, pas la chaîne de caractères#
Un montant tel que 79,99 ne permet aucune comparaison. Il peut correspondre à une mensualité, un acompte, une remise conditionnelle ou la variante la moins chère. Le schéma de données doit donc décrire l’offre avant de stocker sa valeur.
Un relevé exploitable conserve au minimum :
- l’identifiant interne et l’identifiant concurrent, avec GTIN, MPN ou référence fabricant lorsqu’ils existent ;
- la variante exacte : capacité, taille, couleur, état et conditionnement ;
- le prix actif, l’ancien prix éventuel, la devise et le traitement des taxes ;
- les frais de livraison connus et les conditions qui les modifient ;
- la disponibilité, le vendeur et la zone géographique ;
- la règle promotionnelle : code, adhésion, abonnement ou quantité minimale ;
- l’URL canonique, l’horodatage, le mode d’accès et la version de l’extracteur.
La preuve brute complète ce contrat : fragment HTML, réponse JSON ou capture ciblée. Une capture seule se recherche et se compare mal. Une valeur structurée seule devient difficile à défendre lorsqu’un métier conteste une variation. La durée de conservation dépend du besoin d’audit et des contraintes applicables aux données collectées.
Séparez prix_affiché, prix_conditionnel et coût_total_connu. Si le calcul de la livraison exige un code postal absent, ne fabriquez pas un prix livré. Retournez une valeur manquante avec son motif. Cette absence explicite vaut mieux qu’un total précis en apparence, mais incomparable.
Les erreurs sémantiques survivent aux refontes#
Un sélecteur cassé produit souvent une erreur visible. Le cas coûteux est celui qui continue de remonter un nombre valide depuis le mauvais emplacement : prix conseillé, mensualité, produit associé ou option par défaut.
Prenons un exemple hypothétique. Une fiche propose plusieurs capacités sans changer d’URL. Le JSON-LD expose 499 €, alors que la variante demandée affiche 649 € après interaction. Le parseur fonctionne, la donnée passe les contrôles de type, et le relevé reste faux.
Traitez donc la sélection comme une opération à valider. Après l’interaction, relisez le libellé actif, l’identifiant de variante et le prix associé. Si ces éléments ne correspondent pas à la demande, classez le relevé en échec. Le retour silencieux vers la variante par défaut est une corruption, pas une stratégie de repli.
Même exigence pour les promotions. Dans une hypothèse où une remise de 20 % s’applique à partir de 3 articles, le prix promotionnel ne représente pas une baisse unitaire générale. Conservez la règle, la quantité et l’éligibilité. Pour un tarif membre, distinguez l’offre publique de celle qui suppose une adhésion.
Le matching doit posséder son propre score de confiance. Une ressemblance de titre ne compense pas un GTIN différent, un conditionnement incompatible ou du reconditionné comparé au neuf. Le processus de surveillance des prix concurrents dépend d’abord de cette correspondance ; augmenter la fréquence ne corrige jamais un mauvais appariement.
La supervision doit contrôler le sens des données#
Une erreur serveur se repère facilement. Un extracteur qui confond prix conseillé et prix actif peut terminer sans alerte pendant des semaines. Superviser seulement les statuts techniques revient donc à mesurer la disponibilité du pipeline, pas la qualité de ses résultats.
Modélisez trois issues sans les confondre :
observé: l’offre a été extraite et validée ;indisponible: la page répond, mais l’offre n’est plus accessible ;échec: les éléments obtenus ne permettent pas de conclure.
Ne recopiez pas le dernier prix connu dans un nouveau relevé. Vous pouvez l’afficher comme historique avec son véritable horodatage, mais pas le présenter comme une observation fraîche. Cette distinction évite qu’une panne de collecte ressemble à une stabilité tarifaire.
À l’échelle d’une page, contrôlez l’identifiant produit, la devise, les bornes métier et la cohérence entre disponibilité et possibilité d’achat. À l’échelle du site, surveillez le taux d’extraction, la part des promotions, les valeurs absentes et la distribution des prix.
Une grille de départ peut, par hypothèse, alerter lorsqu’un taux de réussite habituel de 98 % tombe à 61 %. Les seuils réels doivent découler de la volatilité de chaque source, pas d’une règle universelle.
Ajoutez des références témoins couvrant les états qui cassent réellement : promotion, rupture, variantes et rendu dynamique. Un seuil initial de 14 jours sans aucune variation sur toutes les références d’un domaine peut signaler une immobilité anormale. Il doit ensuite être ajusté à la fréquence de changement observée.
Reprendre selon la cause, pas selon le symptôme#
Une reprise aveugle amplifie souvent le problème. Réservez les nouvelles tentatives aux délais réseau et aux erreurs serveur transitoires, avec une limite et un délai croissant. Relancer immédiatement une erreur de parsing sur la même réponse ne produit qu’un deuxième échec identique.
Après une anomalie, conservez l’URL finale, le statut HTTP, le type de contenu, les événements réseau utiles et une preuve du rendu. La comparaison avec le dernier succès révèle souvent le changement déterminant : nouveau gabarit, consentement bloquant, redirection locale ou retrait du produit.
La stratégie de repli doit rester explicite. Vous pouvez, par exemple, lire d’abord les données structurées puis vérifier le DOM rendu. Chaque source garde son niveau de confiance. Si deux valeurs se contredisent sans règle permettant de les départager, placez le relevé en quarantaine.
Ce mécanisme dépasse la veille tarifaire. Extraction de catalogues, vérification de mentions, tests de parcours, relevés de stock et contrôle documentaire rencontrent le même problème : une exécution réussie ne prouve pas que l’automatisation a observé le bon objet. Le contrat de sortie change, pas l’exigence de preuve.
Respecter une limite plutôt que l’automatiser#
Le caractère public d’un prix n’accorde pas une permission générale de collecte ou de réutilisation. Les CGU, les droits portant sur les bases de données, la finalité, le volume et la juridiction doivent entrer dans la conception. Les collectes importantes méritent une validation juridique adaptée à leur contexte.
Consultez robots.txt et identifiez le trafic lorsque cela convient au dispositif. Le RFC 93092 définit ce protocole comme un moyen de transmettre des règles aux robots, pas comme un mécanisme d’autorisation. Il ne vaut donc ni licence d’exploitation ni protection technique à franchir.
Un CAPTCHA, une authentification obligatoire, un paywall ou un refus d’accès matérialisent une limite. La bonne réponse consiste à réduire la cadence, obtenir une autorisation, utiliser une interface prévue à cet effet ou retirer la source.
Une collecte peut aussi récupérer des données personnelles sans les viser, notamment sur une place de marché. La CNIL recommande3 de limiter le moissonnage aux données librement accessibles et de prendre en compte les oppositions exprimées par CAPTCHA, robots.txt ou CGU. La minimisation commence dans le schéma : un champ sans usage démontré ne doit pas être collecté.
Sources et références
Montrez la tâche une fois. Anitask la rejoue.
Un agent travaille dans le vrai navigateur, à votre fréquence, et ne vous livre que les changements utiles.
Créer ma première automatisation
