Surveiller les prix concurrents en e-commerce avec n8n et l'IA

Un concurrent baisse son prix de 8 % sur votre produit phare un vendredi soir, et vous ne le découvrez que le lundi matin en consultant son site par hasard. Le week-end de conversions perdues ne se rattrape pas. À l'inverse, surveiller manuellement les prix d'une trentaine de concurrents sur plusieurs centaines de références n'est humainement pas tenable au-delà de quelques produits stratégiques. n8n permet de construire ce guet tarifaire sans abonnement à un outil de repricing coûteux : un scraping régulier, une extraction fiable du prix par IA, et une alerte dès qu'un écart franchit votre seuil — la décision finale restant entre vos mains.

Pourquoi la surveillance manuelle des prix échoue vite

Trois limites reviennent systématiquement dès qu'on dépasse la poignée de produits suivis à la main :

• Le temps ne suit pas le volume. Ouvrir dix fiches produit concurrentes chaque matin est faisable ; en suivre cent devient une tâche à temps plein qui n'apporte aucune valeur ajoutée humaine.
• Les prix bougent sans prévenir. Un concurrent qui utilise déjà un algorithme de repricing peut ajuster ses tarifs plusieurs fois par jour — la fenêtre de réaction manuelle est structurellement trop lente.
• L'information arrive incomplète. Un prix relevé sans le contexte (le produit était-il en rupture ? le prix affiché incluait-il une remise ponctuelle ?) conduit à des décisions de repricing fausses.

C'est un problème d'échelle et de régularité, exactement le type de tâche que l'automatisation résout mieux qu'un humain, sur le même principe que notre veille concurrentielle par flux RSS — sauf qu'ici la source n'est pas un article de blog mais un prix affiché sur une page produit, une donnée bien plus volatile et bien plus directement liée au chiffre d'affaires.

Architecture du pipeline de veille tarifaire

Le workflow s'articule en cinq étapes, répétées à intervalle régulier pour chaque référence suivie :

Schedule Trigger (toutes les X heures)
        │
        ▼
Liste des URLs concurrentes à surveiller (Sheets / Supabase)
        │
        ▼
Récupération de la page (HTTP Request ou navigateur headless)
        │
        ▼
Extraction du prix par IA (sortie structurée)
        │
        ▼
Comparaison avec le dernier prix connu
        │
        ▼
Écart > seuil ? ── non ──► mise à jour silencieuse de l'historique
        │ oui
        ▼
Alerte Slack/email + proposition de nouveau prix

La liste des références suivies

Tout part d'une table (Google Sheets pour démarrer, Supabase pour tenir la charge) qui associe chacun de vos produits à une ou plusieurs URLs concurrentes, avec le dernier prix connu et sa date de relevé. C'est cette table, et elle seule, qui fait foi : le workflow ne compare jamais deux relevés entre eux à la volée, il compare toujours au dernier prix enregistré.

Le déclencheur planifié

Un Schedule Trigger interroge la liste à intervalle régulier — quotidien pour la majorité du catalogue, horaire pour une poignée de références stratégiques ou volatiles. Le réglage de la fréquence, du fuseau horaire et des jours ouvrés suit les mêmes principes que ceux détaillés dans notre guide du Schedule Trigger et des fuseaux horaires : mieux vaut un cron explicite et documenté qu'un intervalle approximatif qui dérive avec le temps.

La récupération de la page

Pour un site qui rend son prix côté serveur, un simple node HTTP Request suivi d'un node HTML pour cibler le bloc de prix suffit, sur le principe détaillé dans notre guide d'extraction de contenu avec le node HTML. Beaucoup de sites modernes rendent en revanche le prix côté client en JavaScript : il faut alors un navigateur headless, couvert dans notre guide Browserless et Playwright avec n8n, avec la méthodologie générale — délais, blocages, robots.txt — détaillée dans notre guide de scraping web avec IA dans n8n.

L'extraction du prix par IA

C'est l'étape qui rend le pipeline robuste aux changements de mise en page. Plutôt qu'un sélecteur CSS fragile qui casse à la moindre refonte du site concurrent, un LLM reçoit le HTML brut (ou le texte extrait) de la zone produit et renvoie, via un Structured Output Parser, un objet structuré : prix affiché, devise, présence d'une remise, statut de stock (en stock, rupture, précommande). Un prix relevé sur un produit en rupture ne doit jamais déclencher un ajustement de votre côté — c'est précisément ce que la sortie structurée permet de filtrer avant toute alerte.

La comparaison et le seuil d'alerte

Le nouveau relevé est comparé au dernier prix connu pour le même produit chez le même concurrent, sur le principe déjà détaillé dans notre guide du node Compare Datasets. Un seuil en pourcentage (par exemple 3 %) plutôt qu'en valeur absolue évite de déclencher une alerte pour un centime de différence sur un produit à 8 € tout en restant sensible sur un produit à 800 €.

Alerter plutôt que repricer à l'aveugle

La tentation, une fois le pipeline en place, est de brancher directement le nouveau prix concurrent sur votre propre catalogue via l'API de votre plateforme e-commerce. C'est risqué sans garde-fou : deux algorithmes de repricing qui se répondent en boucle peuvent entraîner les prix vers le bas bien au-delà de ce que la marge supporte, un phénomène documenté par Fisher, Gallino et Li dans leur étude publiée en 2018 dans Management Science (« Competition-Based Dynamic Pricing in Online Retailing: A Methodology Validated with Field Experiments ») : leur expérience en conditions réelles montre qu'une stratégie de meilleure réponse calibrée — et non un ajustement mécanique à chaque mouvement concurrent — a généré 11 % de revenus supplémentaires tout en respectant une marge cible fixée à l'avance. Le repricing gagnant n'est donc pas le plus réactif, mais le plus calibré.

Une seconde étude, publiée en 2025 dans l'International Journal of Research in Marketing par Vomberg, Homburg et Sarantopoulos (« Algorithmic pricing: Effects on consumer trust and price search »), ajoute un angle souvent négligé : la tarification algorithmique dynamique réduit la confiance des clients qui la perçoivent, et allonge la durée de comparaison avant achat. Un repricing trop visible ou trop erratique peut donc coûter en confiance ce qu'il gagne en marge à court terme.

La pratique la plus sûre, en particulier pour une PME sans historique de calibration, consiste à router l'alerte vers un humain avec un prix suggéré plutôt qu'à publier automatiquement :

• Écart faible (sous le seuil) : mise à jour silencieuse de l'historique, aucune alerte.
• Écart significatif : notification Slack ou email avec le produit, l'ancien et le nouveau prix concurrent, la marge résiduelle si vous appliquiez le même prix, et un lien direct vers la fiche produit à modifier.
• Catégories à très faible marge et forte vélocité (produits d'appel, articles saisonniers) : seul cas où un ajustement automatique dans une fourchette pré-validée (plancher et plafond fixés à l'avance) se justifie, une fois le pipeline éprouvé sur plusieurs semaines.

Mettre à jour son propre catalogue

Que la décision soit humaine ou automatisée dans la fourchette autorisée, la mise à jour du prix côté catalogue suit le même chemin que pour toute intégration e-commerce : l'API REST de Shopify, de WooCommerce ou de PrestaShop permet de pousser le nouveau prix en un appel HTTP Request une fois validé. Si vous suivez déjà vos niveaux de stock avec n8n, le même workflow de synchronisation des stocks Shopify est l'endroit naturel où brancher cette mise à jour, plutôt que de créer un troisième pipeline isolé sur le même catalogue.

Fiabiliser le pipeline en production

• Respecter les CGU des sites cibles. Un scraping trop fréquent ou qui ignore le fichier robots.txt expose à un blocage d'IP et pose une question de conformité indépendante de la question technique.
• Gérer les échecs de récupération. Un site qui change de structure ou bloque temporairement votre IP ne doit jamais être interprété comme une rupture de stock : un Error Workflow dédié isole ces cas des relevés valides dans le journal.
• Surveiller le coût des appels IA. Sur un catalogue vérifié quotidiennement, le coût d'extraction par LLM reste modeste avec un modèle économique, mais mérite d'être suivi — notre guide de suivi du coût des appels IA couvre la gestion des quotas applicable ici.
• Conserver l'historique complet. Chaque relevé, pas seulement le dernier, doit rester en base : c'est ce qui permet de repérer une tendance qu'une simple comparaison au relevé précédent ne verrait jamais.

Par où commencer

Choisissez d'abord une dizaine de produits à forte marge ou à forte concurrence directe plutôt que tout le catalogue : le pipeline se règle et se calibre bien plus vite sur un périmètre restreint, et les seuils d'alerte pertinents pour un produit à 800 € ne le sont pas pour un produit à 15 €. Une fois la mécanique — récupération, extraction IA, seuil, alerte — éprouvée sur ce premier lot, l'élargissement au reste du catalogue ne demande qu'à dupliquer la liste des URLs suivies, pas à repenser le workflow. Pour resituer cette veille tarifaire dans une automatisation e-commerce plus large — commandes, stocks, retours — notre guide complet n8n pour l'e-commerce couvre l'ensemble de la chaîne autour de ce point de vigilance concurrentiel.

Le même mécanisme d'extraction structurée par IA à partir d'une page web — scraping, LLM en sortie structurée, seuil de déclenchement — est au cœur du Pack Assistant RAG (119 €), qui applique une logique voisine à l'ingestion de documents plutôt qu'à des pages produit. Pour la traçabilité complète de chaque relevé et de chaque décision de repricing, le Pack Conformité & Audit (149 €) fournit la piste d'audit horodatée déjà prête. Les trois packs réunis dans le Bundle FlowKit Complet (269 € au lieu de 347 € pris séparément) couvrent, au-delà de la veille tarifaire, l'ensemble des cas d'usage IA les plus rentables à automatiser en premier.