Scraper un site web avec n8n et structurer les données avec l'IA : le guide complet

Surveiller les prix affichés par vos distributeurs, agréger des offres d'emploi de plusieurs sites carrières, suivre les mentions de votre marque sur des sites qui n'exposent aucun flux, vérifier qu'un produit est de nouveau en stock : autant de tâches qui se résument à « lire une page web régulièrement et en extraire trois informations ». Fait à la main, c'est ingrat et vite abandonné. Avec n8n, cela tient en quelques nodes — et l'IA règle au passage le problème historique du scraping : les sélecteurs CSS qui cassent à chaque refonte du site. Ce guide couvre la méthode complète, du cadre légal à poser avant toute chose jusqu'à l'industrialisation avec stockage, alertes et déduplication.

Avant d'écrire le moindre node : légalité et éthique

Le scraping n'est pas une zone de non-droit, et c'est le premier point à traiter — pas le dernier. Un tutoriel académique de Krotov, Johnson et Silva, « Tutorial: Legality and Ethics of Web Scraping », publié en 2020 dans Communications of the Association for Information Systems, propose précisément une grille d'analyse juridique et éthique à dérouler avant tout projet de scraping : que dit le droit applicable, que disent les conditions du site, et quel impact ma collecte a-t-elle sur le site cible et les personnes concernées. En pratique, cela se traduit par quatre réflexes :

• Respecter le fichier robots.txt du site : il indique ce que l'éditeur accepte de voir crawlé. L'ignorer est le plus court chemin vers un blocage — et une position indéfendable en cas de litige.
• Lire les CGU du site. Beaucoup interdisent explicitement l'extraction automatisée ; d'autres la tolèrent pour un usage raisonnable. Vos distributeurs, avec qui vous avez déjà une relation contractuelle, accepteront souvent une veille tarifaire si vous la mentionnez.
• Le RGPD s'applique dès que des données personnelles apparaissent : noms de recruteurs sur une offre d'emploi, auteurs d'avis, adresses email. Une donnée publiquement accessible n'est pas une donnée librement réutilisable — il vous faut une base légale, une durée de conservation et une finalité définies.
• Préférer l'API officielle ou le flux RSS quand ils existent. C'est plus stable, plus rapide, et c'est le canal que l'éditeur a prévu pour vous. Le scraping est le plan B, pas le plan A.

Ajoutez à cela une cadence raisonnable : une requête toutes les quelques secondes, pas cinquante en parallèle. Vous voulez lire une page comme le ferait un visiteur assidu, pas faire subir au serveur cible une charge qu'il n'a pas dimensionnée. Et si un site vous bloque ou affiche un captcha, c'est un signal à respecter, pas un obstacle à contourner.

La méthode simple : HTTP Request + HTML Extract

Pour un site classique rendu côté serveur, deux nodes suffisent. Un node HTTP Request en GET récupère le HTML de la page. Un node HTML (opération Extract HTML Content) applique ensuite des sélecteurs CSS pour en sortir les champs voulus :

• h1.product-title → nom du produit
• .price → prix affiché
• .availability → disponibilité

Chaque sélecteur devient une clé du JSON de sortie, directement exploitable par les nodes suivants. Pour trouver le bon sélecteur, un clic droit → « Inspecter » dans le navigateur sur l'élément visé suffit dans la majorité des cas. Testez avec l'option « Return Array » activée quand la page liste plusieurs éléments (plusieurs offres d'emploi, plusieurs produits) : vous obtenez un tableau que le node Split Out transforme en items individuels.

Cette méthode est gratuite, rapide, et parfaite pour des pages dont la structure bouge peu. Sa faiblesse est connue : le jour où le site change ses classes CSS, l'extraction renvoie des champs vides sans lever d'erreur. D'où l'intérêt de valider la sortie (un IF qui vérifie que le prix n'est pas vide) et d'alerter quand l'extraction échoue.

La limite : les sites rendus en JavaScript

De plus en plus de sites construisent leur contenu côté navigateur : le HTML renvoyé par HTTP Request contient une coquille vide et le contenu utile est injecté par JavaScript après coup. Symptôme typique : vos sélecteurs sont corrects dans l'inspecteur du navigateur, mais le node HTML ne trouve rien. Deux options, dans cet ordre :

1. Chercher l'API JSON que le site appelle lui-même. Ouvrez l'onglet réseau des outils développeur, rechargez la page, filtrez sur XHR/Fetch : vous trouverez souvent un appel qui renvoie exactement les données affichées, déjà en JSON propre. Appelez cette URL directement depuis HTTP Request — c'est plus fiable que tout parsing HTML, et si l'API est paginée, notre guide sur la pagination d'API dans n8n montre comment tout récupérer proprement.
2. Passer par un service de rendu headless externe (Browserless, ScrapingBee et équivalents) : n8n envoie l'URL au service, qui exécute le JavaScript dans un vrai navigateur et renvoie le HTML final, que vous traitez ensuite normalement. Cela ajoute un coût et une dépendance, à réserver aux pages qui le justifient.

L'apport de l'IA : remplacer les sélecteurs fragiles par un LLM

C'est ici que l'approche moderne change la donne. Au lieu de cibler .price-v2__amount--discounted, envoyez le texte de la page (le HTML converti en texte via un node Markdown ou HTML, pour économiser des tokens) à un LLM avec une consigne d'extraction et un schéma de sortie : « extrais le nom du produit, le prix en euros, la date de publication, la disponibilité ; réponds uniquement en JSON ». Un node Structured Output Parser garantit que la réponse respecte le schéma — la mécanique exacte est détaillée dans notre guide du Structured Output Parser.

L'avantage est décisif pour les sources instables : une refonte de la mise en page ne casse rien, puisque le LLM lit le contenu comme un humain, pas la structure du DOM. Les contreparties sont réelles :

• un coût par page — négligeable pour cinquante pages par jour avec un modèle économique, significatif à grande échelle ;
• un risque d'erreur — le modèle peut mal lire un prix barré ou confondre deux dates. Validez donc les champs critiques : un IF qui vérifie que le prix est un nombre dans une fourchette plausible, et une mise en quarantaine (plutôt qu'une insertion silencieuse) quand la validation échoue.

En pratique, la combinaison gagnante est souvent hybride : sélecteurs CSS pour les sites stables que vous contrôlez bien, LLM pour les sources hétérogènes ou changeantes.

Industrialiser : cadence, retry, stockage, alertes

Un scraping utile est un scraping qui tourne tout seul. Le squelette du workflow de production :

1. Schedule Trigger pour lancer le passage une à quelques fois par jour — inutile de scruter toutes les cinq minutes une page de prix qui change une fois par semaine.
2. Boucle sur la liste d'URLs : stockez vos cibles dans une table plutôt qu'en dur, puis itérez avec un node Loop Over Items en insérant un node Wait de quelques secondes entre chaque requête — c'est votre cadence raisonnable de la première section, appliquée concrètement.
3. Retry sur les erreurs HTTP : un site cible peut répondre 503 ou expirer. Activez « Retry On Fail » sur le node HTTP Request avec un délai entre tentatives, et gérez proprement les échecs définitifs — notre article sur les retries et timeouts du node HTTP Request détaille les bons réglages.
4. Stockage : une table Supabase pour les volumes sérieux et les requêtes SQL, ou un Google Sheets partagé quand l'équipe veut consulter les données sans outil supplémentaire.
5. Alerte sur changement : avant d'écrire, comparez la valeur extraite à la dernière valeur stockée. Prix qui bouge chez un distributeur, produit de nouveau disponible, nouvelle offre d'emploi correspondant à vos critères → message Slack ou email immédiat. C'est le même réflexe de routage par seuil que dans notre pipeline de veille concurrentielle par IA.

Dédupliquer entre deux passages : l'idempotence

Un scraping planifié revoit les mêmes pages à chaque passage : sans garde-fou, votre table se remplit de doublons et vos alertes se déclenchent en boucle. La parade est la même que pour les webhooks : donner à chaque résultat une clé stable — l'URL de la fiche, une référence produit, ou un hash du couple source + titre — et poser une contrainte unique dessus dans la base. Avant chaque insertion, un node vérifie si la clé existe : si oui, on met à jour la ligne (et on ne déclenche l'alerte que si une valeur surveillée a réellement changé) ; sinon, on insère. Ce principe d'idempotence, détaillé dans notre article sur l'idempotence et les doublons dans n8n, rend le workflow rejouable sans effet de bord : un passage relancé après un échec ne pollue jamais les données.

Pour aller plus loin

Un pipeline de scraping robuste avec n8n tient finalement en une phrase : un cadre légal vérifié en amont, HTTP Request + HTML Extract pour les cas simples, un LLM avec sortie structurée pour les sources changeantes, et une couche d'industrialisation — planification, pauses, retries, stockage, déduplication — qui transforme le prototype en outil fiable. Ces briques sont exactement celles que nous assemblons dans les workflows FlowKit : la chaîne LLM à sortie structurée et le routage par seuil du Pack Inbox IA s'appliquent tels quels à des données scrapées, et le pipeline de veille décrit plus haut en est le prolongement naturel. Commencez par une seule URL et trois champs, validez la qualité d'extraction sur une semaine, puis élargissez la liste — c'est le chemin le plus court vers une collecte qui tourne sans vous.